Warum eine einzige Gruppenrichtlinie über die Domänensicherheit entscheidet
In nahezu jedem Active-Directory-Assessment, das wir durchführen, prüfen wir als eines der ersten Dinge den Wert einer bestimmten Gruppenrichtlinie: Network security: LAN Manager authentication level. Das Ergebnis ist ernüchternd. In der Praxis finden wir diese Einstellung in der Mehrzahl mittelständischer Umgebungen entweder gar nicht konfiguriert oder auf einem Wert, der NTLMv1-Authentifizierung weiterhin zulässt — oft aus Sorge vor Kompatibilitätsproblemen mit Legacy-Systemen, die in vielen Fällen gar nicht mehr existieren.
Dabei gehört diese Einstellung zu den wirksamsten Einzelmaßnahmen in der Härtung einer Active-Directory-Umgebung. Sie bestimmt, welche Variante des NTLM-Protokolls Clients senden und Server akzeptieren dürfen. Steht der Wert zu niedrig, können Angreifer über Coercion-Techniken wie PetitPotam oder den PrinterBug einen Domain Controller dazu bringen, sich an einem von ihnen kontrollierten System zu authentifizieren — und die dabei abgefangene NTLMv1-Antwort innerhalb von Minuten für eine vollständige Domänenkompromittierung nutzen.
Dieser Artikel erklärt die sechs Stufen des LAN Manager Authentication Level, zeigt, warum Level 5 in den meisten Umgebungen das Ziel sein sollte, und beschreibt den praktischen Weg dorthin — inklusive Auditing, Migration und dem Umgang mit verbreiteten Mythen.
Was LmCompatibilityLevel technisch steuert
Die Einstellung kontrolliert zwei getrennte Aspekte der NTLM-Authentifizierung, die in der Praxis häufig verwechselt werden: das Sendeverhalten des Clients (welche Protokollvariante bei der Authentifizierung verwendet wird) und das Akzeptanzverhalten des Servers (welche eingehenden Authentifizierungsanfragen er annimmt). Diese Unterscheidung ist entscheidend, weil ein Domain Controller in beiden Rollen agiert — als Server, der Authentifizierungsanfragen von Clients entgegennimmt, und als Client, wenn er sich selbst bei anderen Systemen authentifizieren muss.
Der zugehörige Registrierungsschlüssel befindet sich unter HKLM\System\CurrentControlSet\Control\Lsa\LmCompatibilityLevel. Über Gruppenrichtlinien lässt sich der Wert unter Computer Configuration → Windows Settings → Security Settings → Local Policies → Security Options → Network security: LAN Manager authentication level zentral steuern. Änderungen werden sofort wirksam — ein Neustart ist nicht erforderlich.
Die sechs Stufen im Detail
Das LAN Manager Authentication Level kennt die Werte 0 bis 5. Jede Stufe definiert eine Kombination aus Sende- und Akzeptanzverhalten. Die folgende Tabelle zeigt alle sechs Stufen mit ihrem jeweiligen Sicherheitsniveau.
| Stufe | Gruppenrichtlinien-Name | Client sendet | Server akzeptiert |
|---|---|---|---|
| 0 | Send LM & NTLM responses | LM und NTLM | LM, NTLM, NTLMv2 |
| 1 | Send LM & NTLM – use NTLMv2 session security if negotiated | LM und NTLM (mit NTLMv2-Session-Security, falls ausgehandelt) | LM, NTLM, NTLMv2 |
| 2 | Send NTLM response only | NTLMv1 | LM, NTLM, NTLMv2 |
| 3 | Send NTLMv2 response only | NTLMv2 | LM, NTLM, NTLMv2 |
| 4 | Send NTLMv2 response only. Refuse LM | NTLMv2 | NTLM, NTLMv2 (kein LM) |
| 5 | Send NTLMv2 response only. Refuse LM & NTLM | NTLMv2 | nur NTLMv2 |
Warum die Standardkonfiguration nicht ausreicht
Seit Windows Server 2008 R2 liegt der effektive Standardwert bei 3 — Clients senden also NTLMv2-Antworten. Das klingt zunächst vernünftig. Das Problem liegt jedoch auf der Serverseite: Bei Stufe 3 akzeptiert der Domain Controller weiterhin eingehende LM- und NTLMv1-Authentifizierungen. Ein Angreifer, der einen Domain Controller über PetitPotam oder den PrinterBug zur Authentifizierung an einem von ihm kontrollierten System zwingt, kann die abgefangene NTLMv1-Antwort per Relay an einen anderen Domain Controller weiterleiten — vorausgesetzt, dieser akzeptiert NTLMv1. Fehlt dort LDAP Channel Binding, ermöglicht der Relay-Angriff über Shadow Credentials oder Resource-Based Constrained Delegation die vollständige Übernahme des Domain Controllers.
Stufe 3 schützt also das Sendeverhalten des Clients, lässt aber die Servertür weit offen. Erst ab Stufe 5 verweigert der Server sowohl LM- als auch NTLMv1-Anfragen — und schließt damit den Angriffsvektor auf beiden Seiten.
Warum Level 5 das Ziel sein sollte
CIS Benchmarks und Microsoft Security Baselines empfehlen Level 5 für alle Domain Controller und Mitgliedserver. Die Gründe sind sowohl defensiv als auch regulatorisch.
Der kryptografische Unterschied
NTLMv1 basiert auf DES-Verschlüsselung und verwendet eine Challenge-Response ohne Zeitstempel. Ein abgefangener NTLMv1-Hash lässt sich mit Tools wie Hashcat auf modernen GPUs in Sekunden bis Minuten knacken. NTLMv2 verwendet HMAC-MD5 mit einem Client-Zeitstempel und einer variablen Challenge, was die Berechnung um Größenordnungen aufwendiger macht. Zusätzlich enthält NTLMv2 einen Message Integrity Code (MIC), der Manipulationen an der Authentifizierungsnachricht erkennt — ein Schutzmechanismus, der NTLMv1 vollständig fehlt.
NTLMv1 ermöglicht Domain Compromise in Minuten
Der Unterschied zwischen NTLMv1 und NTLMv2 ist nicht akademisch. NTLMv1-Antworten lassen sich in vielen Fällen direkt in einen NTLM-Hash zurückrechnen, der für Pass-the-Hash-Angriffe verwendbar ist. Bei NTLMv2 ist diese Rückrechnung nicht möglich — ein NTLMv2-Hash kann zwar per Relay weitergeleitet oder offline per Brute-Force angegriffen werden, aber die direkte Umwandlung in einen verwendbaren NTLM-Hash entfällt.
In der Praxis bedeutet das: Solange ein einziger Domain Controller in der Umgebung NTLMv1-Authentifizierung akzeptiert, genügt ein authentifizierter Domänenbenutzer mit Zugang zum Netzwerk, um über Coercion-Techniken eine vollständige Domänenkompromittierung durchzuführen.
Microsofts NTLM-Abschaltungsplan
Microsoft hat NTLM im Juli 2024 offiziell als veraltet eingestuft und einen dreistufigen Plan zur Abschaltung veröffentlicht. In Phase 1 (seit Windows 11 24H2 und Windows Server 2025) stehen erweiterte Audit-Tools bereit. Phase 2 (zweite Jahreshälfte 2026) führt IAKerb und einen lokalen KDC ein, um häufige NTLM-Fallback-Szenarien zu eliminieren. Phase 3 deaktiviert Netzwerk-NTLM standardmäßig in künftigen Windows-Versionen. Ab Oktober 2026 wird zudem der Registry-Schlüssel BlockNTLMv1SSO standardmäßig auf Enforce gesetzt.
Wer jetzt bereits auf Level 5 konfiguriert, ist auf diese Änderungen vorbereitet, statt später unter Zeitdruck nachziehen zu müssen — eine Parallele zur RC4-Abschaltung in Kerberos, bei der Microsoft mit einem ähnlichen Phasenmodell vorgeht.
NTLM-Nutzung auditieren, bevor Sie umstellen
Die größte Hürde bei der Anhebung des LAN Manager Authentication Level ist nicht die technische Umstellung selbst, sondern die Angst vor dem Unbekannten: Welche Systeme und Anwendungen nutzen noch NTLMv1? Die Antwort liefert ein strukturiertes Auditing, das vor jeder Änderung stehen sollte.
Schritt 1: NTLM-Auditing per Gruppenrichtlinie aktivieren
Drei Richtlinien unter Computer Configuration → Windows Settings → Security Settings → Local Policies → Security Options ermöglichen die vollständige Erfassung des NTLM-Verkehrs.
| Richtlinie | Empfohlene Einstellung | Wirkung |
|---|---|---|
| Network security: Restrict NTLM: Audit Incoming NTLM Traffic | Enable auditing for all accounts | Protokolliert alle eingehenden NTLM-Authentifizierungen |
| Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers | Audit all | Protokolliert alle ausgehenden NTLM-Authentifizierungen |
| Network security: Restrict NTLM: Audit NTLM authentication in this domain | Enable all (nur auf DCs) | Protokolliert domänenweite NTLM-Nutzung auf Domain Controllern |
Diese Richtlinien erzeugen Ereignisse im Eventlog unter Applications and Services Logs\Microsoft\Windows\NTLM\Operational.
Schritt 2: Audit-Events auswerten
Die relevanten Event-IDs für die Analyse sind:
| Event ID | Beschreibung |
|---|---|
| 8001 | Ausgehende NTLM-Authentifizierung von Client-Geräten |
| 8002 | Eingehender NTLM-Verkehr auf Servern (Audit von Incoming NTLM Traffic) |
| 8003 | NTLM-Authentifizierung in der Domäne (Pass-Through-Validierung auf DCs) |
| 8004 | NTLM-Credential-Validierung von Domänenmitgliedern an Domain Controllern |
Wer Windows Server 2025 oder Windows 11 24H2 einsetzt, profitiert von erweiterten Events (4020, 4022, 4032), die zusätzlich den Fallback-Grund, die NTLM-Version und den Service Principal Name protokollieren.
Schritt 3: Baseline erstellen und Top-Talker identifizieren
Die Audit-Phase sollte mindestens zwei bis vier Wochen laufen, um auch seltene Authentifizierungsmuster zu erfassen. In einem SIEM lässt sich die NTLM-Nutzung nach Quellsystem, Zielserver und Protokollversion aggregieren. Besonderes Augenmerk gilt dabei Systemen, die NTLMv1 statt NTLMv2 verwenden — diese sind die primären Kandidaten für die Remediation.
Auf Domain Controllern kann zusätzlich der Performance-Counter Security System-Wide Statistics → NTLM Authentications als schneller Indikator für das NTLM-Volumen dienen.
Migration auf Level 5: Der praktische Weg
Phase 1: Auditing und Analyse
Aktivieren Sie die NTLM-Audit-Richtlinien auf allen Domain Controllern und Mitgliedservern. Lassen Sie das Auditing mindestens zwei Wochen laufen und erstellen Sie ein Inventar aller Systeme und Anwendungen, die NTLM verwenden. Differenzieren Sie dabei zwischen NTLMv1- und NTLMv2-Nutzung.
Phase 2: Remediation der NTLMv1-Abhängigkeiten
Die häufigsten Gründe für NTLMv1-Nutzung in der Praxis lassen sich in vier Kategorien einteilen. Ältere Netzwerkgeräte wie NAS-Systeme, Drucker und Legacy-Appliances verwenden häufig NTLMv1, weil ihre Firmware nie aktualisiert wurde. Anwendungen, die explizit NTLMv1 erzwingen statt Negotiate als Authentifizierungsprotokoll zu verwenden, sind ein weiterer häufiger Verursacher. Fehlende Service Principal Names lösen einen Kerberos-Fallback auf NTLM aus — hier hilft setspn -x zur Erkennung von Duplikaten und setspn -l <account> zur Überprüfung der SPN-Konfiguration. Schließlich erzwingen manche Netzwerkdienste NTLM aufgrund von IP-basiertem Zugriff statt DNS-Namen, da Kerberos zwingend einen Hostnamen für die SPN-Auflösung benötigt.
Für jede identifizierte Abhängigkeit gibt es typischerweise einen Lösungsweg: Firmware-Update, Konfigurationsänderung, SPN-Registrierung oder — im Notfall — eine gezielte Ausnahme.
Phase 3: Stufenweise Anhebung
Der sicherste Weg ist eine schrittweise Anhebung über separate Gruppenrichtlinien:
Beginnen Sie mit der Anhebung auf Level 3 über die Default Domain Controllers Policy. Dieser Schritt ist in nahezu allen Umgebungen risikofrei, da er lediglich sicherstellt, dass Domain Controller selbst nur NTLMv2 senden — eingehende NTLMv1-Anfragen werden weiterhin akzeptiert. Beobachten Sie die Umgebung für eine Woche.
Anschließend heben Sie auf Level 4 an, was eingehende LM-Authentifizierung auf den Domain Controllern blockiert. LM ist seit über 15 Jahren veraltet und wird in der Praxis von keinem aktuellen System mehr benötigt. Auch dieser Schritt verursacht erfahrungsgemäß keine Probleme.
Der letzte Schritt ist die Anhebung auf Level 5, die zusätzlich eingehende NTLMv1-Authentifizierung blockiert. Hier zeigen sich eventuell verbliebene Legacy-Abhängigkeiten, die das Auditing identifiziert haben sollte. Für nicht kurzfristig migrierbare Systeme stehen Ausnahmerichtlinien bereit: Network security: Restrict NTLM: Add server exceptions in this domain erlaubt die gezielte NTLM-Freigabe für einzelne Server, ohne die gesamte Domäne zu schwächen.
Phase 4: Mitgliedserver und Clients
Nach der erfolgreichen Umstellung der Domain Controller sollten auch Mitgliedserver und Client-Systeme auf Level 5 konfiguriert werden. Dies stellt sicher, dass auch bei lateraler Bewegung innerhalb des Netzwerks kein System NTLMv1 akzeptiert. Die Konfiguration erfolgt über eine separate GPO, die auf die entsprechenden OUs angewendet wird.
Verbreitete Mythen und deren Korrektur
„Level 5 bricht unsere Legacy-Anwendungen"
In den meisten Fällen betrifft Level 5 ausschließlich NTLMv1 und LM. NTLMv2 bleibt vollständig verfügbar. Anwendungen, die Kerberos oder NTLMv2 verwenden, sind nicht betroffen. Tatsächlich problematisch sind nur Systeme, die explizit NTLMv1 oder LM erzwingen — und diese sind in der Regel so veraltet, dass sie aus anderen Gründen (fehlende Sicherheitsupdates, End-of-Support) ohnehin ein Risiko darstellen.
„Unsere Drucker und NAS-Geräte funktionieren dann nicht mehr"
Aktuelle Drucker und NAS-Systeme unterstützen NTLMv2 seit vielen Jahren. Geräte, die tatsächlich nur NTLMv1 beherrschen, sind typischerweise älter als zehn Jahre. In unseren Assessments stellt sich regelmäßig heraus, dass die befürchteten Kompatibilitätsprobleme auf Annahmen basieren, die nie verifiziert wurden.
„Wir können erst umstellen, wenn Microsoft NTLM komplett abschaltet"
Das Gegenteil ist richtig. Microsofts dreistufiger Abschaltungsplan setzt voraus, dass Unternehmen proaktiv migrieren. Wer bis zur erzwungenen Abschaltung wartet, riskiert unkontrollierte Ausfälle statt einer geplanten Migration.
„Level 3 reicht doch, das ist der Standard"
Level 3 schützt nur das Sendeverhalten. Ein Domain Controller auf Level 3 akzeptiert weiterhin eingehende NTLMv1-Authentifizierungen — und ist damit anfällig für Relay-Angriffe, bei denen ein Angreifer die NTLMv1-Authentifizierung eines anderen Systems weiterleitet. Erst Level 5 schließt beide Seiten.
Ein Sonderfall: WinRM über HTTP und LmCompatibilityLevel
Ein häufig übersehener Zusammenhang besteht zwischen dem LAN Manager Authentication Level und der Sicherheit von Windows Remote Management (WinRM) über HTTP. WinRM über HTTP wird in vielen Umgebungen als unsicher abgetan, weil der Verkehr nicht verschlüsselt sei. Das stimmt jedoch nur bedingt: Wenn das LAN Manager Authentication Level auf 5 steht und NTLMv2-Session-Security ausgehandelt wird, ist die WinRM-Sitzung durch Message Confidentiality und Message Integrity geschützt — auch ohne TLS. Der Schutz basiert auf der Sitzungsverschlüsselung, die NTLMv2 aushandelt.
Steht das Level jedoch auf 3 oder niedriger und ein Angreifer kann einen Downgrade auf NTLMv1 erzwingen, entfällt dieser Schutz. WinRM-Sitzungen über HTTP werden dann tatsächlich im Klartext übertragen. Das LAN Manager Authentication Level beeinflusst also nicht nur die Authentifizierungssicherheit, sondern indirekt auch die Vertraulichkeit von Remote-Management-Verbindungen.
Der Zusammenhang mit RC4 und der NTLM-Abschaltung
Das LAN Manager Authentication Level ist kein isoliertes Thema. Es gehört in eine Reihe von Maßnahmen, die gemeinsam die Identitätsinfrastruktur härten. Die Abschaltung von RC4 in Kerberos eliminiert schwache Verschlüsselung bei Service Tickets. Die Anhebung des LAN Manager Authentication Level auf Stufe 5 eliminiert NTLMv1 als Angriffsvektor. Und die mittelfristige Einschränkung von NTLM insgesamt — über die „Restrict NTLM"-Richtlinien — reduziert die Angriffsoberfläche weiter, bis Kerberos als alleiniges Authentifizierungsprotokoll verbleibt.
Alle drei Maßnahmen lassen sich unabhängig voneinander umsetzen, profitieren aber voneinander. Wer RC4 bereits abgeschaltet hat, sollte als nächsten Schritt das LAN Manager Authentication Level prüfen. Wer das LAN Manager Authentication Level bereits auf 5 gesetzt hat, sollte die Restrict-NTLM-Richtlinien als nächste Stufe in Betracht ziehen.
Ergänzend empfiehlt sich die Aufnahme privilegierter Konten in die Protected Users-Gruppe, die unter anderem NTLM-Authentifizierung für ihre Mitglieder vollständig unterbindet und keine Credential-Caches in LSASS zulässt.
Nächste Schritte
Ein strukturiertes AD Security Assessment deckt nicht nur das LAN Manager Authentication Level auf, sondern alle Fehlkonfigurationen, die Angreifern den Weg zum Domain Admin ebnen — von NTLMv1-Akzeptanz über fehlende LDAP-Signierung bis hin zu unsicheren Delegierungen. Sprechen Sie mit uns über ein Identity & Access Hardening für Ihre Umgebung.