Common AAA Requirements

eos.arista.com/common-aaa-requirements

Aesha Parikh

This article describes sample configuration for most common AAA requirements. It covers
default behavior of EOS and a basic configuration guide with respect to Authentication and
Authorization through local, RADIUS and TACACS+. The article also includes sample
TACACS+ config files and RADIUS dictionary files.

Contents [hide]

Authentication
SSH Authentication
Console Authentication
Authorization
Authorization exec
Local role based command authorization
Authorization through RADIUS
Authorization through TACACS+
Console Authorization
Removing admin credentials
AAA Fallback
Debugging Commands
Additional Reading

Authentication

SSH Authentication
To have users locally authenticated, configure by entering the command:

Arista(config)#aaa authentication login default local

Other methods available are TACACS+ and RADIUS.

Console Authentication
By default console login will derive authentication method from the command “aaa
authentication login default “.

To configure authentication method for console login different than the default method,
configure:

Arista(config)#aaa authentication login console ?

group Use a server-group

local Use local database for authentication
none No authentication (always succeeds)
1/6
For example, if you want remote logins to use authentication method TACACS+ and
console login to use local, the required configuration is:

Arista(config)#aaa authentication login default group TACACS+

Arista(config)#aaa authentication login console local

Authorization

Authorization exec
By default, users open CLI session in user exec mode (irrespective of privilege level
assigned to the user). To enable user privilege control on the access prompt in which a CLI
session will open into i.e. in User exec mode (switch>) or privilege mode (switch#),
configure:

Arista(config)#aaa authorization exec default ?

group Use a server-group

local Use local database for authorization
none No authorization (always succeeds)

Users with privilege level 0/1 will open a CLI session in user exec mode. Users with
privilege level 2-15 will open CLI session in privilege mode.

If you the see below error while running scp to the switch, make sure authorization exec is
enabled and privilege level of the user is 2-15.

% The 'scp' command is only available in privileged mode

Local role based command authorization

Without using command authorization, any user irrespective of privilege can run all
commands.

To configure command authorization, enter the following command:

switch(config)#aaa authorization commands all default local

Note: By default, the above “aaa authorization commands” command is disabled.

Roles

EOS by default has 2 roles pre-programmed:

role network-admin ----> Can run ALL commands

10 permit command .*
!
role network-operator ----> Can ONLY run commands in privileged mode
10 deny mode exec command configure|bash|python-shell|\|
20 permit mode exec command .*

By default the username “admin” has the role of network-admin. Additonally, by default a
user with no role defined assumes the role of network-operator.

2/6
You can change the above default role using command:

Arista(config)#aaa authorization policy local default-role no_access

To see the current logged in users and their user-roles use the command “show aaa
sessions” (shown below):

Arista#show aaa sessions

Session Username Roles TTY State Duration Auth

---------- ----------- ---------------- ------- -------- ------------ ---------

1 admin network-admin vty3 E 0:45:25 local

16 test vty5 E 0:08:20 local

Authorization through RADIUS

Switch configs

You cannot configure aaa authorization commands through RADIUS. You can, however,
configure a RADIUS server to send role information and authorize users locally. This
avoids sending each command to the server for authorization.

As the roles are locally defined on the switch, you need command:

Arista(config)#aaa authorization commands all default local

Arista(config)#aaa authorization exec default group radius local

Note: Make sure your authorization exec is also configured correctly for RADIUS Service.

RADIUS Vendor-Specific Attribute-Value Pairs

RADIUS server and client companies extend basic RADIUS functionality through vendor
specific attributes. A dictionary file includes a list of RADIUS attribute-value pairs that Arista
switches use to perform AAA operations through the RADIUS server.

Arista switches use the following attribute values:

Arista Vendor number: 30065 Attribute: Arista-AVPair 1 string

Acceptable string values for Arista-AVPair include:

“shell:priv-lvl=<privilege level of a user, 0-15>”

“shell:roles=<list of roles for a user>”

​Example

This is a sample dictionary file that identifies Arista RADIUS vendor-specific attribute value
pairs.

3/6
#
# dictionary.arista
#
VENDOR Arista 30065
# Standard Attribute
BEGIN-VENDOR
ATTRIBUTE
END-VENDOR
Arista
Arista-AVPair 1
Arista
String

Authorization through TACACS+

TACACS+ Authorization supports attribute “priv-lvl” and “priv_lvl”. If the reply from tacacs
server contains any other mandatory attribute, authorization will fail. To ignore unknown
mandatory attributes, configure “tacacs-server policy unknown-mandatory-attribute ignore”.

If you are configuring authorization through TACACS+, you have to set permit/deny rules
on the server itself. For each command, message will be sent to TACACS server for
authorization. To enable authorization through TACACS+, use the command:

Arista(config)#aaa authorization commands all default group tacacs+ local

Sample TACACS+ config:

In this example, the customer requires user1 mapped to group 1 to have privilege 1 with
just the authority to use the show commands, and user2 belonging to group 2 with privilege
15 and should be able to get into EXEC mode and execute all show and terminal
commands.

On Server under /usr/local/share/tacacs+/tac_plus.conf:

4/6
user = user1 {
login = cleartext arista123 #enable
member = tacacstest1
}

user = user2 {
login = cleartext arista123 #enable
member = tacacstest2
}

group = tacacstest1 {
default service = permit
service = exec {
default attribute = permit
priv-lvl = 1
}
}

group = tacacstest2 {
cmd = enable { permit .* }
cmd = show { permit .* }
cmd = terminal { permit .* }
cmd = dir { permit flash.* }
service = exec {
default attribute = permit
priv-lvl = 15
}
}

Role based Authorization through TACACS+:

Starting 4.18.0, Role based authorization through TACACS+ is supported. To use

TACACS+ for role-based access control, run following CLI commands to configure
authentication and authorization methods:

Arista(config)#aaa authentication login default group tacacs+ local

Arista(config)#aaa authorization exec default group tacacs+ local
Arista(config)#aaa authorization commands all default local

On the TACACS+ server, use attribute “roles” to assign role to the user and configure
deny/permit rules for the role on the switch.

Console Authorization
By default, commands entered through the console do not require authorization. All
console logins will enter in exec mode (switch>) and by default, EOS does not verify
authorization of commands entered on the console port. To enable authorization for
commands entered through console, configure:

Arista(config)#aaa authorization console

Console authorization method will now be derived from “aaa authorization commands all
default ” and “aaa authorization exec default ”

5/6
Removing admin credentials
The “Admin” username cannot be removed from running configuration. To deny all
commands for admin username, you can create a role as below and assign role to admin.

role no_access
10 deny mode exec command .*
20 deny mode config command .*
30 deny mode config-all command .*
Arista(config)#Username admin privilege 0 role no_access secret ####

Note: By default, the console does not go through AAA authorization

AAA Fallback
If the first service is unavailable, AAA will fallback to the next service mentioned.

Aaa: %AAA-4-AUTHN_FALLBACK: Authentication method ‘group tacacs+’ is currently

unavailable; falling back to next method for service ‘sshd’.

If AAA service is falling back to next service, check:

1. IP connectivity to server
2. Service is running on the server
3. Key mismatch

If the user does not exist on the service mentioned, service does not fallback to
authenticate/authorize locally.

Debugging Commands
show aaa counters
show tacacs
show radius
show aaa sessions
show aaa method-lists all

Additional Reading
1. For information on AAA Accounting, https://eos.arista.com/using-aaa-to-log-all-
commands-from-users-on-arista-eos/
2. For detailed information on AAA commands, https://www.arista.com/en/um-eos-4180f
3. For more information on TACACS+ RBAC Support, https://eos.arista.com/eos-4-18-
0f/tacacs-rbac/

inShare

6/6