Deaktivierung von NTLM: Warum Kerberos für alle Active-Directory-Umgebungen wichtig ist
Uwe Grohne
Senior Solution Architect
Microsoft hat seine Roadmap zur Abschaltung von NTLM in Windows-Systemen erweitert und fortgeführt. Die finale Entfernung des unsicheren Authentifizierungsprotokolls liegt zwar noch in weiter Ferne, aber die nächsten Schritte werden die Sicherheit in Umgebungen weiter erhöhen. Allerdings sind die IT-Abteilungen gefragt, konkrete Maßnahmen zu ergreifen.
Den meisten IT-Administratoren in Windows-Umgebungen sind die Begriffe NTLM und Kerberos bekannt. Beide beschreiben Methoden, mit denen sich Nutzer gegenüber Windows-Systemen authentifizieren. Während NTLM in der Regel einfach funktioniert, bietet Kerberos ein deutlich höheres Sicherheitsniveau. Allerdings erzeugt Kerberos auch deutlich mehr Aufwand bei der Einrichtung in vielen Situationen.
Für viele endet hier jedoch das Detailwissen. Authentifizierungsprotokolle sind grundsätzlich kompliziert und solange sie funktionieren, ist alles in Ordnung. Administratoren setzen sich meist erst bei komplexen Szenarien wie dem Double-Hop tiefer mit den Protokollen auseinander. Ein klassisches Beispiel ist die Weitergabe von Anmeldedaten vom Client über einen Anwendungsserver bis hin zum SQL-Server. Dann versucht man die Implementierung mit Hilfe einer Anleitung und Trial & Error, bis es funktioniert. Ob es dann wirklich funktioniert, oder ob das System ein Fallback auf NTLM macht, wird dann aber meistens nicht geprüft.
Das Problem
NTLM ist seit vielen Jahren ein bekanntes Sicherheitsrisiko in Windows-Umgebungen, da es Angriffe leicht macht. Die fehlende gegenseitige Authentifizierung begünstigt Angriffsformen wie Replay-Attacken, Brute-Force oder Man-in-the-Middle-Angriffe.
Microsoft hat Mitte 2024 daher NTLM bereits als "deprecated" gekennzeichnet und hat NTLMv1 bereits aus Windows 11 und Windows Server 2025 größtenteils entfernt. Allerdings sind noch manche Restbestandteile davon enthalten und werden z.B. für MS-CHAPv2 bei VPN-Verbindungen genutzt.
NTLMv2 bleibt vorerst als funktionale Komponente erhalten. Diese Verfügbarkeit darf jedoch nicht über die bestehenden Sicherheitsrisiken hinwegtäuschen, da Microsoft auch für diese Version die standardmäßige Deaktivierung eingeleitet hat.
Der Abschied von NTLM
Im Januar hat Microsoft in einem Blogpost angekündigt, dass auch das Ende von NTLMv2 naht. Aber der Abschied kommt nicht plötzlich, denn zunächst mal ist das Ziel, NTLM standardmäßig zu deaktivieren:
Microsoft erweitert zunächst im Laufe der zweiten Jahreshälfte das Toolset um ein Enhanced Auditing, damit Sie Anwendungen, die NTLM verwenden, präzise identifizieren können. Die Ereignisprotokolle zeigen Ihnen dabei die genauen Ursachen für jeden Fallback auf NTLM, wie zum Beispiel die Nutzung von IP-Adressen oder fehlende Service Principal Names.
Erst mit der nächsten Windows Server-Version wird NTLM standardmäßig deaktiviert. Es ist also weiterhin mit an Bord, falls es benötigt wird. Aus den genannten Sicherheitsaspekten wird jedoch dringend davon abgeraten, NTLM weiterhin zu verwenden.
Besonderheit NTLMv1: Hier wird es dieses Jahr noch ernst!
Wie weiter oben bereits beschrieben, ist NTLMv1 nur noch in speziellen Szenarien aktiv, wie MS-CHAPv2 (VPN, WLAN), ältere Geräte wie Multifunktionsdrucker, NAS und Betriebssysteme (z. B. XP, 2003).
Microsoft hat in Windows 11 und Windows Server 2025 bereits die Deaktivierung vorbereitet. Hierzu gibt es den neuen Registry Key „BlockNTLMv1SSO“ unter HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\msv1_0. Mit dem Wert „0“ ist der Audit Mode aktiv, der NTLMv1-Anforderungen mit den Event IDs 4024 protokolliert. Bei einem Wert von „1“ ist der Block-Mode aktiv und lehnt diese Anforderungen generell ab. Im Event Log wird die ID 4025 protokolliert.
Wie stelle ich fest, wo NTLM noch im Einsatz ist?
In einem älteren Blog-Artikel von Microsoft ist beschrieben, wie man das Auditing einschalten kann.
Webanwendungen, die über einen Alias statt über den Servernamen verwendet werden, verwenden in der Regel NTLM, da keine Service Principal Names definiert sind. Das gleiche Problem tritt bei SQL-Servern häufig auf, falls der Installer die Kerberos-Konfiguration nicht korrekt durchführen konnte.
Wie konfiguriere ich Kerberos für eine Anwendung?
Die Verwendung von Kerberos setzt korrekt konfigurierte Service Principal Names (SPN) voraus. Diese Namen müssen direkt im Service Account der jeweiligen Anwendung hinterlegt sein. Nur so kann der Domain Controller (DC) die Tickets korrekt verschlüsseln. Den richtigen Service Account zu finden ist aber nicht immer so einfach, im Endeffekt kommt es darauf an, welcher Prozess das Ticket zur Entschlüsselung erhält. Gerade beim Webserver IIS ist hier die standardmäßig aktive Kernel Mode Authentication zu beachten, die dafür sorgt, dass der unter dem Systemkontext laufende Prozess das Ticket erhält. Ansonsten erhält der Application Pool für die jeweilige Anwendung das Ticket.
Am einfachsten ist es natürlich, wenn es eine Anleitung des Herstellers gibt, wie Kerberos zu konfigurieren ist. Idealerweise weiß man aber auch bei diesen Anleitungen, was die einzelnen Schritte tatsächlich bewirken. Denn nur so lassen sich Fehler auf sichere Art und Weise beheben bzw. die Anleitung an die eigenen Gegebenheiten anpassen.
Ist die Anwendung dann mit Kerberos 100% sicher?
Grundsätzlich ist Kerberos bereits sicherer als NTLM. Die Krux liegt aber oftmals im Detail. Denn in den Authentifizierungseinstellungen findet sich oftmals der Wert „Negotiate“. Das bedeutet, dass Client und Server das Protokoll selbst aushandeln.
Angreifer können einen gezielten Protokoll-Fallback provozieren, solange NTLM im Netzwerk aktiv bleibt. Der Server nutzt dann das unsichere NTLM-Verfahren, anstatt die sicherere Kerberos-Authentifizierung zu erzwingen. Trotz seiner konzeptionellen Überlegenheit gegenüber NTLM ist auch das Kerberos-Protokoll kein Garant für absolute Sicherheit. Administratoren müssen sich mit spezifischen Angriffsvektoren wie Pass-the-Ticket, Golden- und Silver-Tickets sowie Kerberoasting oder Delegation-Attacks auseinandersetzen. Um diese Risiken zu minimieren, sind verschiedene technische Gegenmaßnahmen erforderlich:
- KRBTGT Password Rollover
- Unsichere Verschlüsselungen deaktivieren (RC4) oder sichere erzwingen
- Managed Service Accounts verwenden
- Starke Passwörter bei Service Accounts oder Passwortrotation
- Nur constrained delegation verwenden
- Monitoring über Security Tools (z.B. Defender for Identity und Endpoint)
Wie kann ich sicherstellen, dass alle notwendigen Maßnahmen ergriffen wurden?
Die Deaktivierung von NTLMv2 durch Microsoft ist ein notwendiger Schritt zur Härtung moderner Active-Directory-Umgebungen. Dieser Prozess erfordert jedoch eine präzise Analyse der bestehenden Infrastruktur, um Ausfälle in Systemen zu vermeiden. Das Zeitfenster bis zur Standard-Deaktivierung bei der nächsten Windows Server-Version sollte genutzt werden, um NTLM-Abhängigkeiten zu bereinigen und bekannte Sicherheitsprobleme bei Kerberos wie Kerberoasting oder Delegation-Attacks proaktiv anzugehen. Damit sind Sie auch für das nächste Windows Server-Upgrade bereits gerüstet und können bereits vorher einen Haken bei der Migrations-Checkliste setzen.
Fazit: Strategische Weichenstellung für eine sichere Authentifizierung
Die Umsetzung dieser Maßnahmen setzt ein tiefes Verständnis der Windows-Authentifizierungsverfahren voraus. Falls Sie Unterstützung bei der Identifikation von NTLM-Abhängigkeiten oder der Absicherung Ihrer Kerberos-Konfiguration benötigen, begleiten unsere Experten Sie gerne bei diesen Schritten:
- Infrastruktur-Audit: Wir führen eine detaillierte Analyse Ihrer Umgebung durch und identifizieren kritische NTLM-Fallbacks.
- Härtung der Umgebung: Unsere Experten unterstützen Sie bei der Konfiguration von AES-Verschlüsselung, gMSAs und der Constrained Delegation.
- Managed Security: Wir bieten kontinuierliches Monitoring Ihrer Authentifizierungs-Vorgänge über Microsoft Defender for Identity im Rahmen eines Managed Service an.
Stellen Sie sicher, dass Ihre Dienste auch ohne NTLM funktionsfähig bleiben. Wir unterstützen Sie dabei, verdeckte Protokoll-Fallbacks zu identifizieren und Ihre Kerberos-Konfiguration zu härten. Kontaktieren Sie uns jetzt für eine gezielte Analyse Ihrer Authentifizierungs-Infrastruktur.