[Solved] Radius - Access WebUI
-
I found thanks to this link.
https://redmine.pfsense.org/projects/pfsense/repository/revisions/709c2f99f1bf99022ee8ba670cfd8025e2c71592the files are in /etc/inc/ and not in /etc/
-
Your RADIUS server needs to return the groups in the CLASS attribute as a string separated by semicolons (e.g. "admins;group2;group3")
The same groups must exist on pfSense with identical names, and the groups must have privileges assigned to them for what they should be able to access.
-
I have tried this setup with my windows nps and have a test client to confirm that this is being passed via radius, but pfsense is still giving the no page assigned to user. Please help!
-
But how is it being passed from RADIUS? As a string? Or encoded in some way (Octal, binary, etc)?
-
As a string I believe. I can read it via the test client. I'll take a screen shot for ya.
-
I see this is set as solved but what was the actual resolution?
I can add the class attribute (25) but the attribute value is set as OctetString, I enter my AD group in as a String value. I also have the exact same group name set up on the pfsense. When I log in, I can see I get authenticated off my Radius server but it just says no pages for this user. So it's still not getting the groups from AD it appears.
What do I need to change to make it work?
-
I have this same problem. I have verified that the radius server is sending class (25) as a string with the group name. Was this tested by the devs? What is the best way to debug this?
-
After doing a packet capture. I can see that the packet actually contains 2 class 25 attribs… One with the name of the group and the other that contains accounting information.
After looking at https://tools.ietf.org/html/rfc4372 this seems to be a normal operation of the RADIUS server.
I suspect that pfSense has not taken this into account when it is looking at the attribs?... Can anyone confirm my findings?
-
EDIT: See post by jimp below for proper fix
I ended up "fixing" it by switching to another attrib which is filter-id
I edited file:
/etc/inc/auth.inc/* $attributes must contain a "filter_id" key containing the groups and local groups must exist to match. */ function radius_get_groups($attributes) { $groups = array(); if (!empty($attributes) && is_array($attributes) && !empty($attributes['filter_id'])) { $groups = explode(";", $attributes['filter_id']); foreach ($groups as & $grp) { $grp = trim($grp); if (strtolower(substr($grp, 0, 3)) == "ou=") { $grp = substr($grp, 3); } } } return $groups; }filed bug: https://redmine.pfsense.org/issues/6086
-
We do testing for this but generally against FreeRADIUS only in the majority of cases (we prefer to keep things OSS where possible), and FreeRADIUS had been working.
Using the System Patches package you can apply the following commit to fix issues with the processing of the Class attribute from AD and some other servers.
https://github.com/pfsense/pfsense/commit/461bae6b08d883d232db853a21337e688c1defee.patch
With that patch in place, it works for me with FreeRADIUS and AD+NPS (2012).
-
Thank you jimp! I really appreciate you coming up with a fix so quickly.
-
Just confirming that using Class attribute is an issue with some RADIUS servers, possibly due to the extra Class attribute in the Access-Accept.
By the way, Filter-ID is a more industry-standard way of applying a role via RADIUS so would be a better default choice.
One other thing - NAS-IP address is always set to 0.0.0.0 in the Access-Request. This is not great practice, can we allow the user to choose one of the PFSense IP addresses for this field. Will assist with differentiating PFSense requests from others on busy RADIUS servers.
Will try patch and provide feedback :)
-
Patch works :) :) :)
v2.2.6
-
@yrebrac - your patch to set the NAS-IP to a different value, was that merged into the project? I am running into a problem where the RADIUS server I am using will not accept 0.0.0.0 as the NAS-IP. I am running the latest 2.3.1 release. Can you post the diff?
Patch works :) :) :)
v2.2.6
