FreeRADIUS 3.x package is here! Feedback, please
-
As of 0.5.1 the package appears to be reasonably stable and working for a wide variety of situations, and it suitable for wider testing. Feedback is welcome!
Be sure to remove the FreeRADIUS 2.x before attempting to install FreeRADIUS 3.x.
-
As of version 0.6_5, the package is available on 2.3.4, 2.3.x snapshots, and 2.4 snapshots!
Please remember to uninstall freeradius2 before attempting to install freeradius3.
-
FreeRADIUS 3 (0.6.6)
I just did some tests (EAP-TLS for wifi users)
works great! :)I have a question about OTP (Google-Authenticator) configuration: how to generate qrcode (or txt)? And the pin code is a mandatory field also using Google-Authenticator?
Configuring OTP using app like DroidOTP is very easy (user decide for a pin and the mobile app generate a random init string) but how to configure Google-Authenticator?
I didn't find exhaustive info about, here on the forum (but If I'm wrong please let me know) -
I have a question about OTP (Google-Authenticator) configuration: how to generate qrcode (or txt)? And the pin code is a mandatory field also using Google-Authenticator?
Configuring OTP using app like DroidOTP is very easy (user decide for a pin and the mobile app generate a random init string) but how to configure Google-Authenticator?
I didn't find exhaustive info about, here on the forum (but If I'm wrong please let me know)That code was submitted very recently, so it probably still has some issues. I don't think the PIN is mandatory, I've not seen a PIN be required for GA before.
The script says it was from http://www.brool.com/post/using-google-authenticator-for-your-website/ but the code on that site is a bit different.
The original PR for the GA code is https://github.com/pfsense/FreeBSD-ports/pull/357 – I merged it in manually so that's why it shows closed.
-
Thanks for your reply.
Now seems more clear to me:
I need to:- Manually generate a 16digit base32 "secret key" string (Base32 alphabet is: A-Z 1-7), like this for exmple: H2EFO7LD566Q22PB
- On G.A. mobile app add a new user account (username and the 16digit secret key just created)
- On pfsense create a new user in freeradius using the same username and the 16digit in "Init-Secret" field.
Note: "PIN" field in "FreeRADIUS: Users/Edit/Users" seems to be mandatory, I can't leave it empty, error "The 'PIN' field may not be empty when 'Enable One-Time-Password for this user' is checked."
-
Appears that the password field for the LDAP account to use when connecting is not properly escaping or sanitizing input;
radiusd -C -X ... /usr/local/etc/raddb/mods-enabled/ldap[5]: Parse error after <redacted>: unexpected token "}"</redacted> -
Appears that the password field for the LDAP account to use when connecting is not properly escaping or sanitizing input;
radiusd -C -X ... /usr/local/etc/raddb/mods-enabled/ldap[5]: Parse error after <redacted>: unexpected token "}"</redacted>Did that work in FreeRADIUS 2.x or was it also broken there? At the moment I'm only concentrating on regressions in behavior. I'll get around to fixing other issues once the dust settles.
-
Continuing to see issues with the STARTLS
(1) ldap: EXPAND (|(userPrincipalName=%{%{Stripped-User-Name}:-%{User-Name}}@corp.contoso.com)(sAMAccountName=%{%{Stripped-User-Name}:-%{User-Name}})) (1) ldap: --> (|(userPrincipalName=test@corp.contoso.com)(sAMAccountName=test)) (1) ldap: Performing search in "dc=corp,dc=contoso,dc=com" with filter "(|(userPrincipalName=test@corp.contoso.com)(sAMAccountName=test))", scope "sub" (1) ldap: Waiting for search result... rlm_ldap (ldap): Rebinding to URL ldap://corp.contoso.com/CN=Configuration,DC=corp,DC=contoso,DC=com rlm_ldap (ldap): Waiting for bind result... rlm_ldap (ldap): Bind with cn=radius,cn=users,dc=corp,dc=contoso,dc=com to ldap://hypnotoad.corp.contoso.com:389 failed: Strong(er) authentication required rlm_ldap (ldap): Server said: BindSimple: Transport encryption required.. -
Appears that the password field for the LDAP account to use when connecting is not properly escaping or sanitizing input;
radiusd -C -X ... /usr/local/etc/raddb/mods-enabled/ldap[5]: Parse error after <redacted>: unexpected token "}"</redacted>Did that work in FreeRADIUS 2.x or was it also broken there? At the moment I'm only concentrating on regressions in behavior. I'll get around to fixing other issues once the dust settles.
This was working on 2.x; I've created a new user on the LDAP server for the time being with a simpler password to continue testing.
-
Continuing to see issues with the STARTLS
Did you check the new box to use STARTTLS near the bottom? It was assumed before, but it shouldn't have been. Now TLS on its own == TLS on a TLS port (LDAPS), and TLS+STARTTLS does STARTTLS on a traditional LDAP port like you want. Previously it was impossible to configure plain TLS.
/usr/local/etc/raddb/mods-enabled/ldap[5]: Parse error after <redacted>: unexpected token "}"</redacted>This was working on 2.x; I've created a new user on the LDAP server for the time being with a simpler password to continue testing.
Can you check how that password was formatted in the actual configuration file(s) on 2.x vs 3.x? It may be too late now. It's difficult for me to test every permutation of all these settings.
-
Continuing to see issues with the STARTLS
Did you check the new box to use STARTTLS near the bottom? It was assumed before, but it shouldn't have been. Now TLS on its own == TLS on a TLS port (LDAPS), and TLS+STARTTLS does STARTTLS on a traditional LDAP port like you want. Previously it was impossible to configure plain TLS.
/usr/local/etc/raddb/mods-enabled/ldap[5]: Parse error after <redacted>: unexpected token "}"</redacted>This was working on 2.x; I've created a new user on the LDAP server for the time being with a simpler password to continue testing.
Can you check how that password was formatted in the actual configuration file(s) on 2.x vs 3.x? It may be too late now. It's difficult for me to test every permutation of all these settings.
I don't have the 2.x config anymore; I can try and reinstall and check later. Below is a slightly redacted sample of my ldap config, please note that the password was not quoted before I redacted.
Packet captures do show that a TLS session is established to the LDAP server on 389 with clear text communication interleaved.
ldap { server = "hypnotoad.corp.contoso.com" port = "389" identity = "cn=radius,cn=users,dc=corp,dc=contoso,dc=com" password = <redacted>base_dn = "dc=corp,dc=contoso,dc=com" user { base_dn = "${..base_dn}" filter = "(|(userPrincipalName=%{%{Stripped-User-Name}:-%{User-Name}}@corp.contoso.com)(sAMAccountName=%{%{Stripped-User-Name}:-%{User-Name}}))" ### access_attr = "dialupAccess" ### } group { base_dn = "${..base_dn}" filter = '(objectClass=posixGroup)' ### name_attribute = cn ### ### membership_filter = "(|(&(objectClass=GroupOfNames)(member=%{control:Ldap-UserDn}))(&(objectClass=GroupOfUniqueNames)(uniquemember=%{control:Ldap-UserDn})))" ### ### membership_attribute = radiusGroupName ### ### compare_check_items = yes ### ### do_xlat = yes ### ### access_attr_used_for_allow = yes ### } profile { filter = "(objectclass=radiusprofile)" ### default_profile = "cn=radprofile,ou=dialup,o=My Company Ltd,c=US" ### ### profile_attribute = "radiusProfileDn" ### } tls { start_tls = yes ca_file = /usr/local/etc/raddb/certs/ca_ldap1_cert.pem ca_path = /usr/local/etc/raddb/certs/ certificate_file = /usr/local/etc/raddb/certs/radius_ldap1_cert.crt private_key_file = /usr/local/etc/raddb/certs/radius_ldap1_cert.key random_file = /dev/urandom require_cert = "never" }</redacted> -
Hmm, the password formatting is identical between versions. Their parser must have changed.
Can you try this patch?
diff --git a/usr/local/pkg/freeradius.inc b/usr/local/pkg/freeradius.inc index 87753d6..418b28a 100644 --- a/usr/local/pkg/freeradius.inc +++ b/usr/local/pkg/freeradius.inc @@ -2725,7 +2725,7 @@ function freeradius_modulesldap_resync($restart_svc = true) { $varmodulesldapserver = ($arrmodulesldap['varmodulesldapserver'] ?: 'ldap.example.com'); $varmodulesldapserverport = ($arrmodulesldap['varmodulesldapserverport'] ?: '389'); $varmodulesldapidentity = ($arrmodulesldap['varmodulesldapidentity'] ?: 'cn=admin,o=My Company Ltd,c=US'); - $varmodulesldappassword = ($arrmodulesldap['varmodulesldappassword'] ?: 'mypass'); + $varmodulesldappassword = (escapeshellarg($arrmodulesldap['varmodulesldappassword']) ?: 'mypass'); $varmodulesldapbasedn = ($arrmodulesldap['varmodulesldapbasedn'] ?: 'o=My Company Ltd,c=US'); $varmodulesldapfilter = ($arrmodulesldap['varmodulesldapfilter'] ?: '(uid=%{%{Stripped-User-Name}:-%{User-Name}})'); $varmodulesldapbasefilter = ($arrmodulesldap['varmodulesldapbasefilter'] ?: '(objectclass=radiusprofile)'); @@ -2738,7 +2738,7 @@ function freeradius_modulesldap_resync($restart_svc = true) { $varmodulesldap2server = ($arrmodulesldap['varmodulesldap2server'] ?: 'ldap.example.com'); $varmodulesldap2serverport = ($arrmodulesldap['varmodulesldap2serverport'] ?: '389'); $varmodulesldap2identity = ($arrmodulesldap['varmodulesldap2identity'] ?: 'cn=admin,o=My Company Ltd,c=US'); - $varmodulesldap2password = ($arrmodulesldap['varmodulesldap2password'] ?: 'mypass'); + $varmodulesldap2password = (escapeshellarg($arrmodulesldap['varmodulesldap2password']) ?: 'mypass'); $varmodulesldap2basedn = ($arrmodulesldap['varmodulesldap2basedn'] ?: 'o=My Company Ltd,c=US'); $varmodulesldap2filter = ($arrmodulesldap['varmodulesldap2filter'] ?: '(uid=%{%{Stripped-User-Name}:-%{User-Name}})'); $varmodulesldap2basefilter = ($arrmodulesldap['varmodulesldap2basefilter'] ?: '(objectclass=radiusprofile)');As for STARTTLS I can't really comment on that behavior. I'd expect the initial exchange to be plain until STARTTLS kicked in and then it should be encrypted, but it looks like we're setting all the correct options, it may also be something in FreeRADIUS 3.x that changed.
I don't have a viable test setup for LDAP-backed connections, I'd have to try to rig one up and test more.
-
I'll give that a shot and report back as soon as I can; pulled to another issue at the moment.
-
That patch does appear to have resolved the issue with the password contents according to radiusd -C -X; not sure whether it's transmitting correctly to the LDAP server yet.
-
Disabling STARTLS and moving to 636 has resolved further issues. I am still having LDAP integration issues and may need to modify some config files by hand.
-
Setup a WPA2-EAP SSID for testing works fine.
Thought I'd have a play with accounting.
One thing that would be nice would be changing the port when you change the interface type, ie changing from Auth to Accounting the port stays on 1812 rather than changing to 1813
Not sure if this was the same with V2.
-
That patch does appear to have resolved the issue with the password contents according to radiusd -C -X; not sure whether it's transmitting correctly to the LDAP server yet.
I just pushed an update that contains the patch (and that's the only change), so next time you update that your password should keep working.
-
Hi guys,
great job. Thanks for developing. I've test the google authentificator otp while using OpenVPN with freeradius. First i was a little bit confused, because i expected an automatic generated init secret-code and don't know what i had to type in. After reading in this topic i found out, that i've to create an base32 code. Now it runs glad. It would be nice, if the secret-code will be generated automaticaly und an icon is behind the input-bar, so that there could be generated another one, if you click to them.
Sencond it would be fantastic if it would possible to login with freeradius and otp in the webgui.
Many thanks and great job.
Chris
-
Just switched over from FreeRADIUS 2 to 3 - upgrade went smooth and everything appears to be working just fine. Thanks for all your hard work on this.
-
Unfortunately upgrading to Version 3 breaks authentication enitrely for me.
I uninstalled Version 2 and installed version 3.
I'm using local users i.e. no sql or ldap.For Users authenticating with a username password (Cleartext) I get the following error:
(98) Login incorrect (mschap: FAILED: No NT/LM-Password. Cannot perform authentication): [USERNAME] (from client NAS port 15 cli XX-XX-XX-XX-XX-X via TLS tunnel)Devices that do not support 802.1x and which get authenticated with their MAC-Address as username and password, I get the follwoing error:
(103) Login incorrect (Failed retrieving values required to evaluate condition): [MAC_ADDRESS] (from client NAS port 23 cli XX:XX:XX:XX:XX:XX)Until I figure this out I have reverted to Version 2.
