FreeRADIUS 3.x package is here! Feedback, please
-
Is it possible to run multiple instances of FreeRADIUS?
I want to run 2 Radius server at once.No, but what would be the use case for that? Why do you believe that you need two instances?
-
This is because I want to have a FreeRadius server for each SSID I have.
I cannot get the user separation working. So having multiple FreeRadius servers can "fix" that.
Of course this setup is not ideal and requires more administration etc but better something than nothing. ;) -
I tried out the FreeRADIUS3 package today. The curious part was that I uninstalled v2 from the GUI, and installed v3, expecting to set up the RADIUS service and enter all the MACs. All the settings and MAC addresses had been retained…. maybe this is an issue? Or there is another uninstall step?
Basically, MacAuth was no joy, as that is the only thing I tested before rolling back to a previous snapshot. RADIUS sends back a REJECT. v2 works like a champ.
Wireless users only with Proxim APs. RADIUS Mac Authentication enabled.
-
I tried out the FreeRADIUS3 package today. The curious part was that I uninstalled v2 from the GUI, and installed v3, expecting to set up the RADIUS service and enter all the MACs. All the settings and MAC addresses had been retained…. maybe this is an issue? Or there is another uninstall step?
That's by design, the GUI parts are nearly identical so the settings all carried over to make the transition easier.
Basically, MacAuth was no joy, as that is the only thing I tested before rolling back to a previous snapshot. RADIUS sends back a REJECT. v2 works like a champ.
Wireless users only with Proxim APs. RADIUS Mac Authentication enabled.
Curious, it works when I try it here. In the FreeRADIUS settings are your MAC addresses in upper or lower case? How are they transmitted from the APs? Perhaps something in the FreeRADIUS backend changed and it's expecting or using a different case now than before.
-
Very good. Glad I didn't miss a step.
FreeRADIUS settings are lower-case, i.e. ab-cd-ef-01-02-03.
pfSense Packet capture: AP>pfSense (FreeRADIUS2):
Username: e4ce8fxxxxxx
Password: 8e5e8b82…....
Called-Station-ID: 00-20-A6-XX-XX-XX
Calling-Station-ID: E4-CE-8F-XX-XX-XX
Message Authenticator: f8e5ecbd......The response, RADIUS>AP is Access-Accept with the Authenticator in all CAPS, and life goes on.
I'll revert back to v3 and repeat the capture a little later and post. Too much going on in the network at the moment.
Curious if formatting is the issue as there are formatting "normalization" routines at work here within the configuration scripts. Or are you referring to the bowels of the implementation?
-
Curious if formatting is the issue as there are formatting "normalization" routines at work here within the configuration scripts. Or are you referring to the bowels of the implementation?
Assuming the normalization is kicking in like it's supposed to… There is a policy in place that should be shifting the Calling-Station-ID to lowercase, but whether or not it's actually happening for your config is another question.
-
There are no differences between the captures, FreeRADIUSv2 versus v3. Everything on the wire is the same, with the exception of the RADIUS response for v3.
v2: Access-Accept
v3: Access-RejectEnvironment:
VMware ESXi 5.5
PfSense 2.3.4_1No hardware, application or environmental differences between the snapshots I am testing, with the exception of FreeRADIUSv2 versus v3
Uninstall v3. Re-install v3. No joy.
Restart radiusd. No joy.
Reboot pfSense. No joy.
Reboot workstation. No joy.
Reboot AP. No joy.Full capture v3:
14:03:37.079733 PROXIM AP > PFSENSE, ethertype IPv4 (0x0800), length 180: (tos 0x0, ttl 64, id 50596, offset 0, flags [none], proto UDP (17), length 166)
172.29.10.61.33996 > 172.29.10.1.1812: [udp sum ok] RADIUS, length: 138
Access Request (1), id: 0x0e, Authenticator: a4b81d694ec4f…............
Username Attribute (1), length: 14, Value: 44d884xxxxxx
0x0000: 3434 6438 3834 ......
Password Attribute (2), length: 18, Value:
0x0000: bd58 76d8 2e10 0ea9 .............
Called Station Attribute (30), length: 19, Value: 00-20-A6-XX-XX-XX
0x0000: 3030 2d32 302d 4136 .........
0x0010: 38
NAS Port Type Attribute (61), length: 6, Value: Wireless - IEEE 802.11
0x0000: 0000 .......
Calling Station Attribute (31), length: 19, Value: 44-D8-84-XX-XX-XX
0x0000: 3434 2d44 382d 3834 ......
0x0010: 39
Connect Info Attribute (77), length: 24, Value: CONNECT 11Mbps 802.11b
0x0000: 434f 4e4e 4543 5420 .......
0x0010: 3032 2e31 ......
Message Authentication Attribute (80), length: 18, Value: ?. 0x0000: 3f95 3c21 3291 d6c7 .............
14:03:38.088976 PFSENSE > PROXIM AP, ethertype IPv4 (0x0800), length 62: (tos 0x0, ttl 64, id 25537, offset 0, flags [none], proto UDP (17), length 48)
172.29.10.1.1812 > 172.29.10.61.33996: [bad udp cksum 0x6ca6 -> 0x7be5!] RADIUS, length: 20
Access Reject (3), id: 0x0e, Authenticator: 2a3e41ab58ca2b53…..........Full capture v2:
14:22:24.796839 PROXIM AP > PFSENSE, ethertype IPv4 (0x0800), length 180: (tos 0x0, ttl 64, id 50598, offset 0, flags [none], proto UDP (17), length 166)
172.29.10.61.33996 > 172.29.10.1.1812: [udp sum ok] RADIUS, length: 138
Access Request (1), id: 0x10, Authenticator: 2afd1eec286178d3d…............
Username Attribute (1), length: 14, Value: 44d884xxxxxx
0x0000: 3434 6438 3834 ...........
Password Attribute (2), length: 18, Value:
0x0000: 4bde 25e9 aa8c 15fa ................
Called Station Attribute (30), length: 19, Value: 00-20-A6-XX-XX-XX
0x0000: 3030 2d32 302d 4136 .............
0x0010: 38
NAS Port Type Attribute (61), length: 6, Value: Wireless - IEEE 802.11
0x0000: 0000 .....
Calling Station Attribute (31), length: 19, Value: 44-D8-84-XX-XX-XX
0x0000: 3434 2d44 382d 3834 .............
0x0010: 39
Connect Info Attribute (77), length: 24, Value: CONNECT 11Mbps 802.11b
0x0000: 434f 4e4e 4543 5420 .............
0x0010: 3032 ..........
Message Authentication Attribute (80), length: 18, Value: ...B.....a.`.4..
0x0000: f2cf de42 ecd0 8a95 fe61 ...........
14:22:24.820913 PFSENSE > PROXIM AP, ethertype IPv4 (0x0800), length 62: (tos 0x0, ttl 64, id 10718, offset 0, flags [none], proto UDP (17), length 48)
172.29.10.1.1812 > 172.29.10.61.33996: [bad udp cksum 0x6ca6 -> 0x5db7!] RADIUS, length: 20
Access Accept (2), id: 0x10, Authenticator: e5ff69f36735f1c8…............ -
Did you try changing your MAC in the user records or MACs tab to upper case instead of lower case?
-
Yes, lower case, ab-cd-ef-01-23-45, does not work for v3 MacAuth, but UPPERCASE MACs, AB-CD-EF-01-23-45, does work with v3 MacAuth.
Thanks for your help!
-
- authentication method: Google Authenticator
- init secret: 16 character long base32 encoded string. (used the same string as above)
- pin: 4 digit numeric pin
User-Password: PIN+OTP code. So in case the PIN was 1234 and 'Google Authenticator' app generated 564782, then 1234564782
[…]
So the key: password is the PIN+OTP.I added some notes to the FreeRADIUS 3 GUI to make this more clear. I also added a button to generate an OTP secret automatically of the correct type for the selected OTP method. So mOTP will generate one in hex (0-9,a-f) and GA will generate one in base32 (A-Z,2-7). I also added buttons to show the secret and PIN so they can stay obscured on the screen unless you want to see them. The secret is automatically displayed when generating a random one, otherwise you'd have no way to view it :-)
I'm also tinkering with a QR code generator for GA, we'll see how that goes tomorrow if I have time.
-
0.12 has a QR Code generator for Google Authenticator and also has some more improvements to the field notes for OTP in general.
-
Yes, lower case, ab-cd-ef-01-23-45, does not work for v3 MacAuth, but UPPERCASE MACs, AB-CD-EF-01-23-45, does work with v3 MacAuth.
Thanks for your help!
I found a problem in the code that writes out the policy files which may have prevented our MAC address normalization from working. Once you update to version 0.13 of the package, please try again with lowercase MAC addresses.
-
0.12 has a QR Code generator for Google Authenticator and also has some more improvements to the field notes for OTP in general.
Just updated to rel. 0.10, Google Authenticator now works great!
Aug 30 00:00:53 radiusd 29529 (0) Login OK: [GOTPTest] (from client apcups port 2) GOOGLEAUTH Aug 30 00:00:53 googleauth.py freeRADIUS: Google Authenticator - Authentication successful for user: GOTPTest
also using "Authy" app!
Well done!! ;D
-
0.12 has a QR Code generator for Google Authenticator and also has some more improvements to the field notes for OTP in general.
Now I'm on 0.13
Seems there is and issue related to QRCODE, It is't recognised by Google Auth. app (and neither by Authy app).
Decoding the qrcode into the string results in this :
otpauth://totp/FreeRADIUS:test_user?secret=ESMN3WTED43NGZ5Z&issuer=FreeRADIUS
where ESMN3WTED43NGZ5Z is correct, It's my Init-Secretps: to generate the qrcode for a new user on FreeRADIUS: Users/Edit/Users you must first create the user, save, then re-open.
![google otp.jpg](/public/imported_attachments/1/google otp.jpg)
![google otp.jpg_thumb](/public/imported_attachments/1/google otp.jpg_thumb) -
It works for me on the GA app, probably the username needs run through urlencode(), maybe that _ is throwing it off.
And you do not have to save a user before it will generate a QR code. Just click the button and it pulls the field values using JavaScript, it doesn't use PHP or anything that loads on save/edit.
-
Actually no, the _ is fine. That same user combination works for me here with the GA app. I copied your secret and username and used them and the resulting QR code worked for me, too, with the code in 0.13. I even scanned your barcode and it worked, too.
I'll add some encoding to be safe, but it doesn't seem to be needed.
-
Works fine here as well.
-
It works for me on the GA app, probably the username needs run through urlencode(), maybe that _ is throwing it off.
And you do not have to save a user before it will generate a QR code. Just click the button and it pulls the field values using JavaScript, it doesn't use PHP or anything that loads on save/edit.
After a lot of tests (using firefox 55.0.3 and ie11, same results) my conclusion is that this issue (Google's Authenticator app doesn't catch the code on the screen) seems to be related to the browser graphic render /antialiasing.
If I save the qr code pic as a file (it's a png pic) and then I open it outside the browser (in the same identical resolution and size) zac! It's catched immediately and recognized. -
you do not have to save a user before it will generate a QR code. Just click the button and it pulls the field values using JavaScript, it doesn't use PHP or anything that loads on save/edit.
On firefox (55.0.3 64bit) I need to save and re-open,
On IE (11) no need to save and re-openMaybe It's related to the fact that on firefox, from rel. 52, the java plugin was dropped?
-
Small typo:
QR Code
Goolge Authenticator supports adding entries via QR Code. Click the button below to generate a QR Code based on the current settings above when Google Authenticator is active. The image can be saved and shown to a user, but treat it as a secure piece of information and do not send it through an insecure channel such as e-mail.