Note: A product listed in this article has either reached hardware End of Life (EOL) OR software End of Engineering (EOE). Refer to End of Life Products & Milestones for the EOL, EOE, and End of Support (EOS) dates.
This article provides information on how to configure FreeRADIUS to authenticate and authorize a NSM user.
How to configure FreeRADIUS to authenticate and authorize an NSM user.
The following role assignment scheme via RADIUS works well till NSM 2010.2 (including NSM 2010.2). Any version later than NSM 2010.2, including the 2010.2_nXX patches, includes a change of behavior in the way NSM handles remote user authorization. Due to this, the custom roles mentioned below might result in unexpected results; including logon failure to the NSM GUI. The issue has been fixed in 2012.1R10 and 2012.2R6. All subsequent releases contain the fix.
It is possible to have NSM authenticate and assign a role to a user who is trying to log on to the NSM GUI via RADIUS. In this scenario, the NSM server will be the RADIUS client.
This is different from the normal authentication via RADIUS, as the role to be assigned to the user is also specified by the RADIUS server, unlike when the user's role is configured locally on the NSM server and the NSM contacts RADIUS just for authenticating the user.
Assigning a role to a user is known as Authorization. The role returned by the RADIUS server on successful authentication must be pre-configured on the NSM server. The role on NSM could be either pre-defined or custom.
To allow the RADIUS server inform the NSM server of the role for a user, it must be configured with the Vendor Specific Attributes (Radius VSA), which the NSM server will understand. For this purpose, there are two NSM VSAs, as listed below:
-
NS-NSM-User-Domain-Name
- NS-NSM-User-Role-Mapping
These two attributes must be included in the dictionary.netscreen NetScreen dictionary file, as shown below. The first line is a comment. Add these lines after the existing attributes and before the END-VENDOR NetScreen line in the file.
# For NSM
ATTRIBUTE NS-NSM-User-Domain-Name 220 string
ATTRIBUTE NS-NSM-User-Role-Mapping 221 string
If the FreeRADIUS' users file is being used to store the user's password, then type the following (a sample configuration for a user with the System Administrator role in the global domain is given below):
"testuser" Auth-Type := Local, User-Password == "netscreen"
NS-NSM-User-Domain-Name = global,
NS-NSM-User-Role-Mapping = "global:System Administrator"
This will enable FreeRADIUS to include the NS-NSM-User-Domain-Name and NS-NSM-User-Role-Mapping attributes with the specified values in the Radius Accept response to the NSM. The System Administrator role is pre-defined on the NSM.
If a custom role is used, then the NS-NSM-User-Role-Mapping attribute's value should be stated as domain:domain.custom role
. For example, for a custom role with the FW-Admin name, for the global domain, the attribute's value should be global:global.FW-Admin. For a subdomain, the domain should be stated as global.subdomain
. For example:
Subdomain "FireWall", custom role "FW-Admin"
NS-NSM-User-Domain-Name = global.FireWall,
NS-NSM-User-Role-Mapping = "global.FireWall:global.FireWall.FW-Admin"
In the above example, the user is expected to logon to the GUI client as <subdomain>/<username>, which in this case would be FireWall/<username>. This is because the Domain-Name attribute has the global.FireWall global subdomain name.
For additional examples of various combinations of roles and domains, refer to the NSM Administration Guide.
Note: If multiple NS-NSM-User-Role-Mapping attributes are used , use +=, instead of =, for each additional line.
The rest of the configuration on FreeRADIUS, such as configuring the NSM as a RADIUS client via the clients file and so on, remains the same as it is for other RADIUS clients.
2020-10-18: Tagged article for EOL/EOE.