FreeRADIUS 3.x package is here! Feedback, please
-
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.
-
The QR Code works for others, so it must still be something local to you on your workstation or your browser environment. There is nothing to make it fail before saving. There is no bug there or anything to solve.
The typo is fixed, it will come in whatever version gets pushed next, didn't warrant a bump just for that.
-
Someone broke the package…
/usr/local/etc/raddb/policy.d/pfs_custom_policies[2]: Reference "${policy.mac-addr-regexp}" not found /usr/local/etc/raddb/policy.d/pfs_custom_policies[2]: Parse error expanding ${...} in condition
This should fix the breakage and also the policy: https://github.com/pfsense/FreeBSD-ports/pull/412
-
The QR Code works for others, so it must still be something local to you on your workstation or your browser environment. There is nothing to make it fail before saving. There is no bug there or anything to solve.
The typo is fixed, it will come in whatever version gets pushed next, didn't warrant a bump just for that.
Yes, I agree, definetely It isn't properly a pfsense issue but… one last thing...
Now I changed pfsense theme from "dark beta" (grey background) to the standard (white background) and... no more issue in reading qr codes...
perhaps the gray backgrond color interfere in some way,
there are many components, the monitor type and resolution, the smartphone optic and image sensor... anyway now It works...
maybe will be useful for other users ;) -
Someone broke the package…
/usr/local/etc/raddb/policy.d/pfs_custom_policies[2]: Reference "${policy.mac-addr-regexp}" not found /usr/local/etc/raddb/policy.d/pfs_custom_policies[2]: Parse error expanding ${...} in condition
This should fix the breakage and also the policy: https://github.com/pfsense/FreeBSD-ports/pull/412
That would be me. Though the syntax I used was the same as what was in the stock policy to rewrite MACs. Odd. Anyhow, I merged your version. Hopefully that fixes it for good.
-
Well actually turns out the syntax was good, just the regex was undefined. I just took the one from /usr/local/etc/raddb/policy.d/canonicalization and copied that in place of the variable to avoid any escaping confusion in the heredoc.
-
The QR Code works for others, so it must still be something local to you on your workstation or your browser environment. There is nothing to make it fail before saving. There is no bug there or anything to solve.
The typo is fixed, it will come in whatever version gets pushed next, didn't warrant a bump just for that.
Yes, I agree, definetely It is't properly a pfsense issue but… one last thing...
Now I changed pfsense theme from "dark beta" (grey background) to the standard (white background) and... no more issue in reading qr codes...
perhaps the gray backgrond color interfere in some way,
there are many components, the monitor type and resolution, the smartphone optic and image sensor... anyway now It works...
maybe will be useful for other users ;)Interesting. Is the QR code a transparent image maybe letting the background color bleed through?
-
Interesting. Is the QR code a transparent image maybe letting the background color bleed through?
You can see his screenshot on the previous page. It's still black and white, no transparency. Though it's possible their monitor/display brightness affected it, nothing we can do for that though.
-
@jimp, random thank you for your hard work on this package. I'm happy FreeRADIUS 2 has been retired, and 3 is doing very well.
I'm still having sporadic issues with my laptop losing connectivity to the outside world as described in this thread, and manually reconnecting the laptop to Wi-Fi fixes it. I just can't narrow down what the problem is. It never happened in the FreeRADIUS 2.x package, and it's hard to re-create.
It's like the laptop randomly loses the ability to do anything with hostnames, but it can use IPs just fine. It smells like a DNS issue, but it's weird as heck why I can fix the issue by disconnecting/reconnecting to Wi-Fi and doing a fresh RADIUS query to authorize my laptop to the EAP-TLS network.