badger
Goto Top

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.

Content-Key: 43805707961

Url: https://administrator.de/contentid/43805707961

Printed on: April 22, 2024 at 16:04 o'clock

Member: DerWoWusste
DerWoWusste Mar 01, 2024 at 08:21:56 (UTC)
Goto Top
Ich kann von unserem vollzogenen NTLM-Exit noch lustige Details beisteuern:

Es gab Prozesse, die das Logging nicht erfasst hat, genau, wie Du es auch angedeutet hast: man aktiviert "Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers", das Log bleibt leer, man sperrt dann NTLM und siehe da, etwas, was man auch vorher täglich benutzt hat, was nicht im Log auftauchte, wird nun blockiert. Erste Sahne, da wird der Ausstieg wirklich kinderleicht gemacht! face-sad

Auch Microsoft hat in aktuellen Produkten hin und wieder noch NTLM vorgesehen: zum Beispiel in Server 2022 bei der WSUS-Rolle: diese bietet ja an, sich per E-Mail Reports schicken zu lassen. Deaktiviert man outgoing NTLM, kommt kein Report. Ich musste somit selbst einen Reportingtask erstellen.
Member: sysad
sysad Mar 02, 2024 at 11:23:02 (UTC)
Goto Top
Danke für die 'Leidensgeschichte'!

Das ist leider so dass man wenns drauf an kommt immer zu wenig oder die falschen Logs hat, wär ja auch zu schön.

Wir haben einige W2012 und W2019 Server in SOHOs (ohne DC und AD) mit 10-20 lokalen Arbeitsplätzen teilweise als NW-Client und teilweise als Terminalclient und mit ca. 5 Homeoffice Arbeitsplätzen. Der Fernarbeiter verbindet sich per VPN mit IPSec/L2TP mit dem Router im Büro und loggt sich dann mit MS Remote Desktop am Server ein und kriegt eine lokale Terminalsession.

Wie kann man in so einer Umgebung NTLM loswerden?
Member: DerWoWusste
DerWoWusste Mar 02, 2024 at 15:38:36 (UTC)
Goto Top
Member: sysad
sysad Mar 03, 2024 at 18:10:55 (UTC)
Goto Top
Ist es überhaupt nötig, in einer solchen Umgebung jetzt schon proaktiv NTLM abzuschaffen?

Wenn MS dann vielleicht in 'Server 2025' oder was auch immer NTLM abschafft, wird vielleicht alles anders: MS liefert gleich was mit mit dem man auch kleine Netze ohne AD/DC einfach aufbauen kann.
Member: DerWoWusste
DerWoWusste Mar 26, 2024 at 09:41:01 (UTC)
Goto Top
Und noch ein weiteres, offenbar von microsoft hausgemachtes Problem, in welches Terminalservernutzer nach NTLM-Verbot laufen, falls RemoteApps bereitgestellt werden: RemoteApp deployment ohne NTLM