ON THIS PAGE
Device AAA Support
Device AAA Overview
Device AAA (authentication, authorization and accounting) frameworks are supported, specifically RADIUS and TACACS+, on certain platforms. Device AAA is optional and correct implementation is the responsibility of the end user. Minimum requirements for correct Apstra AAA implementations are described below.
We recommend adding a local Apstra user to devices when using AAA framework. If AAA authentication or authorization fails when Apstra performs a full configuration push, manual recovery (config push) is required.
You can apply AAA configuration in one of two ways:
| Device AAA Method | Description |
|---|---|
| Configlets (Recommended) |
Configuration is added to configlets which are then imported into blueprints. Local credentials must be available from the Apstra environment so the device can be added and the configlet can be applied. See Configlets for details. CAUTION: Before upgrading the Apstra server, device agents, or NOSes, you must delete device AAA/TACACS configlets from blueprints. After the upgrade is complete, you can re-apply them. |
| User-required | To ensure pre-existing configuration is retained when a device is brought under Apstra management, make sure the config is in place before unacknowledging the device. See Device Configuration Lifecycle . |
Supported Platforms
Juniper Junos
Credentials for the Junos off-box system agent user must always be valid and available. When using the AAA framework we recommend that you add a local user to devices and use it for Apstra off-box system agents. Always have “password” be first in Junos config for authentication-order as follows:
authentication-order [ password radius ]
Cisco NX-OS
A remote user could erratically be removed from NX-OS devices, causing authentication and authorization failures. The user (role 'network-admin') must exist on the device in order to manage the device. If not, Apstra functions such as agent installation, telemetry collection and device configuration may fail. The only known workaround is to use local authentication.
The example NX-OS configuration below has been tested to work correctly with Apstra software. This uses both authentication and authorization:
tacacs-server key 7 “<key>“ tacacs-server timeout <timeout> tacacs-server host <host> aaa group server tacacs+ <group> server <host> use-vrf management source-interface mgmt0 aaa authentication login default group <group> aaa accounting default group <group> local aaa authentication login error-enable aaa authentication login ascii-authentication
Arista EOS
When TACACS+ AAA is configured on EOS devices, device agent upgrades could fail while files are copied from the Apstra server to the device. This commonly happens if TACACS+ uses a custom password prompt. To prevent this type of failure, temporarily disable all TACACS+ AAA where device authentication uses an admin-level username and password for any device agent operations, including upgrades.