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.

For information about using AAA with remote servers to manage administrative access to the DMF Controller, refer to the Configuring AAA to Manage DMF Controller Access section.

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.

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 for viewing and monitoring 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

To add a user to a group, complete the following steps.

Add users from the main Security page or the following page that appears when selecting Security > Users from the DMF GUI main menu.

Click the Provision control (+) in the Users section or in the table displayed when selecting Security > Users from the DMF GUI main menu.
The system displays the Add User dialog.
After completing this page, click Next.
The system displays Page 2 (Groups).
The Groups page lists existing groups for adding the current user.
To add a group to this list, click the Provision control (+) in the upper left corner.
The system displays the Manage Groups dialog.
To create a new group, click the Provision control (+) at the upper left corner of the Manage Groups dialog.
Type a name for the group and click Submit.
The new group is added to the table.
Enable the checkbox for the new group and click Append Selected.
The group is added to the Create User dialog.
Enable the checkbox for the new group and click Save.

Using the CLI to Manage Groups and User Accounts

To add a group, enter the group command from config mode, as in the following example:

controller-1(config)# group dc-group

To associate users with a group, enter the associate command from config-group mode, as in the following example:

controller-1(config-group)# associate user bob
controller-1(config-group)# associate user susan

To associate interfaces with the group, enter the associate command for each interface, as in the following example:

controller-1(config-group)# associate switch DMF-FILTER-SWITCH-1 interface TAP1-ethernet1
controller-1(config-group)# associate switch DMF-FILTER-SWITCH-1 interface TAP1-ethernet1

To associate other resources with the group, use the following options with the associate command:

[no]associate object{policy|service}<object-name>
[created-by<object-creator>[created-on<date-and-time>]]

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 Change Password from the Menu control on the Security > Users page.

Type the new password, confirm it, and click Save.

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 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 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.
```
curl -g -H "Cookie: session_cookie=<session_cookie>" 
                  'https://<controller IP>:8443/api/v1/rpc/controller/os/action/system-user/reset-password'
                  -d '{"user-name" : "recovery","password" : "AdminAdmin"}' -X POST
```

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:~$

Managing Groups

Manage groups from the Security page or the following page displayed when selectingSecurity > Groups from the DMF GUI main menu.

To view the interfaces and users assigned to a group, click the Expansion control. To add a user to the group, click the Provision control (+) in the Users table.

To associate an interface with the group, complete the following steps.

Click the Provision control (+) in the Switch Interfaces table.
The system displays the Add Interfaces to Groups page.
To add an interface to this table, click Provision control (+) in the table.
The system displays the Append Interfaces page.
Enable the checkbox for each interface to add to the group and click Append Selected.
The interfaces are added to the Add Interfaces to Group page.
Enable the checkbox for each interface to add to the group and click Save.
The interfaces are now associated with the group, and any users in the group will have privileges to view and use the interfaces.

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: 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.

GUI Procedure

To manage the configuration of AAA settings on the DMF Controller, select Maintenance > AAA. The system displays the page shown in the following dialog.

This page allows identifying up to five destination TACACS or RADIUS servers, configure the server secret, and specify the timeout.

Enabling Remote AAA Services

GUI Procedure

To log accounting log messages to a remote server, click the Accounting link in the Configuration section.

By default, DMF saves accounting logs on the local controller, which are available for searching and analysis using the Visibility > Analytics option. If local logging is disabled, these logs will not be available for analysis locally.

To send the accounting logs to a remove server move the slider to No and select RADIUS or TACACS from the selection list. To use a remote server for authentication, click the Authentication link in the Configuration section.

Select the primary authentication method from the 1st selection list and the secondary authentication method from the 2nd list. Select RADIUS or TACACS from Remote Type selection list and click Save.

To use a remote server for authorization, click the Authorization link in the Configuration section.

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.

controller-1(config)# aaa authentication policy lockout failure 3 window 180 duration 900

Note:

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-token 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 Active Controller in the cluster, they can log in to 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:

admin@controller-1:~$ sudo pam_tally2 -u recovery
Login Failures Latest failure From
recovery 9 09/08/20 16:16:04 10.95.66.44

To reset the lockout for the user, use the following command:

admin@controller-1:~$ sudo pam_tally2 --reset --user recovery
Login Failures Latest failure From
recovery 9 09/08/20 16:16:04 10.95.66.44
admin@controller-1:~$ sudo pam_tally2 -u recovery
Login Failures Latest failure From
recovery

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.

Click the Add TACACS Server from the Actions menu in the TACACS Servers table.

Figure 10. 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:
tacacs server host <server> key {<plaintext-key> | 0 <plaintext-key> | 7 <encrypted-key>}
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:
```
controller-1(config)# switch DMF-DELIVERY-SWITCH-1
controller-1(config-switch)# tacacs override-global
controller-1(config-switch)# tacacs server host 1.1.1.1 key 7 020700560208
```
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.

<TacacsServiceDictionaries>
<TacacsServiceDictionary dispName="Big Switch Networks" name="shell:ip">
<ServiceAttribute dataType="String" dispName="BSN User Role" name="BSN-User-Role"/>
</TacacsServiceDictionary>

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

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 11. Maintenance AAA: Radius Section
Click the Add RADIUS Server from the Actions menu in the RADIUS Servers table.

Figure 12. 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:

radius server host <server-address> [timeout {<timeout>}][key {{<plaintext>} | 0 {<plaintext>} | 7 {
            <secret>}}]

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.

create dictionary /usr/share/freeradius/dictionary.arista with the contents below:
VENDOR Big-Switch-Networks 37538
BEGIN-VENDOR Arista-Networks
ATTRIBUTE DMF-User-Role 1 string
ATTRIBUTE DMF-AVPair 2
string
END-VENDOR Arista-Networks

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.
```
"user1" Cleartext-Password := "passwd"
BSN-User-Role := "read-only",
```
The following example authorizes user2 for RBAC group AD1:
```
"user2" Cleartext-Password := "passwd"
BSN-User-Role := "AD1",
```
The following example authorizes user3 for RBAC group admin:
```
"user3" Cleartext-Password := "passwd"
BSN-User-Role := "admin",
```
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:
```
client anet {
ipaddr = 10.0.0.0/8
secret = <server’s secret>
}
```

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.

root@radius-bsnl:/var/log/freeradius/radacct/10.8.41.11# tail -f detail-20180123
Tue Jan 23 17:48:22 2018
Acct-Session-Id = "Session@9c7e1872"
Acct-Status-Type = Interim-Update
BSN-AVPair = "auth_description=session/
9c7e18722d6b9334ff6cac2924ae06baa4cdc6b53756e93120145cfd7712b466"
User-Name = "admin"
BSN-AVPair = "remote_address=10.1.2.86"
BSN-AVPair = "cmd_args=show version"
NAS-IP-Address = 10.8.41.11
Acct-Unique-Session-Id = "8d80262884a1abde"
Timestamp = 1516729702

Custom admin role

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 ﬂexible 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.

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.

Group Management

View Group permissions:

NS-178-37(config-group)# group aaa-user
Controller-1(config)# permission category:AAA privilege read-write
Controller-1(config)# show group aaa-user configured-permission
# Permission Privilege
1 category:AAA read-write
Controller-1(config)# show group aaa-user 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)#

Summary:

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 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:

Controller-1(config)# group all-except-AAA-group
Controller-1(config-group)# permission category:DEFAULT privilege read-write
Controller-1(config-group)# permission category:AAA privilege does-not-elevate
Controller-1(config-group)# show group all-except-AAA-group configured-permission
# Permission Privilege
1 category:AAA does-not-elevate
2 category:DEFAULT read-write
Controller-1(config-group)# show group all-except-AAA-group effective-permission
# Effective-permission Inferred privilege
1 category:DEFAULT read-write
2 category:DEFAULT/SENSITIVE inferred-read-write
3 category:AAA does-not-elevate
4 category:AAA/SENSITIVE inferred-does-not-elevate
5 category:APPLOG inferred-read-write
6 category:SYSOPS inferred-read-write
7 category:SYSOPS/SENSITIVE inferred-read-write
8 category:TIME inferred-read-write
9 category:TIME/SENSITIVE inferred-read-write
Controller-1(config-group)#

Summary:

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 immediate parent i.e. Category: AAA which is “does-not-elevate” 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. This action can established using the following 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

Controller-1(config)# show group user-administration configured-permission
# Permission Privilege
1 category:AAA read-write
2 category:DEFAULT does-not-elevate

Controller-1(config)# show group user-administration effective-permission
# Effective-permission Inferred privilege
1 category:DEFAULT 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

Network-admin

Usersbelonging to this group will have admin without the privilege to manage AAA.

Controller-1> enable
Controller-1# configure terminal
Controller-1(config)#
Controller-1(config)# group network-admin
Controller-1(config-group)# permission category:AAA privilege does-not-elevate
Controller-1(config-group)# permission category:DEFAULT: 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

Controller-1(config)# show group network-admin configured-permission
# Permission Privilege
1 category:AAA does-not-elevate
2 category:DEFAULT read-write
Controller-1(config)# show group network-admin effective-permission
# Effective-permission Inferred privilege
1 category:DEFAULT read-write
2 category:DEFAULT/SENSITIVE inferred-read-write
3 category:AAA does-not-elevate
4 category:AAA/SENSITIVE inferred-does-not-elevate
5 category:APPLOG inferred-read-write
6 category:SYSOPS inferred-read-write
7 category:SYSOPS/SENSITIVE inferred-read-write
8 category:TIME inferred-read-write
9 category:TIME/SENSITIVE inferred-read-write

Auditor

Users belonging to this group can read everything for auditing.

Controller-1> enable
Controller-1# configure terminal
Controller-1(config)#
Controller-1(config)# group auditor
Controller-1(config-group)# permission category:DEFAULT: read-only
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

Controller-1(config)# show group auditor configured-permission
# Permission Privilege
1 category:DEFAULT read-only
Controller-1(config)# show group auditor effective-permission
# Effective-permission Inferred privilege
1 category:DEFAULT read-only
2 category:DEFAULT/SENSITIVE inferred-read-only
3 category:AAA inferred-read-only
4 category:AAA/SENSITIVE inferred-read-only
5 category:APPLOG inferred-read-only
6 category:SYSOPS inferred-read-only
7 category:SYSOPS/SENSITIVE inferred-read-only
8 category:TIME inferred-read-only
9 category:TIME/SENSITIVE inferred-read-only

Filtered-auditor

Users belonging to this group can audit everything but cannot see sensitive data.

Controller-1> enable
Controller-1# configure terminal
Controller-1(config)#
Controller-1(config)# group filtered-auditor
Controller-1(config-group)# permission category:DEFAULT: read-only
Controller-1(config-group)# permission category:AAA/SENSITIVE privilege does-not-elevate
Controller-1(config-group)# permission category:DEFAULT/SENSITIVE privilege does-not-elevate
Controller-1(config-group)# permission category:TIME/SENSITIVE privilege does-not-elevate
Controller-1(config-group)# permission category:SYSOPS/SENSITIVE privilege 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

Controller-1(config)# show group filtered-auditor configured-permission
# Permission Privilege
1 category:DEFAULT read-only
Controller-1(config)# show group filtered-auditor effective-permission
# Effective-permission Inferred privilege
1 category:DEFAULT read-only
2 category:DEFAULT/SENSITIVE does-not-elevate
3 category:AAA inferred-read-only
4 category:AAA/SENSITIVE does-not-elevate
5 category:APPLOG inferred-read-only
6 category:SYSOPS inferred-read-only
7 category:SYSOPS/SENSITIVE does-not-elevate
8 category:TIME inferred-read-only
9 category:TIME/SENSITIVE does-not-elevate

Commonly used Category-feature Matrix

Table 1. Software Requirements for DANZ Monitoring Fabric
CATEGORY	FEATURE
AAA	TACACS
AAA/SENSITIVE	TACAS-PASSWORD
AAA	RADIUS
AAA/SENSITIVE	RADIUS-PASSWORD
AAA	ACCOUTING
AAA	AUTHENTICATION
AAA	AUTHORIZATION
AAA	USERS
AAA	CLEAR AAA parameters
AAA	CLEAR SESSION parameters
TIME	TIME-Time Zone
TIME	TIME-NTP-servers
TIME/SENSITIVE	TIME-NTP-KEYS
APPLOG	Show logging commands
SYSOPS/SENSITIVE	connect
SYSOPS	boot
SYSOPS	clear async
SYSOPS	Delete dump files
SYSOPS	Reload controller
DEFAULT	auto-vlan-mode
DEFAULT	auto-vlan-range
DEFAULT	Clear debug counters
DEFAULT	Clear statistics
DEFAULT	Policy
DEFAULT	System restart local-node
DEFAULT	filter-interface-group

Known Limitations

Viewing audit logs is only possible through the built-in admin user.
There must be a built-in admin user to upgrade the DMF Controller and managed appliances.
RBAC has a higher preference over custom admin groups.
The custom group feature doesn't apply to DMF Managed Appliances.

DANZ Monitoring Fabric Deployment Guide