Hallo Freunde der Sonne,
diesmal geht es um die Problematik – wie kann ich ein VPN-Profil austeilen, welches für die XAUTH den Windows-Login des entsprechenden Benutzers verwendet.
LANcom VPN-Clients via RADIUS authentifizieren
Szenario
RADIUS-Authentifizierung auf dem LANcom einrichten und die Anfragen an einen externen RADIUS-Server (Microsoft NPS) weiterleiten.
- LANcom-VPN-Profil auf RADIUS einrichten
- NPS konfigurieren
Quellen/Material
- NPS-Errorcodes: https://technet.microsoft.com/de-de/library/Dd197521%28v=WS.10%29.aspx
- NPS-Events: https://technet.microsoft.com/en-us/library/cc753898%28v=ws.10%29.aspx
1. LANcom-VPN-Profil auf RADIUS einrichten
Zuerst einaml die Login-Felder aus der bereits angelegten VPN-Client-Verbindung entfernen,
hierzu einfach unter „Kommunikation/Protokolle“ gehen und die PPP-Verbindungseinwahl bearbeiten. Siehe Abbildung 1.
Abbildung 1: LANcom IKE – PPP-Authentifizierung
Danach im Menübaum eine Auswahl tiefer auf „Kommunikation/RADIUS“ wechseln und die unten abgebildeten Einstellungen auf den eigenen RADIUS-Server anpassen.
Standard-Ports: 1812 (Authentifizierung), 1813 (Autorisierung)
Schlüssel: <Kennwort welches auch auf dem RADIUS zwecks Auth des Routers eingerichtet ist>
RADIUS-Server: Aktiviert
PPP-Arbeitsweise: Aktiviert
siehe Abbildung 2.
Abbildung 2: RADIUS Weiterleitung
2. NPS konfigurieren
In diesem Beispiel wird davon ausgegangen, dass die folgende Rolle schon auf dem Windows-Server installiert ist: Netzwerkrichtlinienserver (NPS – Network Policy Server) >> RADIUS.
Für den Server müssen nun 2 neue Richtlinien angelegt werden, eine welche die Clients am RADIUS authentifizert (Router/LANCOM, siehe Abbildung 3) und danach eine die den übertragenden Login bestätigt und ggf. Berechtigungen zurückmeldet (siehe Abbildung 4).
Abbildung 3: Verbindungsanforderungsrichtlinien
Abbildung 4: Netzwerkrichtlinien
Einen Hinweis schon Mal vor weg, ich würde die Systemeigene Richtlinie nicht bearbeiten – diese fungiert wie eine DENY-ALL-Regel falls keine selbsterstellte RADIUS-Richtlinie funktioniert (Abbildung 4 – Netzwerkrichtlinien).
2.1 Zuerst erstellen wir eine Verbindungsanforderungsrichtlinie
Wichtig hierbei ist, dass Ihr festlegt von welchem Gerät überhaupt eine Verbindung in Frage kommt, zusätzlich habe ich in meinem Beispiel noch die Verbindungs-Header für das VPN-Profil ausgewählt – also eine Richtlinie für entsprechende Verbindungen des VPN-Profils. (dafür keine Verbindungstyp-Beschränkung, Grund folgt am Ende)
Abbildung 5: Bindungen Anforderungsrichtlinie
Da dieser Leitfaden möglichst einfach durchführbar seien soll, aktivieren wir natürlich alle typischen Authentifizierugnsmethoden die der NPS verarbeiten kann.
Abbildung 6: Authentifizierung Anforderungsrichtlinie
2.2 Nun kommt die Netzwerkrichtlinie
Diese Richtlinie sorgt nun für die korrekte Auswertung der übertragenden Logins, wie eben wird eine Filterung zr Unterscheidung angewendet – da die Client-IP in diesem Falle aber nicht der LANcom/Router ist, wurde diese hier ausgesparrt.
UND NICHT VERGESSEN – Zugriff gewähren…
Abbildung 7: Netzwerkrichtlinie
Für die Ziel-Bedingungen wird in diesem Falle der Authentifizierungs-Header und eine Benutzergruppe als vorhandene Notwendigkeit konfiguriert.
Abbildung 8: Netzwerkrichtlinie – Filter
Wie in der Anforderungsrichtlinie werden zur Vereinfachung alle typischen Authentifizierungsmechanismen aktiviert.
Abbildung 9: Netzwerkrichtlinie – Authentifizierung
2.3 Fehler- bzw. Richtlinien-Überprüfung via Ereignisprotokoll
Um die Funktionsweise der Richtlinien zu überprüfen empfehle ich das Ereignisprotokoll auf dem NPS-Server. Für die Richtlinienprüfung habe ich auch auf den vermeintlichen „Client-Anzeigenamen“ zurückgegriffen, da dieser vom LANcom-VPN-Profil weitergeleitet wird.
Jeweils oben im Beschrebiungstext steht ob die Verbindung gewährt oder abgelehnt wurde.
Am Ende der Beschreibung wird der Fehlercode + Beschreibung für eine Ablehnung mitgeschickt. (ggf. mit der MS-Fehlercode-Seite die oben verlinkt wurde vergleichen)
Abbildung 10: Ereignisprotokoll NPS
