.svg?sv=2022-11-02&spr=https&st=2024-11-25T02%3A22%3A16Z&se=2024-11-25T02%3A32%3A16Z&sr=c&sp=r&sig=CSpNAtMn1sPSVl5vMC6cHeDgkXJg%2BgskmxRPVjPE%2F0s%3D){kind=logo}
Configuring User Authentication (RADIUS)
- 21 Jun 2024
- 11 Minutes to read
- Contributors
- Print
- PDF
Configuring User Authentication (RADIUS)
- Updated on 21 Jun 2024
- 11 Minutes to read
- Contributors
- Print
- PDF
Article summary
Did you find this summary helpful?
Thank you for your feedback
By default, Skylight orchestrator uses its own local user accounts to control access to its web-based user interface and its REST API.
The Skylight orchestrator web user interface also supports RADIUS-based user authentication. If RADIUS is configured as the primary authentication method, local Skylight orchestrator user accounts can be configured as the secondary authentication method. The secondary authentication method is used if users are denied access by RADIUS or if the RADIUS servers are unavailable.
This section explains how to configure the authentication of a user account for Skylight orchestrator, in particular, how to configure it to use the RADIUS authentication.
System administrators can configure user authentication, including RADIUS authentication, in the RADIUS section.
RADIUS page (Admin ▶ Authentication)
The RADIUS section is divided into these areas:
- Authentication order: Allows administrators to set the order in which authentication sources (LOCAL or RADIUS) are used.
- RADIUS general configuration: Allows administrators to set up the basic configuration for the RADIUS servers.
- RADIUS realm setting: Allows administrators to configure the default realm if no realm data is provided by end users.
- Primary and Secondary RADIUS server: Allows administrators to configure and test the configuration of RADIUS servers.
Accessing the RADIUS Section
You need ADMIN level permissions to access the page in which authentication (including RADIUS authentication) is configured.
To access the page in which authentication (LOCAL and RADIUS) is configured
Select Admin ▶ Authentication from the main menu (in the left pane).
The RADIUS section is displayed.
The following sections explain how to set the parameters in the different areas of the RADIUS general configuration section:
- "Setting Authentication Order"
- "Setting RADIUS General Configuration"
- "Configuring RADIUS Realm Settings "
- "Configuring Primary and Secondary RADIUS Servers".
Setting Authentication Order
The Authentication order area of the Admin ▶ Authentication page allows you to set the order in which authentication methods are used to control access to Skylight orchestrator. It also determines how authentication will proceed if a particular authentication method is unavailable or if a user is refused access.
The table below explains how to complete the Authentication order parameters. Four authentication scenarios can be configured using the checkboxes in this area of the RADIUS page. The table explains the four scenarios.
Admin ▶ Authentication - Authentication order parameters
| Column Name | Description |
|---|---|
| Method | The method(s) to use for authentication. By default, the first method is set to LOCAL. The second method is RADIUS. You can change the order of the authentication methods by clicking and dragging the rows for the methods. If you want to use RADIUS as the primary authentication method, click in the RADIUS row, hold down the mouse button, and drag the row to the first position in the table. If you want to use LOCAL as the secondary authentication method, you must convert individual user accounts to type LOCAL. For more information, see "Automatic Creation of RADIUS Users in Skylight orchestrator". |
| Enabled | Check the box for each of the authentication methods that you want to use. At least one authentication method should be enabled at all times. If an authentication method is disabled, the system will not attempt to authenticate users by that method and will try the next enabled method. |
| Try next on refuse | This checkbox determines what happens when credentials are refused using the first authentication method. If this checkbox is checked, after the first authentication attempt, the system will attempt to authenticate again using the next enabled method (in the authentication order) and the same credentials. If the checkbox is not checked, when credentials are refused by the first authentication method, the system will stop trying to authenticate the user. |
| Try next on timeout | This checkbox determines what happens when no response is received from the authentication system within the configured timeout period. This is different from when access is refused in that no explicit refusal is received. When this checkbox is checked, if an authentication attempt times out, authentication is attempted again using the next enabled method (in the authentication order). When this checkbox is not checked, if an authentication attempt times out, authentication will not be attempted again using another method. Note: This checkbox can only be checked for the RADIUS method. A timeout policy is only valid for remote authentication methods. If the authentication order is RADIUS then LOCAL, this option allows you set up a backup authentication if the RADIUS server is down. The system will attempt to validate the user against local Skylight orchestrator user accounts when the RADIUS server is not available. |
The following scenarios show the effect of the Try next on refuse checkbox:
Authentication Scenario 1:
Note: RADIUS is the first authentication method (was dragged to the first position in the list).
- The user attempts to log in with credentials that are not valid on the RADIUS server.
- Authentication is attempted using RADIUS. The RADIUS server refuses access.
- Skylight orchestrator attempts to authenticate against LOCAL accounts. Access may or may not be allowed depending on whether or not the credentials are valid Skylight orchestrator accounts.
Authentication Scenario 2:
Note: RADIUS is the first authentication method (was dragged to the first position in the list).
- The user attempts to log in with credentials that are not valid on the RADIUS servers.
- Authentication is attempted using RADIUS. The user is denied access.
The following scenarios show the effect of the Try next on timeout checkbox:
Authentication Scenario 3:
Note: RADIUS is the first authentication method (was dragged to the first position in the list).
- The user attempts to log in with valid RADIUS credentials.
- RADIUS servers fail to respond within the timeout period.
- Skylight orchestrator attempts to authenticate against LOCAL accounts. Access may or may not be allowed depending on whether the credentials are for a valid Skylight orchestrator account.
Authentication Scenario 4:
Note: RADIUS is the first authentication method (was dragged to the first position in the list).
- The user attempts to log in with valid RADIUS credentials.
- RADIUS servers fail to respond within the timeout period.
- The user is denied access.
Setting RADIUS General Configuration
The RADIUS general configuration area of the Admin ▶ Authentication page includes parameters that apply to both the primary and secondary RADIUS servers.
Admin ▶ Authentication - RADIUS general configuration
| Parameter | Description |
|---|---|
| Authentication method | PAP (Password Authentication Protocol) is the only method that is currently available. |
| RADIUS timeout (s) | A value (in seconds) after which the system considers that the RADIUS server request has timed out. The minimum value is 1. The maximum value is 60. |
| Fallback on local roles | This checkbox is related to RADIUS user roles. For more information about obtaining user roles from RADIUS, see "Configuring RADIUS to Send User Roles". By default Fallback on local roles is disabled (box unchecked), which results in the following behavior:
|
Configuring RADIUS Realm Settings
The RADIUS realm settings area of the Admin ▶ Authentication page allows you to set realm parameters that Skylight orchestrator will add to RADIUS authentication requests.
Admin ▶ Authentication - RADIUS realm setting
| Parameter | Decription |
|---|---|
| Use default realm | Check this box to enable the inclusion of realm parameters in the RADIUS authentication request. |
| Realm name | Realm name to be added to the user name string sent to RADIUS. This field is only enabled if Use default realm is checked |
| Delimiter | Delimiter to be used in the user name string sent to RADIUS. This field is only enabled if Use default realm is checked. |
| Format | Format of the user name string sent to RADIUS. The possible values are:
|
Configuring Primary and Secondary RADIUS Servers
Typically, a RADIUS authentication system includes two servers that are used as a redundant pair.
You set the parameters for connecting to the RADIUS servers in the Primary RADIUS server tab and the Secondary RADIUS server tab (at the bottom of the RADIUS section).
Admin ▶ Authentication - Primary RADIUS server and Secondary RADIUS server
| Parameter | Description |
|---|---|
| Host | Hostname or IP address of the RADIUS server. |
| Port | Listening port of the RADIUS server. This should be the authentication port, not the accounting port. |
| Secret | Confirm secret. Secret key used by Skylight orchestrator to encrypt RADIUS messages. Must match the secret key configured on the RADIUS server. The secret key can be 48 characters long. |
| Source address | Optional field. Required when the RADIUS server uses a cluster of small network access servers (NAS) to simulate a large NAS to improve scalability. If required, this field should be set to the main IP address of the RADIUS NAS. If set, this value will be used as attribute 4 (NAS-IP-Address) in the payload of authentication request packets sent to RADIUS (without changing the source IP address in the IP header of the RADIUS authentication request packet). |
| Test server configuration | Select this button to test the settings for the primary or secondary server. You will need to enter a user name and password that are valid on the RADIUS servers. Note: If set, the values in the RADIUS realm setting section are used for the test. |
Automatic Creation of RADIUS Users in Skylight orchestrator
If RADIUS is the primary authentication method, user accounts are initially defined on the RADIUS servers. When a user logs in to Skylight orchestrator using a RADIUS account, a corresponding Skylight orchestrator user account (with User Type set to RADIUS) is automatically created in the Skylight orchestrator data store.
Users of type RADIUS can only be authenticated and authorized through RADIUS.
These user accounts can be converted to LOCAL users by simply editing the user profile in Skylight orchestrator. This is done by setting the User type to LOCAL, and assigning a password and a role to the user. This makes it possible to use LOCAL (Skylight orchestrator) as the second (or backup method) of authentication. For the procedure, see "Adding and Editing User Accounts".
The reverse is not allowed. A LOCAL user cannot be converted to a RADIUS user. You cannot create an account in the Skylight orchestrator web user interface and have it propagated automatically to RADIUS.
The Admin ▶ Users page displays operational data on RADIUS authentication.
Configuring RADIUS to Send User Roles
After the RADIUS server authenticates a user, it sends Skylight orchestrator a list of roles for the user. The user roles must be among the roles recognized by Skylight orchestrator. See "Managing User Accounts".
Your RADIUS server must be configured to send the list of roles to Skylight orchestrator after authentication. The list is sent as a comma-separated string in a vendor-specific attribute. Consult your RADIUS provider's documentation for instructions on how to add the vendor-specific attribute for Skylight orchestrator to your RADIUS data dictionary.
The vendor-specific attribute for Skylight orchestrator must be defined as follows:
- Vendor ID: 22420
- Vendor Type: 3
- Attribute Type: String
The Attribute Type string contains the list of the roles for the user. At authentication time, it will be assigned one of the following values:
- “ROLE_USER, ROLE_ADMIN"
- “ROLE_USER, ROLE_OPERATOR"
- “ROLE_USER, ROLE_FW_MGMT”
- “ROLE_USER, ROLE_VIEWER”
If RADIUS sends any roles that Skylight orchestrator does not recognize, Skylight orchestrator will ignore those roles. If the resulting list of roles is empty or if RADIUS sends an empty list, Skylight orchestrator will deny access to the user.
About the Default Admin User
Skylight orchestrator has a default user (called: admin) with the ROLE_ADMIN. It is a special user that is always authenticated locally.
The admin user provides some measure of protection against a situation that would make it impossible for users to be authenticated:
- Invalid authentication configuration in the Skylight orchestrator security settings (LOCAL authentication disabled)
COMBINED with: - Invalid RADIUS configuration or an unreachable RADIUS server.
For more information about Skylight orchestrator security settings, see "Editing Security Settings Related to User Accounts".
It is possible to delete the default admin user but this is not recommended. You may lock out all access to Skylight orchestrator.
CAUTION: The default admin user can be deleted from the system, but this is not recommended. You may lock out all access to Skylight orchestrator.
If you decide to delete the default admin user, we highly recommend that you test your authentication configuration before proceeding.
About Password Policies
The password policies (password format, password history and password expiration) of RADIUS and LOCAL users are completely independent. A user (of type LOCAL) can have one password in RADIUS and a different password locally in Skylight orchestrator.
If this user is authenticated against RADIUS for an extended amount of time, the LOCAL password continues to age out according to the normal age-out policy. On the next login, using local credentials, the user may be prompted to change password, in which case, the standard Skylight orchestrator password history and format policies will apply.
It should be noted that non-admin users can only change their local password if they have been authenticated locally. Admin users can change their own local password at any time. The procedure for updating a local password is the same for admin users and other users. For the procedure, see "Changing Your Password ".
© 2024 Cisco and/or its affiliates. All rights reserved.
For more information about trademarks, please visit: Cisco trademarks
For more information about legal terms, please visit: Cisco legal terms
For legal information about Accedian Skylight products, please visit: Accedian legal terms and tradmarks
Was this article helpful?