LM-Hash-Speicherung deaktiviert: NoLMHash in Active Directory

Die Prüfung, ob die LM-Hash-Speicherung deaktiviert ist, wirft in Active Directory zwei getrennte Fragen auf: Ist Windows so konfiguriert, dass es keine LM-Passworthashes mehr erzeugt, und wurden die betreffenden Passwörter geändert, seit diese Konfiguration wirksam wurde? Eine stärkere Passwortrichtlinie oder eine NTLMv2-Netzwerkeinstellung allein beantwortet nicht beide Fragen.

Dieser Leitfaden erläutert die Microsoft-Einstellung zur Speicherung, drei dokumentierte Konfigurationsprüfungen und einen schrittweisen Maßnahmenplan. Er benennt auch ausdrücklich eine Produktgrenze: Die EtcSec-Prüfung ANSSI_R23_LM_HASH_NOT_DISABLED wertet LmCompatibilityLevel aus, nicht NoLMHash. Ihr Ergebnis ist kein Inventar gespeicherter LM-Geheimnisse.

LM-Hash-Speicherung deaktiviert: Bedeutung in Active Directory

Microsoft unterscheidet zwei Passwortdarstellungen: den älteren LM-Hash und den NT-Hash. Sie können in der lokalen Security Accounts Manager-Datenbank (SAM) oder in Active Directory gespeichert sein. Die LM-Darstellung ist schwächer und anfälliger für die Offline-Wiederherstellung von Passwörtern. Microsofts KB 299656 zur Verhinderung der LM-Hash-Speicherung beschreibt die historische Erzeugung von LM-Material für Passwörter mit weniger als 15 Zeichen.

Diese historische Beschreibung belegt nicht, dass jede aktuelle Windows-Installation LM-Hashes für kurze Passwörter erzeugt. Die Microsoft-Referenz zur Speicherrichtlinie führt für die Systemrollen in ihrer Tabelle aktivierte wirksame Standardwerte auf, während die Einträge für die Standard-Domänen-GPO und die Standard-Domänencontroller-GPO nicht definiert sind. Das sind dokumentierte Standardwerte, keine Beobachtungen aus Ihrer Domäne.

Die Speicherrichtlinie greift bei einer Passwortänderung. Ein Konto, dessen Passwort älter als die wirksame Bereitstellung ist, gehört daher auf eine Prüfliste. Dies ist eine bedingte Schlussfolgerung aus dem Wirkungszeitpunkt der Richtlinie: Das alte Passwort könnte bereits aufgrund seiner Länge, einer früheren Konfiguration oder des Betriebssystemverhaltens kein nutzbares LM-Material erzeugt haben. Das Passwortalter allein beweist weder dessen Vorhandensein noch dessen Abwesenheit.

Dieser Artikel konzentriert sich auf LM-Speicherung und Passwortwechsel. Übergreifende Passwortattribute und Dienstabhängigkeiten behandelt Active Directory-Passwortsicherheit und Dienstkontenpflege. Nutzen Sie diesen Leitfaden für die begleitende Kontenprüfung; halten Sie für die hier behandelte Speicherfrage eine eigene Abschlussentscheidung fest.

Funktionsweise: Gespeicherte Hashes und Netzwerkantworten sind getrennte Einstellungen

Microsofts Speicherverfahren dokumentiert NoLMHash als DWORD mit dem Wert 1 unter HKLM\SYSTEM\CurrentControlSet\Control\Lsa für Windows XP und Windows Server 2003. Das Verfahren für Windows 2000 SP2 und höher verwendet stattdessen einen Schlüssel. Diese historischen Registry-Verfahren erfordern einen Neustart und unterscheiden sich beim Umgang mit dem Passwortverlauf; übertragen Sie ihre Löschdetails nicht pauschal auf andere Versionen. KB 299656 beschreibt außerdem, dass Passwörter mit mindestens 15 Zeichen einen LM-Wert erzeugen, der für die Authentifizierung unbrauchbar ist. Eine Erhöhung der Richtlinie zur Mindestlänge belegt nicht, dass ein altes Passwort erneuert wurde. Siehe Microsofts versionsabhängige Verfahren.

Der unabhängige Wert LmCompatibilityLevel steuert das Verhalten bei der Netzwerkauthentifizierung. Die folgende Tabelle gibt die Microsoft-Referenz zur LAN Manager-Authentifizierungsebene sinngemäß wieder. NTLMv1 bezeichnet hier die ältere NTLM-Variante in Microsofts Tabelle.

Ebene 3 ändert die Clientantworten, ohne die serverseitige Ablehnung von Ebene 5 vorzugeben. Ebene 5 erlaubt weiterhin NTLMv2 und löscht keine Geheimnisse aus Datenbanken. Behandeln Sie Netzwerkhärtung und Unterdrückung der Speicherung als getrennte Aufgaben.

Zugehöriger ANSSI-Leitfaden: Recommandations relatives à l'administration sécurisée des systèmes d'information reposant sur Microsoft Active Directory. Die hier beschriebene Einstellung zur LM-Speicherung ist von Microsoft dokumentiert.

Erkennung: Nachweise zu Konfiguration und Passwortwechsel erfassen

Die folgenden Befehle sind aus der Microsoft-Dokumentation abgeleitete Beispiele. Sie wurden nicht gegen eine Active Directory-Umgebung eines Kunden ausgeführt. Führen Sie jede Messung separat auf dem relevanten Windows-System aus und halten Sie dessen Identität, den Zeitstempel, die Ausgabe und etwaige Fehler fest.

1. Den Wert der Speichereinstellung prüfen

Dies kombiniert Microsofts Syntax für reg query mit dem Pfad und dem Wert aus KB 299656:

reg query HKLM\SYSTEM\CurrentControlSet\Control\Lsa /v NoLMHash

Achten Sie auf den dokumentierten DWORD-Wert 0x1, wo das DWORD-Verfahren anwendbar ist. Die Abfrage liest die lokale Konfiguration, keine Passwortdaten aus SAM oder AD. Ein fehlender Wert oder eine fehlgeschlagene Abfrage muss anhand des Betriebssystems und der wirksamen Richtlinie eingeordnet werden. Daraus folgt nicht, dass ein LM-Hash vorhanden ist. Microsoft dokumentiert den Rückgabecode 0 für eine erfolgreiche Registry-Abfrage und 1 bei einem Fehler.

2. Den Wert der Netzwerkeinstellung separat prüfen

Dies verwendet dieselbe Abfragesyntax und den Registry-Speicherort der Authentifizierungsrichtlinie:

reg query HKLM\SYSTEM\CurrentControlSet\Control\Lsa /v LmCompatibilityLevel

Erfassen Sie diesen Wert in einem anderen Feld als NoLMHash. Ein Netzwerkwert von 0x5 ist kein Nachweis für die Unterdrückung der Speicherung oder für einen Passwortwechsel. Getrennte Messwerte erleichtern außerdem die Untersuchung eines unerwarteten Collector-Ergebnisses.

3. Den Computerrichtlinienbericht erfassen

Die Microsoft-Referenz zu gpresult dokumentiert den Computerbereich und die HTML-Ausgabe:

gpresult /scope computer /h lm-policy.html

Prüfen Sie den erzeugten Computerrichtlinienbericht zusammen mit den Registry-Messwerten. Microsoft dokumentiert eine SysWow64-Anforderung für HTML-Berichte auf ARM64 sowie Firewall-Anforderungen für Berichte zu entfernten Systemen. Das lokale Beispiel oben verzichtet auf Parameter für entfernte Zielsysteme. Ein Richtlinienbericht liefert Konfigurationskontext; er untersucht keine gespeicherten Hashes.

Eine Kandidatenliste erstellen, ohne das Signal zu überbewerten

Vergleichen Sie die Passwortwechseltermine der Konten mit den verifizierten Bereitstellungsdaten der Speicherrichtlinie. Wenn die Daten der wirksamen Bereitstellung abweichen, halten Sie diese Unsicherheit fest, statt ein bequemes einheitliches Datum für die gesamte Domäne zu vergeben. Dieser Vergleich ist eine aus dem Verhalten bei der nächsten Änderung abgeleitete Prüfmethode, kein direkter LM-Detektor und kein gemessener Befund über Ihre Umgebung.

Behebung: Speicherung unterdrücken und anschließend die betreffenden Passwörter erneuern (Remediation)

1. Abhängigkeiten ermitteln und Verantwortliche benennen

Erstellen Sie vor jeder Änderung eine abgegrenzte Liste der DCs, der relevanten Windows-Versionen und der zu prüfenden Konten. Nehmen Sie die relevanten Systeme mit lokalen Konten auf, wenn die lokale SAM-Speicherung zum Auftrag gehört. Benennen Sie für jede Dienstkontoänderung und für die Prüfung der Richtlinienverteilung jeweils eine verantwortliche Person.

Microsofts Referenzen zur Speicherung und Authentifizierung beschreiben Kompatibilitätsauswirkungen für ältere Clients und einige Anwendungen. Nutzen Sie diesen Hinweis, um Tests für die tatsächlichen Abhängigkeiten Ihrer Umgebung zu planen. Er belegt nicht, dass eine bestimmte Anwendung weiterhin LM benötigt. Dokumentieren Sie eine Abhängigkeit erst, nachdem die zuständige Person sie identifiziert hat; machen Sie aus einer ungeprüften Sorge keine dauerhafte Ausnahme.

2. Die Microsoft-Speicherrichtlinie aktivieren

Aktivieren Sie in den Computersicherheitsoptionen „Network security: Do not store LAN Manager hash value on next password change“. Microsoft verortet sie unter Computerkonfiguration, Windows-Einstellungen, Sicherheitseinstellungen, Lokale Richtlinien und Sicherheitsoptionen. Die Seite zur Speicherrichtlinie dokumentiert, dass diese Richtlinie keinen Neustart erfordert.

Wenn ein versionsabhängiges Registry-Verfahren erforderlich ist, verwenden Sie die zutreffenden Anweisungen aus KB 299656 einschließlich der Hinweise zur Registry-Sicherung. Die historische Abfolge für XP/Server 2003 umfasst einen Neustart mit anschließendem Passwortwechsel. Vermischen Sie diese Abfolge nicht mit dem separat auf der Richtlinienseite beschriebenen Neustartverhalten.

3. Die wirksame Verteilung bestätigen, bevor der Abschluss geplant wird

Wiederholen Sie die drei Erkennungsmaßnahmen auf jedem relevanten DC und jedem betroffenen System mit lokalen Konten. Bewahren Sie den Bericht und die Registry-Messwerte zusammen auf. Dokumentieren Sie für jedes System ein verifiziertes Wirksamkeitsdatum oder markieren Sie das Datum als ungeklärt.

Verwenden Sie das Vorhandensein einer einzelnen konformen GPO nicht als Abnahmekriterium für die Bereitstellung. Die unten erläuterte Collector-Implementierung kann die Prüfung bestehen, wenn irgendeine inventarisierte GPO die Netzwerkebene enthält, ohne die Abdeckung nachzuweisen. Die Dokumentation der Behebung sollte deshalb ausweisen, welche Systeme direkt geprüft wurden und welche noch nicht verifiziert sind.

4. Den Passwortwechsel mit den Dienstverantwortlichen organisieren

Microsofts Hinweise zur Speicherrichtlinie sehen vor, dass Benutzer bei ihrer nächsten Domänenanmeldung neue Passwörter festlegen. Planen Sie den Passwortwechsel der betreffenden Konten, nachdem die Speichereinstellung wirksam geworden ist.

Weisen Sie Konten, die sich nicht regelmäßig anmelden, eine ausdrückliche Aufgabe zum Passwortwechsel zu, statt auf eine gewöhnliche Benutzeranmeldung zu warten. Koordinieren Sie bei Dienstkonten die abhängigen Dienste, geplanten Aufgaben und Anwendungen mit deren Verantwortlichen. Die praktische Abfolge sollte das Konto identifizieren, die Aktualisierung der Abhängigkeiten vorbereiten, die genehmigte Änderung durchführen, den Dienst testen und das Ergebnis festhalten. Dies ist ein operativer Bereitstellungsplan, keine Behauptung, dass eine Massenrotation durchgeführt wurde.

Ein verwandtes Lebenszyklusproblem erläutert Kerberos-RC4-Fallback und die passwortabhängige Erzeugung von AES-Schlüsseln. Die gemeinsame Lehre für die Planung lautet, den Passwortwechsel in Konfigurationsprojekte einzubeziehen. AES-Schlüsselerzeugung und LM-Unterdrückung bleiben unterschiedliche Mechanismen mit unterschiedlichen Validierungsanforderungen.

5. Netzwerkhärtung als eigenständige Änderung behandeln

Wählen und testen Sie die vorgesehene LAN Manager-Netzwerkebene separat anhand von Microsofts Kompatibilitätshinweisen. Betrachten Sie eine erfolgreiche Bereitstellung von Ebene 5 nicht als Abschluss der Bereinigung der LM-Speicherung.

Belassen Sie NTLMv1-Aushandlung, Relay-Schutz, WDigest-Speicherexposition und ausgehende NTLM-Einschränkungen für Tier 0 in ihren bestehenden Arbeitssträngen. Diese Projekte hier zu wiederholen würde das fehlende Ergebnis verdecken: eine dokumentierte Bereitstellung der Speicherrichtlinie mit anschließendem Passwortwechsel für die abgegrenzte Kontengruppe.

Validierung: Die Prüfung mit einem abgegrenzten Nachweisprotokoll abschließen

Verwenden Sie ein Abschlussprotokoll, das ein zweiter Administrator verstehen kann, ohne das Projekt aus Chats oder Screenshots rekonstruieren zu müssen. Das Folgende ist ein vorgeschlagenes Nachweisformat, kein Windows-Ausgabeschema und keine Bestätigung, dass Geheimnisse untersucht wurden.

Beschreiben Sie die Schlussfolgerung in dem Umfang, den die Nachweise tragen. Ein Protokoll kann beispielsweise belegen, dass die vorgesehene Speichereinstellung auf den aufgeführten DCs verifiziert und die Passwörter der aufgeführten Konten danach erneuert wurden. Es sollte diese Aussage nicht auf ungeprüfte Konten, den Passwortverlauf sämtlicher Windows-Versionen oder ein Inventar aller gespeicherten Geheimnisse ausweiten.

Führen Sie die Konfigurationsprüfungen nach der Änderung erneut aus und klären Sie noch offene Systeme oder Konten. Halten Sie unvollständige Nachweise sichtbar: Für einen unerreichbaren DC, einen ungetesteten Dienst oder einen unbekannten Passwortwechseltermin sollte es eine verantwortliche Person und eine nächste Maßnahme geben.

So erkennt EtcSec diese Konfiguration

Der aktuelle etc-collector-Quellcode stellt zwei verwandte Prüfungen der Netzwerkrichtlinie bereit. Keine liest NoLMHash oder inventarisiert LM-Geheimnisse in SAM oder AD. Die folgende Analyse ist eine statische Quellcodeprüfung am Collector-Commit b767fc1ef7ea4cf52d797d5aea1dd4c2d3d07d7c; sie ist kein Scanergebnis eines Kunden.

ANSSI_R23_LM_HASH_NOT_DISABLED

Trotz seiner historischen Kennung und der speicherbezogenen Katalogbezeichnung wertet dieser Detektor LmCompatibilityLevel aus. In internal/audit/detectors/ad/compliance/anssi/anssi-r23-lm-hash-not-disabled.go:17 überspringt die Schleife in den Zeilen 30–43 Richtlinien oder Einstellungen mit nil-Wert und markiert die Bedingung als erfüllt, sobald irgendeine inventarisierte GPO einen definierten Wert größer oder gleich 5 aufweist.

Er liefert Count = 0, wenn diese Bedingung erfüllt ist, andernfalls Count = 1, auch bei einer leeren Richtlinienmenge oder fehlenden Werten. Die Implementierung berechnet keine wirksame GPO-Rangfolge und belegt keine Abdeckung sämtlicher DCs oder OUs. Sie verwendet außerdem einen numerischen Schwellenwert, statt Microsofts dokumentierten Bereich 0–5 zu validieren: Ein erfasster Wert von 6 würde den Vergleich erfüllen, ohne dadurch zu einer dokumentierten Windows-Ebene zu werden.

Die entscheidende Bedingung im Quellcode lautet:

if p.RegistrySettings.LmCompatibilityLevel != nil &&
    *p.RegistrySettings.LmCompatibilityLevel >= 5 {
    compliant = true
    break
}

Dies ist ein formatiertes Fragment der Zeilen 35–38, kein eigenständiges Programm. Eine Anzahl von null bedeutet, dass diese Netzwerkrichtlinienbedingung in den bereitgestellten Daten gefunden wurde. Sie bestätigt weder die Unterdrückung der Speicherung noch den Passwortwechsel oder eine vollständige Netzwerkhärtung; der Detektor prüft keine Mindestanforderungen an die NTLM-Sitzungssicherheit.

NTLMV1_ALLOWED

Der benachbarte Detektor in internal/audit/detectors/ad/gpo/ntlmv1-allowed.go:22 liest in den Zeilen 32–34 dasselbe Feld. Die Zeilen 37–38 setzen Count = 1, wenn der ausgewählte Wert fehlt oder kleiner als 5 ist; andernfalls bleibt die Anzahl null.

Die Auswahl unterscheidet sich. Der Helfer internal/audit/helpers/gpo_policy.go:130 sucht zuerst nach einem definierten Wert in der Standard-DC-Richtlinie, danach in der Standard-Domänenrichtlinie und anschließend in einer anderen Richtlinie. Dies ist die Auswahlregel des Helfers, keine vollständige Berechnung der resultierenden Windows-Richtlinie.

Folglich können diese Prüfungen voneinander abweichen. Bei einer hypothetischen Eingabe mit einer Standard-DC-Richtlinie auf 3 und einer anderen GPO auf 5 liefert die nach ANSSI benannte Prüfung null, während NTLMV1_ALLOWED eins liefert. Dieses Beispiel folgt der Quellcodelogik; eine solche Kundenkonfiguration wurde nicht beobachtet.