Windows ohne NTLM:
IAKerb, LocalKDC und was jetzt zu tun ist

Kurz gefasst: Microsoft hat angekündigt, NTLM — das alte Authentifizierungsprotokoll von Windows — in künftigen Versionen des Systems standardmäßig zu deaktivieren. Zwei Neuerungen, IAKerb und LocalKDC, bringen Kerberos in die Szenarien, in denen früher auf NTLM zurückgegriffen wurde. Es ist keine Änderung, die man aufschieben sollte: Heute lohnt es sich herauszufinden, wo Ihr Unternehmen noch NTLM verwendet, und die Grundlagen (DNS, SPN, Uhren) in Ordnung zu bringen.

Wie NTLM funktioniert, einfach erklärt

NTLM dient dazu zu beweisen, dass Sie Ihr Passwort kennen, ohne es jemals zu senden. Es funktioniert wie ein Überraschungstest, mit drei Akteuren: Ihre Maschine (Client), der Server, den Sie erreichen wollen, und der Domänencontroller (DC), der die Passwörter in Active Directory verwahrt.

• 1Der Client klopft beim Server an: „Ich bin Mario, lass mich rein".
• 2Der Server wirft eine Challenge aus: eine Zufallszahl, jedes Mal anders.
• 3Der Client mischt diese Zahl mit dem Abdruck des Passworts (dem Hash) und schickt das Ergebnis zurück. Das Passwort verlässt nie die Maschine: Es bleibt auf dem Client.
• 4Der Server kann es nicht selbst überprüfen (er hat den Hash nicht): Er reicht die Anfrage an den DC weiter, der in AD den Abdruck verwahrt. Der DC führt die Berechnung erneut durch und bestätigt, wenn es übereinstimmt. Bei einem lokalen Konto hingegen überprüft die Maschine selbst in ihrer eigenen Datenbank (SAM), ohne jeden DC.

Zusammengefasst: Der Client spricht nur mit dem Server, und es ist der Server, der mit dem DC spricht. NTLM existiert in zwei Versionen: Heute verwendet man NTLMv2 (NTLMv1 sollte deaktiviert werden, weil es deutlich schwächer ist), aber der Mechanismus mit drei Akteuren — und die Probleme, die wir sehen werden — gilt für beide.

Warum NTLM ein Problem ist

Es wirkt solide — das Passwort reist nie im Klartext — hat aber zwei Risse, die heute schwer wiegen:

• Niemand überprüft den Server. Sie beweisen, wer Sie sind, aber der Server muss Ihnen nichts beweisen. Wenn sich jemand einschleicht und sich als der Server ausgibt, fliegt das Ganze auf. Das ist das Gegenteil der Zero-Trust-Logik.
• Es genügt der Abdruck, nicht das echte Passwort. Der Hash bleibt im Speicher der PCs und Server, an denen sich der Benutzer anmeldet, und — für alle Benutzer — auf dem Domänencontroller. Wer eine Maschine mit hohen Privilegien kompromittiert, kann den Hash stehlen und wiederverwenden, um sich als das Opfer zu authentifizieren (pass-the-hash), ohne das Passwort zu kennen. In einer anderen Variante stiehlt der Angreifer nichts: er fängt die Authentifizierung eines Opfers ab und leitet sie an einen dritten Server weiter (NTLM relay). In beiden Fällen wird eine einzige kompromittierte Maschine zum Einfallstor für das gesamte Netz: die typische Dynamik von Ransomware-Angriffen.

Kerberos: das Ticket-Modell

Kerberos ändert den Ansatz. Statt den Test an jeder Tür zu wiederholen, gehen Sie ein einziges Mal zu einem „Vertrauensschalter" (dem KDC, auf dem Domänencontroller), beweisen, wer Sie sind, und erhalten ein signiertes und befristetes Ticket. Jedem Dienst zeigen Sie das Ticket — wie ein Armband, das an einem zentralen Schalter ausgegeben wird, statt an jedem Tor die Ausweise vorzulegen. Die Vorteile:

• Gegenseitige Authentifizierung — nicht nur Sie beweisen, wer Sie sind: Auch der Server beweist Ihnen, dass er echt ist. Die Tür zeigt ein Siegel, das nur das echte Lokal erzeugen kann.
• Single Sign-on und Effizienz — Sie authentifizieren sich einmal und verwenden die Tickets wieder; die Dienste überprüfen sie selbst, ohne bei jedem Zugriff den DC anzurufen, wie es NTLM tut.

Dasselbe Prinzip „überprüfen, nicht vertrauen" liegt auch anderen jüngsten Entwicklungen der Windows-Authentifizierung zugrunde, etwa dem Abschied von der RC4-Verschlüsselung in Kerberos.

Warum NTLM noch überlebt

Wenn Kerberos besser ist, warum ist NTLM dann noch überall? Weil Kerberos in einigen Szenarien, so wie es konzipiert ist, nicht arbeiten kann und Windows automatisch auf NTLM zurückfällt:

• Lokale Konten und nicht in einer Domäne befindliche Maschinen — ohne eine Domäne gibt es keinen KDC, der die Tickets ausstellt.
• Keine Sichtverbindung zum Domänencontroller — wenn der Client keinen KDC erreicht, kann Kerberos das Ticket nicht ausstellen.
• Zugriff per IP-Adresse — Kerberos denkt in Namen (dem SPN, z. B. cifs/server.azienda.local). Wer per IP zugreift, hat keinen entsprechenden SPN und fällt auf NTLM zurück.
• Heterogene Umgebungen — Maschinen einer Domäne, die auf Ressourcen einer anderen Domäne zugreifen, NAS, die nicht in Active Directory eingebunden sind, macOS-Arbeitsplätze außerhalb der Domäne. Das ist die reale Welt sehr vieler KMU, und genau dort hält sich NTLM.

Was sich ändert: IAKerb und LocalKDC

Die zwei Microsoft-Neuerungen (in Preview auf Windows 11 und Windows Server 2025) greifen genau die Lücken an, an denen früher NTLM nötig war:

• 1IAKerb — wenn der Client den KDC nicht erreicht, übernimmt der Server die Botenrolle: Er leitet die Kerberos-Nachrichten an den Domänencontroller weiter und bringt das Ticket zurück. Er sieht nie Passwörter oder Hashes, er reicht nur die Nachrichten durch. Ergebnis: kein Zurückfallen mehr auf NTLM, „weil ich den DC nicht sehe".
• 2LocalKDC — ein „Vertrauensschalter" im Miniaturformat, der auf der Maschine selbst installiert wird und Kerberos-Tickets für die lokalen Konten ausstellt. So können die nicht in einer Domäne befindlichen Systeme Kerberos statt NTLM verwenden.

Auf die realen Fälle angewendet, müssen sie jedoch ehrlich gelesen werden:

• Domänenmaschine, die den DC nicht sieht (segmentiertes Netzwerk oder Außenstelle): IAKerb löst das, der Server leitet an den KDC weiter.
• Zugriff auf eine Ressource einer anderen Domäne mit den Anmeldedaten dieser Domäne: Wenn der entfernte KDC erreichbar und auflösbar ist, funktioniert Kerberos schon heute ohne Trust; wenn nicht, ist es heute NTLM und kann es künftig über IAKerb sein (der Server fungiert als Proxy).
• Nicht-Windows-NAS und macOS-Arbeitsplätze: LocalKDC ist eine Windows-Funktion und IAKerb ist auf der Windows-Seite — die Unterstützung durch Clients und Geräte von Drittanbietern ist nicht garantiert und muss mit dem Anbieter überprüft werden. Oft bleiben diese das letzte Bollwerk von NTLM.

Was heute zu tun ist: Audit, Hygiene und Mitigationen

1. Finde heraus, wo du noch NTLM verwendest. Bevor du irgendetwas anfasst, mach ein Audit: aktiviere das operative NTLM-Protokoll und analysiere die Sicherheitsereignisse — insbesondere 4624 mit NTLM-Authentifizierungspaket und 4776 auf den Domänencontrollern — um zu verstehen, welche Anwendungen, Server und Geräte noch von NTLM abhängen. Man deaktiviert nicht blind.

2. Bring die Kerberos-Grundlagen in Ordnung. Oft ist das Problem nicht „eine fehlende Microsoft-Funktion", sondern Basishygiene: auflösbare DNS-Namen (auch zu verschiedenen Domänen, mit Conditional Forwardern), korrekt registrierte SPN, Zugriff auf Ressourcen per Name und nicht per IP, und auf wenige Minuten synchronisierte Uhren. Sind diese Grundlagen in Ordnung, kehren viele Zugriffe, die heute auf NTLM zurückfallen, von selbst zu Kerberos zurück.

3. Reduziere das Risiko, solange es NTLM noch gibt. Du kannst es nicht von heute auf morgen abschalten, aber du kannst es eindämmen: aktiviere SMB signing und Signing mit Channel Binding (EPA, Extended Protection for Authentication) auf LDAP und Web-Diensten, um einen Großteil der NTLM-relay-Angriffe zu neutralisieren; nutze die NTLM-Einschränkungsrichtlinien (erst im Audit, dann selektives Blockieren), um schrittweise nachzuziehen; und lass Anwendungen das Negotiate-Paket statt direktem NTLM aufrufen, damit Kerberos gewählt wird, wenn möglich.

NTLM, Segmentierung und Zero Trust

Das Ende von NTLM ist nicht nur „Patch-Management": Es ist ein Baustein des Zero Trust, des Modells „nicht vertrauen, immer überprüfen". Hier zeigt IAKerb seine beste Seite: Statt zwei Umgebungen einzuebnen (durch das Öffnen von DNS und Ports zu den Domänencontrollern eines anderen Netzwerks), fungiert der Server als Proxy und Sie setzen das Herz der Identität nicht den externen Clients aus. Weniger implizite Konnektivität und — durch den Wechsel von NTLM zu Kerberos — die gegenseitige Überprüfung statt des blinden Vertrauens.

Aufpassen, die Ebenen nicht zu verwechseln: IAKerb und LocalKDC sind On-Premise- Mechanismen und haben nichts mit Microsoft Entra ID zu tun, der Cloud-Identität (es gibt ein „Entra Kerberos", aber es dient spezifischen Fällen wie Azure Files, nicht einer On-Premise-Freigabe oder einem NAS). Für die wirklich heterogenen Umgebungen ist die Antwort keine einzelne Funktion, sondern eine architektonische Entscheidung: gezielte Trusts, Segmentierung und, wo nötig, ein Zero Trust Network Access (ZTNA), der den Zugriff nach Identität und Gerät steuert, auch für die Nicht-Windows-Clients.

Wie AtWorkStudio hilft

Wir begleiten Unternehmen auf dem Weg zu einer modernen Authentifizierung: Audit der NTLM-Abhängigkeiten, Bereinigung von DNS, SPN und Synchronisierung, Reduzierung der lokalen Konten, digitales Identitätsmanagement und Netzwerksegmentierung. Für die heterogenen Umgebungen gestalten wir den Zugriff in einer Zero-Trust-Logik, im Einklang mit den Anforderungen der NIS2 und mit den Best Practices der ISO/IEC 27001.

Wir sind seit 2000 in Piacenza tätig. Wir sind nach ISO/IEC 27001, 27017, 27018 und ISO 9001 zertifiziert, ACN-qualifiziert für Cloud-Dienste, Mitglied von Clusit (Italienischer Verband für Informationssicherheit) und Confindustria Piacenza im RICT-Cluster.