LmCompatibilityLevel ist eine Windows-Richtlinie, keine VPN-Reparatur

Jemand erreicht eine Dateifreigabe über das VPN nicht, liest, dass ein niedrigeres LmCompatibilityLevel NTLM-Probleme behebt, und ändert es auf einem gemeinsam genutzten Server. Am nächsten Morgen scheitern andere Anwendungen, und das ursprüngliche Problem besteht weiter. Diese Einstellung war nie ein Schalter pro Tunnel; sie ist eine Aussage auf Rechnerebene darüber, welche Authentifizierungsantworten dieses System sendet und akzeptiert. Sie zu ändern, um eine Anmeldung zu reparieren, schreibt die Regeln für jede Anmeldung neu, die der Rechner durchführt.

Die dokumentierten Stufen zu lesen ist der schnellste Weg, einen Richtlinienwert nicht mehr als magische Zahl zu behandeln.

Drei Stufen, drei verschiedene Versprechen

Stufe 1 bringt den Client dazu, LM- und NTLM-Antworten zu senden, und nutzt NTLMv2-Sitzungssicherheit, wenn die Aushandlung es erlaubt. Stufe 3 bringt den Client dazu, nur NTLMv2-Antworten zu senden, was nicht dasselbe ist wie das Ablehnen jeder Altantwort auf der Empfängerseite. Stufe 5 hält den Client bei NTLMv2 und ergänzt die dokumentierte Ablehnung von LM und NTLMv1 durch den Domänencontroller. Drei Zahlen, und der Unterschied zwischen ihnen ist eine Richtlinienentscheidung und keine Vorliebe.

Diese Unterschiede erklären, warum das Kopieren eines Werts aus einem funktionierenden Fall unzuverlässig ist. Einen falsch konfigurierten Client von 1 auf die genehmigte Grundlinie zu setzen, kann richtig sein. Ein gehärtetes Deployment von 5 auf 3 herunterzusetzen, nur weil ein Forumsthread 3 erwähnt hat, lockert eine Grenze, die jemand bewusst gewählt hat, und zwar für jeden Dienst, mit dem der Rechner spricht.

Lesen Sie die wirksame Richtlinie, nicht einen Registrierungswert

Ein schreibgeschützter Blick auf den lokalen Wert ist ein sinnvoller Ausgangspunkt: Get-ItemProperty -LiteralPath 'HKLM:\System\CurrentControlSet\Control\Lsa' -Name LmCompatibilityLevel. Ein fehlender Wert bedeutet nicht, dass die wirksame Richtlinie null ist, denn eine Domänen- oder lokale Sicherheitsrichtlinie kann ihn anderswo setzen, und die Rolle des Rechners verändert, was er mit der Zahl tut.

Prüfen Sie die verwaltete Richtlinie, die Systemrolle und den tatsächlichen Build, bevor Sie irgendetwas schließen. Eine Arbeitsstation und ein Domänencontroller mit demselben Wert verhalten sich am oberen Ende unterschiedlich, und genau das vergessen Menschen, wenn sie zwei Rechner vergleichen.

Bestimmen Sie, welche Authentifizierung tatsächlich fehlgeschlagen ist

Kerberos-Ticketprobleme, NTLM-Ablehnungen und VPN-Zugangsfehler brauchen unterschiedliche Belege. Halten Sie Zieldienst, Konto und den genauen Fehler in einer Notiz zusammen, und schauen Sie dann, was der Dienst angefordert hat, statt was der Client bevorzugt. Diese eine Notiz verhindert den häufigsten Fehlweg, nämlich einen clientseitigen Wert zu ändern, um eine serverseitige Ablehnung zu beantworten.

Eine Richtlinie so lange zu senken, bis ein allgemeiner Anmeldefehler verschwindet, ist keine Diagnose; es ist eine Änderung, die den Beleg verdeckt. Wenn die Anwendung Kerberos nutzt, ist die NTLM-Kompatibilitätsstufe nicht einmal die relevante Kontrolle, und Sie haben eine Grenze umsonst gelockert.

Manche Protokollunterstützung lässt sich nicht wiederherstellen

Windows 11 24H2 und Windows Server 2025 enthalten die NTLMv1-Netzwerkanmeldung überhaupt nicht mehr. Keine Kompatibilitätszahl bringt ein Protokoll zurück, das der Build nicht mehr implementiert, sodass ein Downgrade, das auf einer älteren Version geholfen hat, auf einer neueren schlicht scheitert. Microsoft dokumentiert diese Entfernung getrennt von der Richtlinieneinstellung, und beides zu vermischen erzeugt Ratschläge, die nicht funktionieren können.

Eine verwandte, aber andere Einschränkung gilt für von NTLMv1 abgeleitete Anmeldeinformationen, die von MSCHAPv2-basiertem Single Sign-on verwendet werden. Das ist eine Frage abgeleiteter Anmeldeinformationen, nicht des Netzwerkprotokolls selbst und nicht dieses einen Registrierungswerts. Alle drei als dasselbe Thema zu behandeln, ist der Weg, auf dem Organisationen eine Kontrolle schwächen, während sie eine andere reparieren wollen.

Ändern Sie sie über den Eigentümer und testen Sie dann beide Richtungen

Wenn eine Korrektur wirklich nötig ist, nehmen Sie sie über den Richtlinieneigentümer vor, damit die Grundlinie stimmig bleibt, und halten Sie fest, warum. Testen Sie dann eine autorisierte Anwendung unter der neuen Einstellung und einen bewusst unzulässigen Authentifizierungsfall, denn eine Änderung, die eine Freigabe repariert und anderswo stillschweigend Altantworten erlaubt, ist kein Erfolg. Eine funktionierende VPN-Verbindung beweist, dass der Zugang gelungen ist. Sie validiert nicht die Authentifizierungsrichtlinie des Rechners und zeigt erst recht nicht, dass jeder Dienst dahinter sich noch wie entworfen verhält.

Wenn der fehlerhafte Dienst Kerberos-basiert ist, hören Sie ganz auf, diese Einstellung anzusehen. Ist es ein Altgerät, das wirklich nicht mehr kann, dokumentieren Sie diese Ausnahme und grenzen Sie sie ein, denn die Alternative ist eine still geschwächte Grundlinie, an deren Genehmigung sich niemand erinnert.