Neues zum Thema Abschalten von NTLM
Vor fast zwei Jahren habe ich den Artikel "LM, NTLM und NTLMv2: Was muss vor dem Abschalten beachtet werden?" verfasst. Seitdem haben sich einige Änderungen bei meinen Skripten, sowie beim Thema "Abschaltung von NTLM" ergeben.
Neues von Microsoft
Microsoft hat im KB Artikel 5064479 vom 11.07.2025 Neuerungen bei der Auditierung bekannt gegeben. Für Windows 11 24H2 und Windows Server 2025 wurde die Auditierung für NTLM erweitert und neue Event IDs hinzugefügt: 4020–4023 im Event Log "Microsoft-Windows-NTLM/Operational" für AD-Mitglieder. Für die Domänen-Controller sind die IDs 4030-4033, ebenfalls im Event Log "Microsoft-Windows-NTLM/Operational", hinzugekommen.
Bitte beachten Sie, dass das Erweiterte Protokolieren für die neu angelegten Einträge ebenfalls aktiviert werden muss. Dazu müssen zunächst die neuen Gruppenrichtlinienvorlagen (ADMX-Templates) installiert werden. Alternative habe ich für Sie unten noch eine PowerShell Alternative.
Microsoft hat also offenbar ebenfalls die Erkenntnis gewonnen, dass die bisherigen Meldungen im Event Log nur bedingt hilfreich waren. Wobei, mit etwas Zeit und entsprechender Erfahrung war es schon möglich, auch im Kaffeesatz zu lesen.
Ich hätte mir gewünscht, dass im Falle einer ernsthaften Auseinandersetzung mit dem Thema NTLM auch eine Lösung für Windows Server 2022 angeboten wird. Der letzte bekannte Bug bei Windows Server 2025 im Active Directory Bereich wurde erst im November 2025 behoben. Die meisten Kunden zeigen sich in dieser Angelegenheit noch etwas zurückhaltend und warten vorerst die Umstellung der Domänencontroller auf Windows Server 2025 ab. Es sei denn die Umstellung erfolgte aufgrund der Größe der AD-Datenbank oder eines anderen neuen AD-Features.
Was hätte man noch verbessern können?
Einiges. Microsoft hat immer noch keine vernünftigen Informationen für die Blockierten NTLM Authentifizierungen hinzugefügt. Wenn man sich bei der Einführung eines neuen Dienstes nicht sicher ist, ob NTLM-Probleme die Ursache sind, muss man es wieder erlauben, um es zu protokollieren. Man kann es für die Testsysteme generell erlauben oder eine Ausnahme für das zu prüfende System eintragen. Mein Tipp: FQDN, Kurzname und IP als Ausnahme definieren.
Es wäre gut, wenn die Informationen aus dem Audit auch in den Blockiert-Einträgen zu sehen wären. Veränderungen an der Infrastruktur könnte man so einfacher bemerken.
Es wäre auch hilfreich, die Software auf eine ältere Version zurückzusetzen. Das ist ein Thema für Umgebungen, in denen es besonders wichtig ist, Daten zu schützen. Eigentlich ist es überall wichtig, denn es ist im IT-Grundschutz festgelegt (APP.2.2.A9 und SYS.2.2.3.A9). NTLM sollte nicht mehr verwendet werden (siehe "LM, NTLM und NTLMv2: Was muss vor dem Abschalten beachtet werden?"). Aber oft werden LTSC-Versionen als Client und nicht die neusten Serverversionen eingesetzt.
Neue Protokollierung ohne die neuen ADMX-Vorlagen aktivieren
Manche können oder wollen die neuen Vorlagen nicht importieren, da hilft die PowerShell. Setze vorher die Variable $GPONAME auf den Namen der GPO. Am besten kopieren aus der Liste mit dem folgenden Befehl:
(Get-GPO -All).DisplayName
Für die Aktivierung auf Windows 11 24H2 und später sowie auf Windows Server 2025 Mietgliedsservern:
Set-GPRegistryValue -Key HKEY_LOCAL_MACHINESoftwareMicrosoftWindowsCurrentVersionPoliciesSystemNTLMParameters -Name $GPONAME -Type DWord -Value 1 -ValueName LogEnhancedAuditEvents
Für auf den Windows Server 2025 DCs:
Set-GPRegistryValue -Key HKEY_LOCAL_MACHINESoftwarePoliciesMicrosoftNetlogonParameters -Name $GPONAME -Type DWord -Value 1 -ValueName EnableEnhancedDomainNtlmLogs
Betriebssysteme, die die Einstellung unterstützen, können auch den RegistryKey interpretieren, ohne das passende ADMX zu haben. Wenn dann zu einem späteren Zeitpunkt die Administrativen Vorlagen aktualisiert werden, wird die Einstellung auch richtig angezeigt.
Skripte zum einfacheren Analysieren
Ich nutze schon länger ein PowerShell-Skript, um alle Logs von den Domänenkontrollern einzusammeln und auszuwerten. Neu hinzukommt jetzt eines für die Auswertung der Lokalen NTLM Logs.
Get-NTLMLogons.ps1
Das Skript "Get-NTLMLogons.ps1" analysiert NTLM-Anmeldungen anhand der Sicherheitsereignisse (Event ID 4624) im Windows Security Log. Es erkennt, wenn sich jemand mit NTLM auf dem Domänen Controller auf dem das Skript ausgeführt wird, oder allen Domänencontrollern anmeldet. Für die Abfrage aller Domänen Controller muss das Skript nicht auf einem Domänen Controller ausgeführt werden, aber es muss das Active Directory PowerShell Modul installiert sein, die Firewall muss die Zugriffe zulassen und der Benutzer muss auch die entsprechenden Berechtigungen für den Zugriff haben. Dabei werden Informationen wie Benutzerkonto, Workstation, Logon-Typ, Logon-Prozess, Authentifizierungspaket und verwendete NTLM-Version ausgewertet. Dafür muss NTLM-Auditing aktiviert sein.
Das Skript kann lokal oder domänenweit ausgeführt werden. Es erkennt Domänencontroller automatisch und verarbeitet auch nicht erreichbare Systeme. Die Ergebnisse werden übersichtlich in Tabellen ausgegeben. Sie können auch als CSV-Datei exportiert werden, um sie in Excel oder anderen Programmen auszuwerten. Es ist gut geeignet, um NTLM in Domänenumgebungen zu identifizieren und zu bewerten. Das kann man machen, wenn man die Sicherheit analysiert oder wenn man von einem System auf ein anderes umsteigen will.
Get-LocalNTLMLogs.ps1
"Get-LocalNTLMlogs.ps1" steht seit heute auf GitHub. Darin ist auch die Auswertung der neuen KB5064479 Events enthalten.
Es analysiert das lokale Ereignisprotokoll "Microsoft-Windows-NTLM/Operational" und wertet NTLM-Authentifizierungsereignisse der letzten Tage aus. Es erkennt bekannte NTLM-Event-IDs aus Windows 11 24H2 und Windows Server 2025 und klassifiziert diese in "Audited", "Blocked" oder "Info". Zu jedem Ereignis werden detaillierte Informationen wie Benutzer, Domäne, Zielsystem, Client, IP-Adresse, Protokoll, Logontyp, Prozess und Grund für die NTLM-Nutzung extrahiert und aufbereitet (sofern vorhanden).
Das Programm kann Daten flexibel auswerten. Zum Beispiel kann man einstellen, dass es nur Daten von den letzten 3 Tagen oder nur eine bestimmte Anzahl von Daten verarbeiten soll. Außerdem kann man einstellen, dass es die ursprüngliche Meldung und die Rohdaten aus dem EventLog anzeigen soll. Die Ergebnisse werden nach Aktion und Event-ID angezeigt. Sie können interaktiv (Out-GridView) oder tabellarisch angezeigt werden. Die Ergebnisse können als CSV exportiert werden. Das Skript ist für schnelle lokale Analysen und dokumentierte NTLM-Migrations- und Härtungsprojekte geeignet.
Top Probleme / Ursachen für NTLM aus der Praxis
Hier noch eine Top Liste von Ursachen aus den letzten Jahren:
IP-Adressen statt FQDN
Ein Klassiker auf den ich schon im Artikel "LM, NTLM und NTLMv2 was muss vor dem Abschalten beachtet werden?" ausführlich darüber geschrieben. Kerberos kann zwar auch mit einem entsprechenden Registry-Key nach SPN's mit IP-Adressen suchen, aber die müssen alle von Hand vorher gepflegt werden. Mehr dazu in dem Artikel.
Gesucht wird der SPN mit "CIFS" statt "HOST"
Für bestimmte Speicher-Systeme muss ein entsprechender SPN gesetzt werden, damit Kerberos funktioniert. "CIFS/Storage.domain.tld" wird gerne dafür genommen. Windows benutzt den HOST für SMB/CIFS. Der wird auch für die Systeme angelegt. Warum versucht der Client NTLM? Die Lösung ist oft einfach: Er sucht nach dem SPN für "CIFS/Domain.tld", wenn er zum Beispiel auf SYSVOL oder NetLogon zugreifen möchte. Wenn das nicht geht, benutzt er brav "HOST/DC.Domain.tld" nach kurzer Zeit. Das gilt auch teilweise für Zugriffe auf andere SMB Freigaben.
Um zu sehen, ob es CIFS-Einträge in den SPNs gibt, verwende diesen Befehl:
Setspn.exe -Q "cifs/*"
Das wäre mal was, für Microsoft zum "Entrümpeln".
Der Spooler aka Printer Nightmare
Seit KB5005010 macht der Drucker-Dienst gerne mal komische Sachen. Damals wurde eine Sicherheitslücke namens "Printer Nightmare" geschlossen. Der Spoolerdienst sucht dadurch nach dem SPN "krbtgt/NT Authority". Es gibt diesen aber nicht.
Die Lösung ist, dass man auf Servern, die keine Drucker haben oder brauchen, folgendes macht: Deaktiviere den Dienst. Er hat oft Sicherheitslücken. Wenn er nicht gebraucht wird, sollte er abgeschaltet werden. Damit kommt man auch schon mal der IT-Grundschutz Maßnahme "SYS.1.1.A6 Deaktivierung nicht Benötigter Dienste (B)" und "SYS.1.2.3.A4 Schutz vor Ausnutzung von Schwachstellen in Anwendungen (S)" nach.
Für die anderen Systeme gibt es von Microsoft einen Schlüssel in der Registry:
HKEY_LOCAL_MACHINESOFTWAREPoliciesMicrosoftWindows NTPrintersRPC |
RpcNamedPipeAuthentication == 0x2 (DWORD)
Dieser ändert die Art der Anmeldung für den Dienst. Meistens ist das Problem dann gelöst. Eine Microsoft-Anleitung sagt, wie man das prüfen kann. In dem Microsoft-Artikel "A Print Nightmare Artifact - krbtgt/NT Authority" steht, wie es geht und mehr zu den Hintergründen.
Microsoft CA mit AutoEnrollment
Damit das Autoenrollment im AD klappt, muss NTLM auf der CA erlaubt werden. Wenn jemand eine Lösung findet, würde ich mich über einen Hinweis freuen. Ich habe keine gefunden.
Das sollte Microsoft reparieren.
Terminal Server mit NLA und Zugriff von außerhalb der Domäne
Das ist ein Sonderfall, der aber bei meinen Kunden öfters vorkommt. Das sind abgeschottete Management-Umgebungen (Dark Sites), auf die meist nur von einem speziellen JumpHost aus zugegriffen werden kann. Die ersten JumpHosts sind nicht in der Ziel-Domäne. Es gibt keine AD-Vertrauensstellung (aus Sicherheitsgründen). NLA kann deshalb kein Kerberos nutzen. Es wird also auf NTLM zurückgegriffen. Die Quellserver sind geschützt und die Firewalls zwischen den Umgebungen sehr streng. Deshalb hat man den Grund für NLA eigentlich anders gelöst. Ich denke, wir brauchen für die speziellen Server keine NLA mehr.
In der Kerberos-Zone läuft wieder NLA, auch wenn es Firewalls mit Microsegmentierung gibt. Das spart Diskussionen über den IT-Grundschutz.