Microsoft hat die veraltete NTLM-Authentifizierung in Windows als "deprecated" erklärt. In der nächsten Windows Version (Server und Client) wird NTLM standardmäßig deaktiviert und die Kerberos-Authentifizierung Standard. Damit neigt sich die Verwendung von NTLM seinem Ende zu.
NTLM (steht für NT LAN Manager) ist ein Authentifizierungsverfahren für Rechnernetze, dass auf einem proprietären Protokoll Microsofts basiert und primär in Windows-Rechnernetzen verwendet wurde. Seit mehr als drei Jahrzehnten ist NTLM Teil der Windows-Authentifizierung. Inzwischen gilt NTLM als nicht mehr sicher und wurde in Windows-Umgebungen/-Netzwerken durch die Kerberos-Authentifizierung ersetzt.
Bisher unterstützt Windows aber aus Kompatibilitätsgründen noch das veraltete NTLM, obwohl Microsoft längst den Wechsel auf Kerberos empfiehlt. Standardmäßig wird in Windows-Netzwerken zwar Kerberos zur Authentifizierung verwendet. Problem ist aber der Fallback-Mechanismus. Immer, wenn ein Teilnehmer im Netzwerk kein Kerberos unterstützt, kann er eine (unsichere) NTLM-Authentifizierung als Fallback verwenden.
Spätestens seit Mandiant Rainbow-Tabellen zum Knacken der Verschlüsselung veröffentlicht hat (siehe NTLMv1 ist sicherheitstechnisch tot: Mandiant veröffentlicht Rainbow-Tabellen) ist NTLM auch Sicherheitssicht tot. Administratoren können in ihren Umgebungen NTLM in Domänen mit Windows Servern auf den DCs aus Sicherheitsgründen deaktivieren.
Fahrplan zur NTLM-Abschaltung
Zum 29. Januar 2026 hat Microsoft den Techcommunity-Artikel Advancing Windows security: Disabling NTLM by default veröffentlicht (via), der die Gründe und den Fahrplan zur Abschaltung offen legt. Mit Veröffentlichung des Artikels wurde NTLM offiziell als veraltet (deprecated) erklärt. Veraltete Funktionen sind weiterhin verfügbar, erhalten jedoch keine Updates oder Verbesserungen mehr und können in einer zukünftigen Version entfernt werden – was in der nächsten Version von Windows Server und Windows 11 der Fall sein werde, schreibt Microsoft.
Fahrplan zur NTLM-Abschaltung; Quelle: Microsoft
Microsoft hat einen Fahrplan zur NTLM-Abschaltung aufgesetzt (siehe obige Abbildung), der mehrere Stufen umfasst.
Phase 1: Erweiterte Überwachung
Diese Phase beginnt ab sofort mit der erweiterten Überwachung (Enhanced Auditing). Diese jetzt verfügbare erweiterte NTLM-Überwachung hilft Unternehmen dabei, herauszufinden, wo und warum NTLM in der Umgebung noch verwendet wird. Dieses Auditing lässt sich mit Windows Server 2025 und Windows 11 24H2 und höher durchführen (siehe Disabling NTLM).
Phase 2: Die wichtigsten Probleme mit NTLM angehen
In der zweiten Hälfte des Jahres 2026 sollen in Phase 2 die wichtigsten Probleme im Zusammenhang mit der NTLM-Abschaltung angegangen werden. Microsoft nennt folgende Punkte:
- Keine Verbindung zum Domänencontroller bei deaktiviertem NTLM: Funktionen wie IAKerb und das lokale Key Distribution Center (KDC) (noch Pre-Release) ermöglichen eine erfolgreiche Kerberos-Authentifizierung in Szenarien, in denen die Domänencontroller-Konnektivität (DC) zuvor einen NTLM-Fallback erzwungen hat.
- Fest codierte NTLM-Verwendung: Die Kernkomponenten von Windows werden aktualisiert, um bei der Netzwerkauthentifizierung zuerst die Verwendung von Kerberos zu verhandeln. Dadurch sollen die Fälle der NTLM-Verwendung reduziert werden.
Die Lösungen für die obigen Probleme sollen in der zweiten Hälfte des Jahres 2026 für Windows Server 2025 sowie Windows 11 24H2 und höher verfügbar sein.
Phase 3: NTLM wird standardmäßig deaktiviert
In der nächsten großen Windows Server-Version und den zugehörigen Windows-Client-Versionen will Microsoft dann NTLM standardmäßig deaktivieren. Dies bedeute:
- NTLM wird im Netzwerk standardmäßig deaktiviert.
- Die Verwendung von NTLM erfordert eine explizite erneute Aktivierung durch neue Gruppenrichtlinien.
Die Unterstützung für die Behandlung von Fällen in denen die reine NTLM-Authentifizierung noch erforderlich ist, werde in den neuen Windows-Versionen integriert sein. Dadurch sollen Ausfälle von Anwendungen in Windows-Umgebungen reduziert werden.
Beispiele hierfür sind der Zugriff auf Ziele mit unbekannten SPNs (Service Principal Names), Authentifizierungsanfragen unter Verwendung von IP-Adressen, lokale Konten auf domänengebundenen Computern und neue NTLM-Blockierungsrichtlinien.
Microsoft stellt noch klar, dass die standardmäßige Deaktivierung von NTLM nicht bedeutet, dass NTLM vollständig aus Windows entfernt wird. Windows werde lediglich durch die Blockade der Netzwerk-NTLM-Authentifizierung in einem standardmäßig sicheren Zustand ausgeliefert, in dem die Verwendung der Kerberos-basierten Authentifizierung erzwungen wird. Gleichzeitig sollen gängige Legacy-Szenarien durch neue, in Kürze verfügbare Funktionen wie Local KDC und IAKerb (Vorabversion) berücksichtigt werden.
Frage in die Runde: Spielt NTLM bei euch in Unternehmensumgebungen überhaupt noch eine praktische Rolle? Gibt es Fälle, wo man bei den nächsten Windows-Versionen NTLM wieder per Gruppenrichtlinie einschalten muss?
Ähnliche Artikel:
NTLMv1 ist sicherheitstechnisch tot: Mandiant veröffentlicht Rainbow-Tabellen
Windows 11 24H2-25/H2, Server 2025: SID-Duplikate verursachen NTLM-/Kerberos-Authentifizierungsfehler
Verwirrung um 0-Click-NTLM Authentication Bypass (Telnet) in Windows
Windows NTLM-Schwachstelle CVE-2025-24054 wird ausgenutzt
MVP: 2013 – 2016
Stichwort Monitorig: Vieles läuft in Serverumgebung (der einfachheitshalber) über NTLM (PRTG).
Wer im jahr 2026 noch PRTG einsetzt und sinnfrei viel Geld aus dem Fenster wirft, der dürfte aber mittlerweise selbst Schuld sein. Nutze seit vielen Jahren Zabbix.
Was ist schlecht an PRTG? Es wird von vielen namenhaften Konzernen erfolgreich eingesetzt.
Schlecht ist, das PRTG bei WMI-Sensoren kein Kerberos unterstützt.
Man kann also NTLM nicht abschalten, wenn man PRTG nutzt.
Die haben da zwar KI-Gedöns eingebaut, aber die viel viel wichtigere Unterstützung von Kerberos nicht.
D.H., die Prioritäten völlig falsch gesetzt!
Es ist schon peinlich, wenn ein Produkt im Jahr 2026 noch kein Kerberos unterstützt, selbst wenn es nur Teilbereiche sein sollten.
Kerberos gibt es bei Windows seit Windows 2000, d.h. seit 26 Jahren!
Ja, und dann sitzt du für simple Sachen, die in PRTG 3 Klicks sind , ein WE über Zabbix. Und für jeden Mist brauchst du doch wieder kostenpflichtige Plugins. Ich kenne beide Welten, PRTG ist top, Zabbix auch, aber nur wenn du die Zeit und das Personal hast PRTG-out-of-the-Box Funktionalität nachzubauen. Bau mal ein praxistaugliches Broad-/Multi-/Unknown-Unicast Monitoring in Zabbix. Also erzähl keinen Blödkram!
Nur weil PRTG komfortabler ist, reisst du dur durch die Verwendung von NTLM Sicherheitslöcher ins Netzwerk?
Ja genau… nur wegen PRTG.
Ich kenne einige, die NTLM abschalten wollen. Aber bei jedem war dann doch irgend ein Tool nicht kompatibel oder eine Schnittstelle. Das Ende vom Lied: Viel Aufwand und trotzdem lies sich NTLM nicht abschalten. Da mache ich mir aktuell auch keinen Aufwand beim PRTG.
Ja, faktisch alle Industriebetriebe, wo ältere SPS Industrie-PCs, Visus und Steuerungen mit WinXP (Embedded), Win 7, 8, 2012 – vor drei Jahren legte ich sogar noch einen NT4 PC still) Ihr Zeugs z.B. via SMB mit einem AD austauschen. Oder noch schlimmer: Überall dort, wo fahrlässigerweise der Produktionsbetrieb in einem AD integriert wurde und z.B. Anlagen-Software zur Auswertung auf den Office-Arbeitsplätzen installiert ist, während die Daten selbst weiterhin in der Produktion liegen. Die eingesetzte Software ist da teilweise auf dem technischen Stand von vor 25 Jahren.
Diese müssen nun Ihre Netzwerkstruktur einmal anpacken und absichern.
Mich freut's – genau für sowas bin ich käuflich ;-)
Naja, Windows unterstützt seit Windows 2000 Kerberos.
Bei Windows 2000 allerdings nur RC4 und DES.
Bei allen Clients ab Windows XP SP1 und Servern ab Server 2003 gibt es also im Grunde keinen Grund, NTLM weiter zu nutzen.
Das Auditing von NTLM geht ab Server 2008 R2.
Es wurde vor ca. 3 Jahren bei Systemen, die noch ESU erhalten haben, mit einem Patch nachgerüstet.
Nur einige wenige im MS-Artikel genannte Events sind erst ab Windows 11/Server 2025 vorhanden.
Das Auditing habe ich damals aktiviert und nachdem ich über längere Zeit keine NTLM-Events gefunden habe, habe ich NTLM komplett deaktiviert.
Irgendwelche Probleme sind nicht aufgetreten.
Ich erwische in unserem Betrieb im Monitoring noch zahlreiche auf Linux basierende Appliances und Anwendungen dabei, sich mit NTLMv2 am AD anzumelden. Auch z.B. die Checkpoint-FW… Ich versuche schon seit Jahren, das weg zu bekommen. Aber unsere Koriphaen aus den Fachbereichen schaffen das nicht. :(
Ich hoffe daher dass der Hausmeister einfach nur nicht genau genug gelesen hat, und in wirklichkeit nur NTLMv1 gemeint ist. Das ist zumindestens weg.
Es ist tatsächlich komplett NTLM, wie ich jetzt im verlinkten Artikel nachzulesen ist. Aber die "gute" (traurige!) Nachricht ist, es wird nicht entfernt, sondern lediglich abgeschaltet und man kann es wieder aktivieren. Ob das genug Druck erzeugt? Einen Server 2022 (DC) kann man noch bis 2032 sicher betreiben.
"Mich freut's – genau für sowas bin ich käuflich ;-)"
Du auch? :-D
die Network Level Authentication macht NTLM, jede Authentifizierung mit LAPS gegen eine lokale Instanz macht NTLM, die Cloud only/Workgroup Systeme machen NTLM… von Altlasten haben wir noch gar nicht gesprochen.
ich würde mich freuen, wenn MS hier was umbauen würde.
NLA geht auch mit Kerberos.
Das neue LAPS, eingeführt 2023 ab Server 2016 kann Kerberos.
… wenn du die NLA abschaltest :-)
LAPS: Hast du einen Artikel?
LAPS kann kein Kerberos. Du authentifizierst dich mit einem Lokalen Konto gegen die lokale LSA.
Solange man brav DNS pflegt und fqdn für Zugriffe verwendet, kann man fast alles was von MS kommt, zu Kerberos zwingen. Manchmal müssen SPNs selber erstellt werden oder Durch GUI gesetzte Werte korrigiert werden weil Windows sie abschneidet auf computernamen reduziert.
Eine Herausforderung sind vor allem netzlaufwerkverbindungen/drucker. da müssen alle alten gelöscht werden die nicht per fqdn verbunden wurden. am besten gleich inkl. treiber. dann alle hardening massnahmen umsetzen, einmalig per admin mit fqdn verbinden (drucker, wegen treiber), dann den user für die drucker am besten die printserver gleich mit fqdn vorlegen.
Das schöne ist, man kann NTLM normal domänenweit verbieten. Für zwingend notwendiges NTLM verwendet man dann nur lokale Konten auf dedizierten Maschinen.
"Einen Server 2022 (DC) kann man noch bis 2032 sicher betreiben." -> nicht solange NTLM noch aktiv ist.
Stimmt auch wieder. Aber das mit dem direkten Antworten auf einen bestimmten Beitrag musst du noch ein bisschen üben!
Da hast Du leider absolut Recht. Bin aber lernfähig.
naja ich glaube NTLM ist nicht tot zu bekommen.
Baut mal ein Domain trust und dann wundert ihr euch das kein Kerberos geht. Und da gibts es noch viel mehr was nicht implementiert ist.
Ich würde es so gern los werden.
Hab neulich mit Samba herum gespielt. Da gibts gar keine unidirektionale trusts… auch nicht schön.
Am Ende landen die meisten dann bei der MS Cloud mit Entra weil es so einfach zu verwenden ist und alles schon für Windows Clients vorbereitet ist.
ich bin gespannt wie es mit NTLM weiter geht.
Man könnte auf die Idee kommen, dass genau das von MS erreicht werden will…
Ich habe mir das Thema aus aktuellem Anlass selbst genauer angeschaut, weil NTLM ja nun wirklich auf der Abschussliste steht. Dabei bin ich über die Aussage gestolpert, dass PRTG bei WMI grundsätzlich nur NTLM könne.
In meiner Umgebung habe ich das bewusst nicht theoretisch, sondern praktisch geprüft: WMI-Sensoren aus PRTG ausgelöst und parallel auf dem DC die Security-Events (4624) ausgewertet. Die Logons des PRTG-Kontos tauchen dort bei mir mit AuthenticationPackageName = Kerberos und LogonProcessName = Kerberos auf, NTLM-Einträge für dieses Konto finde ich keine.
Mein Eindruck aus dieser Messung:
PRTG scheint Kerberos bei WMI nicht aktiv zu erzwingen und dokumentiert es auch nicht als offiziell unterstützte Option – nutzt es aber offenbar durchaus, wenn die Windows-Umgebung sauber passt (DNS/FQDN, Domänenmitglied, Maschinen-/Servicekonto, SPNs etc.). In anderen Setups dürfte man dann schnell auf NTLM zurückfallen, was den gegenteiligen Eindruck erklärt.
Heißt für mich: stark umgebungsabhängig – aber „auf keinen Fall Kerberos" deckt sich zumindest nicht mit dem, was ich hier konkret in den DC-Logs sehe
"Kerberos authentication for Windows systems monitoring" steht bei Paessler auf der Roadmap unter "Development"
https://uservoice.paessler.com/discovery/roadmap/20630
Ist hier von NTLM Version 1 und 2 die Rede oder nur Version 1?
Ich benötige NTLMv2 für RDP von Geräten die nicht in der Domäne sind, insofern wäre das recht ungünstig.
Genau das sind die spannenden Fragen, wie MS die Workgroup Situationen abfangen will
NTLM v1 und v2!
Aber wenn du es brauchst, kannst du es ja wieder aktivieren.
Und bis minestens 2034 (aktuelles Supportende von Server 2025) bleibt es ja aktivierbar.
Dieselbe Strategie wie bei SMB1.
Der Default wurde geändert, Aktivieren bedingt eine bewußte Bedienhandling. Damit ist die Verantwortung umgekehrt.
Dafür ist dann LocalKDC gedacht, quasi ein simpler KDC der lokal läuft und mit lokalen Accounts funktioniert. Systeme müssen dann natürlich trotzdem per FQDN angesprochen werden.
Wird jetzt hier im Artikel NTLMv1 und NTLMv2 vermischt?
Gehe ich von der GPO "Computer Configuration – Policies – Windows Settings – Security Settings – Local Policies – Security Options" -> "Network security: LAN Manager authentication level" gibts hier nichts strengeres als "Send NTLMv2 response only. Refuse LM & NTLM".
Oder bedeutet das im Umkehrschluss, dass man diese GPO wieder auf "Not Defined" stellen kann und stattdessen "Network security: Restrict NTLM" für incoming und outgoing aktiviert? Funktioniert in der Domäne dann weiterhin alles sauber? (via Kerberos?)
Das ist die LAN Manager Authentifizierungs Ebene mit der du LM/NTLMv1 loswerden kannst.
NTLM pauschal wird mit unter Netzwerksicherheit/NEtwork Security: NTLM
* Richtlinien konfiguriert.
Also, ob du zB nur monitorst, es für Alle Domänenkonten verweigerst oder eben auch Lokale, oder ob es Ziel Server als Ausnahme gibt, mit denen NTLM trotz "deny" komminiziert werden kann, nach Definition in der LanManager Auth Ebene.
Wenn die genannte Richtlinie "not defined" ist, dann nimmt das System den System Default Wert, der aktuell noch alles erlaubt.
Die AuthEbene ist irrelevant, wenn incomming und outgoing verweigert ist und es keine Server ausnahmen oder RemoteServer ausnahmen gibt.
Mich erschreckt, dass NTLM in manchen Windows-Komponenten noch hardcoded ist, 26 Jahre nach Einführung von Kerberos. Gut, dass sie das mal anpacken. Ich bin mal gespannt, wie sie die Kerberos-Authentifizierung an Hosts realisieren, die nur per IP-Adresse angesprochen werden können. Das dürfte doch garnicht funktionieren?
ab Windows 10 und Server 2016 aufwärts:
https://learn.microsoft.com/de-de/windows-server/security/kerberos/configuring-kerberos-over-ip
Weil man immer wieder einmal Gegenteiliges liest.: NLA bei/für RDP braucht kein NTLM. Auch nicht, wenn der RDP-Client nicht in der Domäne ist.
Stolpersteine:
– In sgmentierten Netzen / VPNs nicht alle Ports für Kerberos definiert?!
– RDP-Host nicht "host.domäne.local"
– Username nicht "user@domäne.local"
Also keine Sorge – das funktioniert auch ohne NTLM.
LocalKDC und IAKerb werden da relevant, für Systeme ohne Domäne oder Clients dich keine direkte Sicht auf den AD haben.