Welche Adresse tragen Sie als NPS-RADIUS-Client ein?
Tragen Sie die tatsächliche Backend-Quelle des Gateways ein, nicht den öffentlichen Hostnamen oder den Client-Pool. Gleichen Sie das gemeinsame Geheimnis ab und bestätigen Sie dann mit einer kontrollierten Anfrage.
Ein VPN-Gateway, das die Authentifizierung an Windows NPS übergibt, braucht auf der NPS-Seite ein Objekt, bevor irgendeine Benutzerrichtlinie greifen kann: einen RADIUS-Client-Eintrag für das Gateway. Die meisten fehlgeschlagenen Versuche tragen die falsche Adresse ein, denn entscheidend ist die Adresse, die das Gateway auf seinem Backend-Pfad verwendet, nicht der Hostname, den Mitarbeiter in ihre VPN-App tippen. Ist dieser Wert falsch, verwirft NPS die Anfrage stillschweigend, was aus Client-Sicht wie ein falsches Passwort aussieht. Drei Bedingungen entscheiden, welche Adresse in das Feld gehört, also klären Sie sie, bevor Sie die Konsole öffnen.
Tragen Sie das Gateway ein, nicht die Laptops oder den Pool
Das RADIUS-Client-Objekt steht für das Netzwerkzugangsgerät, das Authentifizierungsanfragen sendet. Das ist das VPN-Gateway, nicht jeder Laptop mit dem Client und nicht der Adressbereich, der innerhalb der Tunnel vergeben wird.
Diese Tunneladressen erscheinen nie als Quelle einer RADIUS-Anfrage, weil die Anfrage über den eigenen Netzwerkpfad des Gateways läuft. Ein Pool-Eintrag erzeugt eine Richtlinie, die nie passen kann, während die echte Anfrage von einer Adresse ankommt, von der NPS nie gehört hat. Dieselbe Verwechslung verleitet dazu, die Heim-IP jedes Mitarbeiters einzutragen, was ebenso unwartbar wie falsch ist.
Drei Bedingungen entscheiden über die Adresse, die Sie eintragen
Ermitteln Sie zuerst die Quelladresse, die das Gateway tatsächlich Richtung NPS verwendet. Ein Gateway mit mehreren Schnittstellen sendet oft über eine Management- oder Backend-Schnittstelle statt über seinen öffentlichen VPN-Listener. Prüfen Sie zweitens, ob dazwischen NAT läuft: Wird die Anfrage übersetzt, sieht NPS die übersetzte Adresse, und dieser Wert gehört eingetragen. Drittens: Teilen sich zwei Gateways die Rolle, braucht jede Anfragequelle ihren eigenen Client-Eintrag, denn ein einzelnes Objekt mit einer Adresse deckt nur eines von beiden ab.
Ein beidseitiger Eintrag hält das Paar auseinander. Die folgende Tabelle verwendet private Adressen zur Veranschaulichung, ersetzen Sie sie durch die, die Ihr Pfad tatsächlich nutzt.
| At NPS | At the VPN gateway |
|---|---|
| RADIUS client address 10.20.0.10 | Authentication server 10.20.0.20 |
| Shared secret, agreed value | The same secret, same value |
| UDP 1812 permitted from 10.20.0.10 | UDP 1812 permitted toward 10.20.0.20 |
Bestätigen Sie die Quelle, statt sie zu raten. Beobachten Sie während eines Versuchs das NPS- oder Firewall-Protokoll oder zeichnen Sie auf dem NPS-Host mit sudo tcpdump -ni any udp port 1812 auf. Die Adresse in dieser Aufzeichnung ist die einzige belastbare Antwort für den Client-Eintrag. Hat das Gateway mehrere mögliche Quellen, tragen Sie jede unter ihrem eigenen freundlichen Namen ein.
Das gemeinsame Geheimnis ist ein Wert zwischen Gateway und NPS
Das gemeinsame Geheimnis authentifiziert die Gerätebeziehung. Es ist kein Benutzerpasswort und wird nie an Mitarbeiter verteilt oder in Clientprofile eingebettet.
Wählen Sie einen Wert, tragen Sie ihn an beiden Stellen ein und speichern Sie ihn dort, wo die Konfigurationssicherung des Gateways liegt. Eine Abweichung erzeugt eine Anfrage, die NPS ohne brauchbare Fehlermeldung verwirft, was im Gateway-Protokoll von einem unerreichbaren Server nicht zu unterscheiden ist. Wechseln Sie ihn in einem Wartungsfenster und aktualisieren Sie beide Seiten in derselben Änderung.
Bestätigen Sie mit einer erlaubten Anfrage
Nutzen Sie ein kontrolliertes Konto und gleichen Sie einen einzelnen Versuch auf beiden Seiten ab. Am Gateway bestätigen Sie, dass die Anfrage zum vorgesehenen Server ging; an NPS, dass sie vom registrierten Client kam und der erwarteten Verbindungsanforderungs-Richtlinie entsprach. Zeitüberschreitung und Ablehnung bedeuten Unterschiedliches, und beide als Anmeldedatenproblem zu behandeln kostet die nächste Stunde. Testen Sie dann ein gültiges, aber nicht berechtigtes Konto und ein falsches Passwort, denn eine Richtlinie, die alles annimmt, besteht auch den ersten Test.
Prüfen Sie schließlich, was das Gateway mit der zurückgegebenen Autorisierung tut. Die Registrierung eines RADIUS-Clients erlaubt dem Gerät nur die Teilnahme; sie gewährt nicht jeder daraus entstehenden Sitzung Zugang zum LAN.
Halten Sie die Diagnoseausgabe begrenzt: keine gemeinsamen Geheimnisse, keine Benutzerpasswörter, keine vollständigen Paketnutzlasten in einem Support-Ticket. Verlangt das Design, dass der NPS-Server Verzeichnisattribute liest, ist diese Berechtigung eine eigene administrative Aufgabe neben der Client-Registrierung, und fehlt sie, scheitert sie auf andere Weise.