[Solved] Radius - Access WebUI

jimp

But how is it being passed from RADIUS? As a string? Or encoded in some way (Octal, binary, etc)?

mcrook

As a string I believe. I can read it via the test client. I'll take a screen shot for ya.

Cobham_cos

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?

phillipah

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?

phillipah

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?

phillipah

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

jimp

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).

phillipah

Thank you jimp! I really appreciate you coming up with a fix so quickly.

yrebrac

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 :)

yrebrac

Patch works :) :) :)

v2.2.6

poma187

@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