This is how to configure TACACS+ authentication and authorisation for the Cisco SSM On-Prem appliance using a free TACACS+ software implementation like below:

• TACACS+NG
• freeRADIUS
• tac_plus

I have found a Cisco forum configuration issue explaining the issue using Aruba's Clearpass and its solution. This is the only article I have found that has useful information and debugging hints leading to a working solution using any kind of TACACS+ protocol implementation.

What is the issue with SSM On-Prem and TACACS+ protocol authentication?

The SSM On-Prem TACACS+ authentication test ran in the web interface always SUCCEEDS but if a TACACS+ user authenticates it FAILS with following error on the SSM On-Prem side shown in the web user interface:

There is no easy way to debug this on the SSM side. To get to the bottom of the issue is run TACACS+ daemon in the debugging mode, debug authentication and debug authorization. The procedure described below will work for any kind of TACACS+ protocol issues with any application offering TACACS+ protocol support.

Running SSM On-Prem in QEMU/GNS3

Settings shown below are to ease your pain when running SSM On-Prem in a netlab environment. Settings are mandatory KVM/QEMU to get a running the SSM On-Prem appliance in GNS3.

• -cpu host setting is mandatory to the appliance being boot-able and install-able. Per default QEMU assigns virtual and emulated generic CPU type which breaks the installation and boot sequence right on. No installation or booting possible this way.

• Setting -enable-kvm imporves the appliance bootup and responce times significantly, much like 200% or even more.

• US keyboard layout is the default and not meant to be changed easy.

Apply these settings to be able to run CSSM in KVM/QEMU and GNS3:

-cpu host -smp 4 -enable-kvm

This will result in successful installation and running of SSM On-Prem if it is ran in GNS3.

TACACS+ protocol debug

click for more

Configure TACACS+ and LDAP authentication and authorization using users from a directory service. This is a GNS3 netlab the router operating system in this netlab is Cisco's IOS-XE. It will work with every other router too. I have written a lot of simple GNS3 TACACS+NG netlabs, that one is more complex but I plan to make it as simple as possible so you can rebuild it in your own network testing area. The components used in the netlab are following:

• TACACS+ appliance (TACACS+NG)
• LDAP appliance (LLDAP)
• IOS-XE router

Build the both appliances using alpine-linux, the resulting size for both appliances is 500MB. You need to build them by yourself, use following build instructions Building 64bit alpine linux GNS3 FRRouting appliance and add the software from above.

This netlab runs without enabling encryption protocol like LDAPS or TLS or HTTPS. It is not in the scope of the netlab to enable encryption at all. You SHOULD be able to add security protocols on top once everything is setup and working. The scope of this netlab is to build a simple environment where you can play with the programs and protocols. This is a sandbox solution.

Regarding LDAP the official TACACS+NG documentation states in section 5.1.LDAP Backends

mavis_tacplus-ng_ldap.pl is an authentication/authorization back-end for the external module. It interfaces to various kinds of LDAP servers, e.g. OpenLDAP, Fedora DS and Active Directory. The server type is detected automatically. Its behaviour is controlled by a list of environmental variables: ...

TACACS+NG has a very long list of environmental LDAP variables that might be worth reading about and tinkering with once everything is working as configured, to name a few:

• LDAP_FILTER
• LDAP_FILTER_GROUP
• LDAP_MEMBEROF_REGEX

Overview of the used IP addressing in this netlab

Overview of the data that needs to be configured in the directory service LDAP in the order of priority:

click for more

This is a followup to previous GNS3 netlab Configuring TACACS+NG and LDAP authentication. The goal of the previous netlab was to move user credentials and group management to a LDAP server. The goal was achieved.

Reading the TACACS+NG best practices first entry to use TLS/DTLS wherever possible:

TLS/DTLS

• Use TLS/DTLS wherever possible. tac_plus-ng support certificate based authentication, but also TLS pre-shared keys
• TLS only provides authentication. Use a (possibly and most likely custom) MAVIS backend for certificate-based host details ...

So following this advice and preferring LDAPS over LDAP communication.

But also at the same time:

The necessary information to setup a working LDAP GNS3 netlab are explained in the previous Configuring TACACS+NG and LDAP authentication blog entry. The goal of this GNS3 netlab will is the configuration process to use LDAPS as mandatory protocol to use between the TACACS+ daemon and the LDAP daemon.

Topology

Using the now ready setup and converged network topology from Configuring TACACS+NG and LDAP authentication:

IP topology of connected IP networks to router R1:

R1#sh ip int brie | e un
Interface              IP-Address      OK? Method Status                Protocol
Ethernet0/1            198.51.100.1    YES NVRAM  up                    up
Ethernet0/2            203.0.113.1     YES NVRAM  up                    up
Ethernet0/3            10.100.100.1    YES NVRAM  up                    up
Ethernet1/1            10.100.200.50   YES NVRAM  up                    up

Network is converged and ready to use.

click for more

TACACS+ configuration using Huawei's (VRP) OS. This is about configuring authentication and authorization using the TACACS+ protocol. Usually or the universal approach, that works among all routers, is set a value to the wide used VSA priv-lvl which is explained in Configuring TACACS+NG authentication for VRP - blog entry.

Obvious at the start, I am not much of a VRP expert myself. This blog entry is about how to configure TACACS+NG to assign VRP RBAC roles to authenticating users in a simple nutshell networking lab. So email me please, if you have something to correct in this approach.

Most big vendor's router/switch/firewall OS implementations offer RBAC based profile assignment. Huawei's VRP has RBAC in place to be used. How to configure using TACACS+NG and assign VRP RBAC roles to authenticating users.

The initial VRP basic configuration steps are explained Configuring TACACS+NG authentication for VRP. a blog entry about AUTHENTICATION only, using priv-lvl assignment. The approach that every professional router OS offers when it comes to basic AAA configuration,

The TACACS+ daemon used in this netlab is Marc Hubers's Pro-Bono-Publico: TACACS+NG.

Using both at same time, would add another level of complexity. This example is meant to be simple. The priv-lvl assignment configuration using TACACS+NG is already explained in Configuring TACACS+NG authentication for VRP netlab.

Topology

IP addressing

The IP addressing used in this netlab. 3 appliances:

TACACS+ daemon settings:

R1's connected interfaces:

R1#sh ip int brie | e un
Interface              IP-Address      OK? Method Status                Protocol
Ethernet0/0            10.100.200.50   YES NVRAM  up                    up
Ethernet0/2            10.100.100.1    YES manual up                    up
Ethernet0/3            10.100.250.1    YES manual up                    up

R1 IP connected routes, overview in CIDR notation showing the connected subnet mask to interface:

R1#sh ip route connected | i C
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
C        10.100.100.0/24 is directly connected, Ethernet0/2
C        10.100.200.48/30 is directly connected, Ethernet0/0
C        10.100.250.0/24 is directly connected, Ethernet0/3

Testing authentication is done from the node-10 to the router R108 using telnet protocol.

R1 is forwarding IP packets and has no other role, R1 is a symbol for a dynamic routed enterprise network. IP routing within a secure domain.

User settings overview related to the TACACS+ configuration:

click for more