Adieu NTLM - eine Leidensgeschichte?

Nach Monaten habe ich es nun endlich geschafft, mich von NTLM zu verabschieden.
U.a. war der Grund, dass es einem auf kurz oder lang sowieso nicht erspart bleibt (zum nachlesen).

Ja: es ist eine Leidensgeschichte. Aber ich möchte auf diesem Wege nun ein paar Tipps/Infos/Links bereitstellen, die dem ein oder anderen evt. hilfreich sind.

Part I - Logging:
Einfach abschalten spielt's nicht. Daher vorher logging aktivieren. Wie man das am besten macht, findet man auf zig Webseiten. Eine davon ist diese hier.
Wie man die "gewonnen" Logs nun auswertet bzw. wie man dann mittels ProcMon mehr ins Detail gehen kann, liefert MS selbst auf seiner Seite.
Zusätzlich kann auch das aktivieren des Kerberos Logging manchmal hilfreich sein.

Part IIa - Fehlerbehebung - Printserver:
Konnte bei mir zahlreiche Kerberosanfragen vom Printserver aus zu den DCs feststellen. Ist ein Microsoft-Bug, der sich durch setzen eines RegKeys aber beheben lässt.

Part IIb - Fehlerbehebung - CNAME:
Hatte bei einigen Server CNAMEs hinterlegt (u.a. beim Printserver). Das funktioniert nun so mit Kerberos nicht mehr.
Also CNAME entfernen, die Regkeys DisableStrictNameChecking und OptionalNames löschen und alternativen Namen mittels netdom setzen. Auch SPNs sind bei Kerberos dein Freund.

Part IIc - Fehlerbehebung - RDS-Farm:
Microsoft liefert zwei Anleitungen bei Verwendung von Kerberos in Verbindung mit einer RDS-Farm. Nur leider ist zumindest eine davon outdated und funktioniert nicht mehr (nachzulesen hier).
Sofern mehr als ein Terminalserver verwendet wird, habe ich ehrlich gesagt keine Lösung gefunden.
Ist nur ein Session Host in Verwendung, kann ein Workaround über netdom angewendet werden.

Part IId - Fehlerbehebung - RDS-Farm:
Konnte regelmäßig zu Zeiten, wo definitiv kein User mehr am System angemeldet war, ausgehende NTLM-Verbindungen zu cifs/DC01.domain.local/domain.local@domain.local feststellen. Parallel dazu war immer ein Kerberos Fehler "0x6 KDC_ERR_C_PRINCIPAL_UNKNOWN" im Log zu sehen.
Es waren aber keinerlei Einschränkungen sonst feststellbar. Somit ignorierte ich einfach diesen Fehler.

Part IIe - Fehlerbehebung - RD Connection Broker:
Alle paar Wochen konnte ich zahlreiche NTLM-Verbindungsversuche von tssdis.exe feststellen.
Nach einiger Recherche konnte ich dann eruieren, dass der Fehler durch das aktualisieren des Maschinenkennworts des Connection Brokers ausgelöst wird.
Abhilfe schafft nur ein Neustart des tssdis Dienstes.
Zitat: the issue was resolved by creating a scheduled task on the connection broker to restart the tssdis service, with a trigger on NETLOGON event ID 5823. (Begin the task: On an Event).

Part IIf - Fehlerbehebung - DFS:
Zugegebenermaßen handelt es sich dabei um einen reinen Schönheitsfehler: ein Zugriff auf \\domain.local erfolgt über NTLM. \\domain.local\sysvol erfolgt aber korrekt über Kerberos. Weitere Details dazu finden sich hier auf administrator.de
Eine Lösung dafür gibt es allerdings nur, wenn man nicht mehr als einen DC im Einsatz hat.

Part III - die Logging Krux
Als dann endlich keine unbekannten Logeinträge mehr auftauchten, machte ich ernst und "deaktivierte" NTLM.
Sehr zu meiner Verwunderung tauchten aber dann plötzlich Logeinträge von blockierten NTLM-Verbindungen auf, die vorher während der reinen Loggingphase nicht ersichtlich waren.
So löste ein entsperren eines Win10-PCs nun plötzlich einen Logeintrag aus (Process: C:\Windows\System32\svchost.exe).
Nachdem aber scheinbar alles korrekt funktionierte, ignorierte ich diesen Fehler.
Somit hat @DerWoWusste recht behalten: "Das Windows-Eventlog ist NIE sauber. Das Rechner tadellos funktionieren und dennoch x Warnungen und zum Teil auch Fehler zeigen an x Orten ist normales Rauschen. Ich sehe keine Chance, das zu verhindern, so ärgerlich es auch scheint." (hier zum nachlesen)


By the way:
Wer dann immer noch Umgebungen findet, die unter Kerberos nicht funktionieren, kann diese - scheinbar - gerne an MS senden.

Auch ist eine sehr gute Zusammenfassung hier (auf Englisch) zu finden.