This mode authenticates the user in a remote server. Prime Cable Provisioning uses Radius and TACACS for remote authentication.
Radius Authentication
The RDU supports externalizing authentication to a remote Radius server. The user need not have an account in the RDU database. However, a reliable batch submitted by a Radius-only user cannot be guaranteed to execute across reboots or when the user logs out. This applies to those users that do not have their privileges defined in the RDU account but are only provided by remote Radius.
Radius authentication support can be configured using the Admin UI (Configuration > Defaults > RDU Defaults). To leverage Radius, a primary Radius server must be configured. This following properties must be provided: Primary Host, Primary Shared Secret, Primary Port (default=1812), Timeout (default=1000ms), Retries (default =1). If not specified, authentication will fail.
A secondary Radius server can also be configured. Only in the event the primary server is not available the secondary server is consulted to authenticate the user. The primary and secondary Radius servers support the same set of users.
Radius is a UDP-based protocol that supports centralized authentication, authorization, and accounting for network access. Radius authentication involves authenticating the users accessing the network services via the Radius server, using the Radius standard protocol defined in RFC 2865.
Radius authentication are of two modes and they are as follows:
In this mode, username and password are required to log on to RDU which must be configured in Radius server.
Note |
For the users authenticated via Radius, the password can be changed only in the Radius server.
|
In this mode, username and passcode are required to log on to RDU. The username and assigning RSA SecureID Token to user must be configured in RSA Authentication Manager. The RSA SecureID generates the TokenCode which will be updated every 60 seconds in the RSA SecureID Token. The combination of TokenCode and the pin associated with the RSA SecureID Token will be used as the passcode of the user.
For example, if the PIN associated with the RSA SecureID token is 'user' and the Token Code generated from the RSA SecureID token is '12345', then the passcode is 'user12345'.
Note |
Changing the combination order of the passcode from Token Code and PIN will result in authentication failure. The PIN for the RSA SecureID tokens must be assigned in RSA Authentication Manager through RSA Authentication Agents.
Creating or modifying a PIN for RSA SecureID token can be done via RSA Authentication Manager.
|
To enable Radius authentication, the authentication mode must be configured in the RDU Defaults page. For more details, see RDU Defaults.
Radius Integration
Prior to Prime Cable Provisioning, the property /rdu/auth/mode could take the value, LOCAL or Radius indicating which mode of authentication is enabled. With Prime Cable Provisioning, this is changed and the local mode is always enabled. /rdu/auth/mode is only used to enable or disable Radius authentication. If enabled, the external Radius servers are always used for authentication. If the servers fail to respond or reject the user, local authentication is attempted.
For Radius authenticated user, Prime Cable Provisioning supports granting privileges, sessions allowed, and domains to users through the Cisco-AVPair Radius VSA. The Radius Access-Accept can contain zero or more Cisco-AVPair VSA. The supported Cisco-AVPair format is:
Usergroup
Format: cp:groups=<group1>,…<groupN>
Takes zero or more user group names.
If no user group is assigned, the user is not granted any privileges.
First it checks for mapping. If external to internal user group name mapping is found, privileges are given based on internal user group name. If there is no mapping, then the RDU database is searched for a user group with such a name. If that is also not there, then no privileges are assigned.
The aggregate of all privileges is returned. This depends on the roles the user group possess.
If no RDU database user group is found, no privileges are assigned.
Example cp:groups=Administrators,Regional
This specifies that the authenticated user is a member of two user groups: Administrators and Regional. The user is granted the roles assigned to these two groups. Also for a user to be granted privileges, the user group must be granted one or more roles.
Prime Cable Provisioning also supports mapping of external user group name to an internal user group name. See User Group Mapping for more details.
Sessions
Format: cp:sessions-allowed=<integer>
The integer value must be zero or greater.
If the value cannot be parsed, the user is given the RDU session default and an error is logged.
If the Access-Accept does not specify the sessions-allowed, the user is given the RDU session default.
Example cp:sessions-allowed=3
If the Radius Access-Accept Cisco-AVPair VSA contains cp:sessions-allowed=3, the user is allowed three concurrent sessions.
Domain
Format: cp:domains=<domain1>,…<domainN>
Domain names must explicitly match those in the RDU.
Only those domains that match are assigned to the user.
If no domains are specified, the user is not granted any domain memberships.
Example cp:domains=north,south
If the Radius Access-Accept Cisco-AVPair VSA contains cp:domains=north,south, the user is allowed membership into the north and south domains.
Backward Compatibility for Existing Users
Unlike in the earlier releases, there is no need to create duplicate users in both RDU and Radius in Prime Cable Provisioning. RDU user configuration overrides Radius user configuration for authorization. This is done to support backward compatibility of existing Radius users. After migrating from an earlier version to Prime Cable Provisioning, all existing Radius users are created as local users in RDU. So it is advised that you delete all the existing duplicate Radius users once the Radius users are configured with the appropriate Cisco AV Pairs. If there is a duplicate user (same name) present in both RDU and Radius, even though, the user would get authenticated by the Radius server, for authorization RDU configuration takes precedence.
For example:
If the user John is present in both Radius and RDU and in Radius, John is configured with COSAdmin privileges and in RDU, John is configured with DeviceAdmin privileges, on login using the Radius password, John is authenticated by Radius but the privileges set in Radius are ignored as the user configuration for John present in RDU takes precedence for authorization.