Project

General

Profile

Actions

Bug #6086

closed

RADIUS WebUI login does not work with attribute class (25) when the server returns multiple attribute entries with different data

Added by Phillip Hernandez almost 8 years ago. Updated almost 8 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
Web Interface
Target version:
Start date:
04/07/2016
Due date:
% Done:

100%

Estimated time:
Plus Target Version:
Release Notes:
Affected Version:
All
Affected Architecture:
All

Description

After doing several packet capture and reviewing RFC 4372. It seems to be a normal operation to include the class 25 attrib in a response back to the client. This causes 2 of the same type of attribs in the same response. Since this a part of the radius standard to include a class AVP. I suggest that this be changed to filter-id since it is already a string, can be used in this specific use case, and abides by the RFC.

Code that would need to be changed.

/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;
}

Actions #1

Updated by Jim Pingle almost 8 years ago

  • Status changed from New to Needs Patch
  • Priority changed from High to Normal
  • Target version set to Future

Class does work when returned properly by the RADIUS server. If it doesn't work, the RADIUS server isn't returning it properly. While support could be added for an additional attribute for groups, changing it outright to something else would break everyone that is currently working.

It works when used against FreeRADIUS when the user has a reply attribute set similar to:

Class := "admins;VPNUsers" 
Actions #2

Updated by Jim Pingle almost 8 years ago

  • Subject changed from RADIUS WebUI login does not work with attribute class (25) to RADIUS WebUI login does not work with attribute class (25) when the server returns multiple attribute entries with different data
  • Status changed from Needs Patch to Assigned
  • Assignee set to Jim Pingle
  • Target version changed from Future to 2.3.1
  • Affected Version set to All

I was able to reproduce your original issue against an AD server but the fix is not correct. The correct fix is not to use a different attribute, but to check all of the Class responses and not just the last one.

I'll push a fix shortly that will be in 2.3.1, you can apply it to a 2.3 system as a patch if needed. It may also apply to a 2.2.x box but might need some manual adjustment.

Actions #3

Updated by Jim Pingle almost 8 years ago

  • Status changed from Assigned to Feedback
  • % Done changed from 0 to 100
Actions #4

Updated by Phillip Hernandez almost 8 years ago

Can you please add support for another AVP as well? In working systems where the Class AVP is not a string changing its type could cause other adverse affects. In several enterprise radius products this is not a string but an octet array by default.

Changing things outright from what was working is exactly what happen to me when this feature was introduced in the first place :)

Thanks for your help

Actions #5

Updated by Jim Pingle almost 8 years ago

If an additional suitable attribute/AVP is available for this purpose, it would not be difficult to support. "filter_id" as suggested is not for this purpose, it is for ACLs (like firewall rules). That would belong in a separate ticket, however.

With this fix in place it works against FreeRADIUS and AD+NPS (On 2012) without making any fundamental changes to either.

Actions #6

Updated by Phillip Hernandez almost 8 years ago

Ok thanks for your help. I will investigate further and open a separate ticket for adding another AVP.

Thanks

Actions #7

Updated by Phillip Hernandez almost 8 years ago

I wanted to confirm that this works. I created a custom patch to apply to my pfsense boxes that are running 2.2.6 and I am now able to log in without the page error.

Thanks

Actions #8

Updated by Jim Pingle almost 8 years ago

  • Status changed from Feedback to Resolved

Thanks for the additional testing

Actions

Also available in: Atom PDF