NTLM-Ablösung: Was Admins beachten müssen

Historische Rolle von NTLM und strukturelle Schwächen

NTLM begleitet Windows-Domänen seit über drei Jahrzehnten. Technisch basiert das Protokoll auf einem Challenge-Response-Verfahren. Der Client generiert aus dem Passwort einen Hash, kombiniert ihn mit einer vom Server gesendeten Challenge und übermittelt das Ergebnis zur Verifikation an den Server oder Domänencontroller. Das Klartextpasswort verlässt den Client nicht. Dennoch genügt in vielen Angriffsszenarien bereits der Besitz des Hashes zur erfolgreichen Authentifizierung.

Eine gegenseitige Authentifizierung findet nicht statt. Der Client prüft nicht zuverlässig, ob der angefragte Dienst legitim ist. Daraus resultieren strukturelle Angriffsflächen:

• Replay- und Relay-Angriffe, bei denen Authentifizierungsdaten in Echtzeit an andere Dienste weitergeleitet werden
• Pass-the-Hash-Szenarien, bei denen abgefangene Hashes zur lateralen Bewegung im Netzwerk genutzt werden
• Offline-Hash-Cracking durch schwache kryptografische Verfahren
• Brute-Force-Angriffe bei fehlender Multifaktor-Authentifizierung

NTLM-Relay lässt sich in heterogenen Netzen weiterhin erfolgreich einsetzen, da keine echte Serverauthentifizierung erzwungen wird. Selbst aktuelle Patches beseitigen nicht die Designschwächen des Protokolls. Die Sicherheitsprobleme gelten daher als strukturell und nicht rein implementierungsbedingt.

In vielen Active-Directory-Umgebungen bleibt NTLM aktiv, obwohl Kerberos seit Jahren priorisiert wird. NTLM greift automatisch als Fallback, wenn Kerberos nicht verhandelbar ist. Typische Szenarien sind:

• Fehlende direkte Verbindung zum Domänencontroller
• Authentifizierung über IP-Adresse statt DNS-Namen
• Fehlender CIFS Service Principal Name für SMB-Ziele
• Anmeldung mit lokalen Konten auf Domänenmitgliedern
• Hart kodierte IP-Adressen in Anwendungen

Gerade diese implizite Fallback-Funktion erschwert eine saubere Risikobegrenzung. NTLM wird häufig nicht bewusst eingesetzt, sondern bleibt als historische Kompatibilitätsschicht aktiv.

Kerberos als strategischer Zielzustand

Kerberos arbeitet ticketbasiert. Ein Key Distribution Center auf dem Domänencontroller stellt zeitlich begrenzte Tickets aus. Der Client erhält zunächst ein Ticket Granting Ticket und anschließend Service Tickets für konkrete Dienste. Die Authentifizierung erfolgt gegenseitig, wodurch Relay-Szenarien deutlich erschwert werden.

Kerberos reduziert wiederverwendbare Geheimnisse und verbessert die Protokollierbarkeit in Security-Logs. Dennoch existieren auch hier bekannte Angriffstechniken:

• Kerberoasting nutzt Service Tickets, die mit dem Hash von Servicekonten verschlüsselt sind, und ermöglicht Offline-Cracking.
• AS-REProasting betrifft Konten ohne Pre-Authentifizierung.
• Golden-Ticket-Angriffe werden möglich, wenn das KRBTGT-Konto kompromittiert wird.

Kerberos eliminiert damit nicht sämtliche Risiken, reduziert jedoch die strukturellen Schwächen von NTLM deutlich. Microsoft verfolgt daher eine Kerberos-First-Strategie, bei der der automatische Rückfallpfad auf NTLM entfällt.

Phase 1: Sichtbarkeit und erweitertes NTLM-Auditing

Die erste Phase bildet das Fundament der Migration. Windows Server 2025 sowie Windows 11 ab Version 24H2 aktivieren standardmäßig erweitertes NTLM-Auditing. Zwei Gruppenrichtlinien steuern die Protokollierung:

• Log Enhanced Domain-wide NTLM Logs
• NTLM Enhanced Logging

Die Richtlinien dienen primär zum Deaktivieren des bereits aktivierten Loggings. Ereignisse werden unter Anwendungs- und Dienstprotokolle/Microsoft Windows/NTLM/Operational gespeichert. Relevante Event-IDs sind:

• 4020 und 4021 auf Clients bei NTLM-Authentifizierungsversuchen
• 4022 und 4023 auf der Gegenstelle

Die Events enthalten zusätzliche Metadaten, darunter den auslösenden Prozess und den Grund für die NTLM-Nutzung. Reason 10 kennzeichnet Authentifizierungen über IP-Adressen.

Die Auswertung kann per PowerShell erfolgen:

Get-WinEvent -LogName "Microsoft-Windows-NTLM/Operational" | Format-List

Diese Telemetrie erlaubt eine präzise Zuordnung von Clients, Diensten, Servicekonten und Zielsystemen. Unternehmen erhalten erstmals eine belastbare Datengrundlage zur Planung der Ablösung. Authentifizierungsflüsse müssen messbar gemacht werden, bevor eine Default-Deaktivierung operativ vertretbar ist.

Phase 2: Technische Ersatzmechanismen für NTLM-Fallback

Die zweite Phase ist für die zweite Jahreshälfte 2026 vorgesehen. Sie adressiert zentrale technische Blocker, die bisher NTLM-Fallback auslösten.

Initial and Pass Through Authentication using Kerberos erweitert Kerberos um Szenarien, in denen bislang fehlende direkte Sicht auf den Domänencontroller NTLM erzwang. Kerberos-Authentifizierung soll auch bei eingeschränkter Netzwerkkonnektivität stabil funktionieren.

Ein lokales Key Distribution Center ermöglicht die Verarbeitung lokaler Konten ohne NTLM. Authentifizierung lokaler Accounts auf Domänenmitgliedern soll künftig Kerberos-basiert erfolgen.

Windows-Kernkomponenten werden so angepasst, dass sie Kerberos vorrangig verhandeln und nicht automatisch auf NTLM wechseln, wenn temporäre Störungen auftreten. Der automatische Rückfallpfad verschwindet schrittweise aus dem Default-Verhalten.

Diese Funktionen stehen für Windows Server 2025 und Windows 11 ab Version 24H2 zur Verfügung.

Phase 3: NTLM standardmäßig deaktiviert

Im nächsten Windows Server LTSC sowie den zugehörigen Client-Versionen wird Netzwerk-NTLM per Voreinstellung blockiert. Das Protokoll bleibt technisch im Betriebssystem vorhanden, erfordert jedoch eine explizite Reaktivierung per Richtlinie.

Die Default-Blockade bedeutet keine sofortige Entfernung des Codes. NTLM kann bei Bedarf über neue Policy-Controls reaktiviert werden. Microsoft unterscheidet klar zwischen Deaktivierung im Standard und vollständiger Entfernung.

Gleichzeitig sollen Mechanismen integriert werden, um verbleibende Sonderfälle kontrolliert abzubilden:

• Unbekannte SPNs
• Authentifizierung über IP-Adressen
• Lokale Konten auf Domänenmaschinen
• Neue NTLM-Blockrichtlinien

Damit soll Anwendungsbruch minimiert werden, obwohl NTLM nicht mehr automatisch genutzt wird.

Praktische Herausforderungen in Unternehmensumgebungen

In vielen Infrastrukturen wird NTLM nicht aus Bequemlichkeit genutzt, sondern aus technischen Abhängigkeiten. Problemfelder sind:

• Legacy-Anwendungen mit fest verdrahteter Protokollwahl
• Fehlende oder fehlerhafte SPNs
• Inkonsistente DNS-Konfigurationen
• Zeitabweichungen zwischen Systemen
• Integrationen mit eingeschränkter Kerberos-Unterstützung

Für Anwendungen mit hart kodierten IP-Adressen lässt sich der NTLM-Fallback durch manuelles Erstellen eines SPN für die IP-Adresse vermeiden. Solche Behelfslösungen verlieren jedoch mit IAKerb und Local KDC an Bedeutung.

Unternehmen müssen Servicekonten, Vertrauensstellungen, Domänenbeziehungen und SMB-Zugriffe vollständig Kerberos-fähig machen. SMB Signing und LDAP Signing reduzieren bereits heute die Wirksamkeit von NTLM-Relay-Angriffen.

Sicherheitsimplikationen der Default-Deaktivierung

Die sicherheitliche Wirkung ergibt sich primär aus dem Wegfall des automatischen Fallbacks. Viele Angriffsketten kombinieren Kerberos-Fehlkonfigurationen mit anschließendem NTLM-Relay oder Pass-the-Hash. Wird dieser Rückfallpfad blockiert, verliert der Angreifer eine wesentliche Option für laterale Bewegung.

NTLM galt lange als technisches Relikt mit inhärenter Angriffsfläche. Die geplante Default-Deaktivierung entfernt diesen Vektor aus der Standardkonfiguration moderner Windows-Umgebungen. Governance gewinnt an Bedeutung, da jede Reaktivierung künftig bewusst dokumentiert und begründet werden muss.

Strategische Einordnung

Microsoft verfolgt keinen abrupten Bruch, sondern eine gestufte Hygiene-Strategie. Zunächst Transparenz, anschließend technische Ersatzmechanismen, zuletzt Verschärfung der Standardkonfiguration.

Ein endgültiges Datum für die vollständige Entfernung von NTLM hat Microsoft noch nicht bekanntgegeben. Der Fokus liegt derzeit auf der Default-Blockade. Diese Übergangsstrategie erlaubt es Unternehmen, Authentifizierungsflüsse strukturiert zu analysieren und Kerberos konsequent durchzusetzen, bevor NTLM im Standardpfad entfällt.

Die Umstellung markiert einen fundamentalen Architekturwechsel in Windows-Domänen. Kerberos wird nicht nur bevorzugt, sondern alleinige Authentifizierungsbasis. Damit endet die langjährige Fallback-Rolle von NTLM in Windows Server nachhaltig.