Demande manuelle d'un certificat Remote Desktop (RDP)

Auteur Uwe GradeneggerPublié le Catégories Utilisation du certificatÉtiquettes , ,

Es gibt Fälle, in welchen man Remotedesktop-Zertifikate nicht von einer Zertifizierungsstelle in der eigenen Active Directory Gesamtstruktur beziehen kann oder möchte, beispielsweise wenn das betreffende System kein Domänenmitglied ist.

In diesem Fall ist die Verwendung von Zertifikatvorlagen nicht möglich, und man muss manuell einen Zertifikatantrag (Certificate Signing Request, CSR erstellen).

Connaissez-vous TameMyCerts? TameMyCerts est un add-on pour l'autorité de certification Microsoft (Active Directory Certificate Services). Il étend la fonction de l'autorité de certification et permet de Application de la réglementationIl s'agit d'un logiciel de gestion des certificats qui permet d'automatiser l'émission de certificats en toute sécurité. TameMyCerts est unique dans l'écosystème Microsoft, a déjà fait ses preuves dans d'innombrables entreprises du monde entier et est disponible sous une licence libre. Il peut téléchargé via GitHub et être utilisé gratuitement. Une maintenance professionnelle est également proposée.

Travaux préparatoires

Bevor Remotedesktop-Zertifikate beantragt werden, sollten folgende Voraussetzungen erfüllt sein:

  • Die Teilnehmer im Active Directory müssen der Zertifizierungsstellen-Hierarchie vertrauen. Werden die Remotedesktop-Zertifikate von einer fremden Zertifizierungsstelle ausgestellt, muss das Stammzertifizierungsstellen-Zertifikat allen Teilnehmern bekannt gemacht werden. Dies kann beispielsweise via Gruppenrichtlinie erfolgen, was im Artikel „Distribuer les autorités de certification racines de confiance via une stratégie de groupe".
  • Pour que l'état de révocation des certificats puisse être vérifié, il faut s'assurer qu'ils puissent être résolus (système de noms de domaine) et téléchargés (routage, proxy, règles de pare-feu) par tous les participants.

Inventaire pour la création manuelle d'une demande de certificat

Zunächst muss der Inhalt der Zertifikatantrags bestimmt werden. Als Anhaltspunkt hierfür kann eine der Standard-Zertifikatvorlagen für Domain Controller dienen. Im nachfolgenden Beispiel orientieren wir uns an der im Artikel „Configurer un modèle de certificat pour les certificats Remote Desktop (RDP)“ beschriebenen Zertifikatvorlage für Remotedesktop-Zertifikate.

Im Karteireiter „Request Handling“ sieht man, dass der Zwerk der Zertifikatvorlage auf „Signature and Encryption“ eingestellt ist, was dazu führt, dass die Key Usage Erweiterung des Zertifikats „Key Encipherment“ und „Digital Signature“, also den hexadezimalen Wert A0 beinhalten wird. Dies muss bereits bei der Schlüssel-Erstellung auf dem beantragenden Computer berücksichtigt werden.

Im Karteireiter „Cryptography“ sind für uns der Schlüsselagorithmus, die Schlüssellänge und der Cryptographic Service Provider (CSP) von Relevanz. Die Remotedesktop-Vorlage verwendet noch „Legacy“-Anbieter, also CSPs, welche lediglich RSA unterstützen. Die Schlüssellänge ist auf 2048 Bit gesetzt, und es wird der „Microsoft RSA SChannel Cryptographic Provider“ verwendet.

Dans l'onglet "Subject Name", nous voyons que le Subject est vide et qu'un Subject Alternative Name est choisi sous la forme d'un nom DNS.

Dans l'onglet "Extensions", nous voyons que les valeurs suivantes sont définies comme Extended Key Usage (Application Policies) :

  • Remote Desktop Authentication (Object Identifier: 1.3.6.1.4.1.311.54.1.2)

Zertifikatvorlage für manuelle Beantragung von Remotedesktop-Zertifikaten erstellen

Sofern die Zertifikatanforderung von einer Active Directory integrierten Zertifizierungsstelle beantwortet werden soll, muss für diese eine entsprechende Zertifikatvorlage definiert werden . Die Vorgegehensweise hierzu ist im Artikel „Configurer un modèle de certificat pour les certificats Remote Desktop (RDP)“ beschrieben. Für manuelle Beantragungen muss jedoch abweichend im Karteireiter „Subject Name“ konfiguriert werden, dass der Antragsteller die Identität mit der Zertifikatanforderung vorgeben können soll.

Da dies jedoch ein Sicherheitsproblem darstellen kann, sollten die Zertifikatanforderungen durch einen Zertifikatmanager freigegeben werden, was durch Aktivieren der Option „CA certificate manager approval“ im Karteireiter „Issuance Requirements“ erreicht werden kann.

Da bei einer manuellen Zertifikatanforderung ein Benutzer- anstelle eines Computerkontos den Zertifikatantrag stellen wird, muss der entsprechende Benutzer oder eine Sicherheitsgruppe, in welcher er Mitglied ist, das „Enroll“ Recht erhalten.

Créer un fichier d'informations pour la demande manuelle de certificat

Aus all diesen Informationen kann nun eine Informationsdatei (.inf) für den Zertifikatantrag erstellt werden. Nachfolgend ein Beispiel, welches einen Zertifikatantrag analog zur Kerberos Authentication Zertifikatvorlage erzeugen sollte:

Le fichier d'information doit être enregistré avec le codage UTF-8. Si l'encodage est différent, la création de la demande de certificat échouera (voir article "La création d'une demande manuelle de certificat échoue avec le message d'erreur "Expected INF file section name 0xe0000000".„).

[Version] 
Signature="$Windows NT$"

[Strings]
; Die folgende Variable an die Umgebung anpassen
SERVER_FQDN = "CA01.intra.adcslabor.de"

; Nachfolgende Strings nicht bearbeiten
szOID_SUBJECT_ALT_NAME2 = "2.5.29.17" 
szOID_ENHANCED_KEY_USAGE = "2.5.29.37" 
szOID_KP_RDC_AUTH = "1.3.6.1.4.1.311.54.1.2"

 [NewRequest] 
; Nach RFC2818 sollte das Subject nicht mehr verwendet werden und darf leer sein (Subject =)
Subject = "CN=" 
; Der private Schluessel ist nicht exportierbar 
Exportable = FALSE
; Das Schluesselpaar wird im lokalen Maschinenspeicher erzeugt
MachineKeySet = True
; Empfohlene Schluessellaengen: 2048, 3072, 4096
; 2048 Bit sollten nur noch bis 2021 verwendet werden
; Vor Erhöhung der Schluessellaenge sollte die Kompatibilitaet sichergestellt sein
KeyLength = 3072
; AT_KEYEXCHANGE 
KeySpec = 1
; Digital Signature, Key Encipherment 
KeyUsage = 0xA0
ProviderName = "Microsoft RSA SChannel Cryptographic Provider" 
ProviderType = 12 
SMIME = FALSE 
RequestType = CMC

[Extensions]
%szOID_SUBJECT_ALT_NAME2% = "{text}dns=%SERVER_FQDN%"
%szOID_ENHANCED_KEY_USAGE% = "{text}%szOID_KP_RDC_AUTH%"

Génération de la paire de clés et de la demande de certificat

Nun kann anhand dieser Informationsdatei ein Schlüsselpaar und ein Zertifikatantrag erzeugt werden. Die Erstellung erfolgt auf dem Computer als Administrator per Kommandozeile mit nachfolgendem Befehl: 

certreq.exe -new {Informationsdatei}.inf {Zertifikatantrag}.req

La demande de certificat qui vient d'être générée peut être consultée sur demande avec la commande de ligne de commande suivante : 

certutil -dump {Zertifikatantrag}.req

Envoi de la demande de certificat à l'autorité de certification

L'envoi d'une demande de certificat à une autorité de certification et la récupération du certificat délivré sont décrits dans l'article „Envoyer une demande de certificat créée manuellement à une autorité de certification" décrit.

Installation du certificat délivré

Le certificat peut maintenant être copié sur l'ordinateur. Il doit maintenant être installé dans le magasin de certificats et associé à la clé privée. Cela se fait à l'aide de la commande de ligne de commande suivante : 

certreq -accept {Zertifikat}

Activation du certificat et test de fonctionnement ultérieur

Die Zuweisung des Zertifikats zum Remotedesktop-Sitzungshost ist im Artikel „Attribuer manuellement un certificat Remote Desktop (RDP)" décrit.

Wie das derzeit verwendete Remotedesktop-Zertifikat identifiziert werden kann ist im Artikel „Identifizieren des aktiven Remotedesktop (RDP) Zertifikats" décrit.

Liens complémentaires :

Sources externes

Les commentaires sont fermés.

fr_FRFrançais
de_DEDeutsch en_USEnglish fr_FRFrançais