Konfigurieren einer Zertifikatvorlage für Remotedesktop (RDP) Zertifikate

Für die Verwendung von Remotedesktop-Zertifikaten ist es erforderlich, eine entsprechende Zertifikatvorlage zu konfigurieren.

Der Remotedesktop-Sitzungshost kann Zertifikate mit den folgenden Extended Key Usages (EKU) verwenden:

Server Authentication (OID: 1.3.6.1.5.5.7.3.1)
Remote Desktop Authentication (OID: 1.3.6.1.4.1.311.54.1.2)

Es wird empfohlen, dass das Remote Desktop Authentication EKU verwendet wird, da somit gewährleistet ist, dass die Zertifikate nur hierfür und nicht etwa auch noch für die Bereitstellung eines Webservers verwendet werden.

Ebenso kann es bei Verwendung des "Server Authentication" EKU in Kombination mit einem Key Storage Provider (KSP) zu Problemen mit den Active Directory Web Services (ADWS) kommen, da diese keine KSP unterstützen und die Zertifikatauswahl lediglich auf EKU und den vollqualifizierten Hostnamen filtert. Solche Konflikte können bei Verwendung des Remote Desktop Authentication EKU vermieden werden.

Das Remote Desktop Authentication EKU ist jedoch im Auslieferungszustand des Active Directory Verzeichnisdienstes nicht definiert. Dies muss im Lauf der Konfiguration der Zertifikatvorlage vorgenommen werden.

Konfiguration der Zertifikatvorlage

Zunächst wird mit Hilfe der Zertifikatvorlagen-Managementkonsole (certtmpl.msc) eine Kopie der Zertifikatvorlage "Workstation Authentication" erstellt und bearbeitet.

Karteikarte "Compatibility"

Wir beabsichtigen, Key Storage Provider (KSP) einzusetzen. Hierfür ist es erforderlich, die Kompatibilitätseinstellungen für Zertifizierungsstelle und Zertifikatempfänger auf "Windows Vista" bzw. "Windows Server 2008" zu setzen.

Karteikarte "General"

In der Karteikarte "General" wird ein aussagekräftiger Name vergeben.

Im Falle von Remotedesktop-Zertifikatvorlagen sollte unbedingt der gleiche Wert für den Namen der Zertifikatvorlage und deren Anzeigenamen verwendet werden, da es andernfalls dazu kommen kann, dass Zertifikate mehrfach beantragt werden.

Schwachstellenscanner wie die von Qualys werden sowohl einen Fund melden, wenn das Zertifikat nicht einen Monat vor Ablauf erneuert wurde, als auch wenn das Zertifikat länger als ein Jahr gültig ist. Da eine Erneuerung via Autoenrollment erst nach Ablauf von 80% der Zertifikatgültigkeit erfolgt, ist es also sinnvoll, die Zertifikatgültigkeit auf mindestens 6 Monate und höchstens 12 Monate zu setzen und das Zeitfenster für die Zertifkaterneuerung auf mindestens 5 Wochen.

Karteikarte "Request Handling"

In der Karteikarte "Request Handling" muss der Purpose an den zu verwendenden Schlüsselalgorithmus angepasst werden. Hintergrund ist, dass je nach Schlüsseltyp unterschiedliche Anforderungen an die "Key Usage" Erweiterung des Zertifikats gestellt werden (Siehe RFC 5246 und RFC 4492).

Schlüsselalgorithmus	Wert
RSA	Signature and Encryption
ECDSA	Signature
ECDH	Signature and Encryption

Karteikarte "Cryptography"

In der Karteikarte "Cryptography" kann nun die Kategorie "Key Storage Provider" gewählt werden und der jeweilige Schlüsselalgorithmus.

Als Provider sollte der Microsoft Software Key Storage Provider ausgewählt werden, wenn nicht beabsichtigt ist, die Schlüssel beispielsweise mit einem Trusted Platform Modul (TPM) zu schützen.

Wenn ein Cryptographic Service Provider (CSP) verwendet werden soll, sollte der "Microsoft RSA SChannel Cryptographic Provider" verwendet werden. Diese unterstützt nur AT_KEYEXCHANGE, daher muss in der Karteikarte "Request Handling" der Purpose auf "Signature and Encryption" eingestellt werden. Grundsätzlich sollte nach Möglichkeit einem Key Storage Provider der Vorzug gegeben werden.

Hier gibt es jedoch die Ausnahme, dass die Active Directory Web Services (ADWS) bereits bei der Zertifikatauswahl abbrechen, wenn auch nur ein einziges Zertifikat im Computer-Zertifikatspeicher keinen CSP einsetzt. Somit muss in diesem Fall beachtet werden, dass Remotedesktop-Zertifikate auf Domänencontrollern mit aktivierten ADWS ebenfalls einen CSP einsetzen.

Die Wahl des Providers hat nur für Zertifikatbeantragungen, die die Zertifikatvorlage bei der Beantragung auslesen (also manuelle oder automatische Zertifikatbeantragungen per Autoenrollment) Auswirkungen.

Karteikarte "Extensions"

Im der Karteikarte "Extensions" werden die "Application Policies" mit Klick auf "Edit…" bearbeitet.

Das vorhandene "Client Authentication" EKU wird mit Klick auf "Remove" entfernt, da es nicht benötigt wird.

Anschließend wird mit "Add…" ein neues EKU hinzugefügt.

Da das Remote Desktop Authentication EKU im Auslieferungszustand des Active Directory Verzeichnisdienstes nicht definirt ist, muss es zunächst mit Klick auf "New…" erstellt werden.

Die vordefinierten Werte im nachfolgenden Dialog werden entfernt und stattdessen die folgenden eingetragen:

Feld	Beschreibung
Name	Ein Freitext-Feld, jedoch wird der hier eingegebene Text im Zertifikat-Dialog auf jedem Client im Netzwerk angezeigt werden. Daher sollte etwas Aussagekräftges wie "Remote Desktop Authentication" eingegeben werden.
Object identifier	Hier muss exakt der folgende Wert eingetragen werden: 1.3.6.1.4.1.311.54.1.2

Das neu definierte EKU kann nun ausgewählt und mit Klick auf "OK" hinzugefügt werden.

Mit Klick auf "OK" wird die Konfiguration beendet.

Karteikarte "Security"

Im der Karteikarte "Security" müssen für die teilnehmenden Computer die Rechte "Enroll" und "Autoenroll" gesetzt werden.

Wird nur "Enroll" gesetzt, werden die Maschinen dennoch Zertifikate beantragen, sofern die entsprechende Gruppenrichtlinie konfiguriert wurde, da dies dem Fallback-Szenario entspricht. Es wird jedoch empfohlen, mit Autoenrollment zu arbeiten, um eine bessere Verwaltung der Zertifikate zu ermöglichen. Unter Anderem werden bei der Fallback-Option keine abgelaufenen Zertifikate archiviert, was zur regelmäßigen Generierung des Ereignisses mit ID 64 der Quelle Microsoft-Windows-CertificateServicesClient-AutoEnrollment auf den Clients führen wird.

Als Sicherheitsgruppen bieten sich beispielsweise an:

Domain Computers (ist bereits in der Liste enthalten)
Domain Controllers (muss der Liste hinzugefügt werden)

Falls die Active Directory Gesamtstruktur aus mehreren Domänen besteht, müssen natürlich alle Gruppen der entsprechenden Domänen eingetragen werden.

Technisch ist die "Enroll" Berechtigung ausreichend. Es wird allerdings dringend empfohlen, dass auch die "Autoenrollment" Berechtigung vergeben wird, damit die Zertifikate über diesen Mechanismus verteilt und vom Remotedesktop-Sitzungshost verwendet werden. Das clientseitige Verhalten ist im Artikel "Konfigurieren einer Gruppenrichtlinie (GPO) für Remotedesktop (RDP) Zertifikate" beschrieben.

Karteikarte "Subject Name"

Die Option wird im Artikel "Zur Option "Build this from Active Directory information" bei Zertifikatvorlagen" näher beschrieben.

Die Standardeinstellungen der "Workstation Authentication" Zertifikatvorlage können übernommen werden.

Ergebnis

In den ausgestellten Zertifikaten wird nun das Remote Desktop Authentication Enhanced Key Usage angezeigt, da das entsprechende OID-Objekt im Public Key Services Objekt der Gesamtstruktur mit diesem Anzeigenamen verbunden ist und von jedem teilnehmer im Active Directory repliziert wird.

Nächster Schritt: Gruppenrichtlinie konfigurieren

Damit die Zertifikate auch für den Remotedesktop-Sitzungshost verwendet werden, muss nun noch eine entsprechende Gruppenrichtlinie konfiguriert werden. Die Vorgehensweise hierzu ist im Artikel "Konfigurieren einer Gruppenrichtlinie (GPO) für Remotedesktop (RDP) Zertifikate" beschrieben.

Weiterführende Links:

Externe Quellen

Using certificates in Remote Desktop Services (Microsoft)
Configuring Remote Desktop certificates (Microsoft, archive.org)
Object IDs associated with Microsoft cryptography (Microsoft)
Remote Desktop server certificates are renewed two times a day despite being valid for one year (Microsoft)