TACACS+ Authentication with Nokia Service Routers

Nokia SROS supports the use of AAA for a range of tasks, some of the more interesting and complicated are related to subscriber management when the Service Router is acting as a Broadband Network Gateway (BNG) however AAA is also useful for the network operations teams to provide centralised authentication for a fleet of routers where managing individual local accounts is not really something to contemplate.

SROS supports the use of RADIUS or TACACS+ for this management access control and today TACACS+ will be the method used with a linux daemon based on code from http://www.shrubbery.net/tac_plus/ which will be configured to support a Nokia Service Router (however this configuration would be quite Cisco IOS friendly) and the SROS router will use TACACS+ for authentication and identifying what access rights the user has my mapping using profiles.

Nokia SR and TACACS+ Server Test Topology

As you can see above, R1 (instantiated service router in eve-ng) has port 1/1/3 bridged to the internal Ethernet of the computer running eve-ng so both the router interface and the internal Ethernet are on the same IP subnet allowing connectivity to the TACACS+ server that will be run on the laptop.

To install the TACACS+ software, as eve-ng is built on Ubuntu 16.04, installation is as simple as invoking:
root@m4600:~# apt-get install tacacs+
The config was then modified to look like below:

root@m4600:~# cat /etc/tacacs+/tac_plus.conf
# shared secret with TACACS client
key = "tac_secret"
# Set where to send accounting records
accounting syslog;
accounting file = /var/log/tac_plus/tac_plus.acct

acl = mgmt_acl {
        # regex to allow access hosts from 192.168.1.0/24
        permit = 192\.168\.1\.([1-9]|[1-9]\d|1\d{2}|2[0-4]\d|25[0-4])
}

# administrative group, priv-lvl 15 to be mapped to SROS administative profile
group = administrative {
        default service = permit
        expires = "Jan 1 2020"
        acl = mgmt_acl
        service = exec {
         priv-lvl = 15
        }
}
# limited group, priv-lvl 1 to be mapped to SROS limited profile
group = limited {
        default service = permit
        expires = "Jan 1 2020"
        acl = mgmt_acl
        service = exec {
         priv-lvl = 1
        }
}

# our tacacs test accounts
# des password is generated by running tac_pwd on the plaintext
user = testadmin {
        member = administrative
        login = des JZ1fHFoSp.v/E
        # plaintext password = pass
}

user = testlimited {
        member = limited
        login = des O8ZepJOyIIuYo
        # plaintext password = test
}

A couple of the key things here besides the key which is the shared secret between the TACACS+ server and the router is that there are two groups defined administrative and limited, where the only difference is the priv-lvl. With Cisco platforms, this is what is used for TACACS+ uses during the authorisation stage to tell IOS what access rights a user has. SROS is able to map this to a “profile”.

Out of the box, SROS has two built in profiles, administrative (used for most installation and commissioning activities) and default which is somewhat less capable, however it is possible to define specific profiles in line with the roles of your users. In the config above there is a group called limited which will be identified by priv-lvl 1.

On R1 we can define a custom profile in the system security configuration context:

A:R1# /configure system security profile "limited"
A:R1>config>system>security>profile# info
----------------------------------------------
                default-action deny-all
                entry 10
                    match "show router route-table"
                    action permit
                exit
                entry 20
                    match "show users"
                    action permit
                exit
                entry 30
                    match "show system security user"
                    action permit
                exit
                entry 40
                    match "logout"
                    action permit
                exit
This example is certainly quite limited in what can be done due to the default-action deny-all, requiring specific white-listing of commands
To enable TACACS+ support on the router we first need to configure the TACACS server using the aggreed shared secret (configuring the timeout is optional but it specifies how many seconds we shall wait for a response – if the server is down, this is effectively how long you will wait to fall back to local authentication)
A:R1>config>system>security>profile# /configure system security tacplus
*A:R1>config>system>security>tacplus$ server 1 address 192.168.1.47 secret "tac_secret"
*A:R1>config>system>security>tacplus$ timeout 5

Now to create the priv-lvl mapping to profiles:
*A:R1>config>system>security>tacplus$ priv-lvl-map
A:R1>config>system>security>tacplus$ priv-lvl-map
A:R1>config>system>security>tacplus>priv$ priv-lvl 1 "limited"
A:R1>config>system>security>tacplus>priv$ priv-lvl 15 "administrative"

We also need to enable authorisation to be associated with these mappings:
A:R1>config>system>security>tacplus>priv$ back
A:R1>config>system>security>tacplus$ authorization use-priv-lvl

Now to actually enable tacacs authentication, within the password context we specify the authentication order to include the methods we prefer.
*A:R1>config>system>security>tacplus$ /configure system security password
*A:R1>config>system>security>password# authentication-order tacplus local exit-on-reject

If TACACS+ is unavailable, we fall back to local authentication accounts – if we hadn’t include “exit-on-reject”, a failed authentication attempt with TACACS+ (reject) would move onto the next authentication mechanisms (local)

SROS performs a AAA server health check by sending dummy authentication requests to a server and determines if the server is alive based on obtaining a response, this can end up with the authentication logs getting a lot of failed access attempts, however it can be disabled if desired:
*A:R1>config>system>security>password# no health-check
For this testing, I’ll be using telnet, so I need to enable the telnet-server (outside of a lab, I would not suggest this at all!)

*A:R1>config>system>security>password# back
*A:R1>config>system>security# telnet-server

So to recap the router configuration:
*A:R1>config>system>security# info
----------------------------------------------
            telnet-server
            profile "limited"
                default-action deny-all
                entry 10
                    match "show router route-table"
                    action permit
                exit
                entry 20
                    match "show users"
                    action permit
                exit
                entry 30
                    match "show system security user"
                    action permit
                exit
                entry 40
                    match "logout"
                    action permit
                exit
            exit
            password
                authentication-order tacplus local exit-on-reject
                no health-check
            exit
            tacplus
                authorization use-priv-lvl
                priv-lvl-map
                    priv-lvl 1 "limited"
                    priv-lvl 15 "administrative"
                exit
                timeout 5
                server 1 address 192.168.1.47 secret "1mSYRiobfhHAdFA9cZH3wBviQtXKFDld" hash2
            exit

Time to test if this works. Start the tacacs service on (m4600 has the IP of 192.168.1.47 which is what R1 will be communicating with)
root@m4600:~# tac_plus -d 16 -L -C /etc/tacacs+/tac_plus.conf
And start viewing syslog
root@m4600:~# tail -f /var/log/syslog
May 14 14:39:14 m4600 tac_plus[28164]: Reading config
May 14 14:39:14 m4600 tac_plus[28164]: Version F4.0.4.27a Initialized 1
May 14 14:39:14 m4600 tac_plus[28164]: tac_plus server F4.0.4.27a starting
May 14 14:39:14 m4600 tac_plus[28165]: Backgrounded
May 14 14:39:14 m4600 tac_plus[28166]: socket FD 0 AF 2
May 14 14:39:14 m4600 tac_plus[28166]: socket FD 2 AF 10
May 14 14:39:14 m4600 tac_plus[28166]: uid=0 euid=0 gid=0 egid=0 s=-1637085952

Open up another session on m4600 and telnet to 192.168.1.123 using the credentials of testadmin/pass:
May 14 14:39:23 m4600 tac_plus[28201]: connect from 192.168.1.123 [192.168.1.123]
May 14 14:39:23 m4600 tac_plus[28201]: cfg_acl_check(mgmt_acl, 192.168.1.123)
May 14 14:39:23 m4600 tac_plus[28201]: ip 192.168.1.123 matched permit regex 192\.168\.1\.([1-9]|[1-9]\d|1\d{2}|2[0-4]\d|25[0-4]) of acl filter mgmt_acl
May 14 14:39:23 m4600 tac_plus[28201]: host ACLs for user 'testadmin' permit
May 14 14:39:23 m4600 tac_plus[28201]: login query for 'testadmin' port console from 192.168.1.123 accepted
May 14 14:39:23 m4600 tac_plus[28202]: connect from 192.168.1.123 [192.168.1.123]
May 14 14:39:23 m4600 tac_plus[28202]: cfg_acl_check(mgmt_acl, 192.168.1.123)
May 14 14:39:23 m4600 tac_plus[28202]: ip 192.168.1.123 matched permit regex 192\.168\.1\.([1-9]|[1-9]\d|1\d{2}|2[0-4]\d|25[0-4]) of acl filter mgmt_acl
May 14 14:39:23 m4600 tac_plus[28202]: host ACLs for user 'testadmin' permit
May 14 14:39:23 m4600 tac_plus[28202]: authorization query for 'testadmin' console from 192.168.1.123 accepted

Lets go back to the telnet session and check who we are and our access rights:
*A:R1# show users
===============================================================================
User                             Type    Login time             Idle time
  From
===============================================================================
                                 Console       --               0d 00:00:21
  --
testadmin                        Telnet  14MAY2017 04:41:41     0d 00:00:00
  192.168.1.47
-------------------------------------------------------------------------------
Number of users : 1
===============================================================================
*A:R1>config>system>security# show system security user testadmin detail

===============================================================================
Users
===============================================================================
User ID      New User Permissions            Password   Login    Failed   Local
             Pwd console ftp li snmp netconf Expires    Attempts Logins   Conf
-------------------------------------------------------------------------------
testadmin    n   y       n   n  n    n       never      1        0        n
-------------------------------------------------------------------------------
Number of users : 1
===============================================================================

===============================================================================
Temporary User Configuration Detail
===============================================================================
===============================================================================
user id            : testadmin
-------------------------------------------------------------------------------
console parameters
-------------------------------------------------------------------------------
new pw required    : n/a                cannot change pw   : n/a
home directory     :
restricted to home : no
login exec file    :
profile            : administrative
locked-out         : no
===============================================================================

Okay, that’s good. Lets log out and log back in R1 using the credentials of testlimited/test:
May 14 14:43:37 m4600 tac_plus[29058]: connect from 192.168.1.123 [192.168.1.123]
May 14 14:43:37 m4600 tac_plus[29058]: cfg_acl_check(mgmt_acl, 192.168.1.123)
May 14 14:43:37 m4600 tac_plus[29058]: ip 192.168.1.123 matched permit regex 192\.168\.1\.([1-9]|[1-9]\d|1\d{2}|2[0-4]\d|25[0-4]) of acl filter mgmt_acl
May 14 14:43:37 m4600 tac_plus[29058]: host ACLs for user 'testlimited' permit
May 14 14:43:37 m4600 tac_plus[29058]: login query for 'testlimited' port telnet from 192.168.1.123 accepted
May 14 14:43:37 m4600 tac_plus[29059]: connect from 192.168.1.123 [192.168.1.123]
May 14 14:43:37 m4600 tac_plus[29059]: cfg_acl_check(mgmt_acl, 192.168.1.123)
May 14 14:43:37 m4600 tac_plus[29059]: ip 192.168.1.123 matched permit regex 192\.168\.1\.([1-9]|[1-9]\d|1\d{2}|2[0-4]\d|25[0-4]) of acl filter mgmt_acl
May 14 14:43:37 m4600 tac_plus[29059]: host ACLs for user 'testlimited' permit
May 14 14:43:37 m4600 tac_plus[29059]: authorization query for 'testlimited' telnet from 192.168.1.123 accepted

Looks promising from the TACACS server, lets go back to the telnet session and check who we are and our access rights:
*A:R1# show users
===============================================================================
User                             Type    Login time             Idle time
  From
===============================================================================
                                 Console       --               0d 00:04:55
  --
testlimited                      Telnet  14MAY2017 04:43:36     0d 00:00:00
  192.168.1.47
-------------------------------------------------------------------------------
Number of users : 1
===============================================================================
*A:R1# show router route-table

===============================================================================
Route Table (Router: Base)
===============================================================================
Dest Prefix[Flags]                            Type    Proto     Age        Pref
      Next Hop[Interface Name]                                    Metric
-------------------------------------------------------------------------------
192.168.1.0/24                                Local   Local     01h07m25s  0
       TACACS                                                       0
-------------------------------------------------------------------------------
No. of Routes: 1
Flags: n = Number of times nexthop is repeated
       B = BGP backup route available
       L = LFA nexthop available
       S = Sticky ECMP requested
===============================================================================
*A:R1# admin display-config
MINOR: CLI Command not allowed for this user.

Certainly appears to be a limited user,

*A:R1# show system security user testlimited detail

===============================================================================
Users
===============================================================================
User ID      New User Permissions            Password   Login    Failed   Local
             Pwd console ftp li snmp netconf Expires    Attempts Logins   Conf
-------------------------------------------------------------------------------
testlimited  n   y       n   n  n    n       never      1        0        n
-------------------------------------------------------------------------------
Number of users : 1
===============================================================================

===============================================================================
Temporary User Configuration Detail
===============================================================================
===============================================================================
user id            : testlimited
-------------------------------------------------------------------------------
console parameters
-------------------------------------------------------------------------------
new pw required    : n/a                cannot change pw   : n/a
home directory     :
restricted to home : no
login exec file    :
profile            : limited
locked-out         : no
===============================================================================

Okay, so we’re correctly associated with the limited profile account.

Role based access control is a good idea for managing your network and being able to leverage your existing AAA infrastructure helps make operating a heterogeneous network that little bit easier.

Published by

Adam

Adam enjoys playing with and learning about networks and is based in Queensland, Australia.