Warum NTLM selten ein Schalter ist
NTLM ist in vielen Umgebungen nicht absichtlich designt, sondern über Jahre übrig geblieben: alte Appliances, Scanner, Fileserver, Dienstkonten, Legacy-Webanwendungen. Wer es pauschal blockt, findet die Abhängigkeiten oft erst durch Ausfälle.
Der bessere Weg ist nüchtern: messen, Besitzer finden, reduzieren, dann blockieren.
Reihenfolge im Projekt
- NTLM-Auditing auf Domain Controllern aktivieren.
- Eingehende NTLM-Nutzung auf Servern sichtbar machen.
- NTLMv1 konsequent identifizieren und zuerst entfernen.
- Ausnahmen nur mit Owner, Ablaufdatum und Zielmaßnahme führen.
- Kerberos-Fähigkeit prüfen: SPNs, DNS, Zeit, Delegation, Dienstkonten.
Was nicht vergessen werden darf
NTLM-Reduktion ist kein reines GPO-Thema. Häufig liegen die Blocker in Applikationskonfiguration, falschen SPNs, IP-basierten Zugriffen oder fehlenden Service-Account-Konzepten.
Was dadurch besser wird
- Alte Authentifizierung wird sichtbar und kann aus kritischen Pfaden entfernt werden.
- Kerberos wird wieder zum geplanten Zielbild statt zur zufälligen Ausnahme.
- Relay- und Credential-Themen verlieren Reichweite, wenn NTLM weniger oft erreichbar ist.
Wo es weh tun kann
- NTLM-Abhängigkeiten sitzen oft in Anwendungen, Appliances oder IP-basierten Zugriffen, nicht nur in Windows-Policies.
- Zu schnelles Blocken verursacht Ausfälle, die schwer einem Owner zugeordnet werden können.
- Permanente Ausnahmen verhindern, dass das Risiko wirklich sinkt.
Checks vor dem Rollout
- Welche NTLM-Nutzung kommt von Clients, Servern und Servicekonten?
- Welche Fälle sind NTLMv1 und müssen zuerst weg?
- Welche SPNs, DNS-Namen oder Dienstkonten verhindern Kerberos?
- Welche Ausnahme läuft wann aus?
Kurz gesagt
NTLM verschwindet nicht durch Wunschdenken. Ein gutes Projekt macht Nutzung sichtbar und baut Legacy Schritt für Schritt aus dem Betrieb heraus.