NTLM zurückdrängen und auf Kerberos umstellen

Was Microsoft bei NTLM tatsächlich angekündigt hat

In der Übersicht der entfernten und nicht mehr weiterentwickelten Funktionen steht NTLM für Windows Server 2025 in beiden Listen, und das ist der Punkt, an dem sich die Lage entscheidet. NTLMv1 ist entfernt. LANMAN und NTLMv2 sind nicht mehr in aktiver Weiterentwicklung und damit abgekündigt. Zu NTLMv2 schreibt Microsoft ausdrücklich, dass es weiterhin funktionieren wird, aber in einer künftigen Version aus Windows Server entfernt wird.

Die Empfehlung, die Microsoft an derselben Stelle gibt, ist bemerkenswert konkret und für die Planung wichtiger als jede Jahreszahl: Aufrufe von NTLM sollen durch Aufrufe von Negotiate ersetzt werden, also durch den Mechanismus, der zunächst versucht, sich über Kerberos anzumelden, und nur bei Bedarf auf NTLM zurückfällt. Für eigene Anwendungen im Haus ist das eine Anforderung an die Entwicklung, für gekaufte Software eine Frage an den Hersteller.

Zu einer weiteren Umstellung passt das ins Bild. Die Verwendung von RC4 im Kerberos-Protokoll ist ebenfalls als nicht mehr weiterentwickelt eingestuft, und Microsoft nennt dazu den Grund, dass RC4 ein schwaches Verfahren ist, das zum Diebstahl von Zugangsdaten missbraucht werden kann. In Windows Server 2025 stellt das Schlüsselverteilungszentrum keine Ticket-Granting-Tickets mehr mit RC4 aus. Wer also NTLM zurückdrängt, sollte im selben Vorhaben prüfen, wo RC4 in der Kerberos-Welt noch benötigt wird, denn beide Umstellungen treffen häufig dieselben Systeme.

Was aus alldem nicht folgt, ist eine Frist. Es gibt kein angekündigtes Datum, zu dem NTLMv2 verschwindet, und es gibt auch keinen Zwang, morgen zu sperren. Was folgt, ist die Richtung: Alles, was heute neu gebaut wird, sollte ohne NTLM auskommen, und der Bestand sollte messbar kleiner werden statt größer. Ein Vorhaben mit einer eigenen, begründeten Frist ist an dieser Stelle besser als eine erfundene fremde.

Warum Kerberos in genau diesen Fällen aussteigt

Kerberos braucht einen Namen. Der Client fragt beim Schlüsselverteilungszentrum ein Ticket für einen bestimmten Dienst auf einem bestimmten Rechner an, und dieser Dienst wird über einen Dienstprinzipalnamen identifiziert. Wird eine Freigabe über die IP-Adresse angesprochen, gibt es keinen Namen, für den ein Ticket ausgestellt werden könnte, und der Aufruf fällt auf NTLM zurück. Microsoft nennt das in den Empfehlungen zur SMB-Signierung als eigenen Punkt: Nicht über IP-Adressen auf Freigaben zugreifen, sonst wird NTLM statt Kerberos verwendet.

Der zweite häufige Fall sind CNAME-Einträge im DNS. Ein Alias zeigt zwar auf den richtigen Rechner, aber der Name des Alias steht nicht als Dienstprinzipalname am Computerkonto, und damit gibt es wieder kein Ticket. Microsoft empfiehlt an derselben Stelle ausdrücklich, keine CNAME-Einträge zu verwenden und stattdessen zusätzliche Computernamen mit netdom.exe zu vergeben. Das ist der eigentliche Hebel, denn Aliasse sind in gewachsenen Umgebungen die verbreitetste Ursache.

Der dritte Fall betrifft Dienstkonten. Läuft ein Dienst unter einem Domänenkonto, gehört der Dienstprinzipalname an dieses Konto und nicht an das Computerkonto. Wird das Konto später gewechselt und der Eintrag nicht mitgezogen, fällt der Aufruf zurück. Doppelt eingetragene Dienstprinzipalnamen, also derselbe Name an zwei Konten, führen zum selben Ergebnis und sind besonders unangenehm, weil sie zeitweise funktionieren.

Der vierte Fall sind Systeme, die dem Verzeichnis nicht angehören. Ein Speichersystem, ein Gerät in der Fertigung, ein Server eines Dienstleisters: Wo kein Vertrauensverhältnis besteht, gibt es kein Ticket. Für diese Fälle ist die Ausnahmeliste der richtige Ort, und zwar dauerhaft und mit Begründung. Wichtig ist nur, dass sie nicht der erste Griff ist, sondern der letzte.

Die Protokollierung lesen, ohne im Rauschen zu ertrinken

Die Prüfrichtlinie erzeugt in großen Umgebungen sehr viele Ereignisse, und Microsoft weist ausdrücklich darauf hin, die Größe der Protokolle je nach Umfang und Dauer des Tests im Auge zu behalten. Die naheliegende Reaktion, nämlich die Messung zu verkürzen, ist die falsche. Besser ist es, die Auswertung von der Zahl der Ereignisse auf die Zahl unterschiedlicher Kombinationen aus Quellsystem, Konto und Zieldienst umzustellen. Aus mehreren Millionen Zeilen werden so meist einige Dutzend Fälle.

Beachte den Zuschnitt der Messung. Die Richtlinie erfasst auf einem Server nur die Anmeldungen an genau diesen Server. Für ein vollständiges Bild brauchst du sie deshalb auf allen Domänencontrollern und auf allen Systemen, die als Ziel infrage kommen, also insbesondere auf Dateiservern, Datenbankservern und Anwendungsservern. Ein Bild, das nur die Domänencontroller kennt, übersieht genau die Zugriffe zwischen zwei Mitgliedsservern.

Microsoft weist außerdem auf eine Nebenwirkung hin, die in die Planung gehört: Wenn diese Richtlinie eingeschaltet ist, verrät die Protokollierung, welche Server und Clients im Netz NTLM-Verkehr abwickeln, und diese Information ist selbst schützenswert. Beschränk deshalb den Zugriff auf die Protokolldateien und auf die Auswertung, so wie du es auch mit anderen sicherheitsrelevanten Beständen tun würdest.

Ein letzter Hinweis zur Erwartung: Die Protokollierung ist reine Beobachtung. Microsoft formuliert das deutlich, indem es festhält, dass diese Einstellung keine Schwachstelle verhindert oder abschwächt, weil sie ausschließlich der Prüfung dient. Das ist kein Nachteil, sondern der Zweck. Der Sicherheitsgewinn entsteht in den Schritten danach, und die Messung sorgt nur dafür, dass diese Schritte funktionieren.

Die Werkzeuge, die Windows Server 2025 dafür mitbringt

Das wichtigste neue Werkzeug ist die Möglichkeit, NTLM auf dem SMB-Client für ausgehende Verbindungen zu blockieren. Microsoft begründet das damit, dass sich Clients so nicht mehr dazu bringen lassen, NTLM-Anfragen an bösartige Server zu schicken, was Angriffe über das Erraten und Weitergeben von Anmeldeinformationen ins Leere laufen lässt. Voraussetzung ist ein Client unter Windows Server 2025 oder Windows 11 in der Version 24H2 sowie ein Zielserver, der Kerberos zulässt. Auf dem Zielsystem selbst muss nichts verändert werden, das Betriebssystem dort ist beliebig, solange Kerberos oder PKU2U verwendet werden können.

Eingeschaltet wird das über die Richtlinie Block NTLM (LM, NTLM, NTLMv2) unter Computerkonfiguration, Administrative Vorlagen, Netzwerk, Lanman Workstation oder über den Aufruf von Set-SmbClientConfiguration mit dem Schalter BlockNTLM. Für einzelne Verbindungen geht es auch punktuell: Beim Verbinden eines Laufwerks lässt sich der Schalter BLOCKNTLM an NET USE übergeben, und New-SmbMapping kennt einen entsprechenden Parameter. Ausnahmen laufen über die Richtlinie Block NTLM Server Exception List, in die IP-Adressen, NetBIOS-Namen und vollqualifizierte Namen eingetragen werden. Ein vollständiges PowerShell-Gegenstück dazu gibt es nicht, die Liste wird zuerst über die Richtlinie angelegt und lässt sich danach über den zugehörigen Registrierungswert unterhalb der Richtlinien für LanmanWorkstation ergänzen.

Ergänzend wirkt eine Voreinstellung, die weniger bekannt ist. Der SMB-Server verzögert seit Windows Server 2025 und Windows 11 in der Version 24H2 jeden fehlgeschlagenen Anmeldeversuch über NTLM oder PKU2U standardmäßig um zwei Sekunden. Microsoft rechnet vor, was das bedeutet: Ein Angriff, der zuvor dreihundert Versuche je Sekunde über fünf Minuten schaffte, also neunzigtausend Kennwörter, braucht für dieselbe Menge nun fünfzig Stunden oder mehr. Kerberos ist davon nicht betroffen, weil die Anmeldung dort vor dem Verbindungsaufbau erfolgt.

Auf der Kontenseite bleibt die Gruppe Protected Users das wirksamste Mittel für privilegierte Konten. Für ihre Mitglieder speichert NTLM auf dem Gerät weder Klartextdaten noch den abgeleiteten Wert, und auf Seite der Domänencontroller können sich diese Konten ab der Domänenfunktionsebene Windows Server 2012 R2 überhaupt nicht mehr über NTLM anmelden. Das ist eine kontenbezogene Sperre statt einer netzweiten und deshalb der ideale Einstieg. Nebenbei ist noch eine Altlast verschwunden: Die Richtlinie zum Speichern des LAN-Manager-Hashwerts beim nächsten Kennwortwechsel gibt es in neuen Windows-Versionen nicht mehr, weil sie dort keine Bedeutung mehr hat.

Was übrig bleibt und warum das in Ordnung ist

Am Ende eines solchen Vorhabens steht in praktisch jeder Umgebung eine Restmenge. Ein Speichersystem, das nicht der Domäne beitreten kann. Ein Gerät in der Fertigung, dessen Hersteller es seit Jahren nicht mehr gibt. Ein Zugang für einen Dienstleister, der von außen kommt. Diese Restmenge ist kein Scheitern, sondern das Ergebnis. Der Unterschied zum Zustand davor liegt darin, dass sie benannt, begrenzt und begründet ist.

Behandel diese Fälle wie Ausnahmen behandelt gehören: mit einem Eintrag, der sagt, worum es geht, wer dafür geradesteht und wann der Fall erneut geprüft wird. Nutz die Ausnahmeliste des SMB-Clients, um sie technisch auf genau diese Ziele zu begrenzen, statt NTLM für den ganzen Client wieder freizugeben. Und sieh zu, dass diese Liste bei jeder Beschaffung geprüft wird, denn der günstigste Zeitpunkt, einen solchen Fall loszuwerden, ist der Austausch des Geräts.

Zum Schluss ein Punkt, der bei diesem Vorhaben häufig untergeht: Das Ziel ist nicht die Zahl null, sondern die Kontrolle darüber, wo NTLM noch verwendet wird und warum. Eine Umgebung mit fünf begründeten Ausnahmen und einer laufenden Messung ist deutlich besser aufgestellt als eine, in der NTLM zwar nirgends ausdrücklich erlaubt, aber überall stillschweigend im Einsatz ist. Und weil die Messung ohnehin läuft, merkst du sofort, wenn eine neue Anwendung den Bestand wieder wachsen lässt.