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.plis 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
| Hostname | Term | IP address | Function |
|---|---|---|---|
| R101 | NAS | 10.100.100.101 | Testrouter |
| LDAP-10 | LDAP | 198.51.100.10 | directory service |
| AAA-49 | TACACS+ | 10.100.200.49 | TACACS+ daemon |
Overview of the data that needs to be configured in the directory service LDAP in the order of priority:
| Name | Type | Password | Group |
|---|---|---|---|
| ldapadmin | person | ldapadmin | lldap_admin |
| ro | person | readonly | lldap_strict_readonly |
| NOC | group |
|
- |
| cisco | person | cisco123 | NOC |
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:
Your username and/or password does not match our records, kindly try again. If the problem persists, please use 'Forgot Password', or contact your System Administrator.
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 hostsetting 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-kvmimporves 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
The freeRADIUS 4.0 (alpha) release notes, this is taken from the official announcement.
This version of a freeRADIUS would not be as interesting if it did not ship new protocol support. Since the release of the official TACACS+ RFC, now over 5 years agofew years ago, software projects have now the fundamental information they needed to be able to implement TACACS+ protocol support for their software.
Now the alpha freeRADIUS announcement is not 2 years old. But for myself it is new information. This is a reminder build a simple netlab with the freeRADIUS 4.0 version and setup a virtual TACACS+ daemon.
Well not to the news there on the website:
The Good News
- RADIUS Of course.
- DHCPv4 This is now fully supported as a native protocol, and is not "faked out" by pretending it is RADIUS.
- DHCPv6 All DHCPv6 options are supported. The DHPv6 group nesting was a major contributor to the delay in v4.
- TACACS+ Full support for TACACS+.
- cron Simplistic cron jobs can be schedule to perform time-based actions.
The Bad News
This is an "alpha" release. It may crash, and certain feature sets are limited, as noted below.
- RADIUS RADIUS/TLS (RadSec) is not supported. PEAP, TTLS, EAP-FAST, and TEAP are not supported.
- DHCPv4 Relaying has limited support.
- DHCPv6 Relaying has limited support.
- TACACS+ There are a large number of "odd" TACACS+ implementations. We have not tested interoperability with them all.
- cron There is limited support for adding and deleting cron timers "on the fly".
A new, independent and free and open TACACS+ implementation available. Here the download links:
I will build it from the source rather than installing a binary. Before a netlab check the TACACS+ bugs situation:
A interesting bug report where the default example configuration is found, which is one-to-one example from the docs. Good starting point.
References
This is a backbone setup or router infrastructure scenario, using IPv6 only, SR-MPLS, IS-IS, iBGP. Most basic type of a layer 3 iBGP VPN. The BGP speakers are not directly connected and must use other protocols to transport that IP packet across the backbone to its target. More details on the used network topology and its configuration can be found in the BRKSPG-2203 presentation (Slide Nr. 48/Page Nr. 116).BRKSPG-2203.
FRRouting 10.3.1 (PE1) on Linux(6.12.31-0-lts) Copyright 1996-2005 Kunihiro Ishiguro, et al. configured with: ...
FRRouting version and the linux kernel used in this netlab on all routers.
Network topology
Star topology, where all PE edge routers are not directly connected.
PE2
|
|
PE1 -- P1 -- PE3
|
|
RRv6
- All links are IPv6 only
- All links are (IS-IS) point to point
- IPv4 only on PE router ports
eth6-8
Table overview of the configured router-id's, labels, and the NSAP addresses.
| Router | v4 router-id | v6 router-id | label index | NSAP address |
|---|---|---|---|---|
| P1 | 1.2.3.4 | a::1234 | 1236 | 49.0001.1234.1234.1234.00 |
| PE1 | 1.1.1.1 | a::1 | 106 | 49.0001.1111.1111.1111.00 |
| PE2 | 2.2.2.2 | a::2 | 206 | 49.0001.2222.2222.2222.00 |
| PE3 | 3.3.3.3 | a::3 | 306 | 49.0001.3333.3333.3333.00 |
| RRv6 | 6.6.6.6 | a::6 | 606 | 49.0001.6666.6666.6666.00 |
Labels are only created for IPv6 prefixes, no labels for IPv4. All IS-IS routers are level-2-only. PE routers have internal BGP neighorship to the BGP route reflector RRv6.
This is a follow up netlab article about EXOS ESRP simple setup configuration. The prerequisite is the EXOS ESRP adding OSPF. In this step, the ospfrid will be configured and loopback interfaces created and added to OSPF. Routers RS3 and RS4 which have the same ospfrid - 5.5.5.5. Both routers configuration will be changed.
The goal is to get the floating IP prefix 10.1.2.0/24 stable and minimise the amount of generated OSPF events in the area 0. By applying this the network solution using ESRP should get deterministic and operative.
network topology
OSPF configuration is added to RS3 and RS4 only on top of already running and configuration from previous ESRP article EXOS ESRP adding OSPF:
OSPF router-id overview:
| sysName | ospf router-id |
|---|---|
| RS1 | 1.1.1.1 |
| RS2 | 2.2.2.2 |
| RS3 | 3.3.3.3 |
| RS4 | 4.4.4.4 |
Network topology showing relevant IP and OSPF settings:
1.1.1.1 2.2.2.2
+-------+ +-------+
| | 12 12 | |
| RS1 |-----------------------------------| RS2 |
| | | |
+-------+ +-------+
10 | | 10
| (OSPF) |
| |
| |
3.3.3.3 4.4.4.4
+-------+ +-------+
| | 3 3 | |
| RS3 +-----------------------------------+ RS4 |
| | | |
+---+---+ +---+---+
1 | | 1
| ESRP VR1 |
| 10.1.2.3 |
| |
| +-------+ |
| | | |
+-----------------+ RS5 +-----------------+
| |
+-+---+-+
| |
+-------------+ +-------------+
| eth0 eth0 |
+---+---+ +---+---+
| | | |
| node1 | | node2 |
| | | |
+-------+ +-------+
EXOS version
EXOS version used in this netlab:
Card Partition Installation Date Version Name Branch ------------------------------------------------------------------------------ Switch primary Thu Jan 16 13:06:22 UTC 2025 32.7.2.19 rescue.xos 32.7.2.19 Switch secondary Thu Jan 16 13:06:22 UTC 2025 32.7.2.19 rescue.xos 32.7.2.19
This is a follow up netlab article about EXOS ESRP simple setup configuration. The prerequisite is the EXOS ESRP simple setup. In this blog entry 2 new OSPF are added to the network topology, RS1 and RS2, OSPF configuration is added to all routers in the network topology. RS5 is only a switch, nothing is added there. OSPF configuration is added to verify how this vendor described ESRP design is behaving having fully working network topology. This is the simplest EXOS ESRP setup scenario taken from of the Extreme Networks official documentation.
Once again I want to mention this is a blind configuration, I have no experience at all with ESRP, just being curious to see this networking example and learn about EXOS ESRP configuration and operation and how quickly it converges using this example.
network topology
OSPF configuration is added to all topology routers, on top of already running and configured ESRP article from previous blog entry.
| sysName | ospf router-id |
|---|---|
| RS1 | 1.1.1.1 |
| RS2 | 2.2.2.2 |
| RS3 | 5.5.5.5 |
| RS4 | 5.5.5.5 |
Network topology showing relevant IP and OSPF settings:
1.1.1.1 2.2.2.2
+-------+ +-------+
| | 12 12 | |
| RS1 |-----------------------------------| RS2 |
| | | |
+-------+ +-------+
10 | | 10
| (OSPF) |
| |
| |
5.5.5.5 5.5.5.5
+-------+ +-------+
| | 3 3 | |
| RS3 +-----------------------------------+ RS4 |
| | | |
+---+---+ +---+---+
1 | | 1
| ESRP VR1 |
| 10.1.2.3 |
| |
| +-------+ |
| | | |
+-----------------+ RS5 +-----------------+
| |
+-+---+-+
| |
+-------------+ +-------------+
| eth0 eth0 |
+---+---+ +---+---+
| | | |
| node1 | | node2 |
| | | |
+-------+ +-------+
Added port numbers to the network topology above to have a overview how routers are connected in case someone wants to test it by yourself.
EXOS version
EXOS version used in this netlab:
Card Partition Installation Date Version Name Branch ------------------------------------------------------------------------------ Switch primary Thu Jan 16 13:06:22 UTC 2025 32.7.2.19 rescue.xos 32.7.2.19 Switch secondary Thu Jan 16 13:06:22 UTC 2025 32.7.2.19 rescue.xos 32.7.2.19
FHRP protocols are my least favourite topic. Knowing VRRP and HSRP and little of GLBP from configuration and operating side, i have been curious about the EXOS ESRP (FHRP) protocol. Never seen it in action or had the chance to configure it. The FHRP protocol family are most vendor specific and use vendor proprietary protocols. VRRP is the only FHRP protocol that is available on every other networking vendors hardware and software. But VRRP is not the topic here.
This is the simplest EXOS ESRP setup scenario taken from of the Extreme Networks official documentation
This is a rookie netlab, I have never configured ESRP before. So if you spot obvious errors, please write me an email, I will try to correct these.
Network topology
The ESRP configuration example shows a network topology is like following:
+-------+ +-------+
| | | |
| RS1 |-----------------------------------| RS2 |
| | | |
+-------+ +-------+
| |
| (OSPF or RIP) |
| |
routerid routerid
5.5.5.5 5.5.5.5
+-------+ +-------+
| | | |
| RS3 +-----------------------------------+ RS4 |
| | | |
+---+---+ +---+---+
| |
| ESRP VR1 |
| 10.1.2.3 |
| |
| +-------+ |
| | | |
+-----------------+ RS5 +-----------------+
| |
+-+---+-+
| |
+-------------+ +-------------+
| eth0 eth0 |
+---+---+ +---+---+
| | | |
| node1 | | node2 |
| | | |
+-------+ +-------+
The network topology is named Single ESRP Domain Using Layer 2 and Layer 3 Redundancy. OSPF or RIP configuration on RS1/RS2 are not part of the example configuration. This is a ESRP only setup example only.
The network topology above is the simpler version of the one shown on the official vendors website.
EXOS version
This is the EXOS version used in this netlab:
Card Partition Installation Date Version Name Branch ------------------------------------------------------------------------------ Switch primary Thu Jan 16 13:06:22 UTC 2025 32.7.2.19 rescue.xos 32.7.2.19 Switch secondary Thu Jan 16 13:06:22 UTC 2025 32.7.2.19 rescue.xos 32.7.2.19
The most recent image that is available from the official Extreme Networks github repository.