Der Client sendet NTLMv2, die Domäne akzeptiert noch mehr

Im Baseline-Bericht steht bei den Windows-Clients bereits „Send NTLMv2 response only“. Der Fileserver funktioniert, die Anmeldung am Scanner ebenfalls. Daraus wird schnell die Aussage, NTLMv1 sei abgeschaltet. Tatsächlich ist damit zunächst nur das Sendeverhalten der erfassten Clients beschrieben. Welche Antworten ein Domain Controller noch validiert, wurde möglicherweise nie geprüft.

Genau diese Lücke schließt eine konsistente NTLMv2-only-Baseline. Sie ergänzt die allgemeine NTLM-Reduktion um einen konkreten Mindeststandard: Wo NTLM noch benötigt wird, dürfen LM und NTLMv1 nicht mehr als Authentifizierungsverfahren funktionieren. Kerberos bleibt der bevorzugte Weg; die Richtlinie erzwingt keinen Wechsel zu Kerberos.

Auf Windows 11 ab Version 24H2 und Windows Server 2025 ist NTLMv1 bereits entfernt. Der zusätzliche Nutzen liegt deshalb besonders in gemischten Beständen, älteren unterstützten Systemen und einer nachvollziehbaren Konfiguration. Betriebssystem, Update-Stand und tatsächlich verwendete Authentifizierung gehören gemeinsam in die Bestandsaufnahme.

Senden und Validieren getrennt planen

Das Zielbild umfasst drei Rollen. Windows-Clients senden bei notwendiger NTLM-Nutzung ausschließlich NTLMv2. Mitgliedsserver erhalten dieselbe Baseline für ihre eigenen Verbindungen und die lokal zuständige Validierung. Alle Domain Controller lehnen LM und NTLMv1 für die durch sie geprüften Domänenanmeldungen ab.

Bei einem Domänenkonto liegt die Kennwortvalidierung typischerweise am DC, bei einem lokalen Konto am zuständigen Rechner. Ein gehärteter Mitgliedsserver allein beweist deshalb keine domänenweite Durchsetzung. Drittanbietergeräte benötigen zusätzlich eine passende eigene Konfiguration oder ein Update; eine Windows-GPO erreicht deren Authentifizierungsbibliothek nicht automatisch.

Erfassen Sie für jeden verbleibenden NTLM-Pfad Quellsystem, Zielsystem, Anwendung, Kontotyp, fachlichen Eigentümer und geplante Ablösung. Ein Migrationshindernis ist erst ausreichend beschrieben, wenn klar ist, welcher reale Geschäftsprozess davon abhängt.

Den Unterschied zwischen Richtlinienwert 3 und 5 prüfen

Verwenden Sie eine eigene, nachvollziehbar verknüpfte Computerrichtlinie. Der Pfad im Gruppenrichtlinieneditor lautet Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options. Die Einstellung heißt Network security: LAN Manager authentication level.

Das Ziel ist Send NTLMv2 response only. Refuse LM & NTLM. Diese Auswahl entspricht dem Registry-Wert LmCompatibilityLevel = 5 unter HKLM\SYSTEM\CurrentControlSet\Control\Lsa.

  • Wert 3, Send NTLMv2 response only: Der Client sendet NTLMv2. Domain Controller akzeptieren weiterhin LM-, NTLMv1- und NTLMv2-Authentifizierung.
  • Wert 4, Send NTLMv2 response only. Refuse LM: LM wird abgelehnt, NTLMv1 bleibt bei der DC-Validierung möglich.
  • Wert 5, Send NTLMv2 response only. Refuse LM & NTLM: Auch NTLMv1 wird abgelehnt. Das alleinstehende „NTLM“ in diesem historischen Richtliniennamen meint hier NTLMv1, nicht die gesamte NTLM-Familie.

Die Richtlinie ist außerdem nicht mit Restrict NTLM gleichzusetzen. Dessen Audit- und Blockieroptionen steuern die NTLM-Nutzung nach anderen Kriterien. Eine dort gepflegte Serverausnahme macht einen NTLMv1-Client nicht mit einer Validierungsstelle auf Stufe 5 kompatibel.

Erst Abhängigkeiten bereinigen, dann DCs umstellen

Beginnen Sie mit einer repräsentativen Testgruppe aus Windows-Clients und Mitgliedsservern. Prüfen Sie NAS-Systeme, Multifunktionsgeräte, Backup-Agenten, ältere Anwendungen und lokale Notfallkonten ausdrücklich. Ein erfolgreicher Desktop-Login ist kein Test dieser Netzwerkpfade.

Aktivieren Sie vorab die benötigte Überwachung. Dazu gehören passend zum System die erweiterten Überwachungsrichtlinien für Logon und Credential Validation sowie die vorgesehenen NTLM-Auditoptionen. Auf unterstützten, entsprechend aktualisierten Systemen liefert erweitertes NTLM-Auditing im Kanal Microsoft-Windows-NTLM/Operational zusätzliche Versions-, Prozess- und Ursacheninformationen. Umfang und Ereignisse hängen vom Betriebssystem und Update-Stand ab.

Lassen Sie den Pilot mindestens einen vollständigen fachlichen Betriebszyklus einschließlich geplanter Jobs durchlaufen. Beheben Sie veraltete Protokolle beim verursachenden System. Danach folgt die kontrollierte Umstellung der DCs mit Change-Fenster, Überwachung und geprüftem administrativem Zugang. Ein isoliertes Test-AD eignet sich für die Vorprüfung der DC-Wirkung besser als ein dauerhaft abweichender Produktions-DC.

Ein DC-Pilot begrenzt die Wirkung nicht auf die Benutzer einer Pilot-OU: Der betreffende DC kann Anfragen aus der gesamten Domäne validieren. Unterschiedliche Werte zwischen DCs erzeugen je nach ausgewählter Validierungsstelle wechselnde Ergebnisse. Der freigegebene Endzustand muss daher alle DCs einschließen.

Wirksame Werte und neue Verbindungen nachweisen

Nutzen Sie auf den Zielsystemen gpresult /scope computer /r als erste Übersicht der angewendeten Computerrichtlinien. Für den Nachweis der einzelnen Sicherheitseinstellung benötigen Sie zusätzlich einen geschützten HTML-Ergebnisbericht oder die Gruppenrichtlinien-Ergebnisse in der GPMC. Prüfen Sie darin den resultierenden Wert und die gewinnende GPO; nur den Sollwert im Editor zu zeigen reicht nicht.

Der folgende lokale PowerShell-Check liest ausschließlich die explizite Registry-Konfiguration. Ein fehlender Wert ist kein Beleg für eine bestimmte wirksame Standardstufe:

Set-StrictMode -Version Latest
$lsaPath = 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa'
try {
    $settings = Get-ItemProperty -LiteralPath $lsaPath -ErrorAction Stop
    $entry = $settings.PSObject.Properties['LmCompatibilityLevel']
    [pscustomobject]@{
        ExplicitlyConfigured = ($null -ne $entry)
        LmCompatibilityLevel = $(if ($null -ne $entry) { $entry.Value } else { $null })
    }
}
catch {
    throw 'The local LAN Manager policy value could not be read.'
}

Für diese Richtlinienänderung ist kein Neustart erforderlich. Prüfen Sie dennoch die erfolgte GPO-Verarbeitung und eröffnen Sie neue Anwendungssitzungen. Eine vorhandene SMB-Verbindung oder ein bereits angemeldeter Dienst beweist nicht, dass eine neue Authentifizierung dieselben Anforderungen erfüllen würde. Trennen Sie produktive Sitzungen nur im abgestimmten Testfenster.

Ereignisse richtig lesen und Fehlalarme vermeiden

Ereignis 4624 am tatsächlichen Zielsystem kann bei Authentifizierungspaket NTLM im Feld Package Name (NTLM only) die Variante ausweisen. Prüfen Sie passende Auditdaten zusammen mit Anwendung, Konto und neuem Verbindungsaufbau. Anonyme Anmeldungen mit Anzeige NTLM V1 sind kein Beleg für eine Kennwortauthentifizierung über NTLMv1. Auf älteren Systemen sind zudem Fehlklassifizierungen möglich.

Ereignis 4776 zeigt die NTLM-Anmeldeinformationsprüfung bei der zuständigen Validierungsstelle. Der Paketname MICROSOFT_AUTHENTICATION_PACKAGE_V1_0 bedeutet nicht NTLMv1. Das Ereignis nennt auch nicht den angesprochenen Zielserver. Für die Zuordnung sind korrelierte Zielsystem- und Anwendungsdaten notwendig.

Die Abnahme kombiniert wirksame Richtlinie, erfolgreiche neue NTLMv2-Verbindungen und nachvollziehbare Ablehnung tatsächlich inkompatibler Altsysteme in einer isolierten Testumgebung. Produktive Systeme werden dafür nicht auf alte Verfahren zurückgestellt. Kerberos-Verbindungen prüfen Sie separat; ihr Erfolg sagt nichts über den NTLM-Fallback aus. Fehlende Events bei unvollständigem Auditing gelten nicht als Erfolg.

Vorteile: Eine überprüfbare Untergrenze für Rest-NTLM

  • Schwächere LM- und NTLMv1-Verfahren werden an den zuständigen Validierungsstellen abgelehnt, statt nur auf modernen Clients vermieden.
  • Ein einheitlicher Sollwert vereinfacht Compliance-Prüfung, Drift-Erkennung und die Bewertung neuer Server oder Geräte.
  • Inkompatible Abhängigkeiten werden konkreten Anwendungen und Verantwortlichen zugeordnet. Dadurch lassen sie sich gezielt aktualisieren oder ablösen.
  • Die verbleibende NTLM-Nutzung wird zur dokumentierten Übergangslösung mit messbarem Umfang.

Nachteile und Grenzen: NTLMv2 bleibt ein Übergang

Die Umstellung kann ältere Geräte oder Anwendungen vom Zugriff abschneiden. Automatische Wiederholungen können zusätzliche Fehler und Kontosperren verursachen; Helpdesk und Monitoring brauchen vorab die betroffenen Systeme und Eskalationswege. Änderungen an DCs haben einen größeren Wirkungsbereich als eine einzelne Client-GPO.

NTLMv2-only verhindert weder Relay-Angriffe noch Pass-the-Hash allein und ersetzt keine Mehrfaktorauthentifizierung. SMB Signing, LDAP Signing und Channel Binding sowie Extended Protection for Authentication bei unterstützten Diensten bleiben eigene Maßnahmen. Auch eine verschlüsselte Transportverbindung belegt nicht automatisch die verwendete NTLM-Version.

Die Verhandlung im Netzwerk ist außerdem von der Kennwortspeicherung getrennt. Network security: Do not store LAN Manager hash value on next password change sollte aktiviert sein; vorhandene LM-Hashes werden dadurch erst beim nachfolgenden Kennwortwechsel beseitigt. Planen Sie insbesondere Dienstkontoänderungen mit den abhängigen Anwendungen. Stufe 5 allein bereinigt keine gespeicherten Hashes.

Ausnahmen und Rücknahme vor dem Change festlegen

Dokumentieren Sie die vorherigen wirksamen Werte, GPO-Verknüpfungen, Filter und den verantwortlichen Change-Owner. Für einen fehlgeschlagenen Pilot muss eine gezielte Wiederherstellung der freigegebenen Vorher-Konfiguration möglich sein. „Nicht konfiguriert“ ist dafür kein verlässlicher Ersatz: Andere Richtlinien oder verbleibende Einstellungen können weiter wirken.

Ein Legacy-Gerät rechtfertigt keine dauerhafte Absenkung sämtlicher DCs. Bevorzugen Sie Update, Ersatz oder das Aussetzen des betroffenen Zugriffs. Jede vorübergehende Rücknahme benötigt Risikoentscheidung, eng begrenzten Umfang, zusätzliche Überwachung und ein Enddatum. Ein dauerhaft schwächerer DC ist keine belastbare Ausnahmelösung.

Projekt-Checkliste für NTLMv2-only

  1. Betriebssysteme, Update-Stände und vorhandene LAN-Manager-Richtlinien für Clients, Mitgliedsserver und alle DCs erfassen.
  2. Domänenkonten, lokale Konten und Drittanbietergeräte getrennt testen; verbleibende NTLM-Pfade einem Owner zuweisen.
  3. Auditing auf Quell-, Ziel- und Validierungssystemen prüfen, bevor aus fehlenden Ereignissen Schlüsse gezogen werden.
  4. Stufe 5 mit ausgewählten Clients und Servern pilotieren; geplante Jobs und neue Verbindungen einbeziehen.
  5. DC-Umstellung mit ihrem domänenweiten Wirkungsbereich planen und unterschiedliche Endzustände beseitigen.
  6. Resultierende GPO, expliziten Registry-Wert und echte Authentifizierungsergebnisse gemeinsam dokumentieren.
  7. NTLMv2 nicht als Relay-Schutz abnehmen; ergänzende Dienstschutzmaßnahmen und Kerberos-Migration weiterführen.
  8. Rücknahme, Ausnahmen, Verantwortliche und Ablaufdatum festhalten; Drift nach dem Rollout regelmäßig prüfen.