LDAP and RADIUS Fixes/Enhancements - 2.2.5
-
This applies to multiple areas so I'll drop it here: Working on RADIUS and LDAP auth items for the hangout this month I ran across a few issues that were in need of fixes. I committed changes to 2.2.5 and some extra testing would be appreciated. Most of these are geared toward GUI auth. Not all of this is in 2.3 yet because of the pending bootstrap merge.
1. RADIUS for GUI Authentication – Previously did not work because we did not have a way to obtain group information from RADIUS. I fixed up our RADIUS code to pull group information from the RADIUS attribute "Class" which the server will return in a reply. I've seen it used in the same manner by Cisco equipment for groups. Seems to work OK for me. Like with LDAP, make a group locally and assign it privileges and then have your RADIUS server return the same group in the Class attribute. For example in the FreeRADIUS2 package you can add this to the "Additional RADIUS Attributes (REPLY-ITEM)" box:
Class := "admins;VPNUsers"If those groups exist on pfSense, then the user will be considered a member of those groups. Once the group and privilges are in place, the RADIUS server could be used for GUI authentication.
2. GUI slow/unusable if the LDAP server is down/unreachable – I added a timeout field to the LDAP server settings to help with this. Set it to a low-ish value (e.g. 10-30 seconds) and things are much better. Previously one had to wait about 1 minute 20 seconds for the LDAP query to timeout before it would fall back to local authentication. Some of the other fixes on the ticket made compromises in security or complexity, seemed like a better tradeoff to time out faster.
3. RFC 2307 style groups for LDAP – The default group membership behavior of the GUI looks for groups in Active Directory (RFC 2307bis) style, that is where the groups are listed on each user in a field such as memberOf. This new GUI option allows plain RFC 2307 style groups where the members are listed on the group objects instead of the other way around. It does require filling in another new field to specify the group object class, which is typically "posixGroup" or "group" (varies by LDAP schema). Make sure the group member attribute is correct also, it may be "memberUid" and not just "member", again depending on the schema.
-
2. GUI slow/unusable if the LDAP server is down/unreachable – I added a timeout field to the LDAP server settings to help with this. Set it to a low-ish value (e.g. 10-30 seconds) and things are much better. Previously one had to wait about 1 minute 20 seconds for the LDAP query to timeout before it would fall back to local authentication. Some of the other fixes on the ticket made compromises in security or complexity, seemed like a better tradeoff to time out faster.
I havent looked to see if its hardcoded or not, but making this a system tunable/option/setting always gives users the choice.
-
2. GUI slow/unusable if the LDAP server is down/unreachable – I added a timeout field to the LDAP server settings to help with this. Set it to a low-ish value (e.g. 10-30 seconds) and things are much better. Previously one had to wait about 1 minute 20 seconds for the LDAP query to timeout before it would fall back to local authentication. Some of the other fixes on the ticket made compromises in security or complexity, seemed like a better tradeoff to time out faster.
I havent looked to see if its hardcoded or not, but making this a system tunable/option/setting always gives users the choice.
(bolded for emphasis) – it's a user-configurable per-server option.
-
2. GUI slow/unusable if the LDAP server is down/unreachable – I added a timeout field to the LDAP server settings to help with this. Set it to a low-ish value (e.g. 10-30 seconds) and things are much better. Previously one had to wait about 1 minute 20 seconds for the LDAP query to timeout before it would fall back to local authentication. Some of the other fixes on the ticket made compromises in security or complexity, seemed like a better tradeoff to time out faster.
I havent looked to see if its hardcoded or not, but making this a system tunable/option/setting always gives users the choice.
(bolded for emphasis) – it's a user-configurable per-server option.
Sorry that bit didnt register. Thanks for pointing it out.
-
Ive been trying to get RADIUS to work lately. I can get user authentication to work, but the groups dont seem to come through. My radius server is a QNAP TS-859U RP+ I have made the same local groups in pfsense. Not sure if this is a limitation of the QNAP's RADIUS server, or if I have managed to miss a configuration.
Thoughts?
-
Run a packet capture on the RADIUS traffic, see if it's sending back the Class attribute in the reply. And if it is, see if it's in plain text (good) or binary (bad)
-
I am not sure how to do that. Is it something I can do through the pfsense installation?
Thanks for the quick reply Jim!
-
I set up my workstation as a RADIUS client and use radtest for that. Looking at the plain response usually speeds troubleshooting.
It would be nice if the RADIUS auth test could display the request and any reply.
-
I have a pair of pfSense boxes that I use for our guest networks. Up until 2.2.4 RADIUS authentication for the Web GUI was working fine. It appears 2.2.5 broke it and even trying several variations of the "Class" attribute doesn't seem to help. The RADIUS servers are Windows 2012 R2 NPS servers.
Is there a patch on the way? Can the pfSense team revert to the pre- 2.2.5 code? I never had to worry about group info before….the setup was using the users I entered and local groups to determine permissions. The only thing RADIUS was doing was making sure the user account existed in the directory and verify the password that was entered is correct.
Thomas
