Bringt die NTLM-Abschaffung Ihre Fachanwendungen zum Stillstand? — Wie Sie Audit-Protokolle erfassen und in welcher Reihenfolge Sie Abhängigkeiten beseitigen

„NTLM soll wohl abgeschafft werden. Sind wir betroffen?“ — seit Microsoft im Juni 2024 alle Versionen von NTLM als deprecated eingestuft hat, wird uns diese Frage immer häufiger gestellt. Die Antwort lautet: Ob Sie betroffen sind, lässt sich herausfinden – und wenn Sie jetzt nachsehen, haben Sie noch Zeit.

Die Abschaffung von NTLM ist keine Änderung, bei der eines Tages ein Patch einschlägt und das gesamte Unternehmen stillsteht. Sie verschärft sich mit jedem neuen Betriebssystem ein Stück weiter – und nur solange NTLM noch funktioniert, können Sie gefahrlos eine Liste erstellen, wo in Ihrer Umgebung Abhängigkeiten von NTLM bestehen. Erst alles abzuschalten und anschließend nach dem Kaputten zu suchen, ist genau die Reihenfolge, die Sie vermeiden müssen.

Dieser Artikel konzentriert sich auf das praktische Vorgehen, um diese Liste zu erstellen und Punkt für Punkt abzuarbeiten. Die Mechanik der Protokolle selbst (warum NTLM riskant ist, warum die Authentifizierung nicht bei Kerberos bleibt) ist in den begleitenden Artikel „NTLM und Kerberos anhand von Diagrammen erklärt — Warum die Authentifizierung auf NTLM zurückfällt“ ausgelagert.

1. Das Wichtigste zuerst

• NTLM wurde im Juni 2024 als deprecated eingestuft. Das betrifft alle Versionen einschließlich LANMAN, NTLMv1 und NTLMv2 und ist eine Erklärung, dass „es keine aktive Funktionsentwicklung mehr geben wird“. Gleichzeitig heißt es in dem Hinweis, dass „die Verwendung von NTLM in der nächsten Windows-Server-Version und im nächsten jährlichen Windows-Release weiterhin funktioniert“.¹
• Manche Teile wurden bereits entfernt. NTLMv1 wurde in Windows 11 Version 24H2 und Windows Server 2025 entfernt.¹
• Die Abschaffung verläuft in drei Phasen. Phase 1 macht die Nutzung sichtbar und auditiert sie; Phase 2 (zweite Jahreshälfte 2026) bringt Funktionen, die die Situationen beseitigen, in denen NTLM unvermeidbar ist (IAKerb, lokaler KDC); Phase 3 deaktiviert Netzwerk-NTLM-Authentifizierung im nächsten Major-Release standardmäßig.²
• Es gibt gerade jetzt nur eine einzige Aufgabe: Führen Sie den Audit-Modus aus und erstellen Sie eine Liste, „welcher Rechner, welche Anwendung, gegen welchen Server“ NTLM verwendet (Abschnitt 4).
• Untersuchen Sie Domänenkonten ausgehend vom Domänencontroller. Folgen Sie Ereignis 8004 → 8003 auf dem Mitgliedsserver → 8001 auf dem Client, und Sie gelangen bis zum Anwendungsnamen (Abschnitt 4.2). Aber die Authentifizierung mit lokalen Konten läuft nicht über einen Domänencontroller, sodass kein Ereignis 8004 erscheint. Erfassen Sie diesen Weg über 8003 auf dem Server und 8001 auf dem Client.³
• Die meisten Ursachen laufen auf „Namen“ hinaus. Fest codierte IP-Adressen und nicht registrierte SPNs sind die beiden größten Faktoren, und beide lassen sich beheben, ohne die Anwendung neu zu bauen (Abschnitt 5).³²
• Es gibt eine Möglichkeit, gefahrlos auf einem einzelnen Rechner zu testen. Unter Windows 11 24H2 / Windows Server 2025 lässt sich mit NET USE \\server\share /BLOCKNTLM prüfen, „ob die Verbindung ohne NTLM funktioniert“, ohne auch nur eine einzige Richtlinie zu ändern (Abschnitt 7).⁴
• Ändern Sie in eigenen Anwendungen die Stellen, an denen NTLM namentlich genannt wird, auf Negotiate. Microsoft selbst schreibt: „Greifen Sie nicht direkt auf das NTLM-Sicherheitspaket zu“ (Abschnitt 8).⁵

2. Was „deprecated“ tatsächlich bedeutet

Klären wir zuerst die Begriffe. Erklären Sie das dem Fachbereich, solange das vage bleibt, kursieren gleichzeitig „das können wir wohl nicht mehr benutzen“ und „das geht wohl noch jahrelang“, und das Gespräch zerfällt.

Zusammengefasst macht der NTLM-Eintrag in Microsofts Liste der veralteten Funktionen drei Aussagen.¹

1. Alle Versionen von NTLM, einschließlich LANMAN, NTLMv1 und NTLMv2, werden nicht mehr aktiv weiterentwickelt und sind deprecated.
2. Die Verwendung von NTLM funktioniert in der nächsten Windows-Server-Version und im nächsten jährlichen Windows-Release weiterhin.
3. Aufrufe von NTLM sollten durch Aufrufe von Negotiate ersetzt werden, das eine Authentifizierung mit Kerberos versucht und nur bei Bedarf auf NTLM zurückfällt.

Und als Aktualisierung wird ergänzt, dass NTLMv1 in Windows 11 Version 24H2 und Windows Server 2025 entfernt wurde.¹

Der aktuelle Stand ist also „deprecated“, nicht „removed“. Allein NTLMv1 hat die Stufe „deprecated“ bereits hinter sich gelassen und befindet sich in der Entfernungsphase. Kann ein altes Multifunktionsgerät oder ein NAS nur mit NTLMv1 authentifizieren, bricht ein Update auf Windows 11 24H2 genau dort ab. Das ist kein Zukunftsproblem, sondern passiert bereits jetzt.

Der zweite Punkt, den man im Kopf behalten sollte: Für manche Einsatzzwecke von NTLM gibt es weiterhin keine Alternative. Microsoft erklärt ausdrücklich, dass NTLM für die Windows-Authentifizierung auf Systemen, die als Mitglieder einer Arbeitsgruppe konfiguriert sind, sowie für die lokale Anmeldeauthentifizierung auf Nicht-Domänencontrollern weiterhin verwendet wird und verwendet werden muss.⁶ Der für Phase 2 geplante lokale KDC ist genau die Funktion, die diese Lücke „NTLM wird für lokale Konten benötigt“ schließen soll.²

3. Warum es verschwindet — nur drei Minuten

Nur so viel, wie für die Migrationsentscheidung nötig ist. Die ausführliche, mit Diagrammen versehene Fassung finden Sie im begleitenden Artikel.

Microsoft schreibt in der Dokumentation zu den Richtlinieneinstellungen unmissverständlich, dass NTLM- und NTLMv2-Authentifizierung für verschiedene böswillige Angriffe anfällig ist, darunter SMB-Relay, Man-in-the-Middle-Angriffe und Brute-Force-Angriffe.⁷ Die Wurzel davon liegt in den folgenden Eigenschaften, die stets im Vergleich mit Kerberos genannt werden.⁸

• Es gibt keine gegenseitige Authentifizierung. Bei NTLM kann weder der Client die Identität des Servers überprüfen, noch kann ein Server die Identität eines anderen Servers überprüfen. NTLM wurde für Netzwerkumgebungen entworfen, in denen davon ausgegangen werden kann, dass Server echt sind. Kerberos trifft diese Annahme nicht. Genau dieser Unterschied ist die Voraussetzung für Relay-Angriffe, bei denen Anmeldeinformationen an einen gefälschten Server gesendet werden.
• Der Server fragt bei jeder Anmeldung erneut den Domänencontroller (bei Domänenkonten). Bei NTLM muss der Anwendungsserver bei jeder Authentifizierung eines Clients mit einem Domänenkonto eine Verbindung zum Domänencontroller herstellen (bei einem Konto, das lokal auf dem Server liegt, prüft der Server anhand seiner eigenen Kontendatenbank selbst).⁶ Bei Kerberos ersetzen erneuerbare Sitzungstickets diese Pass-Through-Authentifizierung, und der Server muss den Domänencontroller nur kontaktieren, wenn eine PAC-Prüfung (Privilege Attribute Certificate) erforderlich ist.
• Das Authentifizierungsmaterial ist der Passwort-Hash selbst. NTLM-Anmeldeinformationen bestehen aus einem Einweg-Hash von Domänenname, Benutzername und Passwort, und der Client verschlüsselt die Challenge mit diesem Hash und sendet die Antwort zurück.⁵ Daraus ergibt sich die Eigenschaft, dass jemand, der den Hash stiehlt, sich als der Benutzer ausgeben kann, ohne das Klartextpasswort zu kennen.

Die praktische Bedeutung von „keine gegenseitige Authentifizierung“ ist, dass allein der Versuch, sich mit einer SMB-Freigabe zu verbinden, dazu führen kann, dass Anmeldeinformationen an einen gefälschten Server übergeben werden. Auch der Grund, den Microsoft für die NTLM-Blockierung auf SMB-Client-Seite angibt, lautet: „Techniken verhindern, die NTLM-Anfragen an böswillige Server senden lassen“.⁴

4. Auditing — Erfassen, wo NTLM verwendet wird

Das ist der Kern des Ganzen. Auch die Anleitung von Microsoft stellt klar, dass es notwendig ist, den aktuellen Zustand des NTLM-Authentifizierungsverkehrs zu erkennen und zu auditieren, bevor Einschränkungsrichtlinien implementiert werden.⁹

4.1. Audit-Modus aktivieren

Es sind drei Richtlinien zu setzen. Alle liegen unter Computerkonfiguration\Windows-Einstellungen\Sicherheitseinstellungen\Lokale Richtlinien\Sicherheitsoptionen, und ein Neustart ist nicht erforderlich. Ob lokal gespeichert oder per Gruppenrichtlinie verteilt – die Einstellung wird wirksam, sobald sie angewendet wird.⁷

Allerdings sind „kein Neustart nötig“ und „wirkt sofort auf allen Rechnern“ zwei verschiedene Dinge. Verteilen Sie über eine Domänen-GPO, wird beim Speichern der GPO zunächst nur die Richtlinie in AD/SYSVOL aktualisiert; jeder Rechner beginnt erst bei der nächsten Hintergrundaktualisierung oder nach einem gpupdate /force tatsächlich mit dem Auditing. Zählen Sie den Beginn des Audit-Zeitraums nicht ab „dem Zeitpunkt, an dem die GPO gespeichert wurde“, sondern ab „dem Zeitpunkt, an dem die Anwendung auf den betroffenen Rechnern tatsächlich angekommen ist“. Verwechseln Sie das, verzerrt sich das Ergebnis so, dass nur bei der ersten Auswertung weniger Rechner erfasst werden.

Die dritte Richtlinie, „Ausgehender NTLM-Datenverkehr zu Remoteservern“, kennt vier Werte — Alle zulassen / Alle überwachen / Alle verweigern / Nicht definiert —, wobei „Nicht definiert“ wie „Alle zulassen“ behandelt wird. Auch Microsofts Empfehlung ist eindeutig: Wählen Sie nicht sofort „Alle verweigern“, sondern setzen Sie zunächst „Alle überwachen“, prüfen Sie das Betriebsprotokoll, verschaffen Sie sich einen Überblick, welche Server Authentifizierungsanfragen erhalten, und erstellen Sie erst danach eine Ausnahmeliste.⁷

Erfasst werden die Ereignisse unter Ereignisanzeige > Anwendungs- und Dienstprotokolle > Microsoft > Windows > NTLM (Microsoft-Windows-NTLM/Operational). Für dieses Auditing gibt es keine entsprechende Sicherheitsüberwachungsrichtlinie, daher schauen Sie nicht ins Sicherheitsprotokoll, sondern auf diesen Kanal.⁷

Hinweis: Der Audit-Modus zeichnet nur auf und blockiert nichts. Andererseits steigt in Umgebungen mit vielen Rechnern das Protokollvolumen sprunghaft an. Wenn Sie keine Ereignisweiterleitung (WEF) einsetzen, prüfen Sie zuerst die Obergrenze der Protokollgröße und die Aufbewahrungsdauer, bevor Sie das Auditing aktivieren. Auch die Anleitung von Microsoft weist darauf hin, dass die Analyse je nach Komplexität der Umgebung mehrere Monate dauern kann.³

4.2. Verfolgung „vom Domänencontroller stromabwärts“

Für das Lesen der gesammelten Ereignisse gibt es eine feste Reihenfolge. Der von Microsofts Anleitung gezeigte Verfolgungspfad ist der folgende.³

flowchart TD
    DC["Domänencontroller<br/>Ereignis 8004"]
    MS["Mitgliedsserver<br/>Ereignis 8003"]
    CL["Client<br/>Ereignis 8001"]
    APP["Verursachende Anwendung"]

    DC -->|"Sicherer Kanalname =<br/>zu prüfender Server"| MS
    MS -->|"Arbeitsstationsname =<br/>zu prüfender Client"| CL
    CL -->|"Name des Client-Prozesses"| APP
    MS -.->|"PID = 4 (SYSTEM) bedeutet<br/>über SMB"| CL

Abbildung 1: Reihenfolge zur Verfolgung von NTLM-Audit-Ereignissen

Bei jedem Ereignis ist Folgendes zu betrachten.³

Auf diesem Pfad sind besonders der „Zielserver“ und der „Name des Client-Prozesses“ in 8001 wertvoll. Ersterer sagt Ihnen direkt, warum es nicht zu Kerberos kam; Letzterer sagt Ihnen, wer verantwortlich ist. Auch Microsofts Anleitung erklärt, dass sich anhand dieser Informationen feststellen lässt, dass ein Benutzer sich mit der IP-Adresse eines Webservers verbindet, statt den NetBIOS-Namen oder FQDN zu verwenden, mit dem Kerberos hätte genutzt werden können.³

Beachten Sie außerdem: Es gibt Fälle, in denen auf dem Domänencontroller kein 8004 erscheint. Wenn ein lokales Benutzerkonto zur Verbindung mit einem Dateiserver verwendet wird, läuft diese Authentifizierung nicht über einen Domänencontroller.³ Schließen Sie nicht aus einem Blick auf die DC-Protokolle, in denen wenig zu sehen war, dass alles in Ordnung ist.

4.3. Mit PowerShell auswerten

Tausende Einträge in der GUI der Ereignisanzeige zu betrachten, ist nicht realistisch, daher werten Sie mit Get-WinEvent aus. Prüfen Sie zunächst, welche Ereignisse in welcher Anzahl auf dem Rechner vorliegen.

# NTLM/Operational-Ereignisse nach ID auswerten (als Administrator ausführen)
Get-WinEvent -FilterHashtable @{
    LogName   = 'Microsoft-Windows-NTLM/Operational'
    StartTime = (Get-Date).AddDays(-7)
} -ErrorAction SilentlyContinue |
    Group-Object Id |
    Sort-Object Count -Descending |
    Select-Object Count, @{ N = 'EventId'; E = { $_.Name } }

Sobald Sie bestätigt haben, dass Ereignisse anfallen, gruppieren Sie die 8001-Ereignisse der Clientseite nach „Zielserver × aufrufender Prozess“. Der Feldaufbau unterscheidet sich je Ereignis-ID, daher ist es sicherer, zunächst ein Ereignis mit Format-List zu öffnen und die Struktur zu prüfen, bevor Sie sich auf Indizes festlegen.

# Zunächst nur ein Ereignis inhaltlich prüfen
$sample = Get-WinEvent -FilterHashtable @{
    LogName = 'Microsoft-Windows-NTLM/Operational'
    Id      = 8001
} -MaxEvents 1

$sample | Format-List TimeCreated, Id, Message
# Um die strukturierten Felder zu sehen
([xml]$sample.ToXml()).Event.EventData.Data |
    Select-Object Name, '#text'

Sobald die Struktur klar ist, extrahieren Sie über das XML-Attribut Name und werten aus. Attributnamen unterscheiden sich zwischen den OS-Versionen, daher ist ein Zugriff über den Namen weniger fehleranfällig als eine positionsbasierte Indizierung.

# Die 8001-Ereignisse der letzten 7 Tage nach "Ziel x aufrufender Prozess" auswerten
$events = Get-WinEvent -FilterHashtable @{
    LogName   = 'Microsoft-Windows-NTLM/Operational'
    Id        = 8001
    StartTime = (Get-Date).AddDays(-7)
} -ErrorAction SilentlyContinue

$rows = foreach ($e in $events) {
    $data = @{}
    foreach ($d in ([xml]$e.ToXml()).Event.EventData.Data) {
        $data[$d.Name] = $d.'#text'
    }
    [pscustomobject]@{
        Time    = $e.TimeCreated
        # Nur die tatsächlich vorhandenen Feldnamen abholen, priorisiert
        Target  = @('TargetName', 'TargetServer', 'ServerName') |
                  Where-Object { $data.ContainsKey($_) } |
                  ForEach-Object { $data[$_] } | Select-Object -First 1
        Process = @('ClientProcessName', 'ProcessName', 'ApplicationName') |
                  Where-Object { $data.ContainsKey($_) } |
                  ForEach-Object { $data[$_] } | Select-Object -First 1
    }
}

$rows | Group-Object Target, Process |
    Sort-Object Count -Descending |
    Select-Object Count, Name

Da sich die Feldnamen zwischen OS-Versionen unterscheiden, listet der Code Kandidaten in einem priorisierten Array auf und übernimmt nur die tatsächlich vorhandenen. Verwenden Sie hier einen Teiltreffer wie -match 'Process', erwischen Sie auch PID-Felder wie ClientProcessId und werten am Ende nach einer sich jedes Mal ändernden PID statt nach dem Namen der ausführbaren Datei aus (und da die Schlüsselreihenfolge einer Hashtable nicht definiert ist, ist auch nicht stabil, welches der beiden Sie erhalten). Bleibt die Spalte Process vollständig leer, ist das ein Zeichen, dass die Kandidatennamen nicht zum tatsächlichen Schema passen — ergänzen Sie die im vorigen Schritt bestätigten Namen im Array.

Sammeln Sie von mehreren Rechnern, ist es am schnellsten, dies parallel mit PowerShell Remoting auszuführen (“Einstieg in PowerShell Remoting (WinRM)”). Die Filterung mit Get-WinEvent unterscheidet sich je nachdem, ob Sie -FilterHashtable verwenden, um Größenordnungen in der Laufzeit, und die wesentlichen Punkte dazu sind in „Ereignisprotokolle praxisnah mit Get-WinEvent untersuchen“ zusammengefasst.

4.4. Blick von der Sicherheitsprotokoll-Seite — Wird noch NTLMv1 verwendet?

Getrennt von NTLM/Operational gibt es auch die Möglichkeit, die NTLM-Version anhand der Anmeldeereignisse im Sicherheitsprotokoll zu prüfen. Das Vorgehen besteht darin, im Sicherheitsprotokoll nach „Authentifizierungspaket“ zu suchen und bei jedem Ereignis die „Detaillierten Authentifizierungsinformationen“ anzusehen.³

Detaillierte Authentifizierungsinformationen:
    Anmeldeprozess:              NtLmSsp
    Authentifizierungspaket:     NTLM
    Übertragene Dienste:         -
    Paketname (nur NTLM):        NTLM V1
    Schlüssellänge:              128

Dieser „Paketname (nur NTLM)“ zeigt, welches Unterprotokoll der NTLM-Familie verwendet wurde.³ Ein Host, bei dem NTLM V1 erscheint, ist ein Kandidat dafür, dass die Authentifizierung nicht mehr funktioniert, wenn Sie ihn unverändert auf Windows 11 24H2 / Windows Server 2025 heben, da NTLMv1 in diesen Versionen entfernt wurde.¹ Wenn Sie das Auditing durchführen, geben Sie gerade diesem Punkt Priorität.

4.5. Wenn die PID immer 4 (SYSTEM) ist und Sie nicht weiterkommen

Sobald Sie mit dem Auditing beginnen, stoßen Sie fast unweigerlich auf diese Mauer. Bei Anwendungen, die wie SMB (Freigabeordner) über den Redirector kommunizieren, ist die Instanz, die die Authentifizierung anfordert, der Kernelmodus-Redirector, sodass die im Ereignis hinterlegte PID immer 4 (SYSTEM) ist.³

Die von Microsofts Anleitung genannte Abhilfe lautet wie folgt.³

1. Installieren Sie auf dem Client, der die NTLM-Anmeldeinformationen sendet (der „Computer“ in 8001), ein Prozessüberwachungstool.
2. Filtern Sie Pfade nach sowohl dem Computernamen als auch der IP-Adresse des Gegenservers. Ist eine längere Erfassung nötig, führen Sie sie im Hintergrundmodus aus.
3. Gleichen Sie das Erfassungsergebnis mit den Zeitstempeln von Ereignis 8003 auf der Serverseite ab. Benutzer, Pfad und Authentifizierungskennung stimmen überein, sodass sich von dort aus die aufrufende Anwendung identifizieren lässt.

Das Werkzeug dafür ist Process Monitor (ProcMon). Wie Sie Filter setzen und die Ausgabe lesen, ist im „Praxisleitfaden zu Process Monitor (ProcMon)“ zusammengefasst.

Ein praktischer Tipp: Grenzen Sie bis zu diesem Schritt allein mit den Ereignisprotokollen ein, um welchen Rechner es sich handelt, und setzen Sie ProcMon erst danach nur auf diesem einen Rechner ein. Das ist deutlich schneller. ProcMon auf allen Rechnern auszurollen, ist nicht realistisch.

5. Die typischen Muster, die auf NTLM zurückfallen

Sobald das Auditing die Stelle gezeigt hat, folgt als Nächstes die Einordnung der Ursache. Microsofts Anleitung nennt vier Arten von Anwendungen, die NTLM verwenden, obwohl sie theoretisch Kerberos unterstützen.³

• Anwendungen, bei denen Sie zwischen verschiedenen Sicherheitskonfigurationen und Providern wählen können
• Anwendungen, deren SPN (Service Principal Name) nicht korrekt konfiguriert ist
• Anwendungen, die aufgrund einer Fehlkonfiguration oder der Herstellerdokumentation IP-Adressen statt DNS-Namen verwenden
• Anwendungen mit einer Legacy-Codebasis, die noch reine NTLM-Anteile enthält

Der Microsoft-Japan-Support-Blog nennt als typische Ursachen für die Verwendung von NTLM den Serverzugriff per IP-Adresse, Firewall-Einschränkungen bei den von Kerberos benötigten Ports, nicht registrierte SPNs, die Authentifizierung gegenüber vertrauenswürdigen Partnern sowie die Authentifizierung in Arbeitsgruppenumgebungen.²

In die Form gebracht, wie Sie sie in der Praxis antreffen, ergibt sich folgende Tabelle.

Die Einträge, die als „Sofort behebbar“ und „Durch SPN-Registrierung behebbar“ eingestuft sind, dürften den Großteil Ihrer Audit-Ergebnisse ausmachen. Werden allein diese abgearbeitet, sinkt die Zahl der verbleibenden Ausnahmen deutlich.

6. Entscheidungstabelle für die Behebung

7. NTLM-Blockierung bei SMB — Der schnellste Weg zur praktischen Überprüfung

Audit-Protokolle sagen Ihnen, was verwendet wird, aber nicht, was passiert, wenn Sie es abschalten. Hier hilft die auf der SMB-Client-Seite in Windows Server 2025 und Windows 11 Version 24H2 hinzugekommene NTLM-Blockierung.⁴

Diese Funktion blockiert, dass der SMB-Client bei ausgehenden Verbindungen zu entfernten Rechnern NTLM-Authentifizierung verwendet. Microsoft erklärt, dass dies Techniken verhindert, die NTLM-Anfragen an böswillige Server senden lassen, und Brute-Force-, Cracking- und Pass-the-Hash-Angriffen entgegenwirkt, und ordnet die NTLM-Blockierung als notwendig für die Umstellung des Authentifizierungsprotokolls einer Organisation auf Kerberos ein. Gleichzeitig heißt es, dass sich diese Schutzschicht auch aktivieren lässt, ohne NTLM vollständig zu deaktivieren.⁴

Es gibt zwei Voraussetzungen.⁴

• Der SMB-Client läuft unter Windows Server 2025 oder neuer, oder Windows 11 Version 24H2 oder neuer
• Der Ziel-SMB-Server kann Kerberos verwenden (das Betriebssystem des SMB-Servers darf beliebig sein, solange es PKU2U oder Kerberos unterstützt)

7.1. Zunächst nur mit einem Rechner und einer Verbindung testen

Nutzen Sie, statt sofort eine Richtlinie zu verteilen, die Möglichkeit, die Blockierung pro Verbindung anzugeben. Das ist der schnellste Weg zur praktischen Überprüfung.

# Nur für diese Verbindung NTLM verbieten und verbinden (klappt es, kommt die Freigabe ohne NTLM aus)
NET USE \\fileserver.corp.example.com\share /BLOCKNTLM

# Mit einer PowerShell-Zuordnung geht dasselbe
New-SmbMapping -RemotePath \\fileserver.corp.example.com\share -BlockNTLM $true

Klappt die Verbindung, kommt dieser Weg ohne NTLM aus. Schlägt sie fehl, ist dort eine NTLM-Abhängigkeit. Sie können, ohne auch nur eine Richtlinie zu ändern, Verbindung für Verbindung prüfen, ob es im Produktivbetrieb ausfällt, was sich hervorragend eignet, um Audit-Protokolle abzusichern.

Diese Prüfung erfordert jedoch ein Vorgehen. Führen Sie sie unüberlegt aus, erhalten Sie Fehlbeurteilungen in beide Richtungen.

$server = 'fileserver.corp.example.com'

# 1. Sämtliche Zuordnungen zu diesem Server "restlos" entfernen
#    Bleibt auch nur eine andere Freigabe bestehen, lebt die serverweite Sitzung weiter
net use | Select-String $server              # Zunächst ansehen, was verbunden ist
net use \\$server\share  /delete
net use \\$server\other  /delete             # Auch alle anderen Freigaben desselben Servers

# 2. Bestätigen, dass die Sitzung wirklich verschwunden ist (erst weitermachen, wenn leer)
Get-SmbConnection -ServerName $server

# 3. Zunächst prüfen, dass die Verbindung ohne Flag funktioniert (schlägt das schon fehl, liegt es nicht an NTLM)
net use \\$server\share
net use \\$server\share /delete
Get-SmbConnection -ServerName $server        # Auch hier wieder leeren

# 4. Erst dann mit /BLOCKNTLM testen
net use \\$server\share /BLOCKNTLM

• Warum die Schritte 1–2 nötig sind: SMB-Sitzungen bestehen serverweit, nicht freigabeweise. Bleibt eine bereits authentifizierte Sitzung zu diesem Server bestehen, verwendet der Redirector sie erneut, ohne die Authentifizierung zu wiederholen. /BLOCKNTLM wirkt nur auf die Authentifizierung, die für diese eine Zuordnung durchgeführt wird, und prüft eine bereits bestehende Sitzung (die möglicherweise mit NTLM aufgebaut wurde) nicht nachträglich. Mit anderen Worten: Es reicht nicht, nur die zu testende Freigabe zu /delete. Bleibt eine andere Freigabe desselben Servers verbunden, gelingt die Verbindung trotz bestehender NTLM-Abhängigkeit. Bringen Sie den Zustand herunter, bis Get-SmbConnection nichts mehr zurückgibt. Neben Ihren eigenen Zuordnungen können auch residente Anwendungen oder Backup-Jobs Sitzungen offenhalten. Am zuverlässigsten und schnellsten ist es, von einem Rechner aus zu testen, der sich noch nie mit diesem Server verbunden hat.
• Warum Schritt 3 nötig ist: Ein Fehlschlag bei der Namensauflösung, falsche Anmeldeinformationen oder fehlende Zugriffsrechte auf die Freigabe selbst lassen auch die Ausführung mit /BLOCKNTLM fehlschlagen. Schlägt es auch ohne das Flag fehl, liegt keine NTLM-Abhängigkeit vor, sondern ein anderes Problem.

Beachten Sie, dass sich hieraus nur sagen lässt, dass „NTLM nicht erforderlich war“, nicht, dass „mit Kerberos authentifiziert wurde“. Voraussetzung dieser Funktion ist ein „SMB-Server, der Kerberos verwenden kann“, aber als Ziel ist auch ein Betriebssystem zulässig, das PKU2U verwenden kann.⁴ Es bleibt also die Möglichkeit, dass der Erfolg nicht Kerberos, sondern PKU2U zu verdanken ist. Bei einem domänenbeigetretenen Dateiserver als Gegenstelle ist das meist kein Problem, aber wenn Sie tatsächlich feststellen wollen, womit authentifiziert wurde, führen Sie nach dem Verbinden auf dem Client klist aus und prüfen, ob ein cifs/-Ticket für den betreffenden Server ausgestellt wurde, oder prüfen Sie im Sicherheitsprotokoll des Servers das Authentifizierungspaket im Anmeldeereignis (Abschnitt 4.4).

7.2. Rechnerweit aktivieren

Ist die Absicherung erledigt, gehen Sie auf Pilotrechnern zur rechnerweiten Blockierung über.⁴

# NTLM für den gesamten SMB-Client blockieren (Administratorrechte erforderlich)
Set-SmbClientConfiguration -BlockNTLM $true

Bei Gruppenrichtlinien aktivieren Sie unter Computerkonfiguration > Administrative Vorlagen > Netzwerk > Lanman-Arbeitsstation die Option „NTLM blockieren (LM, NTLM, NTLMv2)“.⁴

7.3. Gegenstellen, die zwangsläufig bleiben, auf die Ausnahmeliste

Gegenstellen, die zwingend NTLM benötigen, etwa nicht domänenbeigetretene SMB-Server, können Sie als Ausnahme führen. Aktivieren Sie in der Gruppenrichtlinie unter Lanman-Arbeitsstation > NTLM-Server-Ausnahmeliste blockieren die Einstellung und listen Sie die erlaubten Gegenstellen mit IP-Adresse, NetBIOS-Namen und FQDN auf.⁴

Für die Ausnahmeliste selbst gibt es kein PowerShell-Cmdlet, sodass Sie sie beim ersten Mal im Gruppenrichtlinien-Editor anlegen müssen; einzelne Ergänzungen danach lassen sich per Registrierungsänderung vornehmen.⁴

# Einträge zur bestehenden Ausnahmeliste hinzufügen
$params = @{
  Path = "HKLM:\SOFTWARE\Policies\Microsoft\Windows\LanmanWorkstation"
  Name = "BlockNTLMServerExceptionList"
}
$Entries = "192.168.10.10", "corp.contoso.com", "CORP"

$CurrentValue = (Get-ItemProperty @params -ErrorAction SilentlyContinue).BlockNTLMServerExceptionList
$params["Value"] = if ($null -eq $CurrentValue) { $Entries }
                   else { $CurrentValue + $Entries }
Set-ItemProperty @params

Hinweis: Das in Microsofts Dokumentation enthaltene Beispiel setzt im Zweig für den Fall, dass der Wert noch nicht existiert, lediglich @(""), wodurch die eigentlich gewünschten Einträge stillschweigend verworfen werden.⁴ Das führt dazu, dass beim ersten Durchlauf keine einzige Ausnahme eingetragen wird und erst beim zweiten Durchlauf. Der obige Code schreibt die Einträge daher auch dann direkt, wenn der Wert noch nicht angelegt wurde. Dieser Registrierungswert liegt jedoch grundsätzlich im Verwaltungsbereich der Gruppenrichtlinie. Verwalten Sie dauerhafte Ausnahmen über die Gruppenrichtlinie, und beschränken Sie diesen Eingriff auf akute Notfälle. Bei der nächsten Anwendung der Richtlinie wird er überschrieben.

Hinweis: Diese Funktion ist eine Funktion des SMB-Clients.⁴ NTLM über andere Wege (HTTP-Kommunikation eigener Anwendungen, Verbindungen zu SQL Server, WinRM usw.) wird dadurch nicht gestoppt. Diese müssen Sie gemäß der Einordnung aus Abschnitt 5 einzeln beheben.

8. NTLM aus Entwicklersicht — Negotiate verwenden

Wenn Sie selbst Windows-Anwendungen entwickeln, ist klar, was zu beheben ist. Microsoft schreibt es ausdrücklich.⁵

Anwendungen sollten nicht direkt auf das NTLM-Sicherheitspaket zugreifen. Stattdessen sollten sie das Negotiate-Sicherheitspaket verwenden. Negotiate erlaubt Anwendungen, fortgeschrittenere Sicherheitsprotokolle zu nutzen, sofern die an der Authentifizierung beteiligten Systeme sie unterstützen. Derzeit wählt das Negotiate-Sicherheitspaket zwischen Kerberos und NTLM. Negotiate wählt Kerberos, außer wenn eines der an der Authentifizierung beteiligten Systeme Kerberos nicht verwenden kann.

Kurz gesagt gilt das Prinzip: Stellen, an denen „NTLM“ steht, werden auf „Negotiate“ geändert. Auch die Beschreibung in der Liste veralteter Funktionen lautet gleich: Aufrufe von NTLM sollten durch Aufrufe von Negotiate ersetzt werden.¹

8.1. Die häufige „explizite Nennung von NTLM“ in .NET

// Schlecht: NTLM wird als Authentifizierungstyp namentlich genannt
var credential = new NetworkCredential(user, password, domain);
var cache = new CredentialCache();
cache.Add(new Uri("http://intra.example.local/"), "NTLM", credential);

var handler = new HttpClientHandler { Credentials = cache };

// Gut: Geändert wird nur der Authentifizierungstyp. Die Anmeldeinformationen bleiben unverändert
var credential = new NetworkCredential(user, password, domain);
var cache = new CredentialCache();
cache.Add(new Uri("http://intra.example.local/"), "Negotiate", credential);

var handler = new HttpClientHandler { Credentials = cache };

Was Sie hier ändern, ist ausschließlich die Zeichenkette des Authentifizierungstyps. Ersetzen Sie credential durch CredentialCache.DefaultNetworkCredentials, ändern Sie nicht nur das Authentifizierungsprotokoll, sondern auch die authentifizierende Identität. Die Authentifizierung erfolgt dann nicht mehr mit dem angegebenen Konto, sondern mit dem Konto, unter dem der Prozess läuft (ein Dienstkonto oder der angemeldete Benutzer), und je nach Berechtigungskonfiguration am Ziel funktioniert es möglicherweise nicht mehr. Behandeln Sie den Protokollwechsel und eine Überprüfung der Anmeldeinformationen als getrennte Änderungen.

Möchten Sie hingegen tatsächlich mit den Anmeldeinformationen des angemeldeten Benutzers authentifizieren (integrierte Windows-Authentifizierung), lässt sich das einfacher schreiben. Das ist die Schreibweise für den Fall, dass Sie „wer authentifiziert“ bewusst ändern möchten.

// Integrierte Windows-Authentifizierung (Authentifizierung als aktuell angemeldeter Benutzer)
var handler = new HttpClientHandler
{
    UseDefaultCredentials = true,
};

Der Umgang mit HttpClient selbst (nicht in using einwickeln, Erzeugungsmuster, Timeout-Design) ist in „HttpClient nicht in using einwickeln“ zusammengestellt.

Müssen Sie SSPI direkt behandeln, lässt sich mit System.Net.Security.NegotiateAuthentication, hinzugefügt in .NET 7, die Authentifizierung über Negotiate aus verwaltetem Code heraus abwickeln. Auch hier ist der entscheidende Punkt, im Paketnamen kein NTLM anzugeben.

8.2. Vor dem Code zuerst „wie das Ziel geschrieben ist“ prüfen

Selbst nach einer Korrektur des Codes gilt: Bleibt das Ziel eine IP-Adresse, landen Sie letztlich doch bei NTLM. Standardmäßig versucht Windows keine Kerberos-Authentifizierung gegen einen Host, dessen Hostname eine IP-Adresse ist, und fällt auf ein anderes gültiges Protokoll wie NTLM zurück.¹⁰ Prüfen Sie konkret Folgendes.

• Servernamen in Konfigurationsdateien (appsettings.json, App.config, INI-Dateien)
• Die Serverangabe in SQL-Server-Verbindungszeichenfolgen (Data Source)
• Stellen, an denen UNC-Pfade zusammengesetzt werden. Prüfen Sie auf fest codierte IP-Adressen
• Standardwerte in Installern und Provisionierungsdokumenten
• Stellen, die bei einem früheren Vorfall „weil die Namensauflösung instabil war“ auf eine IP-Adresse umgeschrieben und nie zurückgesetzt wurden

Der letzte Punkt kommt tatsächlich ständig vor. Eine fest codierte IP-Adresse war damals die richtige Notfallmaßnahme; heute ist sie technische Schulden.

8.3. Wenn Sie die Dienstseite selbst entwickeln

Möchten Sie, dass Ihr eigener Windows-Dienst oder Ihre IIS-Anwendung Kerberos akzeptiert, müssen Sie einen SPN, unter dem Namen, den Clients für den Zugriff verwenden, an dem Konto registrieren, das das Ticket entschlüsselt. Wie Microsoft selbst anmerkt, fällt eine Anwendung ohne registrierten SPN auf NTLM zurück, auch wenn sie Kerberos-Unterstützung beansprucht.³

Den Registrierungsort einfach als „das Konto, unter dem der Dienst läuft“ zu betrachten, ist die Stelle, an der Sie IIS eine Falle stellt. Bei der Windows-Authentifizierung von IIS ist die kernelmodusbasierte Authentifizierung standardmäßig aktiviert, und in diesem Fall entschlüsselt nicht die Identität des Anwendungspools das Kerberos-Ticket, sondern das von HTTP.sys verwendete Computerkonto. Betreiben Sie den Anwendungspool unter einem eigenen Domänenkonto und registrieren deshalb den HTTP-SPN der Site an diesem Konto, fallen SPN-Besitzer und tatsächlich entschlüsselndes Konto auseinander, und statt lediglich auf NTLM zurückzufallen, schlägt die Authentifizierung selbst mit KRB_AP_ERR_MODIFIED fehl.

Der entscheidende Punkt ist, Registrierungsziel des SPN und die Identität, die das Ticket entschlüsselt, gleichzusetzen. Es gibt zwei praktikable Varianten.

• Entschlüsselung mit dem Computerkonto (Standard belassen): Wird die Site unter einem Hostnamen veröffentlicht, registrieren Sie den HTTP-SPN dieses Hostnamens am Computerkonto.
• Entschlüsselung mit der Identität des Anwendungspools: Aktivieren Sie useAppPoolCredentials und registrieren Sie den HTTP-SPN am Konto des Anwendungspools.

Welche Variante Sie wählen, hängt davon ab, ob mehrere Server dasselbe Dienstkonto teilen (falls ja, ist die Vereinheitlichung auf die Pool-Identität einfacher zu verwalten). Beachten Sie, dass ein SPN nur an einem einzigen Konto registriert werden kann, vergessen Sie also beim Wechsel nicht, die alte Registrierung zu löschen. Doppelte Registrierungen zerstören die Kerberos-Authentifizierung selbst.

Sieht Ihr Design vor, dass der Dienst den Client imitiert, um andere Server zu erreichen (Delegation), unterscheiden sich NTLM und Kerberos. Kerberos unterstützt einen Delegationsmechanismus, bei dem ein Dienst im Namen des Clients eine Verbindung zu einem anderen Dienst herstellt, während NTLM lediglich die für die lokale Identitätsübernahme benötigten Autorisierungsinformationen liefert.⁸ Die Umsetzung der Identitätsübernahme ist in „Windows-Identitätswechsel-Token korrekt behandeln“ beschrieben.

9. Ein Fahrplan für die stufenweise Verschärfung

Fügt man das alles zusammen, ergibt sich folgende Arbeitsreihenfolge. Jede Stufe ist an die Bedingung geknüpft, umkehrbar zu sein.

9.1. SMB zu stoppen ist nur die halbe Miete der NTLM-Behebung

Die Stufen 4 bis 6 decken nur SMB ab. Wie in Abschnitt 7 erwähnt, ist die NTLM-Blockierung des SMB-Clients eine Funktion des SMB-Clients,⁴ und sie wirkt nicht auf andere Wege. Was Sie in Stufe 2 als „authentifiziert über HTTP“, „SQL Server verwendet NTLM“ oder „WinRM verwendet NTLM“ eingestuft haben, bleibt auch nach Abschluss von Stufe 6 unangetastet. Und da es auch nicht auf der SMB-Ausnahmeliste erscheint, deckt das Zählen dieser Liste es ebenfalls nicht auf.

Stufe 6b ist der Ort, an dem Sie das verschärfen. Verwendet werden dabei genau die drei Richtlinien, die Sie in Abschnitt 4 in den Audit-Modus versetzt haben. Das Vorgehen folgt derselben Form.

1. Belassen Sie „Ausgehender NTLM-Datenverkehr zu Remoteservern“ auf Alle überwachen und erfassen Sie die verbleibenden Ziele
2. Registrieren Sie die tatsächlich benötigten Gegenstellen unter „Ausnahmen für Remoteserver hinzufügen“
3. Stellen Sie Pilotrechner auf Alle verweigern um und warten Sie einen kompletten Geschäftszyklus ab
4. Gibt es keine Probleme, rollen Sie es aus

Verfahren Sie für die gesamte Domäne mit „NTLM-Authentifizierung in dieser Domäne“ ebenso nach der Reihenfolge Überwachen → Ausnahmen („Serverausnahmen in dieser Domäne hinzufügen“) → Verweigern.¹¹ Auch Microsoft rät, vor der Wahl einer Verweigern-Option die zugehörige Audit-Richtlinie auf denselben Wert zu setzen und die Auswirkung zu bewerten.¹¹

„Wir haben SMB blockiert, also ist die NTLM-Behebung abgeschlossen“ ist falsch. Möchten Sie eine Kennzahl für die Vollständigkeit, zählen Sie sowohl die SMB-Ausnahmeliste als auch die Ausnahmeliste von „NTLM einschränken“.

9.2. Legen Sie den Audit-Zeitraum nach „einem vollständigen Geschäftszyklus“ fest, nicht nach Tagesanzahl

Der häufigste Fehler in Stufe 1 betrifft, wie der Zeitraum festgelegt wird. Erklären Sie es „weil wir zwei Wochen gesammelt haben“ für abgeschlossen, ist alles, was in diesen zwei Wochen nicht gelaufen ist, nicht auf der Liste. Und was nicht auf der Liste steht, fällt zum ersten Mal aus, nachdem Sie die Blockierung in Stufe 6 verteilt haben.

Konkret werden am leichtesten übersehen:

• Monats- und Quartalsabschlussprozesse. Ein Monatsendbatch, der sich per fest codierter IP mit einem Freigabeordner oder einer Datenbank verbindet, ist der klassische Fall.
• Jährliche Prozesse. Inventuren, Geschäftsjahreswechsel, Jahresabschlüsse.
• Wege, die nur im Notfall betätigt werden. Wiederherstellungsverfahren aus dem Backup, Failover auf einen Standby-Server, DR-Übungen.
• Rechner, die längere Zeit offline sind. Mitgenommene Notebooks, Rechner von Mitarbeitern in längerer Abwesenheit, normalerweise ausgeschaltete Ersatzrechner.
• Fachanwendungen, die nur wenige Male im Jahr genutzt werden.

Auch Microsofts eigene Anleitung weist darauf hin, dass sich die Analyse je nach Komplexität der Implementierung über mehrere Monate erstrecken kann.³ Die realistische Grenze liegt bei einer der folgenden Optionen.

1. Lassen Sie das Auditing laufen, bis der Geschäftsbetrieb einmal komplett durchlaufen ist. Mindestens einen Monatsabschluss, im Idealfall über ein Quartal hinweg.
2. Erfassen Sie selten genutzte Prozesse und führen Sie sie bewusst aus. Können Sie den Zeitraum nicht abwarten, führen Sie Abschlussprozesse und DR-Verfahren in einer Testumgebung aus und ergänzen Sie die Ergebnisse in der Liste. Entscheidend ist, vorab mit den Verantwortlichen zu sprechen und die Prozesse zu erfassen, die „nur deshalb keine Ereignisse erzeugen, weil sie noch nicht gelaufen sind“.

In beiden Fällen sollten Sie einen Zustand erreichen, in dem Sie „kein Ereignis wurde erzeugt“ von „es ist noch nicht gelaufen“ unterscheiden können, bevor Sie zur nächsten Stufe übergehen.

9.3. Nicht direkt auf „Verweigern“ umschwenken

Der entscheidende Punkt hier: Schalten Sie „Ausgehender NTLM-Datenverkehr = Alle verweigern“ nicht in einem einzigen Schritt. Microsoft weist darauf hin, dass das Setzen dieser Richtlinie auf „Verweigern“ viele NTLM-Authentifizierungsanfragen fehlschlagen lassen und die Produktivität mindern kann, weshalb Sie vor der Implementierung die Protokolle mit „Alle überwachen“ prüfen, die Server analysieren und eine Ausnahmeliste der auszuschließenden Elemente erstellen sollten.⁷ Dieselbe Warnung gilt für die domänenweite Richtlinie „NTLM-Authentifizierung in dieser Domäne“.¹¹

10. Zusammenfassung

• Alle Versionen von NTLM wurden im Juni 2024 als deprecated eingestuft. Das ist keine Änderung, die sofort etwas stoppt; NTLM wird laut Angabe in der nächsten Windows-Server-Version und im nächsten jährlichen Windows-Release weiterhin funktionieren.¹
• Andererseits wurde NTLMv1 bereits entfernt (Windows 11 24H2 / Windows Server 2025). Geräte, die nur NTLMv1 sprechen, sowie Hosts, bei denen NTLM V1 protokolliert wird, sind Ihre nächste Frist.¹
• Die Abschaffung verläuft in drei Phasen: Phase 1 ist das Auditing, Phase 2 (zweite Jahreshälfte 2026) bringt IAKerb und den lokalen KDC, und Phase 3 deaktiviert standardmäßig.²
• Auditing bedeutet, drei Richtlinien in den Audit-Modus zu versetzen und Microsoft-Windows-NTLM/Operational zu sammeln. Bei Domänenkonten folgen Sie 8004 auf dem DC → 8003 auf dem Mitgliedsserver → 8001 auf dem Client, was schließlich bis zum Anwendungsnamen führt. Die Authentifizierung mit lokalen Konten erzeugt kein 8004, erfassen Sie diese daher über Server- und Client-Ereignisse.³⁷
• Verkehr über SMB zeigt immer PID 4 (SYSTEM). Grenzen Sie mit den Ereignisprotokollen auf den Rechner ein und jagen Sie dann nur diesen einen Rechner mit ProcMon.³
• Die meisten Ursachen laufen auf „Namen“ hinaus. Allein das Beheben fest codierter IP-Adressen und nicht registrierter SPNs reduziert die verbleibenden Ausnahmen erheblich.³²
• NET USE \\server\share /BLOCKNTLM ist der sicherste Weg, Verbindung für Verbindung abzusichern, ohne eine Richtlinie zu ändern.⁴
• Ersetzen Sie in eigenen Anwendungen die explizite Nennung von NTLM durch Negotiate und vereinheitlichen Sie Zielnamen auf FQDNs.⁵
• Eine Ausnahmeliste ist ein Aufschub, keine Lösung. Verwenden Sie „sinkt die Anzahl Jahr für Jahr?“ als Kennzahl.

Verwandte Artikel

• NTLM und Kerberos anhand von Diagrammen erklärt — Warum die Authentifizierung auf NTLM zurückfällt
• Fallstricke bei Netzlaufwerken und UNC-Pfaden — Der Umgang mit Dateiservern (Freigabeordnern) aus einer Fachanwendung heraus
• Ereignisprotokolle praxisnah mit Get-WinEvent untersuchen
• Praxisleitfaden zu Process Monitor (ProcMon)
• Einstieg in PowerShell Remoting (WinRM)
• Anmeldeinformationen in PowerShell sicher handhaben — Klartextpasswörter aus Ihren Skripten verbannen
• Entra-ID-Authentifizierung in WinForms/WPF-Anwendungen integrieren — Eine praxistaugliche Architektur mit MSAL.NET und dem WAM-Broker
• Was ist das TPM in Windows? — Eine bebilderte Anleitung zum „Tresor, der Schlüssel niemals herausgibt“, und zum Measured Boot

Verwandte Beratungsleistungen

Die KomuraSoft LLC übernimmt die Erfassung von NTLM-Abhängigkeiten, die Anpassung von Fachanwendungen für die Migration in eine auf Kerberos basierende Umgebung sowie die Untersuchung von Authentifizierungsfehlern.

• Windows-Anwendungsentwicklung
• Fehleruntersuchung und Ursachenanalyse
• Weiternutzung und Migration von Altbeständen
• Kontakt

Referenzlinks

Verwandte Artikel

Aktuelle Artikel mit denselben Schlagwörtern führen zu verwandten Themen weiter.

Verwandte Themen

Diese Seiten ordnen den Artikel in einen größeren Leistungs- und Entscheidungskontext ein.

Leistungen zu diesem Thema

Dieser Artikel ist direkt mit den folgenden Leistungen verbunden.

Häufige Fragen

Fragen, die in Beratungen zu diesem Artikelthema häufig gestellt werden.

Wenn NTLM abgeschafft wird – ab wann steht unser Betrieb still?

Eine bloße Ankündigung als „deprecated“ (nicht mehr aktiv weiterentwickelt) stoppt gar nichts. Microsoft hat im Juni 2024 alle Versionen von NTLM als deprecated eingestuft, aber im selben Hinweis stand, dass NTLM in der nächsten Windows-Server-Version und im nächsten jährlichen Windows-Release weiterhin funktionieren wird. Die konkrete Änderung, die bereits etwas kaputt gemacht hat, ist die Entfernung von NTLMv1 in Windows 11 Version 24H2 und Windows Server 2025. Es gibt einen veröffentlichten Plan, Netzwerk-NTLM in einer künftigen Version standardmäßig zu deaktivieren, aber selbst dann soll es sich per Richtlinie wieder aktivieren lassen. Mit anderen Worten: Das ist keine Änderung, bei der eines Tages das ganze Unternehmen stillsteht, sondern eine, die sich mit jedem neuen Betriebssystem ein Stück weiter verschärft. Genau deshalb ist die einzig realistische Vorbereitung, die eigenen Abhängigkeiten schon jetzt – solange NTLM noch funktioniert – mit Audit-Protokollen zu erfassen, statt erst zu untersuchen, wenn etwas bereits ausgefallen ist.

Wie erstelle ich eine Liste der Stellen, an denen NTLM verwendet wird?

Versetzen Sie die Gruppenrichtlinienfamilie „Netzwerksicherheit: NTLM einschränken“ in den Audit-Modus und sammeln Sie das NTLM/Operational-Protokoll. Setzen Sie auf Domänencontrollern „NTLM-Authentifizierung in dieser Domäne überwachen“ und auf Servern und Clients „Eingehenden NTLM-Datenverkehr überwachen“ sowie „Ausgehender NTLM-Datenverkehr zu Remoteservern = Alle überwachen“. Die Ereignisse werden dann in der Ereignisanzeige unter Anwendungs- und Dienstprotokolle > Microsoft > Windows > NTLM erfasst. Bei der Authentifizierung mit Domänenkonten folgen Sie dieser Reihenfolge: Ermitteln Sie über Ereignis 8004 auf dem Domänencontroller den Benutzer und den Zielserver (Sicherer Kanalname), sehen Sie sich dann die Prozess-ID in Ereignis 8003 auf diesem Server an, und bestimmen Sie schließlich mit Ereignis 8001 auf dem Client, „welche Anwendung, gegen welchen Servernamen“ die Anfrage gestellt hat. Ereignis 8001 enthält den Zielservernamen und den Namen des Client-Prozesses – sobald Sie so weit gekommen sind, kennen Sie die verantwortliche Anwendung. Beachten Sie, dass die Authentifizierung mit lokalen Konten nicht über einen Domänencontroller läuft, sodass kein Ereignis 8004 erscheint. Wege, bei denen ein Arbeitsgruppenrechner oder ein lokales Konto auf einem Dateiserver eine Freigabe anspricht, müssen Sie über 8003 auf dem Server und 8001 auf dem Client erfassen. Schauen Sie nicht nur auf die Protokolle des Domänencontrollers und schließen Sie daraus nicht „bei uns ist es kaum im Einsatz“.

Ich habe das Auditing aktiviert, und bei allen Ereignissen steht als PID nur 4 (SYSTEM). Ich kann nicht erkennen, welche Anwendung dahintersteckt.

Das liegt daran, dass der Datenverkehr über SMB (Freigabeordner) läuft. Die SMB-Authentifizierung wird vom Kernelmodus-Redirector durchgeführt, sodass die aufrufende Anwendung hinter den SMB-Paketen verborgen bleibt und die im Ereignis hinterlegte PID immer 4 (SYSTEM) ist. Die Anleitung von Microsoft nennt diesen Fall ausdrücklich und empfiehlt, auf dem Client, auf dem die Ereignisse auftreten, Process Monitor (ProcMon) auszuführen, die Pfade nach Computernamen und IP-Adresse des Gegenservers zu filtern und die Erfassung mit den Zeitstempeln von Ereignis 8003 auf der Serverseite abzugleichen, um den aufrufenden Prozess zu identifizieren. In der Praxis ist es am schnellsten, zunächst anhand der Ereignisprotokolle einzugrenzen, um welchen Rechner es geht, und erst dann nur diesen einen Rechner mit ProcMon zu untersuchen.

Warum fällt eine Anwendung, die eigentlich Kerberos unterstützen sollte, auf NTLM zurück?

Fast immer ist es ein Namensproblem. Die Anleitung von Microsoft nennt vier Arten von Anwendungen, die NTLM verwenden, obwohl sie theoretisch Kerberos unterstützen: Anwendungen, bei denen Sie die Sicherheitskonfiguration oder den Provider auswählen können; Anwendungen, deren SPN (Service Principal Name) nicht korrekt registriert ist; Anwendungen, die aufgrund einer Fehlkonfiguration oder der Herstellerdokumentation über die IP-Adresse statt über den DNS-Namen verbinden; sowie Anwendungen mit einer Legacy-Codebasis, die noch reine NTLM-Anteile enthält. Steht der „Zielserver“ in Ereignis 8001 weder im NetBIOS- noch im FQDN-Format (also als IP-Adresse), wird in der Standardkonfiguration kein Kerberos verwendet. Die ersten beiden Maßnahmen sind, fest codierte IP-Adressen in FQDNs umzuwandeln und, falls über einen Alias zugegriffen wird, für diesen Namen einen SPN zu registrieren. Für Fälle, in denen sich der Name wirklich nicht ändern lässt, gibt es außerdem die Möglichkeit, auf dem Client TryIPSPN zu setzen und den SPN für die IP-Adresse manuell zu registrieren – Microsoft selbst weist aber darauf hin, dass dies nur infrage kommt, wenn ein Wechsel auf einen DNS-Namen unmöglich ist, und behandelt es strikt als letzten Ausweg.

Was müssen wir in den Windows-Anwendungen ändern, die wir selbst entwickeln?

Ersetzen Sie alle Stellen, an denen NTLM als Authentifizierungspaket namentlich angegeben ist, durch Negotiate. Microsoft schreibt ausdrücklich: „Anwendungen sollten nicht direkt auf das NTLM-Sicherheitspaket zugreifen, sondern stattdessen das Negotiate-Paket verwenden.“ Negotiate wählt zwischen Kerberos und NTLM und entscheidet sich für Kerberos, sofern nicht eines der an der Authentifizierung beteiligten Systeme Kerberos nicht nutzen kann. In .NET besteht die typische Korrektur darin, den an CredentialCache.Add übergebenen Authentifizierungstyp von „NTLM“ auf „Negotiate“ zu ändern (der Authentifizierungstyp wird bei CredentialCache.Add angegeben, nicht im Konstruktor von NetworkCredential). Zusätzlich müssen Sie Zielserver per FQDN statt über eine IP-Adresse oder einen in hosts eingetragenen Alias angeben und, falls Ihr eigener Dienst Kerberos annehmen soll, für das zugehörige Dienstkonto einen SPN registrieren.

Autorenprofil

Profilseite des Artikelautors.

Go Komura

Geschäftsführer von KomuraSoft LLC

Spezialisiert auf Windows-Softwareentwicklung, technische Beratung und Fehleranalyse, insbesondere bei bestehenden Systemen und schwer reproduzierbaren Störungen.