Share via

NPS support for Radius Attribute 136 Management-Privilege-Level

Caboose 5 Reputation points
2024-02-23T23:53:03.79+00:00

My org is moving from Cisco network switches to OcNos network switches. I want to continue to authenticate our network admins using radius to manage our data center network equipment but OcNos latest version is now enforcing "Management-Privilege-Level" radius attribute 136 from RFC 5607 RADIUS NAS-Management Authorization. But I can't find or figure out how to add that radius attribute to Microsoft NPS. It was easy with Cisco equipment to just use vendor specific radius attribute 26 to pass the Cisco-AV-Pair shell:priv-lvl=15 value but now hitting a wall to support "Management-Privilege-Level" radius attribute 136. Any advice would be helpful from the community. I am looking at other tools like FreeRadius but was hoping to avoid having to move to another software to get this working.

Windows Network
Windows Network
Windows: A family of Microsoft operating systems that run across personal computers, tablets, laptops, phones, internet of things devices, self-contained mixed reality headsets, large collaboration screens, and other devices.Network: A group of devices that communicate either wirelessly or via a physical connection.
664 questions
Windows Server Infrastructure
Windows Server Infrastructure
Windows Server: A family of Microsoft server operating systems that support enterprise-level management, data storage, applications, and communications.Infrastructure: A Microsoft solution area focused on providing organizations with a cloud solution that supports their real-world needs and meets evolving regulatory requirements.
518 questions

1 answer

Sort by: Most helpful
Most helpful Newest Oldest
  1. Gary Nebbett 5,721 Reputation points
    2024-05-16T16:30:17.6366667+00:00

    Hello All,

    I think that this can be achieved by editing %SystemRoot%\Windows\ias\dnary.xml on the NPS to add the Management-Privilege-Level to the NPS dictionary.

    The FreeRADIUS documentation contains the useful information:

    By default, Ascend NASes send the Ascend specific attributes as NON VSA’s, which conflict with new RADIUS attributes assigned by the IETF. This was a very bad screw-up by Ascend that still causes many headaches, but sometimes we have to live with it, so we try to cope the best we can.

    The out-of-the-box NPS dictionary contains these "bad" Ascend attributes. The Management-Privilege-Level ID (136) corresponds to Ascend-Client-Secondary-DNS. If one adds this attribute from the "Vendor Specific" NPS dialog, then one can effectively add the Management-Privilege-Level attribute.

    Unfortunately, the Ascend-Client-Secondary-DNS attribute definition specifies a syntax of InetAddr and the InetAddr value that would correspond to a value of 15 (0.0.0.15) is not a valid InetAddr.

    One needs to modify the Ascend-Client-Secondary-DNS attribute definition, changing its ID to something else (or delete the attribute definition) and then add a new definition for Management-Privilege-Level.

    After editing the dnary.xml file, one needs to restart IAS and the out-of-process COM server hosting the NPS data store.

    User's image

    For demonstration purposes, I added Ascend attributes 135 and 137, so that one can see their encoding:

    RADIUS: Code = 2, Id = 2
 136 = 00-00-00-0F [....]
 137 = 00-00-00-3E [...>]
 135 = 0C-00-00-0D [....]
 FramedProtocol = 00-00-00-01 [....]
 ServiceType = 00-00-00-02 [....]
 EAPMessage = 03-02-00-04 [....]
 Class = 9C-BC-08-3B-00-00-01-37-00-01-02-00-AC-1F-21-34-00-00-00-00-60-F7-C8-02-18-4F-38-12-01-DA-A7-C7-F8-6A-3C-1D-00-00-00-00-00-00-00-09 [??.;...7....?.!4....`??..O8..????j<.........]
 VendorSpecific = 00-00-01-37-16-4A-01-00-00-00-48-00-00-00-01-00-00-00-01-00-FF-FF-28-00-00-00-01-00-00-00-20-00-00-00-00-00-00-00-01-00-00-00-01-00-00-00-01-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 [...7.J....H.........??(....... ...............................................]
 VendorSpecific = 00-00-01-37-07-06-00-00-00-02 [...7......]
 VendorSpecific = 00-00-01-37-08-06-00-00-00-0E [...7......]
 VendorSpecific = 00-00-01-37-0A-07-01-48-4F-4D-45 [...7...HOME]
 VendorSpecific = 00-00-01-37-10-24-80-0D-86-EC-D9-CA-2B-E1-70-45-AD-9B-4D-75-C8-3F-4B-C6-02-F5-17-9D-E7-B8-2F-D1-86-3B-25-48-7E-5F-B5-74 [...7.$?.????+?pE??Mu??K?.?.???/??;%H~_?t]
 VendorSpecific = 00-00-01-37-11-24-80-0E-72-C0-2A-99-7D-CB-50-F6-72-E2-86-5C-9A-DA-F5-DE-6B-AE-92-B3-22-38-6C-3A-BC-32-1C-56-57-E1-B3-22 [...7.$?.r?*?}?P?r??\????k???"8l:?2.VW??"]
 VendorSpecific = 00-00-01-37-1A-2D-01-53-3D-44-33-38-30-33-33-32-38-44-44-39-45-41-39-43-43-46-30-44-41-38-37-31-35-41-41-36-34-34-31-32-39-34-34-43-37-38-34-32-41 [...7.-.S=D3803328DD9EA9CCF0DA8715AA64412944C7842A]
 Signature = 68-C5-A7-8C-49-D2-06-4E-64-D2-8D-C6-56-53-54-8A [h???I?.Nd???VST?]

    The only thing that can't be easily fixed is the (localized) description text for the attribute - that is stored a resource string in a DLL.

    User's image

    A non-localized Description can be added to the dnary.xml file, but the dnary.xsd schema limits the length of this string to two characters. The schema can be changed, but I chose to set the description to an empty string (to override the out-dated and now incorrect description).

    I have attached the version of dnary.xml that I am now using. I deleted all of the Ascend attributes and also all of the USRobotics attributes, just leaving the Microsoft, Cisco (widely used) and Nortel (nostalgic reasons) vendor specific attributes.

    dnary.xml

    Gary

    0 comments