Kerberos NTLM-Fallback
NTLM still in Betrieb – ohne dass es jemand bemerktNTLM-Fallback erkennen und abstellen
NTLM ist der zähe Untote der Windows-Authentifizierung. Eigentlich sollte längst überall Kerberos laufen, und dann taucht NTLM doch wieder auf – leise, unbemerkt, im Hintergrund. Das Tückische: Es funktioniert ja. Der Benutzer kommt rein, der Dienst antwortet, niemand beschwert sich. Genau deshalb merkt monatelang keiner, dass die schöne Kerberos-Welt in Wahrheit auf NTLM zurückfällt. Wer NTLM irgendwann abschalten will – und das wollen Sie, aus guten Gründen – muss es erst einmal zuverlässig sichtbar machen. Darum geht es hier.
Wie der Fallback überhaupt passiert
Wenn ein Client einen Dienst ansprechen will, startet Windows die sogenannte Negotiate-Aushandlung. Erste Wahl ist Kerberos. Klappt das nicht – aus welchem Grund auch immer – fällt das System automatisch und ohne Rückfrage auf NTLM zurück. Dieser Fallback ist bewusst eingebaut, damit alte Anwendungen weiterlaufen. In der Praxis verdeckt er aber jede Menge Konfigurationsfehler.

Abbildung 1: Scheitert Kerberos an irgendeiner Stelle, schaltet Negotiate stillschweigend auf NTLM um – ohne dass es jemand merkt.
Die Auslöser sind fast immer dieselben Verdächtigen: ein fehlender oder doppelter SPN, Zugriff über die IP-Adresse statt über den Namen, ein DNS- oder CNAME-Mismatch, eine zu große Zeitabweichung zwischen Client und Server, oder ein Trust-Problem zwischen Domänen. In jedem dieser Fälle wirft Kerberos das Handtuch – und NTLM springt ein, als wäre nichts gewesen.
|
Warum NTLM mehr ist als ein Schönheitsfehler NTLM kann keine Delegierung. Es belastet bei jedem Zugriff den Domänencontroller (Kerberos kommt mit einem zwischengespeicherten Ticket aus). Es nutzt schwächere Kryptografie und ist anfällig für Relay- und Pass-the-Hash-Angriffe. Und solange auch nur ein Dienst auf NTLM angewiesen ist, können Sie es nicht domänenweit abschalten. Jeder verdeckte Fallback ist also auch ein Stück Sicherheits-Schulden. |
|---|
NTLM sichtbar machen: drei Wege
Bevor Sie irgendetwas abschalten, müssen Sie wissen, wer überhaupt noch NTLM nutzt. Es gibt drei Ebenen, auf denen Sie nachschauen können – vom schnellen Einzelcheck bis zur domänenweiten Bestandsaufnahme.

Abbildung 2: Drei Erkennungs-Ebenen – schneller Client-Check, gezielte Server-Logs, domänenweites Audit.
Ebene 1 – Der schnelle Client-Check
Am einfachsten und ohne Sonderrechte: Auf dem Client nach dem Zugriff in den Ticket-Cache schauen. Liegt für den angesprochenen Dienst ein Service-Ticket vor, lief Kerberos. Ist trotz erfolgreichem Zugriff kein passendes Ticket da, war es NTLM.
|
klist purge REM … Dienst nutzen … klist |
|---|
Ebene 2 – Das Server-Eventlog
Auf dem Zielserver verrät das Sicherheitsprotokoll, womit sich ein Zugriff angemeldet hat. Im Event 4624 (erfolgreiche Anmeldung) steht im Feld Authentifizierungspaket entweder „Kerberos“ oder „NTLM“. So sehen Sie nicht nur, dass NTLM läuft, sondern auch, welche Clients es auslösen.
Ebene 3 – Das domänenweite Audit
Die gründlichste Methode: ein NTLM-Audit per Gruppenrichtlinie. Über die Richtlinie „Netzwerksicherheit: NTLM einschränken – eingehenden NTLM-Datenverkehr überwachen“ protokollieren die Server jeden NTLM-Zugriff, ohne ihn zu blockieren. Auf den Domänencontrollern sammelt sich das im Operational-Log unter Event 8004. Damit bekommen Sie ein vollständiges Bild, wer im gesamten Netz noch NTLM spricht – die Grundlage für jede Abschalt-Entscheidung.
|
Ebene |
Werkzeug |
Stärke |
Grenze |
|---|---|---|---|
|
Client |
klist |
Sofort, ohne Rechte |
Nur ein Client/Dienst |
|
Server |
Event 4624 |
Zeigt Quelle pro Server |
Pro Server prüfen |
|
Domäne |
GPO-Audit, Event 8004 |
Vollständiges Bild |
Setup + Sammlung nötig |
Erst die Ursache fixen, dann abschalten
NTLM zu erkennen ist die halbe Miete – die andere Hälfte ist, die Ursachen zu beseitigen, bevor Sie den Hahn zudrehen. Wer NTLM blockiert, ohne vorher Kerberos für alle Dienste zum Laufen gebracht zu haben, legt am Montagmorgen die halbe Firma lahm. Deshalb gilt: in Stufen vorgehen, nie im Big Bang.

Abbildung 3: Der kontrollierte Stufenplan – erst auditieren, dann Ursachen fixen, eingrenzen, und ganz zum Schluss verbieten.
Die typischen Ursachen kennen Sie aus den anderen Kerberos-Themen: fehlende oder doppelte SPNs setzen bzw. bereinigen, DNS und CNAMEs gerade ziehen, Zugriffe per Name statt per IP konfigurieren, Zeitsynchronisation prüfen. Erst wenn das Audit über Wochen keine relevanten NTLM-Zugriffe mehr zeigt, gehen Sie an die Sperre.
|
Die goldene Regel Schalten Sie NTLM niemals direkt von „alles erlaubt“ auf „alles verboten“. Gehen Sie über „überwachen“, dann über gezielte Ausnahmen für die wenigen verbliebenen Altanwendungen (Add server exceptions), und erst dann auf „verweigern“. Jede Stufe gibt Ihnen die Chance, einen vergessenen Dienst zu entdecken, bevor er produktiv ausfällt. |
|---|
Die eigentliche Sperre erfolgt über dieselbe Richtliniengruppe wie das Audit – „NTLM einschränken“, nur eben auf „Alle verweigern“ statt „Überwachen“. Bewahren Sie sich über die Server-Ausnahmeliste die Möglichkeit, einzelne hartnäckige Altanwendungen vorübergehend weiterlaufen zu lassen, während Sie den Rest schon dichtmachen.
Häufige Fragen
Woran erkenne ich am schnellsten, ob ein Zugriff NTLM oder Kerberos nutzt?
Am Client per klist: Cache leeren, Dienst nutzen, Ticketliste ansehen. Liegt ein Service-Ticket für den Dienst-SPN vor, lief Kerberos. Kein Ticket trotz erfolgreichem Zugriff bedeutet NTLM. Das ist die schnellste Methode überhaupt und braucht keine Adminrechte. Für das große Bild über viele Clients hinweg brauchen Sie dann aber das Server- oder Domänen-Audit.
Kann ich NTLM einfach per Gruppenrichtlinie komplett abschalten?
Technisch ja, praktisch wäre das fahrlässig, solange Sie nicht sicher sind, dass kein Dienst mehr darauf angewiesen ist. Schalten Sie zuerst das Audit ein und lassen es lange genug laufen – Wochen, nicht Tage, damit auch selten genutzte Dienste und Monatsläufe erfasst werden. Erst wenn die Audit-Logs sauber sind, gehen Sie schrittweise auf „verweigern“, idealerweise mit Ausnahmeliste für die letzten Altfälle.
Welche Event-IDs sind für das NTLM-Audit relevant?
Auf dem Zielserver ist es Event 4624 im Sicherheitsprotokoll, dessen Feld zum Authentifizierungspaket zwischen Kerberos und NTLM unterscheidet. Für das domänenweite Audit per GPO ist Event 8004 auf den Domänencontrollern (im NTLM-Operational-Log) der zentrale Datenpunkt – er protokolliert eingehenden NTLM-Verkehr inklusive Quelle und Zielserver.
Was sind die häufigsten Gründe, warum Kerberos fehlschlägt und NTLM einspringt?
In dieser Reihenfolge: fehlender SPN, doppelter SPN, Zugriff per IP-Adresse statt per Hostname, DNS- oder CNAME-Mismatch und Zeitabweichung über fünf Minuten. Seltener kommen Trust- und Routing-Probleme zwischen Domänen dazu. Die ersten drei decken den allergrößten Teil der Fälle ab – wer dort sauber arbeitet, eliminiert die meisten NTLM-Fallbacks.
Bricht das Abschalten von NTLM ältere Anwendungen?
Es kann – und genau deshalb der Stufenplan. Manche Altanwendungen, Appliances oder Skripte können ausschließlich NTLM und brechen bei einer harten Sperre. Über die Server-Ausnahmeliste der NTLM-Richtlinie lassen sich solche Fälle gezielt weiter erlauben, während Sie den Rest der Umgebung schon abdichten. Ziel ist, diese Ausnahmen mittelfristig durch Kerberos-fähige Nachfolger abzulösen – aber niemand zwingt Sie, das alles an einem Tag zu erledigen.