Damit unterschiedliche Administratoren oder Benutzer nicht auf jedem Cisco-Switch, -Router, -Controller o.ä. einzeln verwaltet werden müssen, bietet sich die Möglichkeit an, diese Zugriffe (z.B. per Secure Shell oder Console) über einen RADIUS-Server wie den Microsoft Network Policy Server (NPS) 2016 zu authentifizieren und zu autorisieren. Ein kleines “How-To”.
Konfiguration der Cisco Geräte (IOS, IOS-XE)
Auf den Geräten (wie Switches, Routern o.ä.) ist im ersten Schritt Tripple-A (AAA) zu aktivieren. Dies erfolgt über:
aaa new-model
Anschließend können einzelne oder mehrere RADIUS-Server (bzw. NPS-Server) hinterlegt werden:
radius server NPS-SERVER1 address ipv4 10.0.0.1 auth-port 1645 acct-port 1646 key SUPERGEHEIMESPASSWORT radius server NPS-SERVER2 address ipv4 10.0.0.2 auth-port 1645 acct-port 1646 key ANDERESGEHEIMESPASSWORT
Schlussendlich sind noch die aaa-Policies zu definieren:
aaa authentication login default local group radius aaa authorization exec default local group radius if-authenticated
Hierbei ist insbesondere darauf zu achten, dass bei der Autorisierung der Parameter “if-authenticated” angegeben wird. Dieser stellt sicher, dass der Nutzer vor der Autorisierung auch definitiv authentifiziert wurde.
Zudem legt die Reihenfolge “local group radius” fest, dass erst in der lokalen Nutzerdatenbank nachgesehen wird, bevor der RADIUS-Server (bzw. die RADIUS-Server Gruppe) eine Anfrage erhält. Ein wichtiges Kriterium um sich bei einem fehlerhaften NPS-Server oder dessen Regelwerk nicht selbst aus den Netzwerkgeräten auszusperren. Sollte hingegen schlichtweg immer über den RADIUS das AAA durchgeführt werden, kann die Reihenfolge auch gedreht oder auf das local schlichtweg verzichtet werden. Persönlich würde ich jedoch ausdrücklich davon abraten!
Konfiguration des Microsoft Network Policy Server (NPS) 2016
Die Rollte “Netzwerkrichtlinienserver” sollte ebenso wie die Registrierung dessen in Active Directory bereits erfolgt sein. Über das entsprechende MMC-Snap-In ist dann eine neue Netzwerkrichtlinie zu erstellen.
Als nächstes wird der Name der Policy definiert. Ebenso wie die Berechtigung “Zugriff gewähren”. Der Typ des NPS bleibt “nicht angegeben”.
Über die Bedingungen wird angegeben, welche Kriterien der Supplicant (in diesem Falle der Switch oder Router) erfüllen muss, damit das Regelwerk greift. Zum einen wäre die Eingrenzung auf ein Subnetz (MGMT-Netzwerk) denkbar, zum anderen sollte die administrative Benutzergruppe aus dem Active Directory abgefragt werden. Dazu kommen die Bedingungen “Windows Gruppe” und “NAS IPv4-Adresse” zum Einsatz. Während die Windows Gruppe keine Probleme darstellen sollte, muss bei der IPv4-Adresseingabe besonders auf die von Microsoft geforderte Syntax geachtet werden. So ist für den IP-Adressbereich 10.0.0.0/24 folgendes Format zu verwenden:
"10\.0\.0\..+" (inklusive der Anführungszeichen!)
Der entsprechende Microsoft Docs Artikel zu regulären Ausrücken der NPS-Rolle lässt kaum Wünsche offen und kann gerne parallel studiert werden. Klickt dazu hier: https://docs.microsoft.com/de-de/windows-server/networking/technologies/nps/nps-crp-reg-expressions
Mittels der Einschränkungen wird lediglich festgelegt, dass die Anmeldung “unverschlüsselt” über PAP erfolgt. Alle anderen Häkchen und EAP-Typen sollten verschwinden. Schade, mehr unterstützt Cisco hier leider nicht. Über die Sicherheit des Ganzen lässt sich daher sicherlich (an anderer Stelle) debattieren!
Zu guter Letzt gehören alle vordefinierten Service-Typen unter den Einstellungen entfernt und lediglich “NAS Prompt” oder “Administrative” hinzugefügt.
Über die herstellerspezifischen RADIUS-Attribute ist jedoch eine weitgehendere Konfiguration möglich. Über das Attribut “Cisco-AV Pair” lässt sich der folgende Wert konfigurieren:
shell:priv-lvl=15
Das privilege-level gibt an, welche Berechtigungen der angemeldete Nutzer (dessen Autorisierung) schlussendlich auf dem Gerät erhalten soll. Von 0 (keine Rechte) bis 15 (volle Berechtigung) lässt sich hier differenzieren. Mehr dazu kann im Cisco Learning-Network nachgelesen werden. Klickt dazu hier: https://learningnetwork.cisco.com/docs/DOC-15878
Über die Bedingung “Windows-Gruppe” und das RADIUS-Attribut “Cisco AV-Pair” und den Wert “shell:priv-lvl=xx” lässt sich schlussendlich zwischen Interessengruppen unterscheiden. Administratoren erhalten vollen Zugriff, Mitarbeiter aus dem Helpdesk ggf. eingeschränkte Leserechte. Der Kreativität sind keine Grenzen gesetzt.
Der Authentifizierung und Autorisierung von Cisco Geräten über Microsoft NPS 2016 steht nichts mehr im Wege. Es sollte alles einwandfrei funktionieren!
Update 1: Konfiguration für NX-OS
Aus aktuellem Anlass hier noch die entsprechenden Konfigurationen für Cisco Nexus Switches unter dem Betriebssystem NX-OS:
ip radius source-interface mgmt 0 aaa authentication login default group RADIUS-SERVER local radius-server host 10.0.0.1 key EIGENESPW auth-port 1645 acct-port 1646 authentication radius-server host 10.0.0.2 key NOCHEINES auth-port 1645 acct-port 1646 authentication aaa group server radius RADIUS-SERVER server 10.0.0.1 server 10.0.0.2 source-interface mgmt0
Zusätzlich muss dem Shell:priv-Parameter noch eine Ergänzung für das NX-OS Rollensystem hinzugefügt werden. In Nexus OS entspricht Priv-lvl 15 der Rolle “network-admin”. Die Regeln können separiert werden oder in einer zusammengefasst.
shell:roles*"network-admin vdc-admin"
Über den Autor