Feature #935
closedUser manager RADIUS authentication method
100%
Description
pfsense 2.0 has the new radius authentication method, but the code has no way to assign privileges to the radius users.
I was able to bypass this with a crude hack:
/etc/priv.inc line 249-272
(snip..) function getAllowedPages($username) { global $config, $_SESSION; if (!function_exists("ldap_connect")) return; $allowed_pages = array(); $allowed_groups = array(); $authcfg = auth_get_authserver($config['system']['webgui']['authmode']); // obtain ldap groups if we are in ldap mode if ($authcfg['type'] == "ldap") { $allowed_groups = @ldap_get_groups($username, $authcfg); } else if ($authcfg['type'] == "radius") { $allowed_groups = array('RadiusAuthenticated'); } else { // search for a local user by name $local_user = getUserEntry($username); getPrivPages($local_user, $allowed_pages); // obtain local groups if we have a local user if ($local_user) $allowed_groups = local_user_get_groups($local_user); } (snip...)
/etc/auth.inc line 1084-1110
function getUserGroups($username, $authcfg) { global $config; $allowed_groups = array(); switch($authcfg['type']) { case 'ldap': $allowed_groups = @ldap_get_groups($username, $authcfg); break; case 'radius': $allowed_groups = array('RadiusAuthenticated'); break; default: $user = getUserEntry($username); $allowed_groups = @local_user_get_groups($user, true); break; } $member_groups = array(); if (is_array($config['system']['group'])) { foreach ($config['system']['group'] as $group) if (in_array($group['name'], $allowed_groups)) $member_groups[] = $group['name']; } return $member_groups; }
and then creating a group called RadiusAuthenticated and assigning privileges to that group.
Updated by Chris Buechler about 14 years ago
- Category set to User Manager / Privileges
- Target version set to 2.0
- Affected Version set to 2.0
Updated by Ermal Luçi about 14 years ago
- Status changed from New to Feedback
You can create the same user locally and assign it to groups that should work iirc.
Never tested though.
Updated by Chris Buechler almost 14 years ago
- Tracker changed from Bug to Feature
- Subject changed from Radius Authentication method to User manager RADIUS authentication method
- Status changed from Feedback to New
- Target version changed from 2.0 to Future
Updated by Jim Pingle over 9 years ago
At the moment we don't appear to attempt to determine the group from RADIUS to support this. Looks like maybe we could use the "Class" reply attribute which should contain a string in the format "OU=Groupname" or at least "Groupname". It may not be too difficult to grab, though it would need to be populated by the RADIUS server.
Updated by Jim Pingle over 9 years ago
- Status changed from New to Feedback
- % Done changed from 0 to 100
Applied in changeset 709c2f99f1bf99022ee8ba670cfd8025e2c71592.
Updated by Jim Pingle over 9 years ago
Applied in changeset c4a9f99a8d79e201b2af5053a095c83bb1a26467.
Updated by Jim Pingle over 9 years ago
- Assignee set to Jim Pingle
- Target version changed from Future to 2.2.5
- Affected Architecture All added
- Affected Architecture deleted (
)
Turned out to be a relatively minor/safe change. Unlike LDAP, RADIUS would fail to grab the groups if a second query was attempted.
To take advantage of this the RADIUS server must return the groups back in the Class attribute (25). This is supported easily by FreeRADIUS and Windows (NPS with some adjustments). Multiple groups may be specified if they are separated by a semicolon, and the groups can be specified by name directly or prefixed with "ou=" to be compatible with some Cisco and Cisco-like recommendations.
As with LDAP the groups must exist locally and privileges are specified on the local groups.
Updated by Jim Pingle about 9 years ago
- Status changed from Feedback to Resolved
This works everywhere I've tried it, even on the bootstrap branch.
Updated by Paul Evans about 9 years ago
Jim P wrote:
This works everywhere I've tried it, even on the bootstrap branch.
I can confirm that it works in the GUI authentication under Diagnostics. I also tried it to assign permissions for VPN IPSec Xauth Dialin. Whilst it authenticates the user OK, it doesn't pick up the permissions set for the Group under User Manager of the same name as the one in the Class attribute of the user in Radius and therefore drops the IPSec tunnel
Updated by Jim Pingle about 9 years ago
That sounds more like a bug with the IPsec auth permission code -- can you open that as a separate ticket rather than adding it on here?
Updated by Elliot Smith about 9 years ago
Jim P wrote:
Turned out to be a relatively minor/safe change. Unlike LDAP, RADIUS would fail to grab the groups if a second query was attempted.
To take advantage of this the RADIUS server must return the groups back in the Class attribute (25). This is supported easily by FreeRADIUS and Windows (NPS with some adjustments). Multiple groups may be specified if they are separated by a semicolon, and the groups can be specified by name directly or prefixed with "ou=" to be compatible with some Cisco and Cisco-like recommendations.
As with LDAP the groups must exist locally and privileges are specified on the local groups.
Can you Please specify what adjustments are needs for Windows NPS? I updated to 2.2.5 and users cannot logon to the web UI to manage the firewall anymore.
Updated by Jim Pingle about 9 years ago
I don't have that setup handy any more but IIRC it was something about making NPS send the Class as a string and not as binary -- start a thread on the forum to discuss rather than here.