Radius IETF Class Group Assignment - Incorrect Standard
When trying to use the Radius IETF Class(25) attribute to assign pfsense groups for webui administration several industry standard policy servers such as Cisco ISE, Aruba Clearpass, and Windows NPS will convert the string to an octect in accordance with RFC 2865 https://tools.ietf.org/html/rfc2865#section-5.25
Therefore admins becomes 0x61646d696e73
In some implementations of Radius, such as Windows NPS this can be modified to send as string resolving the issue. However in other implementations such as Aruba Clearpass and Cisco ISE the Radius Dictionary is fixed to the vendor ID code (0 for IETF) and modifying the behavior is a global action. Therefore it would break devices who use the Class attribute according to the RFC.
An alternative to a straight bug fix may be one of the following:
1) PFsense could allow the user to specify radius attribute mapping. Citrix takes this approach but it tends to confuse users new to Radius.
2) PFsense could implement group assignment via a more traditional Cisco-AV:Pair mapping. Vendor ID 9 attribute 1.
Updated by Jay Shepherd about 5 years ago
Phillip Hernandez wrote:
I disagree with using Cisco-AV:Pair and believe that using Filter-Id is a better option.
Any particular reason against using Cisco-AV:Pair? It's widely implemented by a lot of vendors both on the Radius Server side and on the client side.
I'm against using Filter-ID as it has the same problem the class attribute has in that the string must be represented as series of octets instead of plain text. Given that the first comment by Jim indicates FreeRADIUS does not correctly transpose to octets for the Class(25) attribute I'm uncertain if it would for Filter-ID.