Using Authentication, Authorization, and Accounting
This chapter describes how to manage administrative access to the DANZ Monitoring Fabric (DMF) Controller using local groups and users (RBAC) and AAA servers in general, and it also provides specific configuration for TACACS+ or RADIUS servers.
Overview
Access privileges to the DANZ Monitoring Fabric (DMF) Controller are associated with groups. Each user assigned to the group obtains the access permissions associated with the group. The current version of DMF supports the following two groups:
Admin Group: Root privileges with access to all modes, including debug modes.
Read-Only: Read-only administrative access.
DMF also supports communication with a remote AAA server. All authentication, authorization, and accounting functions are set to local by default. The general options that control where these functions occur are:
Local only: The accounts on the remote AAA server are ignored, using only the local database accounts.
Local primary and remote backup: The accounts on the local database are used first. If the account is not found locally, DMF uses the database on the remote server.
Remote only: Authentication and authorization do not fall back to local for users other than the admin and recovery accounts, no matter what happens.
Remote primary and local backup: Uses the accounts on the remote AAA database first. If the remote server is unavailable, DMF uses the local database accounts.
Note: The admin and recovery user accounts are special accounts that cannot be authenticated remotely using RADIUS or TACACS+. These accounts are always authenticated locally to prevent administrative access from being lost in case a remote AAA server is unavailable. The following list summarizes the options available for each function:
The following list summarizes the options available for each function:
Accounting: local, local and remote, or remote.
Authentication: local, local then remote, remote then local, or remote.
Authorization: local, local then remote, remote then local, or remote.
Note: Authorization falls back to local only if remote authorization fails because the remote AAA server is unreachable.
Using Local Groups and Users to Manage DMF Controller Access
Administrative access to the monitoring fabric is managed by assigning interfaces to groups and then assigning user accounts to the group, which can then view and use the assigned interfaces.
Viewing Existing Groups and Users
To view the current allocation and assignment of groups and resources, enter the following command from any CLI mode on the active DANZ Monitoring Fabric (DMF) Controller.
To use the GUI to manage groups and users, select Security from the DMF GUI main menu.
Figure 1. Security
The system displays the Security page menu options.
Users
Groups
Sessions
Login/Lockout History
HTTP/SSH Ciphers
Groups
Displays the following preconfigured default groups on the DMF Controller:
admin group: Provides full administrative access to all interfaces. Global configuration options, such as assigning a role to a switch or interface, must be performed by the admin user.
read-only group: Provides access to view and monitor fabric activity and switch configuration for all interfaces but does not allow changing configuration or clearing statistics.
All switch interfaces are assigned to both default groups. The admin user has read, use, and configure access to all the interfaces. Any user added to the read-only group has read-only access to all the interfaces.
You can define a new group, in which case a user added to the group will be a restricted user with privileges to view and use only the interfaces assigned to the group.
Using the GUI to Manage User Accounts & Security Groups
To add a user to a group or to add a group, complete the following steps.
Add users from the main Security page or the following page when selecting Security > Users from the DMF GUI main menu.
Figure 2. Security > Users
Select Actions > + Add User in the Users section.
The system displays the Add User dialog.
Figure 3. Add User
Click Submit.
To edit a user, click the Actions > Edit icon for the requisite Username.
To delete a user, select Actions > Delete Selected Users.
To add a Security Group, select Security > Groups in the Groups section.
Figure 4. Security Groups
Select Actions > + Create Group.
The system displays the Create Group menu.
Figure 5. Create Group
Enter a name for the group and all other required group settings, including:
Category Access
Default - Inherit, Does Not Elevate, Read Only, Read Write (drop-down)
AAA - Inherit, Does Not Elevate, Read Only, Read Write (drop-down)
App Log - Inherit, Does Not Elevate, Read Only, Read Write (drop-down)
Sysops - Inherit, Does Not Elevate, Read Only, Read Write (drop-down)
Time - Inherit, Does Not Elevate, Read Only, Read Write (drop-down)
Telemetry - Inherit, Does Not Elevate, Read Only, Read Write (drop-down)
Enter the show group command to display the currently configured groups and users.
To display the group configuration in the current running-config, enter the show running-config group command, as in the following example:
controller-1# show running-config group
! group
group admin
associate user admin
group dmf-qa
associate switch DMF-FILTER-SWITCH-1 interface ethernet1
associate switch DMF-FILTER-SWITCH-1 interface ethernet2
associate switch DMF-FILTER-SWITCH-1 interface ethernet25
associate switch DMF-FILTER-SWITCH-1 interface ethernet26
associate user test1
group read-only
To use the CLI, enter the following commands from config mode.
controller-1(config)# user bob
controller-1(config-local-user)# full-name Robert Smith
controller-1(config-local-user)# password
Password:
Re-enter:
controller-1(config-local-user)# group admin
controller-1(config-group)# associate user bob
controller-1(config-group)# show user
#User nameFull nameGroups
- |--------- |------------- |--------- |
1adminDefault adminadmin
2bobRobert Smith admin
Enter the no user command from config mode to delete a user, as in the following example.
node1(config)# no user bob
controller-1(config)# show user
#User nameFull nameGroups
- |--------- |------------- |------- |
1adminDefault adminadmin
To add a read-only user, run the following commands from config mode.
controller-1(config)# user john
controller-1(config-local-user)# full-name John Smith
controller-1(config-local-user)# password
Password:
Re-enter:
controller-1(config-local-user)# group read-only
controller-1(config-group)# associate user john
controller-1(config-group)# show user
#User nameFull nameGroups
- |--------- |------------- |--------- |
1adminDefault adminadmin
2bobRobert Smith admin
3john John Smith read-only
Changing User Passwords
To change the password for the admin user or other user accounts, select the Actions > Edit icon for the requisite Username from the Security > Users page.
Figure 6. Security Users
Note: Entering a new password will overwrite the existing one. Leaving it blank retains the original password.
Figure 7. Change Password
Type the new password, confirm it, and click Submit.
Password Reset
Resetting the Password for the Recovery User
To reset the password for the recovery user, please follow one of the following procedures. Perform these steps on each cluster Controller as resetting the password of the recovery user on one Controller won't change it for the recovery user on the other Controller.
Using the Controller’s bash:
Go to the Controller bash by executing debug bash.
Execute sudo passwd
recovery.
admin@controller-1:~$ sudo passwd recovery
New password:
Retype new password:
passwd: password updated successfully
admin@controller-1:~$
From the recovery login account login:
For this to work, the current password for the recovery user is required.
recovery@controller-1:~$ passwd recovery
Changing password for recovery.
Current password:
New password:
Retype new password:
passwd: password updated successfully
recovery@controller-1:~$
Using the API /api/v1/rpc/controller/os/action/system-user/reset-password:
The API call below will reset the recovery user's password to AdminAdmin. The example below uses curl initiated from a Linux host, but any RESTful API client can call the API.
Resetting Password for admin and Other Local Users
To reset the password for admin and other local users, log in to the Controller using recovery user credentials. Use the floodlight-reset-password command to reset the user’s password.
The example below example resets the admin user’s password.
recovery@controller-1:~$ floodlight-reset-password --user admin
Enter new admin password:
Re-enter new admin password:
Password updated for user admin
recovery@controller-1:~$
The example below resets the password for the guest account, a read-only group user.
recovery@controller-1:~$ floodlight-reset-password --user guest
Enter new guest password:
Re-enter new guest password:
Password updated for user guest
recovery@controller-1:~$
Authentication with a User Token and REST API
Use the access-token command to create a long-lived token for authentication with external scripting, such as RESTful API. The token can be deleted (repudiated) at any time. DMF preserves a hashed version of the token in the running-config.
The following example shows an access token with the key sam assigned to the user fred.
controller-1(config)# user fred
controller-1(config-user)# access-token sam
access-token : Y9yVwLawjJ03lSthnBKVh3XeplaJ6sSE
The system replies with the session cookie for use in the REST API.
To display the hashed version of the session cookie, enter the show this command or show running-config fred.
controller-1(config-user)# show this
! user
user fred
access-token sam 459d1d5e0bc42c5bbbee091a984e2807592d11d8a5d4cbac110d32da3f0e436c 2018-01-
08T15:44:02.353Z
hashed-password
method=PBKDF2WithHmacSHA512,salt=N9E9jaPIFTc_ZO9Oq0gd4A,rounds=25000,ph=true,
7eCf1PGAYqUw53vJ2bsGpSVEU5-D6ix5sHufFUi3gFr3AHB4Jqj2eLNZzoo66y_qIRFOOOL8nc5oG5i1gJ1FxA
controller-1(config-user)#
The session cookie does not appear in the running-config; the hashed session cookie instead appears. Because the cookie is in the running-config, it persists over upgrade. To remove the token, enter the no access-token command, as in the following example:
controller-1(config-user)# no access-token sam
Configuring AAA to Manage DMF Controller Access
Authentication, Authorization, and Accounting (AAA) is a general standard for controlling and auditing access to network resources. Various implementations are possible using technologies such as LDAP, RADIUS, Kerberos, TACACS+, or a local database. The current version of DANZ Monitoring Fabric (DMF) supports AAA using a local database on the Controller node or with a remote TACACS+ or RADIUS server. All authentication, authorization, and accounting functions are set to local by default.
Authentication and authorization occur only once, and whatever privileges are associated with the first account found are used. Configuring options separately for authentication and authorization is possible, but Arista Networks recommends using the same settings for simplicity.
When one or more remote AAA servers are available, the best practice is to enable remote logging as the primary authorization method. The local database is only used if no remote server responds to the authorization request before the timeout. By default, the timeout is five seconds per server, with a maximum total timeout of 25 seconds for up to five remote servers.
Note: The admin and recovery user accounts are special accounts that cannot be authenticated remotely using RADIUS or TACACS+. These accounts are always authenticated locally to prevent administrative access from being lost in case a remote AAA server is unavailable.
Note: If the user fails to be authorized by any AAA server, the user account can be authorized as a member of the default group and chosen from the Default Group selection list. The options are admin or read-only when configuring the latter group.
DMF supports AAA services using RADIUS and TACACS+ servers using up to four servers of each type. The default timeout for each AAA server is five seconds, which was previously 30 seconds in earlier releases. The total aggregate timeout for all configured servers is 20 seconds.
By default, the Controller waits five seconds before trying the next server or falling back to the local services provided by the Controller database if that is the configuration. You can change the default timeout, but the maximum aggregated time for all the servers is 25 seconds. Five servers are supported only with a default timeout of five seconds or less.
Using the GUI - Enabling Remote AAA Services
GUI Procedure
To manage the configuration of AAA settings on the DMF Controller, select Maintenance > AAA.
Figure 8. AAA Settings Page
AAA configuration tabs and features include:
Accounting
Authentication
Authorization
RADIUS
TACACS+
Audit Logging
This page supports identifying up to five destination TACACS+ or RADIUS servers, configuring the server secret, and specifying a timeout.
Accounting
To log accounting log messages to a remote server, click Accounting > Edit in the Configuration section.
Figure 9. Accounting Settings
By default, DMF saves accounting logs on the local Controller. If local logging is disabled, these logs will not be available for analysis locally. To send the accounting logs to a remote server, select the Order preference:
Local Only - Default.
Remote Only - Enter a Remote Method, TACACS or RADIUS from the drop-down list.
Local Before Remote - Enter a Remote Method, TACACS or RADIUS from the drop-down list.
Remote before Local - Enter a Remote Method, TACACS, or RADIUS from the drop-down list.
Click Submit.
Tip: Use the Reset button to return to the default setting, if required.
Authentication
To configure the authentication method, click Authentication > Edit in the Configuration section.
Figure 10. Authentication Settings
Select the Authentication Order preference:
Local Only - Default.
Remote Only - Enter a Remote Method, TACACS or RADIUS from the drop-down list.
Local Before Remote - Enter a Remote Method, TACACS or RADIUS from the drop-down list.
Remote before Local - Enter a Remote Method, TACACS or RADIUS from the drop-down list.
Lockout Policy Mode
Configuration for the time-based user lockout policy. In no-lockout mode, the configuration of this container is ignored, and lockout is disabled. In lockout-remote mode, this container's values (or, in their absence, the defaults) dictate the lockout behavior.
Select the desired Lockout Policy Mode:
No Lockout
Lockout Remote
Click Next and set the Password Compliance Requirements from the drop-down list:
None
NIST-800-63B
Custom-Check - Enter the requirements for the detailed password (min/max, etc.).
No-Check
Click Submit.
Authorization
To use a remote server for authorization, click Authorization > Edit in the Configuration section.
Select the Authorization preference:
Figure 11. Authorization Settings
To configure the audit logging method, click Audit Logging > Edit in the Configuration section.
Figure 12. Audit Logging
Set the type of audit logging of request leaf values; if no value is specified, request leaf values will not be audit logged.
Select the Log Request Leaf Values from the drop-down list:
None - Default.
Record All Request Values
Click Submit.
Using the CLI - Enabling Remote AAA Services
CLI Procedure
Use the aaa authorization role default command to assign a default role to the current account. DMF uses the default group if authentication on a remote server is successful but no role is specifically assigned. This command does not apply to local authorization or authentication. If a local user is not associated with a group on the Controller, login is not allowed.
Note: Use the authorization role default admin command carefully because the effect is to provide every user account that authenticates successfully on a remote server with admin-level privileges unless the user account is specifically assigned to a different group.
Time-based User Lockout
Starting in the DMF 8.0 release, DANZ Monitoring Fabric supports time-based user lockout functionality. Users are locked out for ‘t2’ time when attempting with ‘n’ incorrect passwords within ‘t1’ time.
Locked-out users must either be cleared of lockout or wait for the lockout period to expire before attempting another login with a correct password. The feature is disabled by default.
To enable, use the following command:
aaa authentication policy lockout failure <number of failed attempts> window <within t1 time>
duration <lockout for t2 time>
The value range for ‘failure’ is 1 to 255.
The value range for ‘window’ and ‘duration’ is 1 to 4294967295 seconds (2^32-1).
The example below locks out any user out for 15 minutes when attempting three incorrect logins within 3 minutes.
This feature affects only remote logins such as SSH/GUI/REST API using username/password. Console-based login and password-less authentications such as SSH keys, Single Sign-on, and access tokens are unaffected. Locked-out users can still access the Controller via console/password-less authentication.
The feature is node-specific concerning the functionality, i.e., if user1 is locked out of accessing the active Controller in the cluster, they can log in to the standby Controller with the correct password and vice versa. Lockout user information is not persistent across Controller reboot/fail-over.
To view if a user is locked out, admin-group users can run the following command:
show aaa authentication lockout
controller-1# show aaa authentication lockout
User name Host Failed LoginsLockout DateLockout Expiration
--------- |------------ |------------- |------------------------------|------------------------------ |
admin 10.240.88.19312020-09-08 16:07:36.283000 PDT2156-10-15 22:35:51.283000 PDT
To clear the lockout for a user, admin-group users can run the following command:
clear aaa authentication lockout user <username>
To clear all the locked-out users use the following command:
clear aaa authentication lockout
The following example shows how to clear a locked-out admin user:
controller-1# clear aaa authentication lockout user admin
controller-1# show aaa authentication lockout
None.
A Recovery user will also be locked out if attempting with incorrect passwords.
To check if the user is locked out, use the ‘pam_tally2’ tool:
Note: The window parameter does not apply to the Recovery user login as the ‘pam_tally2’ tool does not support it.
Using TACACS+ to Control Access to the DMF Controller
Use remote Authentication, Authorization, and Accounting (AAA) services employing a TACACS+ server to control administrative access to the switch CLI. The following table lists the accepted Attribute-Value (AV) pairs:
Attributes
Values
BSN-User-Role
admin
read-only
bigtap-admin
bigtap-read-only
Note: The remotely authenticated admin and bigtap-admin users and the read-only and bigtap-read-only users have the same privileges. The bigtap-admin and bigtap-read-only values are supported to allow the creation of DMF-specific entries without affecting the admin and read-only TACACS+ server entries.
A remotely authenticated admin user has full administrative privileges. Read-only users on the switch must be remotely authenticated. Read-only access is not configurable for locally authenticated user accounts.
Read-only users can only access login mode, from where they can view most show commands, with some limitations, including the following:
TACACS, SNMP, and user configuration are not visible to the read-only user in the output from the show running-config command.
show snmp, show user, and show support commands are disabled for the read-only user.
Note: Local authentication and authorization take precedence over remote authentication and authorization.
Configure privileges on the remote TACACS+ server using the following attribute-value pairs:
Supported attribute name: BSN-User-Role
Supported attribute values: admin, read-only,
Use the TACACS+ server to maintain administrative access control instead of using the Controller's local database. However, it is best practice to maintain the local database as the secondary authentication and authorization method in case the remote server becomes unavailable.
DANZ Monitoring Fabric requires the following configuration on TACACS+ servers in addition to the configuration required on the Controller.
Authentication Method
Configure the TACACS+ server to accept ASCII authentication packets. Do not use the single connect-only protocol feature.
The DANZ Monitoring Fabric TACACS+ client uses the ASCII authentication method. It does not use PAP.
Device Administration
Configure the TACACS+ server to connect to the device administration login service.
Do not use a network access connection method, such as PPP.
Group Memberships
Create a bigtap-admin group. Make all DANZ Monitoring Fabric users part of this group.
TACACS+ group membership is specified using the BSN-User-Role AVPair as part of TACACS+ session authorization.
Configure the TACACS+ server for session authorization, not for command authorization.
Note: Specify the BSN-User-Role attribute as Optional in the tac_plus.conf file to use the same user credentials to access ANET and non-ANET devices.
Using the GUI to Add a TACACS+ Server
To identify a TACACS+ server to provide remote AAA services, complete the following steps. Repeat this procedure to identify up to five servers.
Procedure
Note: To set the secret and timeout values for all the TACACS+ servers, click the controls under the Default Settings section. Otherwise, set these values individually for each server.
Figure 13. Maintenance AAA
Click the Add TACACS Server from the Actions menu in the TACACS Servers table.
Figure 14. Create TACACS+ Server Dialog
Note: Do not use the pound character (#) in the TACACS secret, as it will be interpreted as the start of a comment in the PAM config file.
Enter the IP address of the TACACS+ server.
Type the password required to access the server in the Secret field.
Note: Click the lock icon to encrypt the password if plain-text passwords are not used in the AAA environment.
Click Submit.
Using the CLI to Enable Remote Authentication and Authorization on the DMF Fabric Controller
CLI Procedure
Use the following commands to configure remote ‘login’ authentication and authorization. The examples use the SSH default for connection type.
controller-1(config)# tacacs server host 10.2.3.201
controller-1(config)# aaa authentication login default group tacacs+ local
controller-1(config)# aaa authorization exec default group tacacs+ local
As a result, all users in the bigtap-admin group on TACACS+ server 10.2.3.201 have full access to the DANZ Monitoring Fabric Controller.
Using the CLI to Add a TACACS+ Server
To view the current TACACS+ configuration, enter the show
running-config tacacs command.
Complete the following steps to configure the DMF Controller with TACACS+ to control administrative access to the switch.
Identify the IP address of the TACACS+ server and any key required for access using the tacacs server command with the following syntax:
Enable up to four AAA servers by repeating this command for each server. For example, using a plaintext key, the following command enables TACACS+ with the server running at 10.2.3.4.
controller-1(config)# tacacs server 10.2.3.4 key 0 secret
If the key is omitted, an empty key is used.
Note: Do not use the pound character (#) in the TACACS+ secret, as it will be interpreted as the start of a comment in the PAM config file.
Encrypt each TACACS+ server connection using a pre-shared key. To specify a key for a specific host, use one of the following:
controller-1(config)# tacacs server host <ip-address> key <plaintextkey>
controller-1(config)# tacacs server host <ip-address> key 0 <plaintextkey>
controller-1(config)# tacacs server host <ip-address> key 7 <plaintextkey>
Replace plaintextkey with a password up to 63 characters in length. This key can be specified either globally, or for each individual host. The first two forms accept a plaintext (literal) key, and the last form accepts a pseudo-encrypted key, such as that displayed with show
running-config.
The following is an example using the key 7 option followed by the encrypted string:
controller-1(config)# tacacs server 10.2.3.4 key 7 0832494d1b1c11
To configure a global key, use the following command:
controller-1(config)# tacacs server key 0 secret
The global key value is used if no key is specified for a given host. If no key is specified globally and no key is specified for a given host, then an empty key is assumed.
Note: Be careful configuring TACACS+ to avoid disabling access to the DANZ Monitoring Fabric (DMF) Controller.
Configuring device-specific TACACS+ server parameters overriding that of the global TACACS+ servers is possible. This applies to switches, service nodes, and recorder nodes. The configuration must be made from the config-device submode. An example to configure a switch-specific TACACS+ server is described below:
Similarly, TACACS+ server keys and timeout values can also be overridden:
controller-1(config)# switch DMF-DELIVERY-SWITCH-1
controller-1(config-switch)# tacacs override-global
controller-1(config-switch)# tacacs server timeout 8
controller-1(config-switch)# tacacs server key 0 qwerty
To move back to using the globally defined TACACS+ servers, run the no tacacs override-global command at the config-switch submode.
To view the TACACS+ configuration on a specific switch, use the show effective-config switch switch-name tacacs command:
controller-1(config-switch)# show effective-config switch DMF-DELIVERY-SWITCH-1 tacacs
! switch
switch DMF-DELIVERY-SWITCH-1
tacacs server host 1.1.1.1 key 7 020700560208
tacacs server timeout 8
The TACACS+ key value displays as a type7 secret instead of plaintext.
Setting up a Tac_Plus Server
After installing the tac_plus server, complete the following steps to set up authentication and authorization for the DMF Controller with the TACACS server:
Configure users and groups.
In the /etc/tacacs/tac_plus.conf file, specify the user credentials and group association.
# user details
user = user1 {
member = anet-vsa-admin
login = des a9qtD2JXeK0Sk
}
Configure the groups to use one of the AV pairs supported by the DMF Controller (for example, BSN-User-Role="admin" for admin users).
# group details
# ANET admin group
group = anet-vsa-admin {
service = exec {
BSN-User-Role="admin"
}
}
# ANET read-only group
group = anet-vsa-read-only {
service = exec {
BSN-User-Role="read-only"
}
}
Note: Different TACACS servers need different ways to define the attributes. The following is an example of configuring an Aruba Clearpass server.
Configure the TACACS+ server and AAA on the DMF Controller.
tacacs server host <IP address> key server’s secret>
aaa authentication login default group tacacs+ local
aaa authorization exec default group tacacs+ local
aaa accounting exec default start-stop locals group tacacs+
This configuration allows authentication and authorization to connect to the TACACS+ server to verify user credentials and privileges. Checking the user account locally only occurs when the remote server is unreachable. In this example, accounting is set to store audit logs locally and send them to the remote server.
Refer to your AAA server documentation for further details or instructions for setting up other servers.
Using the Same Credentials for DMF and Other Devices
To use the same user credentials to access DMF and a non-DMF device, the BSN-User-Role attribute must be specified as Optional in the tac_plus.conf file, as shown in the following example.
group = group-admin {
default service = permit
service = exec {
optional BSN-User-Role = "admin"
}
}
RBAC-Based Configuration for Non-Default Group User
To create an RBAC configuration for a user in a non-default group, complete the following steps:
Create a group AD1.
group AD1
Do not associate any local users.
Use the same group name on the TACACS+ server and associate a user to this group.
Note: The attribute should be BSN-User-Role, and the value should be the group-name.
The following is an example from the open TACACS+ server configuration.
group = AD1 {
service = exec {
BSN-User-Role="AD1"
}
}
After you create the group, associate a user to the group.
user = user3 {
member = AD1
login = cleartext user3
}
Using RADIUS for Managing Access to the DMF Controller
By default, the Authentication and Authorization functions are set to local while the Accounting function is disabled. The only supported privilege levels are as follows:
admin: Administrator access, including all CLI modes and debug options.
read-only: Login access, including most show commands.
Note: RADIUS does not separate authentication and authorization, so be careful when authorizing a user account using a remote RADIUS server to use the correct password configured for the user on the remote server.
The admin group provides full access to all network resources, while the read-only group provides read-only access to all network resources.
Note: The admin and recovery user accounts cannot be authenticated remotely using RADIUS. These accounts are always authenticated locally to prevent administrative access from being lost in case a remote AAA server is unavailable.
DANZ Monitoring Fabric also supports remote AAA server (RADIUS) communication. The following summarizes the options available for each function:
Accounting: local, local and remote, or remote.
Authentication: local, local then remote, remote then local, or remote.
Authorization: local, local then remote, remote then local, or remote.
Note: Fallback to local authentication occurs only when the remote server is unavailable, not when authentication fails.
Configure privileges on the remote RADIUS server using the attribute-value pairs shown in the following table:
Supported attribute names
Supported attribute values
BSN-User-Role
admin
bigtap-admin read-only
bigtap-read-only
The BSN-AV-Pair attribute sends CLI command activity accounting to the RADIUS server.
Using the GUI to Add a RADIUS Server
To identify a RADIUS server to provide remote AAA services, complete the following steps. Repeat this procedure to identify up to five servers.
GUI Procedure
Select Maintenance > AAA > RADIUS from the GUI.
Figure 15. Maintenance AAA: Radius Section
Click the Add RADIUS Server from the Actions menu in the RADIUS Servers table.
Figure 16. Create RADIUS Server Dialog
Enter the IP address of the RADIUS server.
Type the password required to access the server in the Secret field.
Note: Click the lock icon to encrypt the password if plain-text passwords are not used in your AAA environment.
Click Submit.
Using the CLI to Add a RADIUS Server
Use the following command to identify the remote RADIUS server:
For example, the following command identifies the RADIUS server at the IP address 192.168.17.101.
controller-1(config)# radius server host 192.168.17.101 key admin
You can enter this command up to five times to identify multiple RADIUS servers. The Controller tries to connect to each server in the order they are configured.
Setting up a FreeRADIUS Server
After installing the FreeRADIUS server, complete the following steps to set up authentication and authorization for the DMF Controller with the RADIUS server.
Procedure
Create the BSN dictionary and add it to the list of used dictionaries.
Note: Make sure that the BSN-User-Role attribute is in the first position in the Radius attribute dictionary, followed by BSN-AVPair.
Include the arista dictionary in the radius dictionary file: /usr/share/freeradius/dictionary
$INCLUDE dictionary.arista
Configure a sample user with admin and read-only privileges.
The following is an example that defines and configures a user, opens the user file /etc/freeradius/users, and inserts the following entries:
Note: This example shows how the VSA is associated with the user and its privileges. In an actual deployment, a database and encrypted password are necessary.
Configure the RADIUS server and AAA on the DMF Controller.
radius server host <IP address> key server’s secret>
aaa authentication login default group radius local
aaa authorization exec default group radius local
aaa accounting exec default start-stop group radius local
This configuration allows authentication and authorization to connect to the RADIUS server to verify user credentials and privileges. AAA fallback to local occurs only when the remote server is unreachable. In this example, accounting is set to store audit logs locally and send them to the remote server.
Add the DMF Controller subnet to the allowed subnets (clients.conf) on the RADIUS server.
This entry is required if access to the RADIUS server is limited to allowed clients/subnets. The following is an example of the clients.conf file:
Restart the FreeRADIUS service on the server to enable the configuration.
The following is an example accounting record sent from the Controller to the RADIUS server after adding the BSN-AVPair attribute to the /usr/share/freeradius/dictionary.arista file.
Use the custom admin roles feature, which allows the definition of a group that grants the privilege to read or write like a built-in admin group, but only for specific use cases/categories. Configure the required privileges for each predefined set of categories.
This configuration allows a user to define a more flexible group role, such as a group that will enable its users to read and write most of the general configuration like admin, but not the AAA-related parts of the configuration.
This approach helps to create user profiles on DANZ Monitoring Fabric with limited admin access restricted only for the required features.
Categories
Users can be created and associated to groups with the following categories:
category:AAA
Configuration and state related to AAA, including but not limited to local user management, group management AAA group creation and user association.
Controller-1> enable
Controller-1# configure
Controller-1(config)# group aaa-mgmt-group
Controller-1(config-group)# permission category:AAA privilege read-write
Controller-1(config)# user aaa-user
Controller-1(config-user)# password <user_configured_password>
Controller-1(config-user)# group aaa-mgmt-group
Controller-1(config-group)# associate user aaa-user
AAA group user sample configuration
AAA group user sample configuration
Controller-1(config)# aaa authentication login default local
Controller-1(config)# tacacs server host <REMOTE_TACACS_SERVER_IP>
Controller-1(config)# show group aaa-mgmt-group configured-permission
# Permission Privilege
1 category:AAA read-write
Controller-1(config)# show group aaa-mgmt-group effective-permission
#Effective-permission Inferred privilege
- |-------------------------- |------------------------- |
1category:DEFAULT inferred-does-not-elevate
2category:DEFAULT/SENSITIVE inferred-does-not-elevate
3category:AAA read-write
4category:AAA/SENSITIVE does-not-elevate
5category:APPLOGinferred-does-not-elevate
6category:SYSOPSinferred-does-not-elevate
7category:SYSOPS/SENSITIVEinferred-does-not-elevate
8category:TIMEinferred-does-not-elevate
9category:TIME/SENSITIVEinferred-does-not-elevate
When AAA group user tries to configure sensitive information
category:AAA/SENSITIVE:
Sensitive data included in configuration and state related to AAA, including but not limited to local user management, group management.
AAA/SENSITIVE group creation and user association
Controller-1> enable
Controller-1# configure
Controller-1(config)#
Controller-1(config)# group aaa-sen-mgmt-group
Controller-1(config-group)# permission category:AAA/SENSITIVE privilege read-write
Controller-1(config)# user aaa-sen-user
Controller-1(config-user)# password <user_configured_password>
Controller-1(config-user)# group aaa-mgmt-group
Controller-1(config-group)# associate user aaa-sen-user
Controller-1(config)# show group aaa-sen-mgmt-group configured-permission
# Permission Privilege
1 category:AAA/SENSITIVE read-write
Controller-1(config)# show group aaa-sen-mgmt-group effective-permission
# Effective-permission Inferred privilege
1 category:DEFAULT inferred-does-not-elevate
2 category:DEFAULT/SENSITIVE inferred-does-not-elevate
3 category:AAA read-write
4 category:AAA/SENSITIVE inferred-read-write
5 category:APPLOG inferred-does-not-elevate
6 category:SYSOPS inferred-does-not-elevate
7 category:SYSOPS/SENSITIVE inferred-does-not-elevate
8 category:TIME inferred-does-not-elevate
9 category:TIME/SENSITIVE inferred-does-not-elevate
Controller-1(config)#
AAA group user sample configuration
Controller-1(config)# tacacs server host 10.240.176.159 key 12323243
Controller-1(config)#
category:TIME:
Configuration and state related to system time and NTP. TIME group creation and user association
Controller-1> enable
Controller-1# configure
Controller-1(config)#
Controller-1(config)# group time-mgmt-group
Controller-1(config-group)# permission category:TIME privilege read-write
Controller-1(config)# user time-user
Controller-1(config-user)# password <user_configured_password>
Controller-1(config-user)# group time-mgmt-group
Controller-1(config-group)# associate user time-user
Navigate to the following page to create the custom admin groups from GUI.
Login to DMF.
Figure 17. Group Creation
Proceed to Security > Groups and add the required settings.
Figure 18. Custom Group
Permissions & Privileges
Privileges are the permissions set of each category.
Read Only: Grants the user privileges to read only the configurations for the enabled category.
Read-Write: Grants the user read and write privileges for configurations for the enabled category.
Does Not Elevate: The user can neither read nor write configurations for that category. Any category, such as AAA, TIME, etc., configured with Does Not Elevate will not inherit from the parent category.
Inherit: Categories will inherit their permission from their parent category. The DEFAULT category is considered the root of all categories.
For example, if TIME/SENSITIVE is set to inherit and TIME has read-only, then users associated with this group will inherit from the parent category, and it will effectively have the privilege of read-only for TIME/SENSITIVE.
Similarly, if AAA is set to inherit and DEFAULT has read-only, then users associated with this group can read all configurations related to AAA.
Category Identification
DMF helps identify which feature comes under what category, achieved using the following command.
Syntax: :: category <feature_name>
For example, the AAA feature.
Controller-1# configure
Controller-1(config)#
Controller-1(config)# category aaa authentication login default local
syntax of variant:
aaa authentication login default {local | group {tacacs+ | radius} | local group {tacacs+ | radius}
| group {tacacs+ | radius} local}
no aaa authentication login default [local | group {tacacs+ | radius} | local group {tacacs+ |
radius} | group {tacacs+ | radius} local]
Configure authentication parameters
AAA "aaa authentication login default local"
Although the category can be configured, allow-all read access is enabled for the command
Exact matching commands: 1, similar commands (same prefix): 1
In the above output, the AAA "aaa authentication login default local" line signifies that the above feature comes under the AAA category.
Category: AAA is set as read-write privilege as per the user configuration Category: AAA/SENSITIVE is set as read-write since it inherits from the immediate parent, i.e., Category: AAA which is “read-write”.
Rest of the categories are set as does-not-elevate since they inherit from Category: DEFAULT
Example to configure a user part of all categories except AAA:
Category: DEFAULT is set as “read-write” privilege as per the user configuration. Category: AAA is set as “does-not-elevate” privilege as per the user configuration. Category: AAA/SENSITIVE is set as “does-not-elevate” since it inherits from the immediate parent, i.e., Category: AAA which is “does-not-elevate”. The rest of the categories are set as “read-write” since they inherit from Category: DEFAULT.
Remote Users
With Custom Admin, associate users with the groups with required privileges using remote TACACS+ and RADIUS servers. To do that, follow these steps:
Create a user bns-user1 and a desired password.
Create a group “BSN-User-Role with the required categories and privileges and associate the above user to the group.
Configure the username and password, and the group created steps 1 and 2 on the TACACS/RADIUS servers.
Login to the DANZ Monitoring Fabric (DMF) Controller using the above credential.
Commonly used profiles
User Administration
Users belonging to this group can only manage users and groups.
Controller-1> enable
Controller-1# configure terminal
Controller-1(config)#
Controller-1(config)# group user-administration
Controller-1(config-group)# permission category:AAA privilege read-write
Controller-1(config-group)# permission category:DEFAULT: does-not-elevate
Controller-1(config)# user time-user
Controller-1(config-user)# password <user_configured_password>
Controller-1(config-user)# group time-mgmt-group
Controller-1(config-group)# associate user time-user
Note: Do not use the pound character (#) in the TACACS secret, as it will be interpreted as the start of a comment in the PAM config file.
