Nachdem der RADIUS Server konfiguriert ist geht es an die Konfiguration des Clients.
Bei Cisco muss dazu das “neue” AAA Model aktiviert werden. Das geht einfach mit folgendem Befehl:
aaa new-model
Lokale Authentifizierung
Achtung: nach absetzen dieses Befehls ist das neue Model aktiv, d.h. man kann sich nur mehr mit Benutzername und Passwort anmelden. Man sollte jetzt einen lokalen Benutzer angelegen, dieser kann auch im Fallback Fall, also wenn der RADIUS Server nicht erreichbar ist, verwendet werden. Mit folgendem Befehl legt man einen lokalen User cisco mit Passwort cisco an:
username cisco secret cisco
Radius Server
Bevor man RADIUS als Authentifizierung verwenden kann muss ein RADIUS Server konfiguriert werden. Mit folgenden Befehlen konfiguriert man den RADIUS Server 10.1.1.100 und den entsprechendem Pre-Shared Key. RADIUS verwendet standardmäßig die UDP Ports 1812 und 1813 für Authentifizierung und Accounting, Cisco Geräte verwenden die Ports 1645 und 1646, das kann man evtl. mit “auth-port 1812 acct-port 1813” ändern. Der NPS RADIUS Server antwortet auf beide Varianten, man muss das also nicht definieren.
radius-server host 10.1.1.100 key PRE_SHARED_KEY
Mit “radius-server retransmit x” kann man angeben wie oft eine Anfrage gesendet wird wenn innerhalb des Timeouts keine Antwort kommt. Das Zeitfenster für das Timeout kann mit “radius-server timeout x” auf x Sekunden erhöht werden. Das Interface über welches der Cisco Switch die RADIUS Anfrage schickt kann mit “ip radius source-interface x” angegeben werden.
AAA Listen
Das AAA Authentication Model arbeitet mit Listen, man definiert eine Liste und weißt diese Liste einem Interface zu. Die Liste “default” gilt für alle Interfaces auf denen keine andere Liste gebunden ist. Folgender Befehl setzt die Standardauthentifizierung auf RADIUS, Fallback (RADIUS nicht erreichbar) ist local:
aaa authentication login default group radius local
Ab diesem Zeitpunkt muss man sich an allen Interfaces mit Benutzername und Passwort vom RADIUS Server anmelden.
Wenn die Netzwerkgeräte in sicheren Serverräumen untergebracht sind kann man sich überlegen die Authentifizierung für den Console Port zu deaktivieren, damit man im Desaster Fall noch eine letzte Hoffnung auf Zugriff hat. Dazu legt man eine Liste an und setzt die Authentifizierung auf “none”, danach bindet man die Liste auf “line con 0”:
line con 0 Am RADIUS Server habe ich in den Settings das Attribut Service-Type auf “Administrative” gesetzt. Dadurch müsste ich eigentlich im “enable” Mode landen. Das funktionier jedoch erst nachdem auch die Authorization auf RADIUS gesetzt wurde. Folder Befehl legt fest dass RADIUS für alle Interfaces verwendet wird, die Console ist dabei ausgeschlossen: Um Authorization auf der Console über RADIUS zu aktivieren wird folgender Befehl verwendet: Wenn ich mich erneut anmelden lande ich direkt im “Enable” Mode des Switches. Am NPS wird im Event Log Security ein Event 6272 aufgezeichnet, außerdem wird im Logfile (D:\NPS\LogFiles) ein Eintrag hinzugefügt. Mit Wireshark o.ä. sieht man ein RADIUS Access-Request Paket vom Switch zum NPS Server und ein RADIUS Access-Accept Paket vom NPS Server zum Switch. Das Access-Request Paket enthält unter anderem folgende Informationen: User-Name: Der Benutzer der sich am RADIUS Client anmeldet Calling-Station-Id: IP Adresse des Clients (der z.B. die Telnet Session öffnet) NAS-IP-Address: IP Adresse des RADIUS Clients Das Access-Accept Paket enthält die AV-Pair Informationen: AVP: Attribute Value Pair das am NPS konfiguriert wurde (Service-Type: Administrative) tomaaa authentication login liste1 none</p>
login authentication liste1</code>Authorization
aaa authorization exec default group radius localaaa authorization consoleLogging
Sniffing