Tags: Remote Access, Authentifizierung, Switch
In diesem Text erkläre ich, wie man RADIUS-Clients via GUI oder PowerShell zu NPS hinzufügt. Die Authentifizierung, Autorisierung und Zugriffsrechte lassen sich dann über Connection Request Policies und Network Policies regeln. Schließlich nutze ich ein Vendor-Attribut, um Admin-Rechte auf einem Switch zu vergeben.
Wenn ich Clients in meinen RADIUS-Server aufnehmen möchte, dann sollte ich mir vorher Gedanken zum allgemeinen Ablauf des Onboarding-Prozesses machen. Hier sind die wesentlichen Schritte in der passenden Reihenfolge:
- Erfassung von Device-Typ, Name, IP-Adresse, Verschlüsselungsart, eventuell benötigte Vendor-Attribute
- Netzwerk freischalten zwischen RADIUS-Client und NPS-Server auf den Ports 12812, 1645, 1813, 1646
- AD-Benutzer identifizieren, die Zugriff erhalten sollen
- AD-Gruppe erstellen und diese Benutzer hinzufügen
- Shared Secret definieren und den Admins der RADIUS-Clients schicken
- RADIUS-Client einrichten
- RADIUS-Server-IP und das Shared Secret im RADIUS-Client eintragen
- NPS-Network-Policy erstellen
- Testen
RADIUS-Clients erstellen
Einzelne RADIUS-Clients lassen sich bequem per GUI anlegen. Öffnen Sie dazu die NPS-Konsole, klicken Sie mit der rechten Maustaste auf RADIUS Clients und wählen dann New aus.
Danach tragen Sie den Namen, die IP sowie das Secret (also das Passwort) ein und bestätigen mit OK.
Um mehrere Clients gleichzeitig anzulegen, empfiehlt sich der Einsatz von PowerShell. Dazu kann man folgendes Script verwenden, das die Werte aus einer CSV-Datei ausliest:
Nach Ausführen des Scripts werden die eben angelegten RADIUS-Clients mit den dazugehörigen Werten in der Konsole ausgegeben.
Connection Request Policy
Connection Request Policies enthalten Bedingungen, die festlegen, welche RADIUS-Server die Authentifizierung und Autorisierung von Verbindungsanfragen der Clients übernehmen. Wenn der NPS-Server als RADIUS-Proxy fungiert, dann lassen sich damit Anfragen oder auch Accounting-Informationen an einen RADIUS-Server weiterleiten.
Dabei können folgende Faktoren berücksichtigt werden:
- Zeit und Wochentag
- Der Bereichsname (realm name) in der Verbindungsanfrage
- Die Art der angeforderten Verbindung
- Die IP-Adresse des RADIUS-Clients
Da wir in unserem Beispiel die Bedingungen für den Zugriff in der Netzwerkrichtlinie festlegen, man aber eine Connection Request Policy benötigt, lege ich eine zeitbasierte an, die Anfragen immer (24/7) annimmt. Zu diesem Zweck klicken wir zuerst rechts auf Connection Request Policies und dann auf New.
Nun definiert man einen Namen für die Policy und wählt den Typ des Zugriff-Servers. Handelt es sich dabei zum Beispiel um einen WLAN-AP, dann kann die Einstellung auf Unspecified bleiben.
Anschließend wählen wir bei den Bedingungen Day and Time Restrictions und klicken auf Add.
Hier kann dann das Zeitfenster definiert werden.
Authentication und Accounting finden auf dem Server statt, und somit klicke ich auf Next.
Es muss keine Authentication Policy der Netzwerkrichtlinien überschrieben werden, daher können die Einstellungen so belassen werden und man kann auf Next klicken.
Weitere Regeln wollen wir nicht anwenden und klicken daher erneut auf Next.
Und zum Schluss erzeugen wir die Policy mit Finish.
Network Policy anlegen
Network Policies bestimmen, wem es erlaubt ist, sich mit dem Netzwerk zu verbinden. Sie können dabei Bedingungen und Einschränkungen definieren, unter denen eine Verbindung möglich ist oder verwehrt wird.
Im folgenden Beispiel erstellen wir eine Regel, um den Zugriff für eine AD-Gruppe in Kombination mit dem Client Friendly Name des RADIUS-Clients zu gewähren. Diese Bedingungen können in der Network Policy unter Conditions eingegeben werden.
Bei den Werten wie beispielsweise Client Friendly Name wird mit regulären Ausdrücken gearbeitet. Dies ist wichtig zu wissen, um hier keine Fehler zu verursachen.
Um eine Richtlinie anzulegen, klicken wir mit der rechten Maustaste auf Network Policies und dann auf New.
Nun tragen wir einen Namen ein und klicken auf Next.
Conditions können über Add hinzugefügt werden. Hierbei verwenden wir die Bedingungen Windows Groups und Client Friendly Name.
Da die Netzwerk-Admins auch Domain Admins sind, nutzen wir hier die Gruppe Domain Admins.
Der Client Friendly Name des Switches lautet TestSwitch1. Da wir aber mit regulären Ausdrücken arbeiten müssen, ist der Name zwischen ^ und $ einzutragen. Mit dieser Bedingung muss der Client Friendly Name exakt dem Wert TestSwitch1 entsprechen.
Würden wir weitere Clients einpflegen wollen, müssten wir ihre Namen durch ein Pipe-Symbol | trennen. Beispielweise
^TestSwitch1$|^TestSwitch2$
Hilfe für das Verwenden von regulären Ausdrücken gibt es auf dieser Microsoft-DOCs-Seite.
Sind alle Konditionen festgelegt und bestätigt, kann auf Next geklickt werden. Im nächsten Schritt legen wir fest, ob der Zugriff gewährt oder verweigert wird.
Als nächstes werden die Methoden zum Authentifizieren ausgewählt.
Anschließend können Einschränkungen wie Timeouts, Zeitfenster oder Wochentage konfiguriert werden.
Daraufhin werden die Einstellungen für die RADIUS-Attribute sowie für Routing und Remote Access konfiguriert. Hier definieren wir ein Custom Vendor Attribut, das wir als Mapping für unsere AD-Gruppe nutzen, um den Administratoren Admin-Rechte auf dem Switch zu gewähren.
Vendor Attribute für Switch hinzufügen
Für Cisco beispielsweise ist das Attribut Cisco-AV-Pair bereits hinterlegt. Ich verwende hier das Custom Vendor Attribut für Juniper Switch Access, um zu zeigen, wie man ein solches konfiguriert:
- Unter RADIUS Attributes auf Vendor Specific und dann auf Add… klicken.
- Enter Vendor Code auswählen und 2636 eingeben
- Yes. It conforms auswählen und auf Configure Attribute… klicken.
- Vendor-assigned attribute number auf 1 setzen, Attribute format auf String und bei Attribute value den Wert acs-admin eingeben. Alles mit Ok bestätigen.
Im letzten Fenster kann die Policy dann durch das Drücken auf Finish angelegt werden.
Events in der Ereignisanzeige
Die Events für die Zugriffe auf den NPS liegen unterhalb von Security, und alle Events, die den NPS betreffen, werden unter von Server Roles => Network Policy and Access Services gesammelt.
Der NPS loggt verschiedenste Typen von Anfragen. Angehängt sind die drei Fälle, die am häufigsten auftreten. Zum einen haben wir dort die Events mit der ID 6272, welche erfolgreiche Anmeldungen aufzeichnet, und jene mit der ID 6273 für die fehlgeschlagenen. In den Ereignissen wird dann erläutert, was genau vorgefallen ist.
Täglich Know-how für IT-Pros mit unserem Newsletter
Tim Buntrock hat langjährige Erfahrung als Active Directory Enterprise Admin in einem Forest mit über hunderttausend Benutzern weltweit.
Daneben ist er als IT-Autor und Blogger in verschiedenen Communities aktiv und betreibt unter anderem seinen eigenen Blog directoryadmin. Zudem besitzt er Zertifizierungen im Bereich Microsoft, VMWare und Security, die sein Fachwissen bekräftigen.
Ähnliche Beiträge
- RADIUS-Konfiguration zwischen NPS-Servern synchronisieren mit PowerShell
- WLAN-Access-Points von Lancom mit Wave 2 und SDN
- Remote Access: SMS Passcode und NCP kombinieren ihre Lösungen
- NTLM-Authentifizierung überwachen oder blockieren mit Gruppenrichtlinien
- Benutzer am Login-Bildschirm anzeigen oder ausblenden mit Gruppenrichtlinien
Weitere Links