NTLM und Kerberos anhand von Diagrammen erklärt — Warum die Authentifizierung auf NTLM zurückfällt

Auch in einem Unternehmensnetzwerk, das als „Kerberos-Umgebung“ beschrieben wird, taucht bei einem Audit immer wieder NTLM auf. Und was auftaucht, ist meist eine Anwendung, die eigentlich Kerberos unterstützen sollte.

Warum das passiert, wird sofort klar, sobald man die beiden Protokolle nebeneinanderlegt und fragt, was jedes von ihnen eigentlich beweisen will. Dieser Artikel behandelt, wie sich NTLM und Kerberos anhand von Diagrammen verhalten, dann unter welchen Bedingungen die Authentifizierung auf NTLM zurückfällt und warum Microsoft versucht, NTLM loszuwerden — alles gestützt auf die offizielle Dokumentation.

Das Vorgehen zur Bestandsaufnahme der eigenen Umgebung (Konfiguration der Audit-Richtlinien, das Verfolgen der Ereignisse, die Reihenfolge der Behebung) ist im begleitenden Artikel „Bringt die NTLM-Abschaffung Ihre Fachanwendungen zum Stillstand? — Wie Sie Audit-Protokolle erfassen und in welcher Reihenfolge Sie Abhängigkeiten beseitigen“ dargelegt.

1. Das Wichtigste zuerst

• NTLM beweist nur, dass Sie den Passwort-Hash besitzen. Die Anmeldeinformationen sind ein Einweg-Hash von Domänenname, Benutzername und Passwort,¹ und bei NTLMv2 — das heutiges Windows verwendet — wird ein aus diesem Hash abgeleiteter Schlüssel verwendet, um einen HMAC über „die Server-Challenge + einen Zeitstempel + eine clientseitige Challenge + Zielinformationen“ zu berechnen (Abschnitt 2.2).²
• Kerberos beweist, „wer sich gegenüber welchem Dienst“ authentifiziert. Tickets werden gebunden an den Namen des Zieldienstes (den SPN) ausgestellt, sodass ein Ticket für ein anderes Ziel nicht verwendet werden kann.³
• Es gibt drei entscheidende Unterschiede: ob eine gegenseitige Authentifizierung stattfindet, ob der Server (bei der Authentifizierung von Domänenkonten) einen Domänencontroller befragt, und ob Delegation möglich ist. Microsoft nennt alle drei ausdrücklich (Abschnitt 5).⁴
• Der größte Grund für den Rückfall auf NTLM sind „Namen“. Kerberos kann nicht beginnen, wenn sich aus dem Zielnamen kein SPN auflösen lässt. Fest codierte IP-Adressen, nicht registrierte SPNs, Arbeitsgruppen und Wege ohne DC-Erreichbarkeit sind die vier Hauptfaktoren (Abschnitt 6).⁵⁶
• Relay-Angriffe funktionieren, weil NTLM keinen Mechanismus besitzt, der bindet, „mit wem Sie sich authentifizieren“. Pass-the-Hash funktioniert, weil für die Authentifizierung der Hash selbst benötigt wird (Abschnitt 7).⁷¹
• NTLMv1 wurde bereits entfernt. Windows 11 Version 24H2 und Windows Server 2025 sind die betroffenen Versionen. NTLMv2 ist deprecated, funktioniert aber noch (Abschnitt 8).⁸
• Was Anwendungen schreiben sollten, ist Negotiate. 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.¹

2. Was NTLM tatsächlich tut

NTLM (Windows Challenge/Response) ist, wie der Name sagt, ein Challenge/Response-Authentifizierungsprotokoll. Zusammengefasst nach Microsofts Beschreibung: Die Anmeldeinformationen bestehen aus einem bei der interaktiven Anmeldung erhaltenen Einweg-Hash von Domänenname, Benutzername und Passwort, und um zu authentifizieren, ohne das Passwort über die Leitung zu senden, führt die Partei, die die Authentifizierung anfordert, eine Berechnung durch, die beweist, dass sie „auf die sicher gespeicherten NTLM-Anmeldeinformationen zugreifen kann“.¹

Wichtig ist hier, dass das Material für die Authentifizierung nicht das Passwort selbst, sondern der Hash des Passworts ist. Genau diese eine Tatsache macht, wie wir später sehen werden, Pass-the-Hash möglich.

2.1. Bei einem Domänenkonto sind drei Parteien beteiligt

Greift ein bereits angemeldeter Benutzer mit einem Domänenkonto (nicht-interaktive Authentifizierung) auf eine Ressource eines Servers zu, sind drei Parteien beteiligt: der Client, der Server und der Domänencontroller. Das Besondere daran ist, dass der Server selbst die Authentifizierungsberechnung nicht durchführt — er lässt sie stellvertretend vom Domänencontroller ausführen.¹

sequenceDiagram
    autonumber
    participant C as Client
    participant S as Server
    participant DC as Domänencontroller

    Note over C: Hasht bei der Anmeldung das Passwort<br/>und verwirft das Passwort selbst
    C->>S: Benutzername (Klartext)
    S->>C: 8-Byte-Zufallszahl (Challenge)
    Note over C: Verschlüsselt die Challenge<br/>mit dem Passwort-Hash
    C->>S: Antwort
    S->>DC: Benutzername / Challenge / Antwort
    Note over DC: Ruft den Hash aus der SAM ab<br/>und führt dieselbe Berechnung durch
    DC-->>S: Bei Übereinstimmung ist die Authentifizierung erfolgreich
    S-->>C: Zugriff gewährt

Abbildung 1: Nicht-interaktive NTLM-Authentifizierung (mit einem Domänenkonto)

Das von Microsoft konzeptionell dargestellte Vorgehen sieht wie folgt aus (die tatsächliche Berechnung ändert sich bei NTLMv2, wie unten beschrieben, aber die beteiligten Parteien und die Aufgabenverteilung entsprechen genau dem Diagramm).¹

1. (Nur bei interaktiver Authentifizierung) Der Benutzer gibt Domänenname, Benutzername und Passwort ein. Der Client berechnet einen kryptografischen Hash des Passworts und verwirft das eigentliche Passwort.
2. Der Client sendet den Benutzernamen im Klartext an den Server.
3. Der Server erzeugt eine 8-Byte-Zufallszahl (die Challenge, eine Nonce) und sendet sie an den Client.
4. Der Client verschlüsselt diese Challenge mit dem Hash des Benutzerpassworts und sendet das Ergebnis (die Antwort) zurück.
5. Der Server sendet drei Dinge an den Domänencontroller: den Benutzernamen, die an den Client gesendete Challenge und die empfangene Antwort.
6. Der Domänencontroller sucht in der SAM-Datenbank den Passwort-Hash für diesen Benutzernamen und verschlüsselt die Challenge damit.
7. Er vergleicht sein eigenes Ergebnis mit der Antwort des Clients; sind sie identisch, ist die Authentifizierung erfolgreich.

2.2. Die tatsächliche Berechnung — NTLMv2 ist etwas aufwendiger

Die sieben Schritte oben sind die auf Microsofts Übersichtsseite beschriebene Grundform. NTLMv2, das heutiges Windows tatsächlich verwendet, ist einen Schritt komplexer als „die Challenge mit dem Passwort-Hash verschlüsseln“. Die Spezifikation ([MS-NLMP]) definiert es wie folgt.²

• Der Antwortschlüssel ist NTOWFv2 = HMAC_MD5( MD4(UNICODE(Passwort)), Benutzername in Großbuchstaben + Domänenname )
• Der Client baut temp durch Verkettung der Antwortversion, eines Zeitstempels, einer auf der Clientseite erzeugten 8-Byte-Challenge und Zielinformationen (AV-Paare)
• Der Kern der Antwort ist NTProofStr = HMAC_MD5( Antwortschlüssel, Server-Challenge + temp )

Mit anderen Worten: Tatsächlich berechnet wird ein HMAC, der nicht nur die Server-Challenge, sondern auch einen clientseitigen Zufallswert, einen Zeitstempel und Zielinformationen einmischt. Die prüfende Seite reproduziert dieselbe Berechnung. Liegt das Konto in Active Directory, wird das Challenge/Response-Paar zur Prüfung an einen Domänencontroller gesendet; ist das Konto lokal auf dem Server, berechnet der Server den erwarteten Wert anhand des selbst gespeicherten OWF.²

Für die Diskussion in diesem Artikel ist wichtig, dass sich trotz dieser zusätzlichen Komplexität zwei Dinge nicht ändern.

1. Das Schlüsselmaterial bleibt der Passwort-Hash. Ausgangspunkt von NTOWFv2 ist MD4(UNICODE(Passwort)) — der NT-Hash selbst.² Deshalb funktioniert Pass-the-Hash (Abschnitt 7.2).
2. Der Client überprüft nicht, ob der Server echt ist. Microsofts Aussage, dass NTLM keine gegenseitige Authentifizierung besitzt, gilt auch für NTLMv2.⁴

Alles, was folgt, beruht auf diesen beiden Punkten.

2.3. Bei einem lokalen Konto genügen zwei Parteien

Bei einem lokalen Konto verschwindet die rechte Seite des Diagramms. Ein Ressourcenserver fragt bei einem Domänenkonto den Authentifizierungsdienst eines Domänencontrollers der Domäne des Kontos ab, konsultiert aber bei einem lokalen Konto seine lokale Kontendatenbank.⁹ Auf einem Arbeitsgruppenrechner oder bei der Verbindung zu einer Freigabe mit einem lokalen Konto auf einem Dateiserver taucht daher kein Domänencontroller auf: Es ist ein Austausch zwischen zwei Parteien, bei dem der Server anhand seiner eigenen SAM selbst entscheidet.

Diese Unterscheidung fließt direkt in die in Abschnitt 6.3 behandelte Bestandsaufnahme der Abhängigkeiten „Kerberos ist nicht verfügbar, weil es ein lokales Konto ist“ ein. NTLM taucht auf diesem Weg in den Audit-Protokollen der Domänencontroller überhaupt nicht auf.

2.4. Drei Konsequenzen dieses Designs

Betrachten Sie Abbildung 1, und Sie können daraus die Eigenschaften ablesen, die später zum Problem werden.

• Der Server beweist dem Client nichts. Der Austausch verläuft einseitig; nirgendwo gibt es einen Schritt, in dem der Server zeigt, dass „ich echt bin“.
• Der Server kann nur entscheiden, wenn er selbst den Hash besitzt. Bei jedem Bedarf an einem neuen Zugriffstoken muss ein Ressourcenserver bei einem Domänenkonto den Authentifizierungsdienst eines Domänencontrollers abfragen oder bei einem lokalen Konto seine lokale Kontendatenbank konsultieren.⁹ Deshalb hängt die Authentifizierung mit Domänenkonten von einem Domänencontroller ab.
• Die Antwort gilt „nur für diese Challenge“, bindet aber nicht das Ziel. Da sich die Challenge jedes Mal ändert, kann dieselbe Antwort nicht wiederverwendet werden. Es gibt jedoch kein Element, das beweist, „für welchen Server diese Antwort bestimmt ist“, sodass sie unbemerkt an einen anderen Server weitergegeben werden kann.

3. Warum der Server einen Domänencontroller fragt

Bei der Authentifizierung eines Domänenkontos besitzt nur die Kontendatenbank auf der Seite des Domänencontrollers den Passwort-Hash. Der Ressourcenserver kennt den Hash dieses Benutzers nicht und kann daher nicht selbst prüfen. Er muss deshalb bei jeder Authentifizierung einen Domänencontroller abfragen (Pass-Through-Authentifizierung).⁹¹ (Bei einem lokalen Konto konsultiert der Server seine eigene SAM und entscheidet selbst. Alles Folgende zur Abhängigkeit von einem Domänencontroller gilt für Domänenkonten.)

Das kostet sowohl sicherheitstechnisch als auch betrieblich. Microsoft erklärt, dass bei Vor-Kerberos-NTLM-Authentifizierung ein Anwendungsserver bei jeder Authentifizierung eines Clients oder Dienstes eine Verbindung zu einem Domänencontroller herstellen musste, während bei Kerberos erneuerbare Sitzungstickets diese Pass-Through-Authentifizierung ersetzen und der Server einen Domänencontroller nur kontaktieren muss, wenn eine PAC-Prüfung (Privilege Attribute Certificate) erforderlich ist.⁴

Die Migration zu Kerberos ist also gleichzeitig eine Sicherheitsfrage und eine Frage der Reduzierung der Abhängigkeit von Domänencontrollern.

4. Was Kerberos tatsächlich tut

Kerberos geht von einem grundlegend anderen Ansatz aus. Statt die Identitätsprüfung bei jeder Authentifizierung erneut durchzuführen, wird die Identität einmal zu Beginn geprüft, ein „Ticket“ empfangen, und dieses Ticket wird anschließend vorgezeigt.

Der KDC (Key Distribution Center) läuft auf einem Domänencontroller und verwendet die Datenbank der Active Directory Domain Services als Sicherheitskontendatenbank.⁴

sequenceDiagram
    autonumber
    participant C as Client
    participant KDC as KDC (Domänencontroller)
    participant S as Dienst (identifiziert durch SPN)

    Note over C,KDC: AS-Austausch — Identität beweisen und ein TGT erhalten
    C->>KDC: KRB_AS_REQ<br/>(Benutzername + mit Langzeitschlüssel verschlüsselter Zeitstempel)
    Note over KDC: Lässt es sich mit dem Langzeitschlüssel entschlüsseln, ist die Person echt
    KDC-->>C: KRB_AS_REP<br/>TGT (mit dem Schlüssel von krbtgt verschlüsselt) + Sitzungsschlüssel

    Note over C,KDC: TGS-Austausch — ein Dienstticket erhalten
    C->>KDC: KRB_TGS_REQ<br/>(TGT + Ziel-SPN + Authenticator)
    Note over KDC: Sucht das Dienstkonto anhand des SPN<br/>und verschlüsselt das Ticket mit dessen Langzeitschlüssel
    KDC-->>C: KRB_TGS_REP<br/>Dienstticket + Sitzungsschlüssel

    Note over C,S: AP-Austausch — dem Dienst vorlegen
    C->>S: KRB_AP_REQ<br/>(Dienstticket + Authenticator)
    Note over S: Entschlüsselt mit dem eigenen Langzeitschlüssel<br/>= das Ticket ist an ihn adressiert
    S-->>C: KRB_AP_REP (bei angeforderter gegenseitiger Authentifizierung)

Abbildung 2: Die drei Kerberos-Austausche (AS / TGS / AP)

4.1. Der AS-Austausch — Identität einmalig beweisen

Der Client sendet dem KDC seinen Benutzernamen und Domänennamen sowie einen mit seinem eigenen Langzeitschlüssel (dem aus dem Passwort abgeleiteten Schlüssel) verschlüsselten Zeitstempel. Das ist die Vorauthentifizierung. Kann der KDC ihn mit diesem Langzeitschlüssel entschlüsseln und ist der Zeitstempel gültig, schließt er daraus: „Das ist die Person.“³

Der KDC liefert ein TGT (Ticket-Granting Ticket) zurück. Das TGT ist mit dem eigenen Langzeitschlüssel des KDC (dem Schlüssel des krbtgt-Kontos) verschlüsselt, sodass der Client seinen Inhalt nicht lesen kann. Zusammen damit wird ein Sitzungsschlüssel für die Verwendung zwischen Client und KDC übergeben, verschlüsselt mit dem Langzeitschlüssel des Clients.³

Wichtig ist hier, dass der Zeitstempel Teil der Authentifizierung ist. Deshalb ist Kerberos streng bei der Zeitsynchronisierung; die standardmäßig tolerierte Abweichung beträgt fünf Minuten.¹⁰ Wird sie überschritten, scheitert die Vorauthentifizierung, sodass die Kerberos-Authentifizierung selbst mit einem Fehler fehlschlägt (die Windows-Zeitsynchronisierung wird in „Anleitung zur Windows-Zeitsynchronisierung (w32time)“ behandelt). „Kerberos schlägt fehl“ und „es fällt auf NTLM zurück“ sind zwei unterschiedliche Dinge. Die Unterscheidung wird in Abschnitt 6.5 behandelt.

4.2. Der TGS-Austausch — Erklären, mit welchem Dienst Sie sich verbinden

Das ist der entscheidende Unterschied zu NTLM. Der Client teilt dem KDC den Namen des Dienstes, mit dem er sich verbinden möchte (den SPN), mit und fordert unter Beifügung des TGT und eines Authenticators ein Dienstticket an.³

Der KDC ermittelt das zu diesem SPN gehörende Dienstkonto und liefert ein mit dem Langzeitschlüssel dieses Kontos verschlüsseltes Dienstticket zurück.³ Daraus folgt:

• Lässt sich der SPN nicht auflösen, wird kein Ticket ausgestellt. Ist am Dienstkonto kein SPN registriert, kann der KDC die Gegenstelle nicht identifizieren. Dasselbe gilt, wenn das Ziel als IP-Adresse angegeben wird — standardmäßig wird Kerberos dann nicht einmal versucht (Abschnitt 6.1).
• Ein Ticket gilt „nur für dieses Ziel“. Es lässt sich nicht mit dem Langzeitschlüssel eines anderen Dienstes entschlüsseln und kann daher nicht gegen ein anderes Ziel wiederverwendet werden.

4.3. Der AP-Austausch — Vorlage beim Dienst und gegenseitige Authentifizierung

Der Client legt dem Dienst das Dienstticket und einen Authenticator vor. Der Dienst entschlüsselt das Ticket mit seinem eigenen Langzeitschlüssel und extrahiert daraus den Sitzungsschlüssel und die Autorisierungsinformationen. Allein die Tatsache, dass die Entschlüsselung gelingt, ist der Beweis, dass „dieses Ticket an mich adressiert ist“.³

Hat der Client eine gegenseitige Authentifizierung angefordert, verschlüsselt der Dienst den empfangenen Zeitstempel mit dem Sitzungsschlüssel und sendet ihn zurück. Durch dessen Überprüfung kann der Client bestätigen, dass die Gegenstelle der echte Dienst ist.³ Bei NTLM gibt es keinen solchen Schritt.

5. Die entscheidenden Unterschiede

Die beiden unteren Zeilen dieser Tabelle sind unmittelbar „die Gründe, warum die Authentifizierung auf NTLM zurückfällt“. Die Stärken von Kerberos (Bindung des Ziels, Überprüfung der Gegenstelle) beruhen darauf, dass sich Namen korrekt auflösen lassen.

6. Warum die Authentifizierung „zurückfällt“ auf NTLM

Auch wenn eine Anwendung NTLM nicht direkt angibt, wird NTLM verwendet — weil sich Negotiate so verhält. Wie Microsoft erklärt, wählt Negotiate zwischen Kerberos und NTLM und wählt Kerberos, sofern nicht eines der an der Authentifizierung beteiligten Systeme Kerberos nicht nutzen kann.¹

Mit anderen Worten: „Es wurde NTLM“ ist in den meisten Fällen nur eine andere Formulierung für „Kerberos konnte nicht verwendet werden“.

flowchart TD
    START["Authentifizierung beginnt mit Negotiate"]
    Q1{"Ein<br/>Domänenkonto?"}
    Q2{"Lässt sich aus dem Zielnamen<br/>ein SPN bilden?"}
    Q3{"Ist dieser SPN<br/>registriert?"}
    Q4{"Ist der KDC<br/>erreichbar?"}
    KRB["Mit Kerberos authentifizieren"]
    NTLM["Auf NTLM zurückfallen"]

    START --> Q1
    Q1 -->|"Nein<br/>(Arbeitsgruppe / lokales Konto)"| NTLM
    Q1 -->|Ja| Q2
    Q2 -->|"Nein<br/>(fest codierte IP-Adresse)"| NTLM
    Q2 -->|Ja| Q3
    Q3 -->|"Nein<br/>(SPN nicht registriert / Zugriff über Alias)"| NTLM
    Q3 -->|Ja| Q4
    Q4 -->|"Nein<br/>(Standort / VPN / Firewall)"| NTLM
    Q4 -->|Ja| KRB

Abbildung 3: Die Verzweigungen, über die Negotiate auf NTLM zurückfällt

6.1. Sie verbinden sich per IP-Adresse

Das ist die häufigste Ursache. Microsoft schreibt ausdrücklich, dass Windows standardmäßig keine Kerberos-Authentifizierung gegen einen Host versucht, dessen Hostname eine IP-Adresse ist, und auf ein anderes gültiges Authentifizierungsprotokoll wie NTLM zurückfällt.¹¹ Auch die Audit-Anleitung sagt von ihrer Seite dasselbe: Kerberos wird nicht verwendet, wenn der „Zielserver“ in Ereignis 8001 weder im NetBIOS- noch im FQDN-Format vorliegt.⁵

Und die Gründe dafür werden ebenfalls genannt: Anwendungen, die aufgrund einer Fehlkonfiguration oder der Herstellerdokumentation IP-Adressen statt DNS-Namen verwenden.⁵ In der Praxis sehen wir sehr häufig Einstellungen, die früher „weil die Namensauflösung instabil war“ auf eine IP-Adresse umgeschrieben und nie zurückgesetzt wurden.

Das ist allerdings das Standardverhalten, keine absolute Einschränkung. Ab Windows 10 Version 1507 und Windows Server 2016 gibt es einen Mechanismus, um IP-Adressen als SPN-Hostnamen zu verwenden. Setzen Sie den clientseitigen Registrierungswert TryIPSPN auf 1 und registrieren Sie manuell einen SPN für die IP-Adresse in der Form Setspn -s <Dienstklasse>/<IP-Adresse> <Konto>, funktioniert Kerberos auch gegen eine IP-Adresse. Registriert wird dabei die Dienstklasse, die der Client tatsächlich anfragt: Dinge, die auf HOST abgebildet werden, etwa Freigabeordner, sind mit host/192.168.1.1 abgedeckt, aber Web benötigt HTTP/192.168.1.1 und SQL Server einen anderen SPN einschließlich Port, etwa MSSQLSvc/192.168.1.1:1433. Die alleinige Registrierung von host/ passt nicht zum angefragten SPN, und Kerberos funktioniert nicht. Microsoft positioniert diese Funktion genau als Mittel, um die Auswirkung der Deaktivierung von NTLM zu verringern.¹¹

Trotzdem ist es nicht die erste Wahl. Microsoft selbst sagt, dass IP-Adressen vergänglich sind und beim Ablaufen und Erneuern von Leases Konflikte und Authentifizierungsfehler verursachen können, weshalb sie normalerweise nicht anstelle von Hostnamen verwendet werden sollten, und dass die IP-adressbasierte SPN-Registrierung manuelle Arbeit ist, die nur zum Einsatz kommen sollte, wenn ein Wechsel auf einen DNS-basierten Hostnamen unmöglich ist.¹¹ Denken Sie bei fest codierten IP-Adressen, die Sie bei einem Audit finden, zunächst daran, sie in FQDNs zu ändern. TryIPSPN ist der letzte Ausweg für Gegenstellen, bei denen das wirklich unmöglich ist.

6.2. Es ist kein SPN registriert

Das ist die zweithäufigste Ursache. Microsoft nennt Anwendungen, deren SPN nicht korrekt konfiguriert ist, als eine Kategorie von Anwendungen, die NTLM verwenden, obwohl sie Kerberos unterstützen.⁵

Wie wir beim TGS-Austausch in Abbildung 2 gesehen haben, sucht der KDC das Dienstkonto anhand des SPN und verschlüsselt das Ticket damit. Ohne SPN kann der KDC „den Schlüssel dieses Dienstes“ nicht identifizieren. Dasselbe passiert, wenn der Zugriff über einen DNS-Alias (CNAME) oder einen eigenen Hostnamen erfolgt und für diesen Namen kein SPN registriert ist. Die Anwendung funktioniert einwandfrei; nur der Name fehlt im Register.

6.3. Sie befinden sich von vornherein außerhalb von Active Directory

Rechner in einer Arbeitsgruppenkonfiguration und der Freigabezugriff mit lokalen Konten liegen von vornherein überhaupt nicht im Anwendungsbereich von Kerberos. Microsoft schreibt, 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 verwendet wird und verwendet werden muss.⁹

Deshalb lässt sich NTLM nicht einfach verbieten. Der für Phase 2 geplante lokale KDC ist genau die Funktion, die diese Lücke schließen soll.⁶ Gehen Sie aber davon aus, dass er diese Lücke nur zwischen unterstützenden Windows-Systemen schließt. Die Authentifizierung mit lokalen Konten, bei der die Gegenstelle ein älteres Windows oder ein Fremdherstellergerät wie ein NAS oder ein Multifunktionsgerät ist, wird nicht automatisch zu Kerberos, sobald der lokale KDC verfügbar ist. Diese Einordnung wird in den Abschnitten 5 und 6 des begleitenden praxisorientierten Artikels behandelt.

6.4. Sie erreichen den KDC nicht

Der Rückfall passiert auch aus Gründen der Wegeführung — eine Zweigstelle oder VPN-Verbindung, die keinen Domänencontroller erreicht, oder eine Firewall, die die von Kerberos benötigten Ports blockiert.⁶ Ohne Möglichkeit, mit dem KDC zu sprechen, lässt sich kein Ticket beschaffen, sodass Negotiate die verbleibende Option, NTLM, wählt.

6.5. Verwechseln Sie nicht „Kerberos ist fehlgeschlagen“ mit „es fiel auf NTLM zurück“

Trennen wir zum Schluss etwas ab, das verwirrend ähnlich, aber ziemlich verschieden ist. Die Abschnitte 6.1 bis 6.4 sind allesamt Fälle, in denen Kerberos nicht gestartet werden konnte. Weil es nicht gestartet werden konnte, wählt Negotiate NTLM.

Der Fall, in dem Kerberos gewählt wurde und dann fehlschlug, ist eine andere Geschichte. Das klassische Beispiel ist eine Zeitabweichung der Uhr. Lässt sich der SPN auflösen und ist der KDC erreichbar, wählt Negotiate zunächst Kerberos. Weicht die Uhr dann um mehr als die Toleranz (standardmäßig fünf Minuten) ab, besteht die Vorauthentifizierung nicht, und es schlägt als Kerberos-Fehler fehl.¹⁰ Dass das gewählte Protokoll fehlschlägt, bedeutet nicht, dass Negotiate automatisch auf NTLM umschaltet und es erneut versucht (außer wenn die Anwendung ausdrücklich mit einer anderen Methode erneut versucht).

Die praktische Bedeutung ist einfach. Eine durch Zeitabweichung verursachte Fehlfunktion finden Sie nicht, indem Sie nach Ereignis 8001 suchen. Auch die Symptome unterscheiden sich.

Entscheiden Sie zuerst, ob „es auf NTLM zurückgefallen ist“ oder „Kerberos ist kaputt“, und untersuchen Sie dementsprechend.

7. Der Unterschied aus Angreifersicht — Relay und Pass-the-Hash

Microsoft schreibt in der Dokumentation zu den Richtlinieneinstellungen ausdrücklich, 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.⁷ Warum das so ist, lässt sich anhand von Abbildung 1 erklären.

7.1. Relay-Angriffe — Die Folge der fehlenden Zielbindung

sequenceDiagram
    autonumber
    participant V as PC des Opfers
    participant A as Server des Angreifers
    participant T as Echter Server

    Note over V,A: Das Opfer wird auf den Server des Angreifers gelockt
    V->>A: Startet die Authentifizierung (Benutzername)
    A->>T: Startet die Authentifizierung als derselbe Benutzer
    T-->>A: Challenge
    A-->>V: Leitet diese Challenge unverändert weiter
    Note over V: Kann nicht erkennen, ob sie<br/>vom echten Server stammt
    V->>A: Antwort (berechnet mit dem aus dem Hash abgeleiteten Schlüssel)
    A->>T: Leitet diese Antwort unverändert weiter
    Note over T: Sofern weder Signierung<br/>noch Channel Binding verlangt wird
    T-->>A: Authentifizierung erfolgreich → Sitzung als das Opfer aufgebaut

Abbildung 4: Wie ein NTLM-Relay gelingt (gegen eine Gegenstelle ohne Signierung oder Channel Binding)

Der Angreifer muss weder das Passwort noch den Hash kennen. Er gibt lediglich Challenge und Antwort von einer Seite zur anderen weiter. Das funktioniert, weil der Client nicht prüfen kann, ob die Antwort tatsächlich zur beabsichtigten Gegenstelle geht.

Allerdings gelingt die Weiterleitung nicht bei jeder Gegenstelle. Ob aus einem weitergeleiteten Austausch eine nutzbare Sitzung wird, hängt von den Schutzmaßnahmen des Ziels ab.

• Bei einer Gegenstelle, die SMB-Signierung verlangt, gelingt es nicht. Microsoft schreibt ausdrücklich, dass die jeder SMB-Nachricht beigefügte Signatur einen Hash der gesamten Nachricht enthält und die Identität von Absender und Empfänger bestätigt, wodurch Relay-Angriffe verhindert werden.¹² Beachten Sie, dass Domänencontroller von sich verbindenden Clients standardmäßig SMB-Signierung verlangen.¹²
• Ebenso wenig gelingt es gegen einen Dienst, der Extended Protection for Authentication (Channel Binding) erzwingt. Weil die Authentifizierung an den zugrunde liegenden TLS-Kanal gebunden ist, dringt eine auf einen anderen Kanal weitergeleitete Authentifizierung nicht durch.

Was Abbildung 4 zeigt, ist also der Erfolgsweg unter der Bedingung einer Gegenstelle, die NTLM ohne Signierung und ohne Channel Binding akzeptiert. Umgekehrt bedeutet das: Es gibt etwas, das Sie schon jetzt in der Praxis tun können. Es lohnt sich, den Status der SMB-Signierungsanforderungen parallel zur NTLM-Bestandsaufnahme zu prüfen.

Bei Kerberos ist ein Relay dieser Art von vornherein nicht möglich. Ein Dienstticket ist mit dem Langzeitschlüssel des Zieldienstes verschlüsselt, sodass es nicht entschlüsselt werden kann, wenn es an einen anderen Dienst weitergegeben wird.³ Zusätzlich kann der Client durch gegenseitige Authentifizierung bestätigen, ob die Gegenstelle echt ist.⁴

Microsofts Grund für die NTLM-Blockierung auf SMB-Client-Seite ist genau das: Der angegebene Zweck ist, Techniken zu verhindern, die NTLM-Anfragen an böswillige Server senden lassen.¹³ Zur SMB-Signierung empfiehlt Microsoft außerdem, Kerberos statt NTLMv2 zu verwenden, damit der Sitzungsschlüssel von Anfang an stark ist, und sich nicht per IP-Adresse oder CNAME-Eintrag mit Freigaben zu verbinden (weil das dazu führt, dass NTLM statt Kerberos verwendet wird).¹² Das ist dieselbe Geschichte wie in den Abschnitten 6.1 und 6.2.

7.2. Pass-the-Hash — Der Hash ist dem Passwort gleichwertig

flowchart LR
    P["Passwort"] -->|"Einweg-Hash"| H["Passwort-Hash"]
    H -->|"Antwortschlüssel ableiten<br/>und HMAC berechnen"| R["Antwort"]
    R --> AUTH["Authentifizierung erfolgreich"]
    STEAL["Hash von einem<br/>Rechner stehlen"] --> H
    NOTE["Das Klartextpasswort<br/>wird nicht benötigt"] -.-> STEAL

Abbildung 5: Für die Authentifizierung wird der Hash benötigt, nicht das Klartextpasswort

NTLM-Anmeldeinformationen sind ein Einweg-Hash des Passworts.¹ Bei NTLMv2 wird dieses MD4(UNICODE(Passwort)) als Schlüssel verwendet, um den Antwortschlüssel abzuleiten, und dieser Schlüssel wird dann verwendet, um einen HMAC zu berechnen und die Antwort zu bilden.² Die Form der Berechnung hat sich geändert, aber der Ausgangspunkt bleibt der Hash. Das heißt: Für die Authentifizierung wird der Hash benötigt, nicht das Klartextpasswort.

Das hat ernste betriebliche Auswirkungen. Längere und komplexere Passwörter schließen den Weg nicht, über den der Hash gestohlen wird. Microsoft nennt Pass-the-Hash neben Brute-Force und Cracking als Angriff, dem die SMB-NTLM-Blockierung entgegenwirkt.¹³

Auch Kerberos besitzt Langzeitschlüssel, aber was bei der alltäglichen Authentifizierung umherfliegt, sind zeitlich begrenzte Tickets und Sitzungsschlüssel.³ Der Schaden, der bei ihrem Diebstahl entsteht, ist ein anderer.

8. NTLMv1, NTLMv2 und „Entfernung“

NTLM ist kein einzelnes Protokoll, sondern eine Familie von Authentifizierungsprotokollen, zu der LAN Manager Version 1 und 2 sowie NTLM Version 1 und 2 gehören.⁹

Ihr aktueller Status gliedert sich wie folgt.

Es gilt also nicht „wir sind auf NTLMv2, also können wir es vorerst lassen“. Die Priorität ist jedoch klar: Geräte und Hosts, die nur NTLMv1 sprechen, kommen zuerst. Hosts, bei denen ein Audit NTLM V1 protokolliert, schlagen bei der Authentifizierung fehl, wenn Sie sie unverändert auf ein neueres Windows heben. Wie Sie die Versionen unterscheiden (durch Betrachten von „Paketname (nur NTLM)“ im Sicherheitsprotokoll), ist in Abschnitt 4.4 des begleitenden praxisorientierten Artikels beschrieben.⁵

Beachten Sie, dass die Audit- und Blockierungsrichtlinien zur Einschränkung von NTLM auf NTLMv1 und NTLMv2 gleichermaßen wirken.⁵ Das Verhalten unterscheidet sich beim Anwenden von Einschränkungen nicht nach Version.

9. Wie es weitergeht

Microsoft hat drei Richtungen aufgezeigt.

Erstens: Verwenden Sie auf Anwendungsseite Negotiate. Die Anweisung, Aufrufe von NTLM durch Aufrufe von Negotiate zu ersetzen, ist Teil der Abschaffungsankündigung selbst.⁸ Es wird außerdem ausdrücklich festgehalten, dass Anwendungen nicht direkt auf das NTLM-Sicherheitspaket zugreifen sollten.¹

Zweitens: Reduzieren Sie von vornherein die Situationen, die NTLM erfordern. IAKerb und der lokale KDC, geplant für Phase 2 (zweite Jahreshälfte 2026), sind genau das.⁶ Sie sind ein Versuch, auf Protokollebene die beiden in Abschnitt 6.3 gesehenen Lücken zu schließen — „Kerberos ist nicht verfügbar, weil es ein lokales Konto ist“ und „Kerberos ist nicht verfügbar, weil der Domänencontroller unerreichbar ist“. Es gibt jedoch eine Grenze, wie viel davon geschlossen wird. Was IAKerb löst, ist die Erreichbarkeit eines Domänencontrollers, nicht ob die Gegenstelle irgendetwas unterstützt. Der lokale KDC funktioniert ebenfalls nur zwischen unterstützenden Windows-Systemen. Ist die Gegenstelle ein NAS oder Multifunktionsgerät eines Fremdherstellers, ändert das Warten auf Phase 2 nichts, sodass Sie selbst zwischen Geräteerneuerung, Domänenbeitritt, Wechsel auf ein anderes Protokoll oder dem Verwalten einer Ausnahme wählen müssen.

Drittens: Ändern Sie die Standardeinstellungen. In Phase 3 ist geplant, die Netzwerk-NTLM-Authentifizierung im nächsten Major-Release standardmäßig zu deaktivieren.⁶ Es wird jedoch auch festgehalten, dass sie sich per Richtlinie wieder aktivieren lässt.

Diese Reihenfolge hat einen Grund. Weil es „erst die Gründe für die Verwendung beseitigen, dann die Standardeinstellung ändern“ ist, spart es überflüssige Arbeit, Ihre verbleibenden NTLM-Abhängigkeiten in solche zu sortieren, die Phase 2 voraussichtlich löst (Authentifizierung mit lokalen Konten zwischen unterstützenden Windows-Systemen, DC-Erreichbarkeit), und solche, die Sie selbst beheben müssen (fest codierte IP-Adressen, nicht registrierte SPNs sowie Authentifizierung mit lokalen Konten, bei der die Gegenstelle ein älteres Windows oder ein Fremdherstellergerät ist). Stufen Sie letztere Gruppe als „warten auf Phase 2“ ein, taucht das als Ausfall auf, sobald die standardmäßige Deaktivierung kommt. Das konkrete Vorgehen zur Sortierung ist im begleitenden praxisorientierten Artikel dargelegt.

10. Zusammenfassung

• NTLM ist ein Protokoll, das über Challenge/Response beweist, „dass Sie den Passwort-Hash besitzen“. Die Entscheidung wird bei Domänenkonten an einen Domänencontroller delegiert und bei lokalen Konten vom Server selbst anhand seiner eigenen SAM getroffen.¹⁹
• Kerberos beweist, „wer sich gegenüber welchem Dienst“ authentifiziert. Ein Dienstticket ist mit dem Langzeitschlüssel des Zieldienstes verschlüsselt und kann daher nicht gegen ein anderes Ziel wiederverwendet werden.³
• Die entscheidenden Unterschiede sind die gegenseitige Authentifizierung, die DC-Abfrage bei jeder Authentifizierung und ob Delegation möglich ist.⁴
• Der Rückfall auf NTLM bedeutet fast immer, dass Kerberos nicht gestartet werden konnte. Die vier Hauptursachen sind fest codierte IP-Adressen, nicht registrierte SPNs, das Fehlen von Active Directory sowie eine nicht erreichbare KDC.⁵⁶¹¹
• Dagegen zeigen sich Probleme, bei denen Kerberos gewählt wurde und dann fehlschlug — etwa eine Zeitabweichung — als Authentifizierungsfehler, nicht als Rückfall auf NTLM. Die Suche nach Ereignis 8001 findet sie nicht.¹⁰
• Relay-Angriffe funktionieren, weil eine NTLM-Antwort das Ziel nicht bindet. Pass-the-Hash funktioniert, weil für die Authentifizierung der Hash selbst benötigt wird.⁷¹¹³
• NTLMv1 wurde bereits entfernt (Windows 11 24H2 / Windows Server 2025), und alle Versionen einschließlich NTLMv2 sind deprecated.⁸
• Was Anwendungen schreiben sollten, ist Negotiate. Darüber hinaus sind die Vereinheitlichung von Zielnamen auf FQDNs und die Registrierung von SPNs der praktische Inhalt, um Kerberos funktionsfähig zu machen.¹⁵

Verwandte Artikel

• Bringt die NTLM-Abschaffung Ihre Fachanwendungen zum Stillstand? — Wie Sie Audit-Protokolle erfassen und in welcher Reihenfolge Sie Abhängigkeiten beseitigen
• Fallstricke bei Netzlaufwerken und UNC-Pfaden — Der Umgang mit Dateiservern (Freigabeordnern) aus einer Fachanwendung heraus
• Anleitung zur Windows-Zeitsynchronisierung (w32time)
• Ereignisprotokolle praxisnah mit Get-WinEvent untersuchen
• Anmeldeinformationen in PowerShell sicher handhaben — Klartextpasswörter aus Ihren Skripten verbannen
• Was ist das TPM in Windows? — Eine bebilderte Anleitung zum „Tresor, der Schlüssel niemals herausgibt“, und zum Measured Boot
• Die 10 größten Bedrohungen der Informationssicherheit 2026 — Wie man das Ranking liest und was KMU wirklich absichern sollten

Verwandte Beratungsleistungen

Die KomuraSoft LLC übernimmt die Anpassung von Windows-Fachanwendungen im Zuge einer Überarbeitung der Authentifizierungsmethode sowie die Ursachenuntersuchung von Authentifizierungsproblemen rund um Kerberos und NTLM.

• 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.

Was ist der tatsächliche Unterschied zwischen NTLM und Kerberos?

Der größte Unterschied ist, ob Sie überprüfen können, mit wem Sie es zu tun haben. Microsoft schreibt ausdrücklich, dass bei NTLM weder der Client die Identität eines Servers überprüfen kann, noch ein Server die Identität eines anderen Servers. NTLM wurde für Umgebungen entworfen, in denen davon ausgegangen werden kann, dass Server echt sind; Kerberos trifft diese Annahme nicht. Der zweite Unterschied betrifft, ob der Server einen Domänencontroller befragen muss. Bei NTLM verbindet sich der Anwendungsserver bei der Authentifizierung eines Domänenkontos bei jeder Anmeldung mit einem Domänencontroller (bei einem lokal auf dem Server liegenden Konto prüft der Server anhand seiner eigenen Kontendatenbank selbst, ohne dass überhaupt ein Domänencontroller auftaucht). Bei Kerberos ersetzen erneuerbare Sitzungstickets diese Pass-Through-Authentifizierung, sodass der Server nur dann einen Domänencontroller kontaktiert, wenn eine PAC-Prüfung erforderlich ist. Der dritte Unterschied ist, dass Kerberos Delegation durch Dienste unterstützt — einen Mechanismus, um im Namen des Clients eine Verbindung zu einem anderen Dienst herzustellen.

Warum landen wir bei NTLM, obwohl die Anwendung angeblich Kerberos unterstützt?

Kerberos stellt Tickets aus, die an „den Namen des Ziels“ gebunden sind, und kann daher nicht funktionieren, wenn sich der Name nicht auflösen lässt. Der Client legt dem KDC den SPN (Service Principal Name) des Ziels vor, um ein Dienstticket anzufordern, aber Windows versucht standardmäßig keine Kerberos-Authentifizierung, wenn der Hostname eine IP-Adresse ist, und ist am Dienstkonto kein SPN registriert, kann der KDC kein Ticket ausstellen. Auch Microsofts Audit-Anleitung sagt, dass Kerberos nicht verwendet wird, wenn der „Zielserver“ in Ereignis 8001 weder im NetBIOS- noch im FQDN-Format vorliegt. (Bei IP-Adressen können Sie Kerberos ausnahmsweise funktionsfähig machen, indem Sie auf dem Client TryIPSPN setzen und für die IP-Adresse manuell einen SPN registrieren, aber das wird als letzter Ausweg für Fälle beschrieben, in denen ein DNS-Name unmöglich ist.) Weitere Bedingungen, unter denen Kerberos nicht funktionieren kann, sind die Authentifizierung auf Arbeitsgruppenrechnern oder mit lokalen Konten (die vollständig außerhalb von Active Directory liegen), Standorte ohne Erreichbarkeit eines Domänencontrollers sowie die Authentifizierung gegenüber einer Gegenstelle ohne Vertrauensstellung. Negotiate wählt NTLM, wenn Kerberos nicht verfügbar ist – genau das ist mit „Rückfall“ in diesen Fällen gemeint.

Bedeutet ein NTLM-Relay-Angriff, dass man jemanden imitieren kann, ohne dessen Passwort zu knacken?

Genau das. Der Angreifer lockt das Opfer auf einen eigenen Server und leitet den dort ankommenden NTLM-Authentifizierungsaustausch unverändert an den echten Server weiter, wobei er sich als das Opfer ausgibt. Das funktioniert, weil das Challenge/Response-Verfahren von NTLM keinen Mechanismus besitzt, der bindet, „mit wem Sie sich authentifizieren“. Der Client berechnet einfach eine Antwort aus der vom Server ausgegebenen Challenge und sendet sie zurück, ohne prüfen zu können, ob diese Antwort tatsächlich für den echten Server bestimmt ist oder von einem Angreifer weitergeleitet wird. Microsoft schreibt selbst in der Dokumentation zu den Richtlinieneinstellungen, 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. Allerdings gelingt die Weiterleitung nicht bei jeder Gegenstelle. Verlangt das Ziel SMB-Signierung, bestätigt die Signatur die Identität von Absender und Empfänger, sodass die Weiterleitung fehlschlägt; dasselbe gilt für Dienste, die Extended Protection for Authentication (Channel Binding) erzwingen. Umgekehrt sind die Ziele Gegenstellen, die NTLM ohne Signierung und ohne Channel Binding akzeptieren. Bei Kerberos ist ein Dienstticket mit dem langfristigen Schlüssel des jeweiligen Dienstes verschlüsselt, sodass ein für einen Dienst bestimmtes Ticket nicht von einem anderen entschlüsselt werden kann.

Bedeutet Pass-the-Hash, dass man jemanden imitieren kann, ohne das Passwort zu knacken?

Genau das. NTLM-Anmeldeinformationen bestehen aus einem Einweg-Hash von Domänenname, Benutzername und Passwort. Bei NTLMv2, das heutiges Windows verwendet, wird der Antwortschlüssel als HMAC über den MD4-Hash des Passworts (den NT-Hash) abgeleitet, und dieser Schlüssel wird dann verwendet, um einen HMAC über ein Bündel aus Server-Challenge, Zeitstempel, clientseitiger Challenge und Zielinformationen zu berechnen. Es ist also nicht einfach eine Verschlüsselung der Challenge, aber der Ausgangspunkt bleibt der Passwort-Hash. Mit anderen Worten: Für die Authentifizierung wird der Hash benötigt, nicht das Klartextpasswort. Ein Angreifer, der den Hash beispielsweise aus dem Arbeitsspeicher eines Rechners extrahieren kann, kann sich also als dieser Benutzer authentifizieren, ohne das Passwort zu knacken. Längere und komplexere Passwörter schließen diesen Weg nicht. Einer der von Microsoft genannten Gründe für die NTLM-Blockierung auf SMB-Client-Seite ist genau die Abwehr von Pass-the-Hash-Angriffen.

Sind wir mit NTLMv2 vorerst sicher?

NTLMv2 ist stärker als NTLMv1, ist aber nicht von der Abschaffung ausgenommen. Microsofts Liste veralteter Funktionen besagt, dass alle Versionen von NTLM, einschließlich LANMAN, NTLMv1 und NTLMv2, nicht mehr aktiv weiterentwickelt werden und deprecated sind. Die Einschränkungsrichtlinien verhalten sich gleich: Die Audit- und Blockierungsrichtlinien wirken laut Beschreibung auf beide Versionen gleichermaßen. NTLMv1 wird jedoch anders behandelt: Es hat die Stufe „deprecated“ bereits hinter sich gelassen und befindet sich in der Entfernung, und es wurde bereits aus Windows 11 Version 24H2 und Windows Server 2025 entfernt. Die richtige Einordnung lautet also nicht „wir sind auf NTLMv2, also können wir es lassen“, sondern „NTLMv1 ist gerade jetzt eine Frist; NTLMv2 braucht eine Bestandsaufnahme als Vorbereitung auf die standardmäßige Deaktivierung“.

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.