NTLM Deaktivierung

Die Authentifizierung durch Windows Clients an Windows Servern erfolgt seit den ersten Windows Versionen per NTLM und hat mehrere Generationen durchlaufen. Aber alle Verbesserungen haben die Sicherheit aber nicht das eigentliche Funktionsprinzip verbessert und aus Kompatibilitätsgründen sind viele Umgebungen immer noch unsicher. Microsoft hat im Sommer 2024 aber angekündigt, dass in Windows Server 2025 und neueren Windows 11-Versionen jede Abhängigkeit von NTLM entfernt werden soll, so dass sie NTLM komplett deaktivieren können.

Diese Seite wird noch weiter geschrieben, wie die Deaktivierung von NTLM fortschreitet.

Vorarbeiten

Es gibt Umfelder, in denen NTLM weiter genutzt werden wird, weil es einfach keine anderen besseren Verfahren gibt. Kerberos funktioniert nur, wenn die Client auch ein Ticket bekommen und damit irgendwie den KDC erreichen können. Das ist im Homeoffice ohne VPN in der Regel nicht möglich. Selbst die Exchange Online Migration verbindet sich per NTLM mit dem lokalen MRSProxy. Innerhalb einer Firma könnte man aber schon überlegen, welche Dienste noch NTLM anbieten müssen und welche Clients auf NTLM-Challenges reagieren sollten. Auf NTLM MITM mit Edge / PIKABOT habe ich einige Gegenmaßnahme beschrieben. Ehe Sie aber NTLM komplett abschalten, sollten Sie die Sicherheit erhöhen, in dem Sie NTLMv2 erzwingen. Dazu gehört aber eine Bestandsaufnahme, wer aktuell sich wo und wie anmeldet.

Ein einfacher Weg ist es, einen Benutzer in die Gruppe "Protected Group" aufzunehmen.


Quelle: https://learn.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/protected-users-security-group#domain-controller-protections-for-protected-users

Damit werden zwar noch einige andere Schutzfunktionen aktiviert, aber er kann sich auch nicht mehr per NTLM anmelden. So können Sie recht einfach einen Benutzer nach dem Anderen prüfen lassen, ob NTLM erforderlich ist.

Eine andere Option besteht darin, über eine Gruppenrichtlinie die NTLM-Nutzung erst einmal auf wenigen Clients ausgehend zu unterbinden.

Anmeldeüberwachung aktivieren

Wenn Sie NTLM verstanden haben, dann stellt der Server dem Client eine Zufallszahl (Nounce) bereit, die der Client mit dem Hashwert des Kennworts verrechnet und dem Server zurücksendet. Dieser hat natürlich nicht das Wissen und sendet daher den gleichen Nounce und das Ergebnis zum Domain Controller, der die Rechnung mit dem bei ihm gespeicherten Hashwert durchführt. Wenn das Ergebnis identisch ist, dann bekommt der Server das "OK". Damit ist aber auch erklärbar, dass die Domain Controller alle NTLM-Anmeldungen verifizieren, die über Domainkonten erfolgen. Die DCs sehen allerdings nicht, wenn sich jemand auf einem System mit lokalen Anmeldedaten authentifiziert. Das ist in Firmen aber eher nicht der Fall. Wir können daher mit einem entsprechenden Eintrag diese Anmeldungen im Eventlog protokollieren lassen. Dazu aktivieren Sie die Überwachung für Anmeldungen am besten über eine Gruppenrichtlinie für alle Domain Controller.

Danach finden Sie im Eventlog (siehe TrackLoginEvents) die entsprechenden Einträge und können nachvollziehen, wo NTLM aktuell in welcher Version von welchem Client und Server genutzt wird.

Wenn Sie mögen, können Sie natürlich auch die fehlerhaften Anmeldungen und optional auch für alle Server aktivieren und zentral reporten und so möglichen Missbrauch früh zu erkennen oder im Falle eines Falles den Weg eines Angreifers nachverfolgen zu können

Im Eventlog finden Sie dann die entsprechenden Meldungen mit dem verwendeten Anmeldeverfahren. Eine manuelle Auswertung kann z.B. per Skript erfolgen. Wer solche Überwachungen dauerhaft nutzen möchte, sollte Sich über ein SIEM, Eventlog-Forwarding oder z.B. Advanced Threat Protection - ATP nachdenken.

Abschaltung vorbereiten

Sie können nie sicher sein, dass ihre Server alle schon Kerberos oder OAUTH unterstützen. Es gibt durchaus Server, die beides könnten aber durch Konfiguration auf NTLM festgelegt ist. Nur weil eine Webseite auf einem IIS läuft, ist sie nicht immer Kerberos-tauglich. Das kann schon Hostnamen scheitern, d.h. der Server heißt z.B. "Server5.msxfaq.de" aber ist unter https://intranet.msxfaq.de erreichbar. Ohne dass Sie den Hostnamen als SPN mit eintragen oder per CNAME umleiten, wird der Client vom KDC kein passendes Kerberos Ticket bekommen. Das gilt natürlich für viele andere Server und Dienste genauso.

Das Risiko bestehet dabei, dass der Server schon Kerberos anbietet und ein Client ein Kerberos-Ticket für einen SPN bekommt aber dann die Verbindung aus anderen Gründen doch nicht zustande kommt.

Hier müssen Sie also planen, prüfen und testen. Es könnte auch andere Gründe geben, warum Negotiate für einige Dienste nicht funktioniert und Sie mit Basic, OAUTH oder Formularanmeldung arbeiten müssen: Kerberos erfordert, dass der Client einen KDC erreicht, um sich ein Ticket zu beschaffen. Das funktioniert natürlich nicht über Clients im Internet, die z.B. über RPC over HTTP/Outlook Anywhere auf ihr Postfach zugreifen müssen.

Im November 2024 habe ich auf einem Exchange 2019CU14 extra noch einmal die Standardeinstellung nachgeschaut:

Selbst die Dokumentation von Microsoft schreibt dazu:


Quelle: RPC over HTTP Deployment Recommendations
https://learn.microsoft.com/en-us/windows/win32/rpc/rpc-over-http-deployment-recommendations  

Und noch mal auf:


Quelle: https://learn.microsoft.com/en-us/exchange/outlook-anywhere-exchange-2013-help

Die Aussage ist natürlich nur die halbe Wahrheit, denn es ist nicht ausschließlich eine Frage des Servers, welche Anmeldung angeboten wird. Gerade Outlook Anywhere wurde mit Exchange 2013 gerne genutzt, um Benutzern im Homeoffice oder auf Reisen ohne VPN eine Outlookverbindung zu ermöglichen.

Allerdings kann ein Client "draußen" ohne Verbindung zum Domain Controller (KDC) auch kein Kerberos-Ticket bekommen und damit muss er OAUTH, BasicAuth oder eben doch NTLM nutzen. Das könnte ein Blocker bei der Abschaltung von NTLM sein.

Outlook Anywhere kann aber sehr wohl auch Negotiate, wie Microsoft selbst hier beschreibt:


https://learn.microsoft.com/de-de/exchange/architecture/client-access/kerberos-auth-for-load-balanced-client-access

Exchange ist nur ein Beispiel, dass es Server geben kann, die von sich aus gar kein Kerberos anbieten oder unterstützen oder erst die Konfiguration angepasst werden muss. Dazu gehört auch Exchange RPC/HTTP.


Quelle: https://learn.microsoft.com/en-us/windows/win32/rpc/rpc-over-http-deployment-recommendations

Denken sie daran, dass die Aktivierung von Kerberos aus dem Server nur die halbe Miete ist. Sie müssen im Active Directory auch den "Service Principal Name" eintragen.

Prüfen

Wenn Sie NTLM abschalten wollen, dann muss es alternative Anmeldeverfahren geben. Eigentlich sind dann Kerberos oder OAUTH angesagt, wenn Sie keine Anmeldung per "BasicAuth" oder "Formulare" nutzen wollen. Die Nutzung von NTLM können Sie nun natürlich auf dem Client und/oder dem Server abschalten.

Wenn Sie es auf dem Server abschalten, dann betrifft es direkt alle Clients und das ist ein großes Risiko. Schon allein das Angebot von Kerberos kann zu ersten Störungen führen wenn ein Client Kerberos versucht aber es nicht gelinkt.

Da ist es unkritischer, erst einmal auf ausgewählten Test-Clients die Anmeldung mittels Kerberos zu prüfen. Wenn der Zugriff nicht über den FQDN des Servers geht, können Sie temporär ja eine anderen FQDN mit passendem SPN für einen Testzugang nutzen. Damit stören Sie dann nicht die regulären Benutzer.

Erst wenn Sie die Funktion per Kerberos von Clients für die verschiedenen Szenarien verifiziert haben, aktivieren Sie dann Kerberos für die produktiven FQDNs mit einem passenden SPN. Aber dem Moment können und werden dann auch alle Clients die Anmeldung per Kerberos einer Anmeldung per NTLM vorziehen. Sie können aber nicht sicher sein, dass dies alle Clients können und auch tun.

Ehe Sie also NTLM abschalten, sollten Sie die Anmeldeprotokolle auf die verschiedenen Anmeldungen überprüfen und klären, wer sich immer noch per NTLM anmeldet. Für einen Windows Dateiserver können Sie als Client z.B. angeben, dass NTLM explizit nicht genutzt wird.

NET USE \\server\share /BLOCKNTLM
New-SmbMapping -RemotePath \\server\share -BlockNTLM $true

Für andere Dienste, z.B. den IIS könnten Sie mit Fiddler oder im Chromium-Debugger anhand des "Authorization"-Headers nachschauen, welche Anmeldeverfahren genutzt werden.

Abschalten auf Clients

Gehen wir davon aus, dass die Server Kerberos anbieten, die Übertragungsnetzwerke, Firewalls, ProxyServer, VPNs korrekt konfiguriert sind, damit der Client auch ein Kerberos-Ticket vom KDC bekommen und sich anmelden können, dann sollten sie nicht direkt auf dem Server die Anmeldung per NTLM unterbinden. Das ist zwar auch ein wichtiger und zur Erhöhung der Sicherheit notwendiger Schritt, aber er kommt erst an übernächster Stelle.

Die Clients sind auch gefährdet, denn sie könnten sich ja bei Servern anmelden, die nicht unter ihrer Kontrolle sind und dort per LM/NTLM ihre Anmeldeinformationen "verlieren". Daher ist es bei der Abschaltung von NTLM genauso wichtig, dass dies auf den Clients erfolgt.

Die Abschaltung von NTLM auf dem Client alleine ist natürlich nur ein Teil der Lösung.

Aber der Vorteil beim Client ist, dass man stufenweise vorgehen kann. Sie beginnen mit ein paar Client und rollen die Richtlinien nach und nach auf weitere Clients aus. Idealerweise nutzen sie dazu ihre Gruppenrichtlinien oder Softwareverteilung.

In den Gruppenrichtlinien gibt es einen Eintrag "Network Security: Restrict NTLM: NTLM authentication in this domain".

Hier können Sie sehr umfangreich die Nutzung von NTLM kontrollieren und über die GPO-Zuweisung auf OUS oder sogar einzelne Computer steuern. Kontrollieren Sie auf jeden Fall auch noch einmal individuelle Einstellungen für Applikationen, z.B. LANMAN-Server oder Workstation

In einer Intune-Richtlinie können Sie z.B. für Outlook als auch für RPC/HTTP und andere Produkte die vom Anwender nutzbaren Authentifizierungsverfahren steuern.

 

Es gibt also leider keinen "globalen Schalter" auf einem Windows Client, der eine Anmeldung per NTM unterbindet aber die meisten Produkte werden durch die Einstellungen für das Betriebssystem gesteuert, da Sie die Windows-Bibliotheken nutzen.

Abschalten auf Servern

Der zweite Teil der Abschaltung ist die Konfiguration der Server. Auf dem Abschnitt "Abschaltung vorbereiten" habe ich schon beschrieben, dass Sie vor der Abschaltung von NTLM natürlich alternative Anmeldeverfahren aktivieren, konfigurieren und prüfen müssen. Wenn dann im darauffolgenden Schritt die Clients alle auf die alternativen Anmeldeverfahren umgestiegen sind, können Sie ihre Sicherheit erhöhen, indem Sie die schwachen oder unerwünschten Anmeldeverfahren auf dem Server deaktivieren.

Auch hier hängt es vom Service an, auf den Clients mit Authentifizierung zugreifen. Bei einem Windows SMB-Server, der einfach Dateien als Dateiserver zur Verfügung stellt, sind es die SMB/NTLM-Optionen im Betriebssystem.

Beim IIS können Sie die Authentifizierung pro virtuellem Verzeichnis steuern. Meist sind "Negotiate" und "NTLM" in der folgenden Reihenfolge aktiviert.

Sie können hier NTLM entfernen aber das ist nicht korrekt, denn auch in "Negotiate" steckt NTLMv2 mit drin. Um sicher zu sein, müssten sie hier auch Negotiate durch "Negotiate:Kerberos" ersetzten, damit auch nur Kerberos angeboten wird.

Weitere Links