Wer darf sich einwählen? msNPAllowDialin vor dem VPN-Zugang prüfen

Das Passwort stimmt, das Konto ist in der VPN-Gruppe, und die Verbindung wird trotzdem mit einer Meldung abgelehnt, die keine Richtlinie erwähnt. Wenn das auf einem Windows-Server für den Fernzugriff passiert, schaue ich zuerst nicht auf die NPS-Regel, sondern auf ein Active Directory-Attribut, das niemand öffnet: msNPAllowDialin, den Wert hinter der Registerkarte Einwählen. Es hat drei Zustände, und der dritte übergibt die Entscheidung stillschweigend an eine andere Stelle. Meistens hat niemand ihn absichtlich geändert: Das Konto wurde aus einer Vorlage geklont oder von einem Skript angelegt, das vor Jahren eine ausdrückliche Ablehnung geschrieben hat und nie überprüft wurde.

Die Ablehnung kann erfolgen, bevor die Richtlinie gelesen wird

Windows prüft die Einwählberechtigung des Kontos, während es die Autorisierungsentscheidung aufbaut, sodass eine ausdrückliche Ablehnung das Gespräch früh beendet. Was Sie am Client sehen, ist ein allgemeiner Authentifizierungsfehler, manchmal nach abgeschlossenem Zertifikatsaustausch, und deshalb verbringen Leute einen Nachmittag damit, Anmeldedaten zu testen, die nie das Problem waren.

Der umgekehrte Fall ist genauso verwirrend. Ein Konto, bei dem das Flag nie gesetzt wurde, kann sich erfolgreich verbinden, weil die Richtlinie es erlaubt hat, und dann hört dasselbe Konto auf, sich zu verbinden, wenn jemand die NPS-Regel aus einem unabhängigen Grund bearbeitet. Keines der beiden Ereignisse sieht von außen wie eine Änderung der Einwählberechtigung aus.

Drei Zustände, und der dritte ist unsichtbar

TRUE erlaubt das Einwählen, FALSE lehnt es ab, und ein NULL bedeutet, dass das Konto seine Antwort von der Fernzugriffsrichtlinie oder der NPS-Autorisierung erbt. Die GUI zeigt diesen dritten Zustand als "Control access through NPS Network Policy" an, und er liest sich wie ein nicht gesetztes Kontrollkästchen statt wie eine Entscheidung.

Deshalb sagt es fast nichts, erlaubte Benutzer aus der Konsole zu zählen. Ein geerbtes Konto kann heute erlaubt und morgen abgelehnt werden, ohne dass das Konto angefasst wird, und ein FALSE Konto kann sich weiterhin auf einem Server verbinden, dessen Richtlinie so konfiguriert ist, dass sie Benutzer-Einwähleigenschaften ignoriert. Lesen Sie Attribut und Richtlinie zusammen, sonst prüfen Sie die Hälfte einer Entscheidung.

Exportieren Sie die Flags, ohne die geerbten Konten zu verlieren

Führen Sie den Export auf einem Domänencontroller oder auf einer Arbeitsstation mit dem Active Directory-Modul aus, und bewahren Sie die Rohdatei als Nachweis auf, statt eine Zusammenfassung abzutippen:

Get-ADUser -Filter * -Properties msNPAllowDialin, LastLogonDate |
  Select-Object SamAccountName, Enabled, msNPAllowDialin, LastLogonDate |
  Sort-Object SamAccountName |
  Export-Csv -NoTypeInformation .\dialin.csv

Ein einzelner LDAP-Filter lässt sich leichter in einen Änderungsdatensatz einfügen. Dieser liefert nur die ausdrücklichen Erlaubnisse:

dsquery * -Filter "(&(objectCategory=person)(objectClass=user)(msNPAllowDialin=TRUE))" -Attr sAMAccountName

Fragen Sie dann erneut ohne die Einwählklausel ab und suchen Sie Konten, deren Wert fehlt. Das sind die geerbten, meist die größte Gruppe in der Domäne, und wenn Sie sie überspringen, wird aus einer Prüfung eine Liste der wenigen Leute, die jemand noch von Hand zu konfigurieren wusste.

Trennen Sie das Flag vom Gruppenzugriff und von der Kontogesundheit

Das Attribut beantwortet eine Frage: Darf dieses Konto sich einwählen. Es sagt nichts darüber, ob die Person noch hier arbeitet, ob das Konto aktiviert ist oder ob ein gemeinsames Passwort in einer Helpdesk-Notiz liegt. Paaren Sie den Export mit dem Aktivierungsstatus, dem Datum der letzten Anmeldung und der Gruppenmitgliedschaft, die den Zugriff auf den Server gewährt.

Die Kombinationen sind das, worauf Sie reagieren. Ein deaktiviertes Konto mit TRUE ist Rauschen. Ein aktiviertes Konto mit TRUE, das sich seit einem Jahr nicht angemeldet hat, ist ein Kandidat für die Entfernung. Ein geerbtes Konto in der VPN-Gruppe, das niemand erklären kann, ist der Befund, auf den es ankommt, weil keine einzelne Einstellung festhält, warum es gewährt wurde.

Lesen Sie es auf dem Domänencontroller, gegen den sich der VPN-Server tatsächlich authentifiziert. Replikationsverzögerung kann einen Wert zeigen, den der Server bereits ersetzt hat, und eine Prüfung, die einen veralteten DC-Wert zitiert, wird angefochten, sobald jemand erneut nachsieht.

Ändern Sie ein Konto und belegen Sie, dass die Änderung angekommen ist

Um den Zugriff zu entfernen, setzen Sie das Attribut auf FALSE, statt es zu leeren. Leeren bringt das Konto zurück in die Richtlinienvererbung, die es bei der nächsten Verbindung wieder erlauben kann, und die Änderung sieht wie eine Korrektur aus, während sie tatsächlich eine andere Entscheidung ist:

dsmod user "CN=Jane Doe,OU=Staff,DC=corp,DC=example" -allowDialin no
Set-ADUser -Identity jdoe -Clear msNPAllowDialin

Die zweite Zeile ist das Zurücksetzen der Vererbung, bewusst getrennt gehalten, damit niemand die beiden Vorgänge verwechselt. Bestätigen Sie dann aus einer zweiten Sitzung, lesen Sie das Attribut erneut und prüfen Sie die NPS-Abrechnungsereignisse für die Ablehnung, statt der Aktualisierung der Konsole zu vertrauen.

Schreiben Sie schließlich auf, welcher Mechanismus die Entscheidung für jeden Fernzugriffsdienst besitzt. Wenn die Richtlinie Benutzer-Einwähleigenschaften ignoriert, ist die Gruppenbedingung maßgeblich und das Attribut nur beratend für diesen Dienst. Zwei Dienste in derselben Domäne können berechtigt unterschiedlich antworten, und der Prüfvermerk sollte das in einer Zeile pro Dienst festhalten.

Die Ausgabe, die eine Prüfung übersteht, ist kurz: wer sich verbinden darf, unter welchem Mechanismus, wann geprüft, von wem. Das Einwählflag liefert die ersten beiden Antworten; nur die Richtlinienprüfung liefert den Rest.