RDP-Verschlüsselung absichern: TLS und Zertifikate prüfen

30. September 2026 · Active Directory · AD-Hardening · RDP · TLS · Group Policy

Eine verschlüsselte Sitzung braucht eine überprüfbare Gegenstelle

Im GPO-Bericht steht das RDP-Verschlüsselungslevel auf „High“. Administratoren verbinden sich trotzdem über IP-Adressen, bestätigen Zertifikatswarnungen und arbeiten mit automatisch erzeugten Serverzertifikaten. Bei einem Zertifikatswechsel fällt der Fehler erst auf, wenn der nächste Wartungstermin scheitert. Die Verbindung funktioniert, der Nachweis einer vertrauenswürdigen Gegenstelle fehlt jedoch im Betriebsprozess.

Für AD-Umgebungen ist das besonders relevant: Über RDP werden Server und gelegentlich Domain Controller mit privilegierten Konten bedient. Transportverschlüsselung schützt diese Verbindung nur dann zuverlässig gegen eine falsche Gegenstelle, wenn der Client auch die Serveridentität prüft. Ein erlaubtes Anmelderecht und eine Firewall-Freigabe beantworten andere Fragen.

Der Scope dieses Bausteins sind freigegebene RDP-Verbindungen zu unterstützten, gepatchten Windows-Systemen. Er ist kein Anlass, RDP auf bislang nicht erreichbaren Systemen einzuschalten. Für DCs bleibt der Zugang ein gesonderter, eng begrenzter Administrationspfad.

Zielbild: TLS verpflichtend, Zertifikatswarnungen ausgeschlossen

Eine abnahmefähige Baseline beschreibt mehr als einen Registry-Wert:

Der RDP-Host verlangt den TLS-Sicherheitslayer; ein Rückfall auf native RDP-Sicherheit ist nicht vorgesehen.
Zugelassene Clients prüfen einen gültigen, vertrauenswürdigen Servernachweis für den verwendeten DNS-Namen.
Network Level Authentication ist verpflichtend und wird mit den tatsächlich eingesetzten Anmeldeverfahren getestet.
Die freigegebene TLS-Baseline unterstützt mindestens TLS 1.2; veraltete Protokolle werden nach einem Abhängigkeitstest ausgeschlossen.
Zertifikatsausstellung, Erneuerung, Listener-Zuordnung und Ablaufüberwachung haben einen Verantwortlichen.
Ein getesteter Konsolen- oder anderer Recovery-Zugang bleibt verfügbar, wenn RDP ausfällt.

Ein RD Gateway bildet einen zusätzlichen Verbindungsschritt. Sein Zertifikat ersetzt nicht die Prüfung des Zertifikats am Zielhost. Gateway, Broker und Session Hosts müssen innerhalb ihrer jeweiligen Rolle betrachtet werden.

Drei GPO-Einstellungen mit unterschiedlichen Aufgaben

Die Einstellungen liegen unter Computerkonfiguration > Richtlinien > Administrative Vorlagen > Windows-Komponenten > Remotedesktopdienste > Remotedesktopsitzungs-Host > Sicherheit. Die folgenden englischen Richtliniennamen ermöglichen eine eindeutige Suche auch bei abweichenden ADMX-Übersetzungen.

TLS als Sicherheitslayer erzwingen

„Require use of specific security layer for remote (RDP) connections“ aktivieren und „SSL (TLS 1.0)“ auswählen. Der historische Optionsname ist missverständlich: Er ist kein Nachweis, dass eine Sitzung tatsächlich TLS 1.0 verwendet. Die ausgehandelte Version hängt unter anderem von Betriebssystem, Client, Schannel-Konfiguration und deren gemeinsam unterstützten Protokollen ab.

„Negotiate“ ist für dieses Zielbild zu unbestimmt, weil die Option grundsätzlich auch native RDP-Sicherheit zulässt. Das Erzwingen von TLS entspricht im Richtlinienpfad dem Wert SecurityLayer = 2. Damit ist weder eine konkrete Cipher Suite noch automatisch eine TLS-Mindestversion festgelegt.

High als ergänzenden Verschlüsselungswert setzen

„Set client connection encryption level“ aktivieren und „High Level“ wählen. Der zugehörige Richtlinienwert ist MinEncryptionLevel = 3.

High verlangt bei nativer RDP-Verschlüsselung 128-Bit-Verschlüsselung in beide Richtungen. Die Einstellung steuert nicht die Cipher Suites einer TLS-Verbindung. Sie gehört als expliziter Baseline-Wert dazu, darf im Prüfbericht aber nicht als Beleg für TLS 1.2 oder eine bestimmte TLS-Schlüssellänge erscheinen. „Client Compatible“ richtet sich nach den Fähigkeiten des Clients und ist für dieses Zielbild nicht vorgesehen.

„FIPS Compliant“ ist keine pauschale nächste Härtungsstufe. Die Option und eine mögliche systemweite FIPS-Richtlinie müssen zu einem konkreten Compliance-Ziel und zu getesteten Anwendungen passen. Ohne diese Anforderung wird daraus leicht eine zusätzliche Kompatibilitätsstörung.

NLA separat verpflichtend machen

„Require user authentication for remote connections by using Network Level Authentication“ aktivieren. Erwartet wird UserAuthentication = 1.

NLA verlagert die Benutzerauthentifizierung vor die vollständige Remotedesktopsitzung. Es ersetzt weder die Prüfung der Serveridentität noch MFA, Anmelderechte oder eine kontrollierte Behandlung privilegierter Zugangsdaten. Verwendete Smartcard-, Gateway- und Recovery-Abläufe gehören in den Pilot; NLA für ein Altprodukt global abzuschalten ist kein tragfähiger Betriebsweg.

Zertifikate vom Antrag bis zum Listener betreiben

Für verwaltete interne Hosts ist eine kontrollierte Unternehmens-PKI meist der passende Ausstellungsweg. Die Vorlage muss für Serverauthentifizierung geeignet sein, die tatsächlich verwendeten DNS-Namen abdecken und die Ausstellung auf berechtigte Computer begrenzen. Beliebig vom Antragsteller vorgegebene Namen und breite Enrollment-Rechte gehören nicht in eine solche Vorlage.

Das Zertifikat benötigt den zugehörigen privaten Schlüssel. Beim dokumentierten manuellen Listener-Verfahren liegt es im persönlichen Zertifikatspeicher des lokalen Computers. Der RDP-Dienst benötigt Leserechte auf genau diesen Schlüssel; im üblichen Dienstkontext betrifft das NETWORK SERVICE. Breite Rechte auf private Schlüssel sind keine Fehlerbehebung.

Clients müssen der ausstellenden Kette vertrauen und das eingesetzte Prüfverfahren einschließlich erreichbarer Sperrinformationen unterstützen. DNS-Namen, Gültigkeit, Verwendungszweck und Vertrauenskette werden vom vorgesehenen Admin-Arbeitsplatz aus geprüft. Eine Verbindung per IP-Adresse passt regelmäßig nicht zum DNS-Zertifikat. Zertifikatswarnungen durch gespeicherte Ausnahmen zu unterdrücken ist keine Abnahme.

Auf den Admin-Arbeitsplätzen wird zusätzlich unter Computerkonfiguration > Richtlinien > Administrative Vorlagen > Windows-Komponenten > Remotedesktopdienste > Remotedesktopverbindungs-Client die Richtlinie „Configure server authentication for client“ aktiviert und „Don't connect if authentication fails“ gewählt. Der Windows-RDP-Client soll bei fehlgeschlagener Serverauthentifizierung die Verbindung ablehnen. Bei anderen RDP-Clients muss eine entsprechende verbindliche Prüfung separat eingerichtet und getestet werden; die Windows-GPO ist kein Nachweis für deren Verhalten.

Die Richtlinie „Server authentication certificate template“ kann die passende Zertifikatsauswahl anhand des Vorlagennamens steuern. Berechtigungen, gegebenenfalls Autoenrollment und die tatsächliche Ausstellung sind gesondert zu prüfen. Die automatische Auswahl greift nicht einfach über eine bereits manuell festgelegte Zertifikatsbindung hinweg: Eine explizite Listener-Zuordnung hat Vorrang.

Deshalb gehört zur Erneuerung immer ein Test mit einer neuen Verbindung. Ein neu ausgestelltes Zertifikat im Store beweist nicht, dass der Listener es bereits verwendet. Bei manueller Bindung muss der Wechsel des Thumbprints mitgeführt werden. Dienstneustarts, sofern für den gewählten Ablauf nötig, werden im Wartungsfenster geplant; sie können bestehende Sitzungen unterbrechen.

TLS-Versionen separat planen und nachweisen

Die Zielvorgabe lautet: keine SSL-Protokolle und kein TLS 1.0 oder 1.1 für den freigegebenen RDP-Pfad. Die passende Umsetzung wird für die vorhandenen Windows- und Client-Versionen festgelegt und im Pilot bestätigt. Eine pauschale Forderung „TLS 1.3 überall“ lässt sich nicht aus der Unterstützung des Betriebssystems allein ableiten; auch die konkrete Anwendung muss sie unterstützen.

Schannel-Änderungen können weitere Dienste auf demselben Server beeinflussen, beispielsweise andere TLS-Listener oder ausgehende Verbindungen. Deshalb werden Protokoll- und Cipher-Anpassungen als eigener Change mit Abhängigkeitsliste, Neustartplanung und Rücknahme durchgeführt. Ein RDP-Hardening-Termin ist kein geeigneter Rahmen für ungeprüfte domänenweite Schannel-Registry-Änderungen.

Für die Abnahme ist ein RDP-fähiges Prüfwerkzeug oder eine gezielte Aufzeichnung einer eigenen Testverbindung geeignet. Ein normaler TLS-Test gegen Port 3389 ohne die vorausgehende RDP-Aushandlung liefert keinen verlässlichen Befund. Diagnoseaufzeichnungen eng begrenzen und geschützt ablegen; sie können interne Systemnamen und Verbindungsmetadaten enthalten.

Richtlinienwerte lesen, dann die Verbindung testen

Der folgende lokale Check verändert keine Einstellungen. Er liest die drei expliziten Computer-Richtlinienwerte; ein fehlender Wert wird bewusst nicht als null oder als sicherer Standard interpretiert.

Set-StrictMode -Version Latest
$policyPath = 'HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services'
$expected = [ordered]@{
    SecurityLayer = 2
    MinEncryptionLevel = 3
    UserAuthentication = 1
}

foreach ($entry in $expected.GetEnumerator()) {
    try {
        $value = Get-ItemPropertyValue -LiteralPath $policyPath `
            -Name $entry.Key -ErrorAction Stop
        [pscustomobject]@{
            Setting = $entry.Key
            Expected = $entry.Value
            Actual = $value
            Result = $(if ($value -eq $entry.Value) { 'Match' } else { 'Review' })
        }
    } catch {
        [pscustomobject]@{
            Setting = $entry.Key
            Expected = $entry.Value
            Actual = $null
            Result = 'Missing or unreadable; investigate'
        }
    }
}

Der Check ist ein Konfigurationshinweis, kein Verbindungsnachweis. Ergänzend werden die gewinnende GPO per gpresult, die Listener-Konfiguration und das tatsächlich präsentierte Zertifikat geprüft. Auf Windows-Servern mit vorhandenem TerminalServices-WMI-Provider lässt sich die Bindung lokal lesend abfragen:

try {
    Get-CimInstance -Namespace 'root/cimv2/TerminalServices' `
        -ClassName Win32_TSGeneralSetting -Filter "TerminalName='RDP-tcp'" `
        -ErrorAction Stop |
        Select-Object TerminalName, SecurityLayer, MinEncryptionLevel,
            UserAuthenticationRequired, SSLCertificateSHA1Hash
} catch {
    Write-Warning 'Listener query unavailable; verify provider and permissions.'
}

Ein nicht verfügbarer Provider ist ein offener Prüfpunkt. Der SHA-1-Thumbprint ist hier eine Zertifikatskennung, keine Aussage über den Signaturalgorithmus des Zertifikats oder die Sitzungschiffre. Auch eine passende Listener-Konfiguration ersetzt die Prüfung vom Client aus nicht.

Den Rollout mit klaren Abnahmekriterien staffeln

Hosts, Client-Versionen, DNS-Namen, bisherige Warnungen und vorhandene Zertifikatsbindungen inventarisieren.
Eine repräsentative Pilotgruppe und einen erreichbaren Recovery-Pfad festlegen. Änderungen an DCs gesondert planen.
Zertifikate und Vertrauenskette bereitstellen; automatische Auswahl oder manuelle Bindung als verantworteten Betriebsweg festlegen.
Die drei Richtlinien über eine eigene, eng verknüpfte Computer-GPO ausrollen und die wirksame Konfiguration kontrollieren.
Eine neue Sitzung aus dem vorgesehenen Admin-Netz aufbauen: keine Warnung, richtiger DNS-Name, erwartetes Zertifikat, freigegebene TLS-Version und funktionierende Anmeldung.
In einer kontrollierten Testumgebung prüfen, dass eine fehlgeschlagene Serverauthentifizierung oder ein nicht zugelassener Verbindungsmodus zur Ablehnung führt. Eine übergehbare Warnung genügt nicht. Produktive Vertrauensspeicher dafür nicht verändern.
Einen Zertifikatswechsel einschließlich tatsächlicher Listener-Nutzung testen; danach in Wellen erweitern und Fehlerquoten beobachten.

Als Rücknahme werden GPO-Backup, bisherige Listener-Bindung und der erforderliche Zertifikatsbestand vorgehalten. „Nicht konfiguriert“ ist kein garantierter Wiederherstellungswert. Der zuvor genehmigte Zustand muss ausdrücklich wiederhergestellt und erneut geprüft werden.

Vorteile

Prüfbare Serveridentität: Administratoren verbinden sich zu einem bestätigten Ziel statt regelmäßig Zertifikatswarnungen zu übergehen.
Klarer Transportstandard: TLS-Pflicht, Protokollbaseline und Authentifizierung haben getrennte, nachvollziehbare Abnahmekriterien.
Weniger ungeplante Ausfälle: Ablaufüberwachung und getestete Listener-Erneuerung machen Zertifikatswechsel planbar.
Bessere Nachweise: GPO-Ergebnis, Zertifikat und Verbindungsprüfung belegen unterschiedliche Teile derselben Baseline.

Nachteile und Grenzen

PKI-Betrieb ist zusätzlicher Aufwand: Ausstellung, Rechte, Erreichbarkeit der Sperrinformationen und Erneuerung benötigen Pflege.
Kompatibilität kann ausfallen: Alte Clients und Spezialanmeldungen müssen angepasst oder aus dem freigegebenen Pfad entfernt werden.
Aussperren bleibt möglich: Fehler bei Bindung, Namen oder Schannel können RDP unterbrechen; ein unabhängiger Recovery-Zugang ist erforderlich.
Endpunkte bleiben entscheidend: TLS schützt den Transport. Ein kompromittierter Admin-Arbeitsplatz, gestohlene berechtigte Konten oder ein kompromittierter Zielhost werden dadurch nicht vertrauenswürdig.
Weitere Kanäle bleiben separat: Zwischenablage, Laufwerksumleitung, Gateway-MFA, Netzwerkgrenzen und Anmelderechte benötigen eigene Vorgaben.

Typische Stolperfallen

High als TLS-Nachweis zu werten ist der häufigste Denkfehler. Danach folgen die falsche Interpretation des Labels „SSL (TLS 1.0)“, Warnungen als normaler Bestandteil des Logins und ein erneuertes Zertifikat, das der Listener noch nicht verwendet. Ebenfalls kritisch: nur den Gateway-Namen prüfen, IP-Adressen mit DNS-Zertifikaten verwenden oder TLS 1.0 systemweit abschalten, ohne andere Dienste zu testen.

Projekt-Checkliste

[ ] Erforderliche RDP-Pfade und unterstützte Client-/Server-Versionen abgegrenzt.
[ ] TLS-Layer, High und NLA in einer nachvollziehbaren Computer-GPO gesetzt.
[ ] Namen, Zertifikatszweck, Kette, Gültigkeit und Schlüsselzugriff geprüft.
[ ] Clients lehnen fehlgeschlagene Serverauthentifizierung verbindlich ab.
[ ] Automatische Zertifikatsauswahl und manuelle Bindungen sauber unterschieden.
[ ] TLS-Baseline und Schannel-Abhängigkeiten vor dem Rollout getestet.
[ ] Neue Verbindung ohne Zertifikatswarnung mit tatsächlichem Protokollnachweis abgenommen.
[ ] Gateway und Zielhost jeweils geprüft, soweit vorhanden.
[ ] Zertifikatserneuerung bis zur aktiven Listener-Nutzung nachgewiesen.
[ ] Monitoring, Verantwortliche, Recovery und konkrete Rücknahme dokumentiert.