Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?


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:

Table 1: Device AAA Configuration Methods
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.


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:

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:

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.