Authentication, Authorization and Accounting (AAA)¶

Overview¶

This service configures several aspects of users’ authentication process; their origin, role, permissions and how authentication itself is performed.

Users authentication can be done using a TACACS+ or RADIUS remote server.

Each remote user is assigned a role (viewer or admin, see users section for details) that denotes its rights. The way to specify this role is dependent of the remote server.

Note

If a local user with the same name as a remote user exists, the connection can be done by using the local or remote password. The role of the user will be the one defined locally.

Warning

Some names are reserved by the system and cannot be used: _apt, _lldpd, _tacacs, backup, bin, daemon, dhcpd, dnsmasq, fastpath, games, gnats, irc, list, lp, mail, man, messagebus, news, nobody, ntp, proxy, snmp, sshd, statd, sync, sys, syslog, systemd-bus-proxy, systemd-network, systemd-resolve, systemd-timesync, telegraf, uucp, uuidd, www-data.

If one of these names is used, the connection using a remote server will fail.

Manage TACACS+ servers list¶

To add a TACACS+ servers do:

vsr running config# system aaa tacacs 1

Here, 1 is the priority order in case multiple servers are configured. The lower the order, the higher the priority.

Note

Up to 8 TACACS+ servers can be specified.

An IP address and secret to authenticate the TACACS+ exchanges are required:

vsr running tacacs 1#! address 192.168.0.1 secret testing123
vsr running tacacs 1# commit

It’s also possible to specify the VRF from which the TACACS+ server must be joined:

vsr running tacacs 1# vrf vrf1
vsr running tacacs 1# commit

Let’s fetch the state after committing this configuration:

vsr running tacacs 1# show state
tacacs 1
    address 192.168.0.1
    port 49
    secret testing123
    timeout 3
    vrf vrf1
    ..

The same configuration can be made using this NETCONF XML configuration:

vsr running config# show config xml absolute system aaa tacacs
<config xmlns="urn:6wind:vrouter">
  <system xmlns="urn:6wind:vrouter/system">
    <aaa xmlns="urn:6wind:vrouter/system/aaa">
      <tacacs>
        <order>1</order>
        <port>49</port>
        <timeout>3</timeout>
        <address>192.168.0.1</address>
        <secret>testing123</secret>
        <vrf>vrf1</vrf>
      </tacacs>
    </aaa>
  </system>
</config>

See also

The command reference for details.

Configuring TACACS+ authentication servers¶

6WIND Vendor-Specific TACACS+ Attributes can be used to configure users’ privileges. They are specified in the TACACS+ server configuration file on a per-user basis. Virtual Service Router retrieves these attributes through an authorization request to the TACACS+ server after authenticating a user.

These attributes must be configured in the 6WIND or exec (shell in CISCO servers) service statement in the TACACS+ server configuration file.

There are 3 ways to configure user privileges in the TACACS+ server:

using the TACACS+ priv-lvl attribute
using the 6WIND local-role attribute
configuring custom rules with 6WIND Vendor-Specific attributes

Note

These 3 ways are exclusive. For example, if a user has the priv-lvl and the local-role attributes set in the same service, the authentication will be rejected.

Using TACACS+ privilege level attribute¶

Users configured with the TACACS+ priv-lvl attribute can also connect to the Virtual Service Router:

service = exec {
   priv-lvl = <0-15>
}

The association between the TACACS+ priv-lvl value and the user role is defined in the system aaa user-role-privilege configuration context.

Using the 6WIND local-role attribute¶

The local-role 6WIND Vendor-Specific Attribute can be used to set a list of local user roles:

service = 6WIND {
   local-role = "admin|viewer|role1,role2,..."
}

Note

Roles set in the list of local-role must be configured in the Virtual Service Router.

Configuring custom rules¶

Custom user permission rules can be configured in the TACACS+ server configuration file. The attributes values format is based on the local custom user role configuration:

service = 6WIND {
   netconf-admin = "true|false"
   deny-protected = "true|false"

   deny-config = "path"
   deny-state = "path"
   deny-rpc = "<yang-module>:<rpc> [vrf <name> [l3vrf <name>]]"
   deny-notification = "<yang-module>:<notification>"

   permit-config = "path [access-permission read|read-write]"
   permit-state = "path"
   permit-rpc = "<yang-module>:<rpc> [vrf <name> [l3vrf <name>]]"
   permit-notification = "<yang-module>:<notification>"
}

deny-config and permit-config attributes respectively deny and permit access to a part of the router configuration;
deny-state and permit-state attributes respectively deny and permit access to a part of the state;
deny-rpc and permit-rpc attributes respectively deny and permit execution of RPCs;
deny-notification and permit-notification attributes respectively deny and permit receiving notifications;
deny-protected deny access to sensitive data when set to true (this corresponds to the nacm-deny-protected user role). This attribute is regarded as false by default.
netconf-admin gives Netconf administrator permission when set to true (this corresponds to the nacm-netconf-admin user role). This attribute is regarded as false by default.

A suffix (like an identifier) can be added to set several rules with the same attribute. In the following example: the firewall-operator TACACS+ group sets 3 times the permit-config attribute to give read access to the network-stack, firewall, and physical interfaces configuration:

group = firewall-operator {
   service = 6WIND {
      permit-config = "/vrf/network-stack"
      permit-config-1 = "/vrf/firewall"
      permit-config-2 = "/vrf/interface/physical"
   }
}

See also

The user role configuration documentation for details about rules format.

TACACS+ server configuration example¶

Here is a complete example:

group = admins {
   service = exec {
      priv-lvl = 15
   }
}

group = viewers {
   service = exec {
      priv-lvl = 5
   }
}

group = firewall-manager {
   service = 6WIND {
      deny-config = "/vrf[name=\"mgmt\"]"
      deny-rpc = "* vrf mgmt"

      permit-config = "/vrf/firewall/ipv4 access-permission read-write"
      permit-config-1 = "/vrf/firewall/ipv6 access-permission read-write"
      permit-config-2 = "/vrf/group"
      permit-rpc = "vrouter-firewall*:*"
   }
}

user = john {
     name = "John C"
     member = admins
     pap = PAM
}

user = alice {
     name = "Alice F"
     pap = PAM
     service = 6WIND {
        local-role = "admin"
     }
}

user = bob {
     name = "Bob D"
     member = viewers
     pap = PAM
}

user = barney {
   name = "barney"
   member = firewall-manager
   pap = PAM
}

With this configuration:

john and alice can connect to the Virtual Service Router with the admin role
bob can connect to the Virtual Service Router with the viewer role
barney can connect to the Virtual Service Router with a custom role that gives read/write access to the IPv4 and IPv6 firewall configuration, read-only access to the address and network group configuration, and all firewall RPC in any VRF except in the mgmt one

Note

the length of the user name must be less or equal to 32 characters
if both methods are configured for a user, only the 6WIND Vendor-Specific Attributes will be taken into account
for CISCO tacacs servers, the service shell should be configured instead of exec

TACACS+ accounting¶

The TACACS+ accounting can record user sessions start/end, configuration commit, and all RPCs that impact this system (like flush RPCs).

User sessions start/end TACACS+ accounting packets contain the following attributes:

start_time/end_time: the session start or end time in milliseconds since the Epoch
user: the user name which login or logout
task_id: the process ID on which the user session is attached

TACACS+ accounting packets for configuration commit and executed RPCs contain the following attributes:

start_time: the time in milliseconds at which the command has been executed
user: the user that has executed the command
port: the identifier of the user netconf session
cmd: the executed command. commit for a commit or the yang xpath of the executed RPC
cmd-args: the commit identifier followed by the list of services modified in the configuration for a commit accounting message or the RPC argument list for a command accounting message

Note

When a configuration is committed by the system (at Virtual Service Router startup for example), the user is set to [system], and the netconf session identifier is -1.
The commit corresponding to an ID can be displayed via the show config commit <id> command, or diff with the running configuration with the diff running commit <id> command.

Here is an example of accounting logs from a tac_plus server:

Oct 24 11:10:48 10.175.0.1      [system]  -1      unknown    start   start_time=1729586868   service=6WIND   cmd=commit      cmd-args=commit-id=10      cmd-args=fastpath       cmd-args=physinterface        cmd-args=netconf-server cmd-args=routing        cmd-args=aaa    cmd-args=snmp   cmd-args=vrf    cmd-args=vrrp   cmd-args=license     cmd-args=system  cmd-args=auth
Oct 24 11:14:55 10.175.0.1      admin     ssh     10.200.0.1 start   start_time=1729753495   task_id=5767    service=6WIND
Oct 24 11:18:35 10.175.0.1      admin     119     unknown    start   start_time=1729753498   service=6WIND   cmd=/vrouter-system:banner    cmd-args=post-login={'message': 'Welcome!'}
Oct 24 11:20:00 10.175.0.1      admin     ssh     10.200.0.1 stop    stop_time=1729753499    task_id=5767    service=6WIND

The first line shows the startup configuration committed at Virtual Service Router system startup
The second one shows the admin user login from the 10.200.0.1 to 10.175.0.1
In the third one, the admin user sets the post-login banner to “Welcome!”
Then the last line shows the admin user log out

Note

For performance reasons, the list of modified services in a commit accounting message will contain all the services present in the configuration when the commit affects many leaves.

Configure RADIUS server list:¶

Add a new RADIUS server using:

vsr running config# system aaa radius 1

Here, 1 is the priority order in case multiple servers are configured. The lower the order, the higher the priority.

Note

Up to 8 RADIUS servers can be specified.

An “IPv4” or “IPv6” address and the shared secret to authenticate with the RADIUS server are required:

vsr running radius 1#! address fe80::1ac0:4dff:fea6:d455 secret testing123
vsr running radius 1# commit

It’s also possible to specify the VRF from which the RADIUS server must be joined, this option is set to main by default:

vsr running radius 1# vrf vrf1
vsr running radius 1# commit

Let’s fetch the state after committing this configuration:

vsr running radius 1# show state
radius 1
    address fe80::1ac0:4dff:fea6:d455
    port 1812
    secret testing123
    timeout 3
    vrf vrf1
    ..

The same configuration can be made using this NETCONF XML configuration:

vsr running config# show config xml absolute system aaa radiu
<config xmlns="urn:6wind:vrouter">
  <system xmlns="urn:6wind:vrouter/system">
    <aaa xmlns="urn:6wind:vrouter/system/aaa">
      <radius>
        <order>1</order>
        <port>1812</port>
        <timeout>3</timeout>
        <address>fe80::1ac0:4dff:fea6:d455</address>
        <secret>testing123</secret>
        <vrf>vrf1</vrf>
      </radius>
    </aaa>
  </system>
</config>

See also

The command reference for more details.

Configuring RADIUS authentication servers¶

RADIUS users can be configured in two ways on the server:

Using the Management-Privilege-Level attribute associated with the system aaa user-role-privilege configured in the Virtual Service Router.
Or configuring custom rules using the 6WIND-AVPair vendor-specific attribute.

Note

If neither of these 2 methods are used, the RADIUS user will be regarded as a viewer.

Using the Management-Privilege-Level attribute¶

The RADIUS Management-Privilege-Level attribute can be used to associate a RADIUS user with a Virtual Service Router local role:

barney
   Management-privilege-level 15

See also

the user role privilege level configuration.

Using the 6WIND-AVPair vendor-specific attribute¶

RADIUS users can also be configured using the 6WIND-AVPair vendor-specific attribute. There are 2 ways to configure user privileges using this method:

One or a set of user roles defined locally in the Virtual Service Router can be assigned to a user.
Or a set of access permission rules can be assigned directly to a user.

The second way enables the RADIUS configuration to be independent of the Virtual Service Router configuration.

All sub-attributes described below are of a type referred to as 6WIND-AVPair, consisting of a vendor type of 1 and an ASCII string as an Attribute-Specific value. This string is of the form auth:Attr=Value with auth: identifying the attribute as reserved for the user authentication, Attr being a string containing the name of the 6WIND-AVPair attribute itself, and Value being the value whose expected format will depend on Attr.

Using the auth:local-role sub-attribute¶

The local-role 6WIND-AVPair sub-attribute can be used to set a list of local user roles:

6WIND-AVPair "auth:local-role=admin|viewer|role1,role2,..."

Note

Roles must be comma-separated.
The admin and viewer roles cannot be set in concatenation with other roles.
Roles set in this sub-attribute must be defined in all Virtual Service Routers using this RADIUS server for user authorization processing.

Using the custom rule sub-attributes¶

Custom user permission rules can be configured in the RADIUS server configuration file. The sub-attributes Attr=Value pair format is based on the TACACS+ and the Virtual Service Router custom user role configuration.

Here is an example of a RADIUS user configuration. In this example, Barney can:

Configure and execute RPCs in the Virtual Service Router via nc-cli or other NETCONF clients.
Edit the firewall configuration in any VRF except the mgmt.
Execute the show-interface and all firewall RPCs except in the mgmt VRF.

barney Cleartext-Password := "barney"
        6WIND-AVPair = "auth:netconf-admin=true",
        6WIND-AVPair = "auth:deny-protected=true",
        6WIND-AVPair = "auth:deny-config=/vrf[name=\"mgmt\"]",
        6WIND-AVPair = "auth:deny-rpc=* vrf mgmt",
        6WIND-AVPair = "auth:permit-config=/vrf/firewall/ipv4 access-permission read-write",
        6WIND-AVPair = "auth:permit-config=/vrf/firewall/ipv6 access-permission read-write",
        6WIND-AVPair = "auth:permit-config=/vrf/group",
        6WIND-AVPair = "auth:permit-rpc=vrouter-interface:show-interface",
        6WIND-AVPair = "auth:permit-rpc=vrouter-firewall*:*"

See also

the :|tacacs-p| custom rules configuration for details about the Attr=Value format.
The user role configuration documentation for details about the rules format.

Configure the local authentication mode¶

The following modes can be configured for local authentication:

in the default always mode, the local users are queried after the remote servers in all cases
in the fallback mode, the local users are queried only if the remote servers are unreachable
in the always-for-root mode, the local root users can always authenticate. The fallback mode is applied for others.

See also

The command reference for more details.

Customize user role privilege¶

The user-role-privilege option enables associating the viewer, admin, and any custom user roles to the TACACS+ priv-lvl or the RADIUS Management-Privilege-Level attributes.

The following example configures the viewer privilege level to 1, admin to 15, and the custom firewall-manager role to 10. This allows any user with a privilege level equal to 15 to log in as admin, less than 15 and greater or equal to 10 to log in as firewall-manager, and less than 10 and greater or equal to 1 to log in as viewer.

vsr running config# system aaa user-role-privilege
vsr running user-role-privilege# admin 15
vsr running user-role-privilege# viewer 1
vsr running user-role-privilege# custom firewall-manager 10

Note

it’s not possible to set an admin privilege level less than the viewer one.

See also

The custom user role configuration documentation.

Locking accounts with failed login attempts¶

As a security measure against brute force or dictionary attacks, authentication-failure-lock can be set up to temporarily lock accounts affected by a number of consecutive authentication failures regardless of their origin.

vsr running config# system aaa authentication-failure-lock
vsr running authentication-failure-lock# enabled true

Affected accounts will be locked for 10 minutes after 3 consecutive failed attempts. A successful authentication before reaching the limit resets the counter.

Note

Accounts are automatically unlocked when disabling this feature.

See also

The command reference for more details.