RDP ohne NTLM - Richtlinien und Verhaltensweisen zur Reduktion von NTLM

NTLM the never ending Story.

Mir wurde von jemandem zugetragen, das wir wohl noch die nächsten 50 Jahre mit NTLM leben werden. Ich halte das nicht für ausgeschlossen, ich hätte aus dem Bauch heraus 20 Jahre angegeben. Am Ende ist NTLM tief im System als Fallback verwurzelt und wir können nur die Menge der NTLM Pakete auf ein Minimum reduzieren.

Selbstverschuldetes NTLM

Der Aufbau einer RDP Verbindung über die IP Adresse oder auch der Zugriff auf den UNC Pfad \\IP-Adresse per SMB verwendet NTLM, statt Kerberos. Ein klares Eigentor. Lasst das sein! Der Grund ist, das das System anhand der IP nicht ermitteln kann zu welcher Domäne das System gehört, sodass Kerberos genutzt werden kann. Es geht davon aus, es ist ein Workgroup System und dort steht nur NTLM zur Verfügung.

Ihr könnt den Hostnamen verwenden, wenn dieser über die DNS Suffixe einem AD zugeordnet werden kann, in derselben Domäne wie der Client steht, wo das primäre Suffix automatisch angehangen wird oder gleich den FQDN des Ziel verwenden, um Kerberos zu nutzen.

Für Kerberos benötigt es eine Auflösung der Zugehörigkeit zu einer Domäne oder einen SPN (Service Principle Name). Mit Server 2016 können auch Service Principal Names für IP Adressen Adressen gesetzt werden und dann Kerberos statt NTLM zur IP genutzt werden. Manchmal benötigt es das, weil es technisch auch nicht anders möglich ist (Workgroup Scenarien, VPNs von extern etc). Die 1te Wahl sollte aber immer der FQDN sein. Wieder ein Grund für einen zentralen RDP Manager in der Firma ;-)

Kerberos mit der IP verwenden, es benötigt 2 Dinge:

• Dem Client/Absprung muss mitgeteilt werden, daß er Kerberos trotz IP versuchen soll. Hierfür benötigt es einen Registry Eintrag, denn wir über die GPPs oder Set-GPRegistryValue in eine Richtlinie integrieren können. Ich möchte jetzt micht darüber reden, das der Pfad einer “echten” Policy entspricht, Microsoft aber keine Policy im Bereich der Administrativen Vorlagen dafür zur Verfügung stellt. Nichtskönner …
  Set-GPRegistryValue -Name "EureGPO" -Key "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Parameters" -Valuename "TryIPSPN" -Value 1 -Type DWord
   
• Kerberos-Clients unterstützen IPv4- und IPv6-Adresshostnamen in Dienstprinzipalnamen (SPNs)
  Ihr müsst die IP Adresse als SPN zu dem Zielsystem im AD eintragen.
  Setspn -s host/192.168.222.10 Majestix

Server Härtung mit Fokus auf NTLM Reduktion

Microsoft hatte vor vielen Jahren ein großes Sicherheitsproblem mit RDP und hat daraufhin mit der RDC Version 6.1 die “Authentifizierung auf Netzwerkebene” eingeführt. Wir reden hier über XP SP3, Vista, Server 2008. Die NLA (Network Level Authentication) sorgt dafür, daß ein Client/Benutzer sich zuerst Authentifizieren muss, bevor er per RDP zum Host durchgereicht wird. Die Änderung zu vorher ist, daß er nicht schon per RDP am Host ist und sich dann “nur noch” authentifiziert, sondern das der Zugriff zuerst eine Authentifizierung erfordert. Sehr geile Idee und sehr guter Prozess.

Dumm ist nur: die NLA macht NTLM statt Kerberos :-S

ACHTUNG! Die folgenden Richtlinien Einstellungen funktionieren im Hinblick auf die Kommunikation innerhalb von Windows Systemen, mit dem Fokus auf RDP. Offiziell wird in eimem AD seit Windows 2000(!) nur Kerberos verwendet. Soso, wer´s glaubt … Wer NTLM abschaltet sollte vorher protokolliert haben, welche Systemen hausintern noch NTLM erfordern. Diese können dann als Excludes in der Richtlinie definiert werden. Sind sie es nicht, werden Dienste und Funktionen nicht mehr erreichbar sein. Die NTLM Einstellungen in den Sicherheitsoptionen bieten “Überwachen” anstelle “Verweigern”. 

Chuck-Norris-NTLM-Konfiguration:

Teil 1: Beschränken von NTLM

Computerkonfiguration\Richtlinien\Windows-Einstellungen\Sicherheitseinstellungen\Lokale Richtlinien\Sicherheitsoptionen\
Netzwerksicherheit: Beschränken von NTLM:

• Ausgehenden NTLM-Datenverkehr zu Remoteservern = Alle verweigern
  “Alle überwachen” wäre hier die Angsthasen Konfigration :-)
• Eingehenden NTLM-Datenverkehr überwachen = Überwachung für alle Konten = Aktivieren
  es könnten nur Domänenkonten überwacht werden. Das Lokale Konto macht immer NTLM. Die Protokollierung erlaubt einen möglichen Missbrauch des Lokalen Kontos zu erkennen.
• Eingehender NTLM-Datenverkehr = Alle Domänenkonten verweigern
  Ihr habt LAPS eingeführt und nutzt den .\Administrator, bzw. ein lokales LAPS kontrolliertes Konto für den Zugriff, dann darf hier nicht “Alle Konten verweigert” gewählt werden.
  Alle Domänenkonten verweigern → .\Administrator - OK, DOM\User - NOGO
  Alle Konten verweigern → .\Administrator - NOGO, DOM\User - NOGO
  Alle Konten zulassen → .\Administrator - OK, DOM\User - OK
• NTLM-Authentifizierung in dieser Domäne = Nicht definiert
  am Client/MemberServer ist diese Richtlinie nicht relevant, das ist eine Einstellungen auf Domänen Controller Ebene und damit für das AD.
• NTLM-Authentifizierung in dieser Domäne überwachen = Nicht definiert
  siehe vorherige Richtlinie
• Remoteserverausnahmen für die NTLM-Authentifizierung hinzufügen = Nicht definiert
  Ausnahmeliste als FQDN oder NetBIOS/Hostname
• Serverausnahmen in dieser Domäne hinzufügen = Nicht definiert
  siehe vorherige Richtlinie

Teil 2: Konfiguration vom Remote Desktop Host und Client

Wir definieren NTLM als das größere Übel, und deaktivieren die NLA (Network Level Authentication). Der Schutz des direkten Zugriffs auf ein System, ist durch unsere Kennwortrichtlinie mit mindestens 16 Zeichen und der Umstellugn auf Passphrases  ausreichend gesichert.

• Computer: Computerkonfiguration/Administrative Vorlagen/Windows-Komponenten/Remotedesktopdienste/Remotedesktopsitzungs-Host/Sicherheit
  Benutzerauthentifizierung mit Authentifizierung auf Netzwerkebene ist für Remoteverbindungen erforderlich = Deaktiviert
• Computerkonfiguration/Administrative Vorlagen/Windows-Komponenten/Remotedesktopdienste/Remotedesktopsitzungs-Host/Sicherheit
  Bei der Verbindungsherstellung immer zur Kennworteingabe auffordern = Deaktiviert
  Diese Richtlinie ist nicht zwingend notwendig, ist aber in Systemem gesetzt, die nach dem BSI Dokument Hilfsmittel zur Umsetzung von Anforderungen des IT-Grundschutzes für Windows 10 konfiguriert sind.
  Es würde zu einem Schönheitsfehler kommen. Die Authentifizierung wird durch die deaktivierte NLA nicht mehr durchgereicht und die Person muss das Kennwort auf der Oberfläche des RDP Ziels erneut eintippen. 

Phänomen: Obwohl die NLA deaktiviert ist, kommt es beim Start der mstsc.exe weiterhin nach der Abfrage von Benutzername/Kennwort. Das kann zum Testen verwendet werden, ob die NLA wirklich deaktiviert ist. Gibt man hier ein falsches Kennwort ein, dann landet man trotzdem auf der Oberfläche in der RDP Sitzung und muss hier die richtige Kombination verwenden. Bei aktivierter NLA würde die Fehlermeldung schon am Client/Absprung System generiert und erneut zur Eingabe des richtigen Kennworts auffordern.

Teil 3, optional/Kundenspezifisch

Ihr nutzt ein lokales Konto mit individuellen Kennworten pro Computer (LAPS oder andere Technik) und wollt mit diesem Konto auf die Computer über das Netzwerk zugreifen. Kontrolliert in dem Fall die Einstellungen in Computerkonfiguration\Richtlinien\Windows-Einstellungen\Sicherheitseinstellungen\Lokale Richtlinien\Sicherheitsoptionen\Zuweisen von Benutzerrechten

• Anmelden über Remotedesktopdienste verweigern
• Zugriff vom Netzwerk auf diesen Computer verweigern
• […] und Ähnliche.
  Hier bitte den Verweis auf das “Lokales Konto” (SID S-1-5-113 und S-1-5-114) entfernen

Teil 4, optional/Kundenspezifisch

Neben dem NTLM Problem bin ich bei einigen Kunden über die empfohlene Schlüssellänge des PKCS (Public-Key Cryptography Standards) gestolpert. Das BSI hätte gerne mindestens 3000 Bit, was in den meisten Konfigurationen zu 3072 Bit führt, diese muss ich regelmässig auf 2048 reduzieren.
Ich verwende ein Group Policy Template for Schannel von Crosse auf Github. Die Einstellungen des Security Channels sind Preferences, sie bleiben nach dem Entfernen der Richtlinie erhalten. 

Gernell lässt sich sagen, das die Fehlermeldungen der Programme nicht auf gehärtete Systeme ausgelegt sind. Die Fehlermeldungen sind nichtssagend und unspezifisch oder oft nur der letzte Fehlerpunkt, den das System meldet, wenn es nicht weiss warum es scheitert. So gibt es im RDP Thema immer wieder den berühmten “CredSSP” Fehler. Sucht man im Internet nach der Fehlermeldung dann gibt es einen Patch aus dem Jahre 2018, der diesen Fehler beseitigt, der durch eine Härtungsmassnahme erfolgte. Den Patch hat mittlerweile jeder eingespielt, die ganzen Artikel könnt ihr also direkt ignorieren.
Das System hat keine Ahnung was schief läuft, aber sagt sehr zuversichtlich, was der Programmieren als “Last exit” definiert hat. Mit anderen Worten die Meldung ist identisch zu “Tut´s nicht”. Das wussten wir schon.

Bei Fehlern aus dem NTLM Bereich oder der PKCS Schlüssellänge tauchte regelmässig “0x0” oder “0x3” in der mstsc.exe auf. Ebenfalls ein langer Tiemout, gefolgt von einem schwarzen RDP Fenster, das am Ende nach Timeout mit einem pauschalen Netzwerkfehler quittiert wird.

Kleine Wunder. Mit Windows 11 24H2 gibt es eine neue Fehlermeldung in bei mstsc.exe/NLA die auf ein NTLM Problem hinweist, wenn man NTLM verweigert, aber die NLA nicht abgeschaltet hat. Das stimmt 🙂 

P.S.: findet jemand den Übersetzungsfehler im Bild?