VPN-Anmeldung abgelehnt: Prüfen Sie den Build vor der Registry
Ein fehlender Registrierungswert kann nach einem Update seinen eigenen Standard durchsetzen. Lesen Sie zuerst den Build-Stand, die wirksame Richtlinie und ein passendes Ereignis.
Die Anmeldung wird auf einem Rechner abgelehnt, an dem niemand die Registry bearbeitet hat, und die Forenantwort rät, einen Wert hinzuzufügen, der dort nicht vorhanden ist. Die Abwesenheit ist nicht der Befund. Windows wendet Standardwerte an, ein Standardwert kann sich mit einem installierten Update ändern, und deshalb kann die wirksame Richtlinie auf dem Gerät strenger sein, als die Registry vermuten lässt.
Beginnen Sie mit dem Fehler, den der Client tatsächlich angezeigt hat
Lesen Sie die Meldung und nicht die Zusammenfassung, die Sie aus zweiter Hand erreicht hat. Eine Abfrage, die sofort zurückkehrt, ein Timeout nach dem Aufbau des Tunnels und ein Fehler, der erst auftritt, wenn die Verbindung das angemeldete Konto wiederverwenden will, sind drei verschiedene Situationen. Nur die dritte betrifft überhaupt Single Sign-on, und die ersten beiden werden durch nichts in diesem Artikel behoben.
Die Schicht, die die Entscheidung getroffen hat, bestimmt, welches Protokoll sie beantwortet. Diese vier Beobachtungen deuten auf vier verschiedene Zuständigkeiten hin:
| What you observe | Where the decision was made | Who owns the fix |
|---|---|---|
| The prompt returns before the tunnel forms | Local credential handling on the client | Device policy or the installed build |
| Authentication succeeds, no internal site loads | Routing or access control after login | The gateway or network owner |
| Fails only when the logged-on account is reused | SSO credential generation | The policy boundary this page covers |
| Every user on one build fails | Update level or vendor regression | Patch management |
Schreiben Sie den genauen Wortlaut, die Minute und den Kontokontext ins Ticket. Ob der Versuch interaktiv oder automatisch war, entscheidet, welche Windows-Komponente den Aufruf gemacht hat, und ein Bericht, das VPN sei kaputt, beschreibt oft eine fehlende interne Website statt abgelehnter Anmeldedaten.
Lesen Sie die wirksame Richtlinie, nicht den fehlenden Wert
Ermitteln Sie zuerst den Build- und Updatestand, denn der Standard für die Erzeugung von aus NTLMv1 abgeleiteten Anmeldedaten hat sich in den genannten Releases von Windows 11 und Windows Server 2025 geändert. Bei ausgeschaltetem Credential Guard und nicht gesetztem BlockNtlmv1SSO verschiebt ein am oder nach dem 13. Oktober 2026 veröffentlichtes Update das Verhalten von Audit auf Enforce, ohne diesen Wert jemals anzulegen. In der Registry erscheint nichts, und das Gerät wird strenger, als der letzte Administrator beabsichtigt hat. Das ist der ganze Grund, warum eine Registry-Suche hier so wenig beweist.
Halten Sie die Grenzen getrennt, während Sie die Ausgabe lesen. LmCompatibilityLevel ist die Antwortstufe der Netzwerkauthentifizierung, die festlegt, welche Aufforderung und Antwort der Rechner an einen Server sendet; sie ist nicht die Kontrolle, die die Erzeugung von Single-Sign-on-Anmeldedaten regelt, daher stellt eine Absenkung die Anmeldung nicht wieder her. Ob das Gerät NTLMv1 überhaupt als Netzwerkprotokoll sprechen wird, ist eine dritte Grenze, und die aktuellen Releases von Windows 11 und Server 2025 haben es bereits gestrichen. Credential Guard, die vierte, schützt Geheimnisse auf dem Gerät.
Verknüpfen Sie einen Versuch mit einem Ereignis
Reproduzieren Sie den Fehler einmal, notieren Sie die Minute und holen Sie dann die lokalen Belege in einem Durchgang. Drei Befehle decken den Build, den wirksamen Wert und das NTLM-Betriebsprotokoll ab, in dem eine blockierte Single-Sign-on-Anmeldedaten-Erzeugung aufgezeichnet wird:
Get-ComputerInfo | Select-Object WindowsProductName, OsBuildNumber, OsVersion
reg query "HKLM\SYSTEM\CurrentControlSet\Control\Lsa" /v LmCompatibilityLevel
Get-WinEvent -LogName "Microsoft-Windows-NTLM/Operational" -MaxEvents 30 | Select-Object TimeCreated, Id, MessageEin Ereignis zum selben Zeitpunkt wie der Fehler ist ein Beleg. Ein Ereignis von gestern, von einem anderen Konto oder ein Protokoll ohne Eintrag ist keiner, und der leere Fall sollte als leer festgehalten werden und nicht als fehlender Beweis. Die Microsoft-Anleitung zu den NTLMv1-Änderungen nennt die Ereignis-ID für blockierte Single-Sign-on-Anmeldedaten-Erzeugung, also vergleichen Sie die Id damit, statt aus dem Meldungstext zu raten.
Halten Sie die eigene Meldung des Clients und die Sicht des Gateways auf denselben Versuch zusammen. Eine lokale Blockade der Anmeldedaten-Erzeugung, eine entfernte Kontenabweisung und eine fehlende private Route nach erfolgreicher Anmeldung haben drei verschiedene Zuständigkeiten, und nur die erste ist eine Windows-Richtlinienfrage. Bereinigen Sie das Ereignis, bevor es das Team verlässt: Zeitstempel und Ereignis-Id beantworten die Frage meist ohne die Kontodaten.
Wechseln Sie zu einer unterstützten Anmeldemethode
Ist die wirksame Richtlinie die Blockade, dann ist die Antwort ein unterstützter Authentifizierungspfad und keine stille Rücknahme des Standards. Zertifikatbasierte Authentifizierung ist das übliche Ziel, wo die Bereitstellung sie unterstützt, und sie erfordert Registrierung, Vertrauensverteilung und ein Gateway, das die Zertifikate akzeptiert. Die Microsoft-Anleitung zu den bevorstehenden NTLMv1-Änderungen ist das Dokument, das bei der Überprüfung des Falls zitiert wird.
Credential Guard als Experiment abzuschalten entfernt den Schutz, ohne eine Ersatzanmeldung zu liefern, und die dokumentierten Einschränkungen für wiederverwendbare Anmeldedaten sind der Grund, warum das eine Designentscheidung und kein Diagnoseschritt ist. Wird eine vorübergehende Ausnahme genehmigt, geben Sie ihr einen Umfang, einen Verantwortlichen und ein Auslaufdatum, und halten Sie einen unabhängigen Verwaltungsweg zum Rechner bereit, falls die Änderung Sie von der Verbindung aussperrt, die Sie brauchen. Der Abnahmetest ist die beabsichtigte Authentifizierung plus die Ressource dahinter, nicht das Verschwinden eines lokalen Fehlercodes.