Die Ausgangssituation

Einer meiner Kunden benötigte vor kurzem Unterstützung bei der AAA-Integration seiner Cisco Nexus 9k Datacenter Switches per TACACS+ an eine Cisco ISE als Authentication Server. Ich bot an die benötigten Befehle für NX-OS zusammenzustellen und diese im Anschluss mit ihm gemeinsam einzurichten.

Die Herausforderung für mich bestand darin, dass ich bis dato über keine relevanten Hands-On Erfahrungen mit Cisco Nexus verfüge und demzufolge auch nicht auf entsprechende Beispielconfigs zurückgreifen konnte. Von daher war ich im ersten Schritt darauf angewiesen die benötigten Zeilen in NX-OS Syntax anhand der offiziellen Configuration Guides zusammenzustellen. 

Mein erster Entwurf eines entsprechenden Templates sah wie folgt aus:

feature tacacs+
!
tacacs-server host {{ tacacs-server.ip }} key {{ tacacs-server.key }}
ip tacacs source-interface {{ mgmtInt }}
!
aaa group server tacacs+ AAA_TACACS
 server {{ tacacs-server.ip }}
 source-interface {{ mgmtInt }}
aaa authentication login default group AAA_TACACS
aaa authentication login console group AAA_TACACS
aaa accounting default group AAA_TACACS
aaa authentication login invalid-username-log
aaa authentication login error-enable

Ich wollte aber nicht nur stumpf ein paar Config-Befehle mit dem Hinweis “sollte theoretisch funktionieren” übergeben, sondern die tatsächliche Funktionalität im Vorfeld auch verifizieren. Dies hat darüber hinaus den Vorteil gleich die notwendigen Troubleshooting-Methoden kennenzulernen, sofern es nicht auf Anhieb funktionieren sollte. 🤓

Cisco Modeling Labs zur Rettung

Für dieses Unterfangen ist bspw. Cisco CML in der Version 2.9 prädestiniert, denn es verfügt sowohl über ein Cisco Nexus 9000v Image als auch eine Cisco ISE Appliance.

📝 Hinweis
Die Cisco ISE Appliance ist Teil des “supplemental reference platform ISO”, das ausschließlich Nutzern mit aktiver Personal, Personal Plus, Enterprise, oder Education Lizenz zur Verfügung steht. In der kostenlosen CML-Free Variante kann die ISE von daher nicht genutzt werden.
Ein einfaches Setup, dass die Anforderungen meines Anwendungsfalls abdeckt, würde inkl. einem Admin-Host auf Linux-Basis in etwa so aussehen: Cisco Nexus AAA-Test Lab-Setup

Cisco ISE - das Schwergewicht

Bevor man hier aber allzu voreilig das Lab inkl. Identity Services Engine zusammenklickt und startet, ist ein Blick in den zugehörigen Installation Guide zu empfehlen. Selbst im minimalen “Evaluation” Deployment benötigt die ISE stolze 300GB Speicherplatz, was sicher dem ein oder anderen CML-Host Schwierigkeiten bereiten könnte. Da HW-Ressourcen nicht unendlich zur Verfügung stehen und ich für meinen Use-Case nicht auf eine vollumfängliche ISE-Instanz angewiesen war, musste eine Alternative gefunden werden.

TAC_PLUS Container - die smarte Alternative

Interessanterweise wurde mit Cisco CML v2.9 nicht nur eine virtuelle ISE, sondern auch der Support für Docker-Container integriert. Dies ermöglicht es, neben den typischen VM-basierten Nodes auch simple containerisierte Anwendungen zu nutzen. Von denen hat Cisco auch direkt ein paar sehr nützliche Exemplare hinterlegt - neben typischen Netz-Diensten (DNS, DHCP, TFTP, Syslog), Web-Browsern und -Servern sowie weiteren Tools findet sich u.a. auch ein RADIUS- und ein TACACS+ Container.

Dieser TACACS+ Server basiert auf dem tac_plus Daemon, der ursprünglich von Shrubbery Networks entwickelt und gepflegt wurde. Für meinen simplen Use Case war das vollkommen ausreichend letztlich genau das was ich gesucht habe.

Das Setup

Ich ersetze in meinem Lab also kurzerhand die ISE durch den simplen tac_plus Daemon. Die Nutzung dieses Containers ist dann auch sehr einfach gestaltet, denn von Haus aus verfügt er bereits über eine vordefinierte Basiskonfiguration, die bereits ein simples Policy Set sowie die Definition der NAS Devices inkl. Shared secret beinhaltet. Dieses Config-File kann über den Node-Reiter “Config” > “Configuration File”: “tac_plus.conf” angezeigt werden: TAC_PLUS Config File

ℹ️ Info

Sofern erforderlich lässt sich die Konfiguration natürlich auch noch anpassen und erweitern. Es gibt leider keine aktuelle und vollständige Doku, aber die folgenden Links finde ich ganz hilfreich:

Zusätzlich zur TACACS-Konfiguration benötigt der Container natürlich auch noch eine IP-Config für das Interface mit dem er mit unserem Cisco Nexus verbunden ist. Hier kann man wie für alle Linux Hosts bzw. Container in CML mit einem simplen startup Skript (“Config” > “Configuration File”: “boot.sh”) die Einstellungen beim Hochfahren statisch festlegen. TAC_PLUS IP-Config

Im Anschluss muss nur noch die Config des Cisco Nexus inkl. der AAA-Befehle zur Anbindung an den TACACS-Container finalisiert und ausgerollt werden:

feature tacacs+
feature interface-vlan
!
tacacs-server host 192.168.255.100 key tacacs123
ip tacacs source-interface Vlan10
!
aaa group server tacacs+ AAA_TACACS
 server 192.168.255.100
 source-interface Vlan10
aaa authentication login default group AAA_TACACS
aaa authentication login console group AAA_TACACS
aaa accounting default group AAA_TACACS
aaa authentication login invalid-username-log
aaa authentication login error-enable
!
vlan 10
  name AAA_Test
!
interface Vlan10
  no shutdown
  ip address 192.168.255.1/24
!
interface Ethernet1/1
  switchport access vlan 10
  spanning-tree port type edge
!
interface Ethernet1/2
  switchport access vlan 10
  spanning-tree port type edge
ℹ️ Info
Ich verwende in diesem Fall nicht das OOB-Management Interface des Nexus. Der Remote-Zugriff sowie die TACACS-Anfragen erfolgen inband über das SVI im VLAN10.

Unerwartete Probleme

Nachdem nun alle Systeme vorbereitet und verkabelt waren, war die Zeit reif für den finalen Test, der darin bestand eine SSH Session vom Linux Hosts zum Cisco Nexus zu öffnen und sich dann mit den im TACACS-Server hinterlegten Informationen anzumelden. Allerdings musste ich zu meiner Enttäuschung feststellen, dass weder der Login mit dem tacadmin User, noch mit dem tacoper User möglich war und der SSH-Zugriff somit verwehrt blieb ⛔🙁. Da meine Console-Session über die CML-Node noch aktv war, konnte ich das Problem über diesen Weg allerdings weiter eingrenzen.

Durch Auswertung entsprechender Debugs am Switch sowie der Logs am TACACS-Server, konnte ich zumindest schon mal verifizieren, dass die Anfragen am Server eingingen und auch nicht etwa wegen einem fehlerhaften Key verworfen wurden. Das Problem musste also woanders liegen und beim weiteren Troubleshooting stieß ich auf folgende Log am Server:

connect from 192.168.255.1 [192.168.255.1]
pap-login query for 'tacadmin' port 0 from 192.168.255.1 rejected
login failure: tacadmin 192.168.255.1 (192.168.255.1) 0

Scheinbar gab es ein Problem mit dem Authentifizierungsprotokoll im Zusammenspiel zw. Cisco Nexus und TACACS-Server. Wenn nicht anders konfiguriert, dann sendet NX-OS die TACACS-Anfrage per simpler PAP-Authentifizierung. Das scheint der tac_plus Container in der aktuellen Konfiguration nicht zu akzeptieren. Ich habe von daher noch mal im Configuration Guide für NX-OS recherchiert und festgestellt, dass man dieses Verhalten bspw. auch auf die sog. ASCII-Authentication umstellen kann:

aaa authentication login ascii-authentication

Und siehe da 💡 - nachdem ich den Befehl auf dem Nexus hinzugefügt habe, konnte ich mich schlussendlich erfolgreich mit den verschiedenen Usern anmelden und auch die Autorisierung der zugehörigen Berechtigungsstufen (Admin / Read-only) erfolgte wie gewünscht ✅. Die entsprechenden Logs am Server sehen dann wie folgt aus:

connect from 192.168.255.1 [192.168.255.1]
login query for 'tacadmin' port 0 from 192.168.255.1 accepted
connect from 192.168.255.1 [192.168.255.1]
Start authorization request
do_author: user='tacadmin'
user 'tacadmin' found
exec authorization request for tacadmin
exec is explicitly permitted by line 11
nas:service=shell (passed thru)
nas:cmd= (passed thru)
nas:cisco-av-pair* svr:absent/deny -> delete cisco-av-pair* (i)
nas:shell:roles* svr:absent/deny -> delete shell:roles* (i)
nas:absent, server:priv-lvl=15 -> add priv-lvl=15 (k)
replaced 2 args
authorization query for 'tacadmin' 0 from 192.168.255.1 accepted

Das Fazit

Als Fazit lässt sich also festhalten, dass mit dem Tacacs Server Container Image ein extrem nützlicher und leichtgewichtiger Container in CML ab Version 2.9 zur Verfügung steht, mit dem man in kürzester Zeit die AAA Funktionalitäten in Kombination mit verschiedenen Geräten bzw. Konfiguration verproben kann. Sollte darüber hinaus auch die Anforderung bestehen weitere AAA-Funktionalitäten per RADIUS umzusetzen, beinhaltet CML v2.9 wie erwähnt auch einen entsprechenden FreeRADIUS Container. Somit ist man für simple Use-Cases und Integrationstests nicht mehr darauf angewiesen eine ressourcen-intensive Identity Services Engine inkl. komplexer Policy-Logik zu implementieren.

Wenn ihr das Ganze selbst ausprobieren wollt, dabei aber die Stolpersteine vermeiden möchtet, die mich aus dem Tritt gebracht haben, könnt ihr das komplette CML Lab inkl. aller Konfigurationen im zugehörigen GitHub Repo herunterladen.