Using TACACS+ and RADIUS to Control Access to the Arista Analytics CLI

This appendix describes using TACACS+ and RADIUS servers to control administrative access to the Analytics Node.

Using AAA Services with Arista Analytics

Use remote Authentication, Authorization, and Accounting (AAA) services using TACACS+ or RADIUS servers to control administrative access to the Analytics Node 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 create BMF-specific entries without affecting the admin and read-only TACACS+ server entries.
You must also create a role in Elasticsearch with the same name as the group configured in the CLI.
Figure 1. Creating a Group in Elasticsearch

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 which 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.
Privileges at the remote TACACS+ server must be configured using the following attribute-value pairs:
  • Supported attribute name: BSN-User-Role
  • Supported attribute values: admin, read-only

Use a TACACS+ server to maintain administrative access control instead of using the Analytics Node local database, however, it is a best practice to keep the local database as the secondary authentication and authorization method in case the remote server becomes unavailable.

DMF TACACS+ Configuration

The DANZ Monitoring Fabric (DMF) requires the following configuration on TACACS+ servers and the configuration required on the Analytics Node.

Authentication Method

  • Configure the TACACS+ server to accept ASCII authentication packets. Do not use the single connect only protocol feature.
  • The DMF 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 AV Pair as part of TACACS+ session authorization.
  • Configure the TACACS+ server for session authorization, not for command authorization.
    Note: The BSN-User-Role attribute must be specified as Optional in the tac_plus.conf file to use the same user credentials to access ANET and non-ANET devices.

Enabling Remote Authentication and Authorization on the Analytics Node

Use the following commands to configure remote login authentication and authorization. The examples use the SSH default for connection type.
analytics-1# tacacs server host 10.2.3.201
analytics -1# aaa authentication login default group tacacs+ local
analytics -1# aaa authorization exec default group tacacs+ local

All users in the bigtap-admin group on TACACS+ server 10.2.3.201 have full access to the Arista Analytics Node.

User Lockout

Use the following command to lock out an AAA user after a calculated number of incorrect login attempts.
(config)#aaa authentication policy lockout failure F window W duration D
max-failures = F = [1..255] duration = D = [1..(2^32 - 1)] window = W = [1..(2^32 - 1)]

Adding a TACACS+ Server

To view the current TACACS+ configuration, enter the show running-config command, as in the following example:
analytics -1(config-switch)# show run switch BMF-DELIVERY-SWITCH-1 tacacs override-enabled
tacacs server host 1.1.1.1 key 7 020700560208
tacacs server key 7 020700560208 
analytics -1(config-switch)#

It displays the TACACS+ key value as a type7 secret instead of plaintext.

Complete the following steps to configure the Analytics Node 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, which has the following syntax:
tacacs server <server> [key {<plaintext-key> | 0 <plaintext-key> | 7 <encrypted-key>}
You can 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.
analytics -1(config-switch)# tacacs server 10.1.1.1 key 0 secret

In case of a missing key, it uses an empty key.

Note: Do not use the pound character (#) in the TACACS secret. It is the start of a comment in the PAM config file.

Each TACACS+ server connection can be encrypted using a pre-shared key.

To specify a key for a specific host, use one of the following commands:
analytics -1# tacacs server host <ip-address> key <plaintextkey> 
analytics -1# tacacs server host <ip-address> key 0 <plaintextkey> 
analytics -1# 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 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.

It uses the global key value when no key is specified for a given host. An empty key is assumed when no key is specified globally or specified for a given host.

The following example uses the key 7 option followed by the encrypted string:
analytics-1(config-switch)# tacacs server 10.1.1.1 key 7 0832494d1b1c11
Note: Be careful while configuring TACACS+ to avoid disabling access to the Analytics Node.

Setting up a TACACS+ Server

Refer to your AAA server documentation for further details or instructions on setting up other servers.

After installing the TACACS+ server, complete the following steps to set up authentication and authorization for Analytics Node with the TACACS+ server:

  1. Configure users and groups.
  2. 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
    }
  3. Configure the groups to use one of the AV pairs supported by the Analytics Node (for example, BSN-User-Role=admin for admin users).
    # group details# 
    ANET admin group
    group = anet-vsa-admin {
        service = exec {
        BSN-User-Role="admin"
        }
    }
    # BSN read-only group
    group = anet-vsa-read-only {
        service = exec {
        BSN-User-Role="read-only"
        }
    }
  4. Configure the TACACS+ server and AAA on the Analytics Node.
    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 sets authentication and authorization to first connect to the TACACS+ server to verify user credentials and privileges. It checks the user account locally only when the remote server is unreachable. In this example, accounting stores audit logs locally and sends them to the remote server.

Using the Same Credentials for the Analytics Node and Other Devices

The BSN-User-Role attribute must be specified as Optional in the tac_plus.conf file to use the same user credentials to access the Analytics Node and other devices, 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:
  1. Create a group AD1.
    group AD1

    Do not associate with any local users.

  2. 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"
    }
    }
  3. After you create the group, associate a user to the group.
    user = user3 {
    member = AD1
    login = cleartext user3
  4. Click save.

Using RADIUS for Managing Access to the Arista Analytics Node

Note: RADIUS does not separate authentication and authorization, so be careful when authorizing a user account with a remote RADIUS server to use the password configured for the user on the remote server.
By default, 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: The admin and recovery user accounts cannot be authenticated remotely using TACACS. These accounts are always authenticated locally to prevent administrative access from being lost in case a remote AAA server is unavailable.

The admin group provides complete access to all network resources, while the read-only group provides read-only access to all network resources.

DANZ Monitoring Fabric also supports communication with a remote AAA server (TACACS+ or RADIUS). 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.
Privileges at the remote TACACS+ server must be configured using the attribute-value pairs shown in the following table:
 
Supported attribute names Supported attribute values
BSN-User-Role admin

read-only

bigtap-admin

bigtap-read-only

The BSN-AV-Pair attribute sends CLI command activity accounting to the RADIUS server.

Adding a RADIUS Server

Use the following command to specify 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:
analytics-1(config)# radius server host 192.168.17.101 key admin

You can enter this command up to five times to specify multiple RADIUS servers. The Analytics Node 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 Analytics Node with the RADIUS server:
  1. Create the BSN dictionary and add it to the list of used dictionaries.
    create dictionary /usr/share/freeradius/dictionary.bigswitch with the contents below:
    VENDORBig-Switch-Networks 37538
    BEGIN-VENDOR Big-Switch-Networks
    ATTRIBUTE BSN-User-Role 1 string
    ATTRIBUTE BSN-AVPair2
    string
    END-VENDOR Big-Switch-Networks
  2. Include the bigswitch dictionary in the RADIUS dictionary file: /usr/share/freeradius/dictionary
    $INCLUDE dictionary.bigswitch
  3. 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:
    "user1" Cleartext-Password := "passwd"
    BSN-User-Role := "read-only",
    Note: It shows the VSA's association with the user and its privileges. In an actual deployment, a database, and an encrypted password are necessary.
    The following example authorizes the user2 for RBAC group AD1:
    "user2" Cleartext-Password := "passwd"
    BSN-User-Role := "AD1",
  4. Configure the RADIUS server and AAA on the Analytics Node.
    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 sets authentication and authorization to first 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 stores audit logs locally and sends them to the remote server.

  5. Add the Analytics Node subnet to the allowed subnets (‘clients.conf’) on the RADIUS server.
    It is required when access to the RADIUS server is limited to allowed clients or subnets. The following is an example of the clients.conf file:
    client anet {
    ipaddr = 10.0.0.0/8
    secret = <server’s secret>
    }
  6. Restart the FreeRADIUS service on the server to enable the configuration.

    The following is an example accounting record sent from the Analytics Node to the RADIUS server after adding the BSN-AVPair attribute to the /usr/share/freeradius/dictionary.bigswitch file.

    s