NTLM abzuschalten ist kein einzelner Gruppenrichtlinien-Schalter, sondern ein Migrationsprojekt. Wer in einer produktiven Active-Directory-Umgebung direkt auf „Deny all“ geht, riskiert Ausfälle bei Fileshares, alten Anwendungen, Management-Tools, Service Accounts oder Systemen, die Kerberos wegen DNS- und SPN-Problemen nie korrekt verwendet haben.
Der bessere Ansatz beginnt mit Sichtbarkeit. Microsoft hat die NTLM-Auditing-Funktionen in Windows 11 24H2 und Windows Server 2025 deutlich erweitert. Administratoren können damit besser erkennen, welche Anwendung oder welcher Dienst NTLM initiiert und aus welchem Grund der Fallback erfolgt.
Phase 1: NTLM messen, bevor etwas blockiert wird
Zuerst sollten Domain Controller, kritische Server und ausgewählte Clients NTLM-Aktivität protokollieren. Das Ziel ist eine belastbare Liste: Quelle, Ziel, Dienst, Anwendung, Häufigkeit und geschäftliche Relevanz. Einzelne manuelle Administrator-Anmeldungen sind anders zu bewerten als ein Produktionsdienst, der rund um die Uhr NTLM verwendet.
Wichtig ist auch die zeitliche Dimension. Ein Audit über wenige Stunden übersieht Monatsjobs, Backup-Prozesse, selten genutzte Administrationswege oder Disaster-Recovery-Abläufe. Für produktive Umgebungen ist eine ausreichend lange Beobachtungsphase sinnvoll, bevor Blockierregeln verschärft werden.
Phase 2: Kerberos-Abhängigkeiten reparieren
Viele NTLM-Fälle verschwinden, sobald Kerberos wieder technisch möglich ist. Typische Ursachen sind fehlende oder doppelte Service Principal Names, Zugriffe über IP-Adressen, ungeeignete DNS-Aliase, falsche Namensauflösung, nicht synchronisierte Zeit oder Anwendungen, die NTLM direkt anfordern.
Deshalb sollten Administratoren nicht nur „NTLM ersetzen“, sondern die eigentliche Ursache korrigieren. Bei SMB und SQL Server ist beispielsweise wichtig, dass Clients den richtigen Hostnamen verwenden und der Dienst mit einem passenden SPN erreichbar ist. Bei Webanwendungen müssen Integrated Authentication und Delegation sauber geplant werden.
Phase 3: Schutzmaßnahmen vor dem vollständigen Blockieren
Bevor NTLM komplett verschwindet, sollte die Umgebung bereits gegen typische Missbrauchsszenarien gehärtet sein. Dazu gehören SMB Signing, Credential Guard, eingeschränkte lokale Administratorrechte, Protected Users beziehungsweise getrennte privilegierte Konten sowie eine saubere Segmentierung zwischen Clients, Servern und Management-Zonen.
Windows Server 2025 bietet zusätzlich NTLM Blocking für SMB. Damit kann ein besonders relevanter Angriffsweg gezielt reduziert werden, ohne sofort alle denkbaren NTLM-Szenarien im gesamten Unternehmen zu blockieren.
Phase 4: Pilot statt Big Bang
Die Durchsetzung sollte zuerst auf klar abgegrenzte Systeme angewendet werden: Testumgebung, IT-Arbeitsplätze, moderne Member Server oder eine ausgewählte Applikationsgruppe. Nach jeder Stufe müssen Funktion, Event Logs und Helpdesk-Rückmeldungen ausgewertet werden.
Ein sauberer Pilot beantwortet drei Fragen: Welche Systeme brechen wirklich? Welche NTLM-Abhängigkeiten waren im Audit nicht sichtbar? Und welche Ausnahmen sind technisch begründet statt nur historisch gewachsen? Erst wenn diese Fragen beantwortet sind, folgt die nächste Welle.
Phase 5: Enforcement mit dokumentiertem Rollback
Für jede Enforcement-Stufe sollte ein Rollback existieren. Das bedeutet nicht, dass man dauerhaft zurückweichen will. Es bedeutet, dass ein geschäftskritischer Fehler kontrolliert behoben werden kann, ohne unter Zeitdruck unsichere Ad-hoc-Ausnahmen zu erzeugen.
Besonders aktuell: Microsoft plant für Oktober 2026, den Standard für bestimmte NTLMv1-abgeleitete Anmeldeinformationen in Windows Server 2025 von Audit auf Enforce zu verschärfen, sofern die entsprechende Einstellung nicht explizit konfiguriert wurde. Unternehmen sollten deshalb jetzt prüfen, ob ihre Altlasten noch unbemerkt von diesen Mechanismen abhängen.
Was am Ende erreicht sein sollte
Eine reife Umgebung hat NTLM nicht nur „deaktiviert“, sondern die Gründe für NTLM beseitigt. Kerberos funktioniert zuverlässig, SPNs sind dokumentiert, DNS ist konsistent, SMB ist gehärtet, technische Konten sind kontrolliert und verbleibende Ausnahmen sind nachvollziehbar. Genau dann wird Abschaltung zu einer Sicherheitsverbesserung statt zu einem Betriebsrisiko.
Fazit
Der Weg weg von NTLM ist ein hervorragendes Beispiel dafür, dass Security und Betrieb zusammengehören. Audit liefert Transparenz, Kerberos-Bereinigung beseitigt Ursachen, Piloten reduzieren Risiko und Enforcement schafft am Ende eine messbar kleinere Angriffsfläche. Wer 2026 noch wartet, wird durch kommende Windows-Änderungen zunehmend unter Zeitdruck geraten.
Quellen und weiterführende Hinweise
Microsoft Support: NTLM auditing enhancements.
Microsoft Support: Upcoming NTLMv1 changes.