Anleitung zum vollständigen Entfernen von NTLM aus Ihrer Umgebung

Mit dem Ende des Windows 10-Lebenszyklus wird die NTLM-Authentifizierung abgeschafft. Erfahren Sie in dieser Schritt-für-Schritt-Anleitung, wie Sie die NTLM-Nutzung erkennen und verhindern.
Silverfort Bild
Legacy-Infrastruktur (1)

Executive summary

Die Eliminierung von NTLM aus einer Unternehmensumgebung ist eine große Herausforderung. Es ist tief in vielen Infrastrukturen eingebettet, und in einigen Fällen sind kritische Legacy-Anwendungen immer noch davon abhängig. Der Ersatz dieser Anwendungen kann unrealistisch erscheinen, und das ist seit Jahren der Grund NTLM blieb im Einsatz. Doch die Realität sieht anders aus: Die meisten Organisationen benötigen NTLM nicht wirklich, und das größere Hindernis besteht darin, dass NTLM-Aktivitäten innerhalb Active Directory. Diese Schwierigkeit nimmt mit zunehmender Skalierung der Umgebung nur zu. 

Unter Berücksichtigung der Windows 10 Lebensende, zusammen mit der Ankündigung von Microsoft, NTLM als Teil davon zu veralten, ist dieses Problem wieder aufgetaucht. Unternehmen müssen sich fragen: Wie werden wir ohne NTLM arbeiten? AD-Authentifizierungund welche Schritte sollten wir jetzt unternehmen, um uns vorzubereiten? 

NTLM muss nicht unbedingt eine Tatsache sein – es kann geändert werden. Dieser Leitfaden erklärt, wie NTLM funktioniert in Active Directory, warum die schrittweise Abschaffung schwierig sein kann, und bietet einen praktischen Plan, mit dem Sie die NTLM-Nutzung in Ihrem Unternehmen erkennen und eliminieren können.

Teil 1: Wie funktioniert NTLM?

NTLM (NT LAN Manager) ist eines der älteren Authentifizierungsprotokolle von Microsoft, das ursprünglich für frühe Windows-Netzwerke entwickelt wurde. Es wurde entwickelt, um Benutzern den Nachweis ihrer Identität zu ermöglichen, ohne ein Kennwort im Klartext senden zu müssen. Stattdessen wurde ein Challenge-Response-MechanismusWährend dies in den 1990er Jahren effektiv war, gilt es nach heutigen Maßstäben als veraltet und unsicher.  

Der NTLM-Authentifizierungsprozess folgt einem dreiteiligen Nachrichtenaustausch zwischen Client, Server und Domänencontroller: 

  1. NTLM-Verhandlung 
    Der Client leitet die Authentifizierung ein, indem er eine „Negotiate“-Nachricht an den Server sendet. Diese Nachricht enthält Details zu den Fähigkeiten des Clients, beispielsweise welche NTLM-Versionen er unterstützt. 
  1. NTLM-Herausforderung 
    Der Server antwortet mit einer „Challenge“-Nachricht, die eine zufällig generierte 16-Byte-Nonce (die Challenge) enthält. Dadurch wird sichergestellt, dass Authentifizierungsversuche nicht einfach wiederholt werden können. 
  1. NTLM-Authentifizierung 
    Der Client weist nun seine Identität nach, indem er unter Verwendung des gespeicherten Passwort-Hashs eine Antwort generiert. 
  • Der entscheidende Schritt: die Der Client berechnet die NTLM Challenge Response gemäß den Kriterien des Servers (z. B. NTLMv1 oder NTLMv2). 
  • Bei NTLMv1 verschlüsselt der Client die Challenge mit DES, einem schwachen Verfahren, das leicht durch Brute-Force-Angriffe geknackt werden kann. 
  • Bei NTLMv2 fügt der Client zusätzliche Daten wie einen Zeitstempel und eine Client-Nonce hinzu, wodurch eine stärkere, aber immer noch unvollständige Antwort erzeugt wird. Der Client sendet diese Antwort in einer „Authenticate“-Nachricht an den Server zurück. 
  1. Akzeptieren oder ablehnen 
    In Active Directoryleitet der Server die Challenge und die Antwort an den Domänencontroller weiter. Der DC sucht den gespeicherten Passwort-Hash des Benutzers in Active Directoryführt die gleiche Berechnung durch und vergleicht die Ergebnisse. Wenn sie übereinstimmen, wird die Authentifizierung akzeptiert, andernfalls wird sie abgelehnt. 
Grundlegender NTLM-Authentifizierungsprozess

Obwohl Kerberos- ist seit langem die bevorzugte Authentifizierungsmethode in Active DirectoryNTLM ist immer noch weit verbreitet. Häufig greifen Anwendungen auf NTLM zurück, wenn Kerberos ausfällt. Dieses Fallback-Verhalten ist einer der Hauptgründe, warum die Eliminierung von NTLM schwierig ist: Administratoren sind sich möglicherweise nicht einmal bewusst, dass NTLM in ihren Umgebungen noch aktiv ist. 

Teil 2: Eliminieren Sie NTLM in Ihrem Unternehmen

Das Entfernen von NTLM ist keine einmalige Konfigurationsänderung – es ist ein Prozess, der Transparenz, Planung und sorgfältige Ausführung erfordert. Der Schlüssel liegt darin, zunächst zu verstehen, wo NTLM noch verwendet wird, dann die Abhängigkeit davon schrittweise zu reduzieren und es schließlich vollständig abzuschaffen. 

Schritt 1: Bestimmen Sie, welche Anwendungen NTLM verwenden

Man kann nicht beseitigen, was man nicht sieht. Der erste Schritt besteht darin, Erkennen Sie die NTLM-Nutzung in Ihrer Umgebung

Das manuelle Zuordnen von NTLM-Anwendungen ist keine leichte Aufgabe. Dazu müssen die Windows-Ereignisprotokolle – beispielsweise die Ereignis-IDs 4624 (erfolgreiche Anmeldung) und 4776 (NTLM-Authentifizierung) – durchsucht und NTLM-Überwachungsrichtlinien über die Gruppenrichtlinie aktiviert werden. Dies ist zwar möglich, aber zeitaufwändig und wird in großen Umgebungen noch komplexer. 

Stattdessen moderne Identity-Security-Lücken Mithilfe der Funktionen können Sie alle Instanzen der NTLM-Nutzung in Ihrer Umgebung in einer einzigen Ansicht zusammenfassen. 

Im Silverfort Plattform erstellen Sie wie folgt einen umfassenden Bericht aller Anwendungen, die NTLM in Ihrer Umgebung verwenden: 

1. Öffnen Sie die Registerkarte Authentifizierungsprotokolle 

2. Erstellen Sie einen NTLM-Protokollfilter 

  • Fügen Sie bei Bedarf weitere Filter hinzu (Zeitraum, Benutzer, Geräte usw.).
  • NTLMv1 kann direkt durch Anwendung des Risikoindikators gefiltert werden
Filter zu den Protokollen hinzufügen
Risikoindikator auf „Einschließen“ umschalten

3. Exportieren Sie den Bericht

  • Gruppieren Sie die Daten nach Ziel, um zu ermitteln, welche Anwendungen und Server noch NTLM verwenden
Wählen Sie „Ziel“ unter „Gruppieren nach:“
Exportierter Bericht aus dem Silverfort Lernumgebung
NTLMv1-Nutzung anzeigen in Silverfort ISPM

Es ist wichtig zu bedenken, dass der Client für die NTLM-Berechnung verantwortlich ist. Das bedeutet, dass die Erkennungsbemühungen nicht auf Anwendungsebene enden dürfen – Sie müssen auch identifizieren, welche Clients auf NTLM zurückgreifen. Um NTLM vollständig zu eliminieren, müssen Sie die Clients kontinuierlich überwachen und die Gründe für den Fallback ermitteln. In vielen Fällen geschieht ein Fallback, weil Kerberos nicht eingerichtet werden kann, beispielsweise aufgrund falsch konfigurierter Service Principal Names (SPNs) oder wenn ein Client eine Verbindung zu einer Ressource über eine IP-Adresse statt über einen NetBIOS- oder DNS-Hostnamen herstellt, wie es Kerberos erfordert. Sie müssen diese zugrunde liegenden Ursachen beheben, um zu verhindern, dass Clients standardmäßig auf NTLM zurückgreifen. 

Bei der Untersuchung von Kerberos-Authentifizierungsfehlern ist zu beachten, dass auf einen fehlgeschlagenen Kerberos-Versuch in den meisten Fällen unmittelbar eine erfolgreiche NTLM-Authentifizierung folgt. Dieses Verhalten erleichtert es NTLM, unbemerkt in der Umgebung zu verbleiben. Jeder Kerberos-Fehler sollte daher überprüft werden, um die zugrunde liegende Ursache zu ermitteln, sei es ein fehlender oder falsch konfigurierter Service Principal Name (SPN), die Verwendung von IP-Adressen anstelle von Hostnamen oder andere Implementierungsfehler. Ohne diese Untersuchung bleibt der NTLM-Fallback ungeprüft bestehen und untergräbt die Bemühungen, ihn zu beseitigen. 

So untersuchen Sie Kerberos-Fehler mit Silverfort:

1. Authentifizierungsprotokolle öffnen

2. Filter anwenden: IdP-Ergebnis: Verweigern, Protokoll: Kerberos

3. Analysieren Sie die Ergebnisse

Überprüfen Sie die fehlgeschlagenen Kerberos-Authentifizierungen und untersuchen Sie die Gründe für die Ablehnung
Wenn die Authentifizierung letztendlich erfolgreich war, wenden Sie einen Zielfilter für den beteiligten Server an
Fügen Sie Kerberos als zusätzlichen Protokollfilter hinzu, um festzustellen, ob auf den fehlgeschlagenen Kerberos-Versuch eine erfolgreiche NTLM-Authentifizierung folgte.

Schritt 2: Bewerten Sie das Risiko – NTLMv1 vs. NTLMv2

Nicht jede NTLM-Nutzung birgt das gleiche Risiko. Ein wichtiger Teil Ihres Eliminierungsplans ist die Unterscheidung zwischen NTLMv1 und NTLMv2. 

NTLMv1

NTLMv1 verwendet DES für seine Challenge-Response-Berechnung, was nach modernen Standards viel zu schwach ist. Angreifer können Rainbow Tables oder moderne GPU-basierte Brute-Force-Methoden verwenden, um NTLMv1-Antworten in Sekundenschnelle zu knacken. Aus diesem Grund sollte NTLMv1 in jeder Umgebung sofort blockiert werden. Eine fortgesetzte Zulassung setzt Benutzeranmeldeinformationen unnötigen Risiken aus. 

NTLM-Relais

NTLMv2

NTLMv2 verbessert die Sicherheit durch die Einführung von HMAC-MD5 und die Einbeziehung zusätzlicher Informationen in den Authentifizierungsaustausch. Eine wichtige Verbesserung ist die Verwendung von AV_PAIRS (Attribut-Wert-Paaren), die Daten wie den Zeitstempel des Clients, den Namen des Zielservers und Zielinformationen enthalten können. Diese Felder helfen beim Schutz vor einfachen Replay- und Relay-Angriffen, da die Antwort an einen bestimmten Server und Sitzungskontext gebunden ist. 

Der Schutz ist jedoch nicht vollständig. Wenn Angreifer die AV_PAIRS manipulieren oder entfernen können (z. B. in Konfigurationen, die keine Zielvalidierung erzwingen), sind Relay-Angriffe weiterhin möglich. In der Praxis bleibt NTLMv2 anfällig für Pass-the-Hash- und NTLM-Relay-Angriffe in Szenarien, in denen Signierung und Kanalbindung nicht erzwungen werden. 

AV_PAIRS in NTLMv2

Bei der Erstellung Ihres NTLM-Eliminierungsplans ist es wichtig, nach Risiko zu priorisieren. NTLMv1 sollte als unmittelbares Risiko betrachtet und unverzüglich blockiert werden, da seine Verwendung eine direkte und leicht ausnutzbare AngriffsflächeNTLMv2 ist zwar stärker, sollte aber nur als vorübergehende Maßnahme betrachtet werden. Es bietet besseren Schutz als NTLMv1, setzt Ihre Umgebung aber weiterhin Relay- und Hash-basierten Angriffen aus. In der Praxis bedeutet dies, zunächst NTLMv1 zu eliminieren und sich dann auf die systematische Reduzierung und schrittweise Abschaffung von NTLMv2 zu konzentrieren, bis NTLM vollständig entfernt ist. 

Schritt 3: Blockieren Sie NTLMv1 mit Gruppenrichtlinien und kennen Sie die Einschränkungen

Das Blockieren von NTLMv1 über Gruppenrichtlinien ist ein wesentlicher Schritt in jedem Eliminierungsplan. Mit der Richtlinie LMCompatibilityLevel (oder der entsprechenden Gruppenrichtlinie) können Sie Domänencontroller so konfigurieren, dass sie NTLMv1-Authentifizierungen ablehnen und nur NTLMv2 akzeptieren. Dies ist die empfohlene Basiskonfiguration für jeden Active Directory Umwelt. 

So aktivieren Sie die Gruppenrichtlinie: 

  1. Öffne Gruppenrichtlinien-Verwaltungskonsole (GPMC). 
  1. Navigieren Sie zu: Computerkonfiguration → Windows-Einstellungen → Sicherheitseinstellungen → Lokale Richtlinien → Sicherheitsoptionen 
  1. Suchen Sie die Einstellung: Netzwerksicherheit: LAN Manager-Authentifizierungsebene 
  1. Legen Sie den Wert fest auf: Nur NTLMv2-Antwort senden. LM und NTLM ablehnen 

Dadurch wird sichergestellt, dass Windows-Systeme angewiesen werden, nur NTLMv2-Antworten zu generieren und dass Domänencontroller NTLMv1-Authentifizierungen ablehnen. 

Es ist jedoch wichtig zu verstehen, dass diese Kontrolle allein möglicherweise keinen vollständigen Schutz bietet. In bestimmten Fällen können falsch konfigurierte Anwendungen trotz der Gruppenrichtlinieneinstellung weiterhin NTLMv1-Authentifizierungen erzwingen. Dies birgt das Risiko falscher Sicherheit: Administratoren glauben, NTLMv1 sei blockiert, während es in Wirklichkeit in der Umgebung aktiv bleibt. 

Eine detaillierte technische Erklärung, wie ein solcher Bypass funktioniert und warum er auftritt, finden Sie in meinem Blogbeitrag: NTLMv1-Bypass in Active Directory – Technischer Deep Dive

Meine aktuelle Empfehlung ist, NTLMv1 zu überwachen und zu eliminieren und, wenn möglich, eine risikobasierte Richtlinie für alle NTLMv1-Authentifizierungen zu erstellen, indem Silverfort. 

Risikobasierte NTLMv1-Richtlinie

Schritt 4: Prüfen, ob Anwendungen andere Authentifizierungsmethoden unterstützen

Ein häufiger Grund für die anhaltende Verwendung von NTLM in Umgebungen ist die Annahme, dass bestimmte Anwendungen nur mit NTLM funktionieren. In vielen Fällen ist dies jedoch nicht der Fall. Anwendungen können aufgrund von Fehlkonfigurationen, fehlenden Voraussetzungen oder einfach, weil Administratoren keine stärkeren Protokolle aktiviert haben, auf NTLM zurückgreifen. 

Bevor Sie eine Anwendung ersetzen oder außer Betrieb nehmen, prüfen Sie, ob sie bereits eine sicherere Authentifizierungsmethode unterstützt: 

  • Kerberos- – Die meisten modernen Windows-Anwendungen unterstützen die Kerberos-Authentifizierung, wenn die Service Principal Names (SPNs) korrekt konfiguriert sind. Viele NTLM-Abhängigkeiten lassen sich durch die Korrektur von SPNs oder die Sicherstellung, dass Clients über DNS-Hostnamen statt über IP-Adressen eine Verbindung herstellen, beheben. 
  • SAML, OpenID Connect (OIDC) oder OAuth – Webanwendungen und Cloud-Dienste unterstützen diese modernen Authentifizierungsstandards häufig entweder nativ oder durch Integration mit Identitätsanbietern (IdPs). 
  • Zertifikatbasierte Authentifizierung – Einige Unternehmensanwendungen ermöglichen die Anmeldung per Smartcard oder Zertifikat, sodass NTLM vollständig überflüssig wird. 

Bei der Bewertung von Bewerbungen: 

  • Suchen Sie nach neueren Versionen – Neuere Versionen haben möglicherweise NTLM-Abhängigkeiten gelöscht oder Unterstützung für moderne Identitätsprotokolle hinzugefügt. 
  • Dokumentation untersuchen – Viele Anbieter dokumentieren die Unterstützung von Kerberos oder föderierten Identitäten, diese wird jedoch häufig nicht genutzt. 
  • Überprüfen der Identitätskonfigurationen – Stellen Sie sicher, dass Ihre Anwendungen nach Möglichkeit in Ihren zentralen Identitätsanbieter integriert sind. 

Ein gutes Beispiel hierfür ist Microsoft SQL Server, wenn auf den Server mit dem offiziellen mssql-jdbc-Treiber zugegriffen wird. Auf den ersten Blick scheinen viele Bereitstellungen auf NTLM-Authentifizierung zu basieren. Tatsächlich unterstützt der Treiber jedoch vollständig Kerberos-Authentifizierung, vorausgesetzt, dass die Service Principal Names (SPNs) korrekt konfiguriert sind und der Client die Verbindung über einen DNS-Hostnamen statt einer IP-Adresse herstellt. Darüber hinaus beschreibt die Microsoft-Dokumentation, wie der Treiber explizit für Kerberos konfiguriert wird, um einen NTLM-Fallback zu vermeiden. In diesem Fall scheint NTLM unvermeidlich, doch durch Lesen der Dokumentation und Anpassen der Identitätskonfigurationen können Administratoren die Anwendung auf Kerberos umstellen und die NTLM-Nutzung reduzieren. 

Zudem hat auch Frau Erwägen Sie die Hinzufügung einer Multi-Faktor-Authentifizierung (MFA) wo immer möglich. Selbst wenn NTLM oder Kerberos weiterhin verwendet werden, reduziert MFA das Risiko erheblich Diebstahl von Anmeldeinformationen und Missbrauch. Silverfort erweitert den MFA-Schutz auf Authentifizierungsprotokolle wie NTLM und Kerberosund bietet eine zusätzliche Schutzebene für ältere und moderne Systeme. 

Schritt 5: Planen Sie das Herunterfahren NTLM-basierter Anwendungen

Nachdem Sie die NTLM-Nutzung identifiziert, NTLMv1 blockiert und wo möglich stärkere Alternativen aktiviert haben, besteht der letzte Schritt darin, Planen Sie die vollständige Abschaltung aller NTLM-basierten AnwendungenNur so können die mit NTLM verbundenen Risiken vollständig ausgeschlossen werden. 

Dieser Plan sollte Folgendes umfassen: 

Upgrades, Modernisierungen & TIPs – Wechseln Sie zu neueren Versionen von Anwendungen, die Kerberos oder moderne Authentifizierungsstandards unterstützen. Viele Anbieter haben in den letzten Versionen NTLM-Abhängigkeiten aufgegeben. 

Ersatzteile – Wenn Upgrades nicht möglich sind, prüfen Sie Ersatzoptionen, die zu Ihrer Identitätsstrategie passen. 

Stilllegung – Erstellen Sie einen klaren Zeitplan für die Außerbetriebnahme von Anwendungen, die ausschließlich von NTLM abhängen. 

Denken Sie außerdem daran Clients spielen eine Schlüsselrolle bei der NTLM-Eliminierung. Da der Client für die NTLM-Berechnung verantwortlich ist, müssen Sie kontinuierlich Monitor für Clients, die auf NTLM zurückgreifen und identifizieren Sie die Gründe dafür. Häufige Ursachen sind: 

IP-Nutzung anstelle von Hostnamen – Wenn ein Client eine Verbindung mit einer IP-Adresse statt mit einem NetBIOS- oder DNS-Hostnamen herstellt, kann Kerberos nicht verwendet werden, sodass ein Fallback auf NTLM erforderlich ist. 

Unsachgemäße Verwendung von Kerberos in Anwendungen – Einige Anwendungen implementieren Kerberos nicht korrekt und verwenden stattdessen standardmäßig NTLM. Ein gutes Beispiel für unsachgemäße Verwendung ist die KDC-Spoofing-Schwachstellen identifiziert von Silverfort in mehreren Produkten wie IBM QRadar (CVE-2019-4545), Cisco ASA und Palo Alto Networks PAN-OS , wo eine falsche Kerberos-Behandlung es Angreifern ermöglichte, Kerberos zu umgehen und erweiterte Zugriffsrechte zu erlangen (Lesen Sie hier mehr). 

Für eine kurze Übersicht dieser Schritte, die Sie mit Ihrem Team teilen können, Besuchen Sie hier.

Das Erkennen und Beheben dieser Probleme ist wichtig, um zu verhindern, dass NTLM unbemerkt wieder auftaucht, nachdem Sie geglaubt haben, es sei beseitigt. 

Die bevorstehende Windows 10 Lebensende und Microsoft Ankündigung der Abschaffung von NTLM Schaffen Sie die richtige Gelegenheit, diesen Shutdown-Plan mit umfassenderen IT-Modernisierungsprojekten abzustimmen. Betrachten Sie die NTLM-Eliminierung als Teil Ihrer Infrastrukturaktualisierung, sodass Ihre Umgebung zum Zeitpunkt der Abschaffung von Windows 10 nicht mehr von NTLM abhängig ist.

Um Ihr Team auf diese entscheidenden Veränderungen vorzubereiten, Schauen Sie sich unser On-Demand-Webinar an. Dort erkläre ich, wie man die NTLM-Authentifizierung aufdeckt und skalierbare Richtlinien entwickelt, die Ihnen dabei helfen, sie zu eliminieren.

Wir haben Identity Security auf ein neues Level gehoben.
Entdecken Sie, was möglich ist.

Vereinbaren Sie eine Demo und erleben Sie die Silverfort Identity-Security-Plattform in Aktion.