Authentication, Authorization and Accounting (AAA)¶

Overview¶

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>

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.

To specify these attributes, include a service statement in the TACACS+ server configuration file, in a user or a group statement:

service = 6WIND {
   local-role = "admin|viewer"
}

At the moment, the local-role attribute is supported. If not specified, the viewer role is assigned by default.

Users configured with exec privilege level can also connect to the Virtual Service Router:

admin users must have a priv-lvl set to 15
viewer users must have a priv-lvl greater or equal to 5 and less than 15.
users with priv-lvl less than 5 are refused, these values are reserved for future use.

Here is a complete example:

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

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

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
}

With this configuration, john and alice can connect to the product with the admin role and bob with the viewer role.

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

Customize user role privilege¶

The user-role-privilege node configures the user role privilege level for the viewer and the admin roles. The following example configures the viewer privilege level to 1 and admin to 15, allowing any users with a privilege level less than 14 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

Note

this feature is taken into account only by TACACS+
it’s not possible to set an admin privilege level less than the viewer one

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>

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.