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>

See also

The command reference for 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 attribute.

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 TACACS+ priv-lvl 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

  • this feature is taken into account only by TACACS+

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

See also

The custom user role configuration documentation.

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

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.

Important

To set RADIUS user’s role Management-Privilege-Level attribute must be configured on the RADIUS server configuration otherwise all RADIUS users will default to viewer. You can set a value of 15 in this attribute for the admin role.

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.