La demande de certificat échoue avec le message d'erreur "The certificate request could not be submitted to the certification authority. Error : The RPC server is unavailable. 0x800706ba (WIN32 : 1722 RPC_S_SERVER_UNAVAILABLE)"

Auteur Uwe GradeneggerPublié le Catégories Dépannage, Utilisation du certificat, Autorité de certificationÉtiquettes , ,

Supposons le scénario suivant :

  • Un utilisateur ou un ordinateur demande un certificat auprès d'une autorité de certification intégrée à Active Directory (Enterprise Certification Authority).
  • La demande de certificat échoue avec le message d'erreur suivant :
The certificate request could not be submitted to the certification authority. Error: The RPC server is unavailable. 0x800706ba (WIN32: 1722 RPC_S_SERVER_UNAVAILABLE)

Alternativement, ce message d'erreur pourrait également apparaître :

The encryption certificate for the certification authority (CA) could not be retrieved. Error: The RPC server is unavailable. 0x800706ba (WIN32: 1722 RPC_S_SERVER_UNAVAILABLE)

Même si une application basée sur IIS (Service d'enregistrement des périphériques réseau (NDES), Service web d'enregistrement des certificats (CES), Enregistrement web des autorités de certification (CAWE) ou ses propres développements basés sur IIS), le code d'erreur peut apparaître de la même manière.

Il n'y a (en fait) que deux raisons

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.

En généralisant, on peut dire que le code d'erreur „RPC_S_SERVER_UNAVAILABLE“ ne peut en fait apparaître que pour exactement deux raisons :

  • La connexion à l'interface RPC de l'autorité de certification n'est pas possible.
  • La connexion à l'interface RPC de l'autorité de certification est possible, mais aucune authentification n'est possible auprès de celle-ci.

Nous allons examiner de plus près les causes de ces deux cas.

Les problèmes avec le pare-feu se manifestent souvent par le fait que la demande de certificat „traîne“ longtemps avant que l'erreur ne soit affichée sur le client (car les paquets non autorisés sont dans la plupart des cas rejetés par les pare-feu, ce qui entraîne l'absence de réponse). En revanche, les erreurs d'authentification se manifestent généralement par une réponse très rapide.

Les composants impliqués dans une communication DCOM avec l'autorité de certification

Le diagramme suivant devrait donner une vue d'ensemble des composants impliqués dans une communication basée sur DCOM avec l'autorité de certification, c'est-à-dire du client au service de l'autorité de certification.

Il est important pour la compréhension que la même logique est utilisée lorsque la connexion se fait via un des services supplémentaires basés sur le web pour l'ICP (Service d'enregistrement des périphériques réseau (NDES), Service web d'enregistrement des certificats (CES), organismes de certificationEnregistrement sur le web (CAWE) ou des développements propres basés sur IIS). En conséquence, on trouve souvent le même code d'erreur dans leurs logs.

1. connexion au réseau

Tout d'abord, le client doit être en mesure de communiquer avec l'autorité de certification via le réseau.

Il convient tout d'abord de vérifier que l'on utilise le nom d'hôte correct pour le serveur d'autorité de certification. Lors d'une connexion manuelle, celui-ci est indiqué avec la commande de ligne de commande ou l'appel de programme. Lors d'une connexion via la Microsoft Management Console ou Autoenrollment, le nom d'hôte est lu sur l'objet pKIEnrollmentService dans l'Active Directory.

En supposant que le nom d'hôte est correct, la question suivante est de savoir si la résolution de nom fonctionne correctement et résout le nom du serveur correctement. Il faut notamment vérifier si le nom d'hôte de l'autorité de certification a été réutilisé et si l'enregistrement DNS est toujours enregistré sur l'ancien objet informatique.

Ensuite, une connexion réseau peut être établie avec le serveur de l'autorité de certification. Pour cela, les ports correspondants doivent être activés (si disponibles) sur tous les pare-feux sur le chemin (Pare-feu réseau et pare-feu Windows sur le serveur de l'autorité de certification) sera ouvert.

Les règles de pare-feu nécessaires sont décrites dans l'article „Règles de pare-feu requises pour Active Directory Certificate Services" décrit.

Il convient également de vérifier s'il y a un pare-feu „intelligent“ sur le chemin, qui pourrait peut-être (pas si intelligemment) endommager les paquets de données RPC.

Si le port TCP 135 est accessible, mais pas les „ports hauts“ 49152-65535, le code d'erreur sera probablement „RPC_E_VERSION_MISMATCH“.

Même si cela semble trivial, il convient également de vérifier si le serveur d'autorité de certification et le service d'autorité de certification sont démarrés.

2. l'interface RPC

Une fois arrivé à l'autorité de certification, le premier obstacle doit être surmonté en ce qui concerne l'authentification sur l'interface Remote Procedure Call (RPC). Pour qu'une connexion puisse être établie, le compte de connexion doit disposer de l'autorisation „Access this computer from the network“.

Par défaut, ce champ est rempli :

  • Administrateurs
  • Opérateurs de secours
  • Everyone
  • Utilisateurs

Veuillez également vérifier le groupe local „Users“ sur l'autorité de certification. Par défaut, les „Authenticated Users“ y sont inscrits, mais il se peut que ceux-ci aient été supprimés par une mesure de durcissement. Dans ce cas, il peut arriver que la demande de certificat fonctionne pour les utilisateurs, mais pas pour les comptes d'ordinateur.

Veuillez également noter qu'il existe un droit contraire „Deny access this computer from the network“, dans lequel le compte de connexion ne doit pas non plus être inclus.

Si l'authentification échoue à ce stade, on trouvera dans la plupart des cas un événement d'audit correspondant sur l'autorité de certification dans le journal des événements de sécurité.

Une délégation Kerberos erronée peut également provoquer le même code d'erreur à cet endroit. Il en va de même pour la circonstance, si un utilisateur travaille avec un jeton d'ouverture de session expiré.

Si le compte d'utilisateur avec lequel le certificat a été demandé se trouve dans une structure globale Active Directory différente de celle de l'autorité de certification, une position de confiance mutuelle doit être établie.

Si l'on travaille avec Selective Authentication lors d'une demande de certificat sur des positions de confiance (en anglais Cross-Forest Autoenrollment), le compte demandeur doit posséder le droit „Allowed to Authenticate“ sur l'objet informatique de l'autorité de certification.

3. autorisations DCOM

Si l'obstacle RPC a été surmonté, une authentification à DCOM sera effectuée. Il existe une liste de contrôle d'accès spécifique pour l'utilisation de DCOM. Celle-ci peut être consultée dans la console d'administration des services de composants (dcomcnfg) sous „My Computer“.

Dans la carte „COM Security“, sous „Edit Limits“, le groupe de sécurité „Certificate Service DCOM Access“ doit avoir les autorisations suivantes :

  • Permissions d'accès : „Accès local“ et „Accès à distance“
  • Permissions de lancement et d'activation : „Lancement local“ et „Lancement à distance“.“

Dans le groupe de sécurité local „Certificate Service DCOM Access“ (CERTSVC_DCOM_ACCESS) se trouvent, par défaut, les „Authenticated Users“.

Un (explicable par cela) curiosité bien connue est que - si l'on installe une autorité de certification sur un contrôleur de domaine (ce qui est fortement déconseillé) - il n'est pas possible de faire une demande de certificat illimitée. En effet, les contrôleurs de domaine ne connaissent pas les groupes de sécurité locaux et le groupe de domaine „CERTSVC_DCOM_ACCESS“ doit être mis à jour en conséquence.

Il convient de noter que ces paramètres peuvent être contrôlés par une stratégie de groupe. Dans ce cas, les boutons „Edit Limits“ sont grisés et inutilisables.

Les paramètres se trouvent sous „Security Settings“ - „Local Policies“ - „Security Options“ et s'appellent

  • DCOM : restrictions d'accès à la machine dans la syntaxe du langage de définition des descripteurs de sécurité (SDDL)
  • DCOM : restrictions de lancement de la machine dans la syntaxe du langage de définition des descripteurs de sécurité (SDDL)

Il peut arriver que des „directives de durcissement“ bien intentionnées aient écrasé les autorisations DCOM en conséquence et que le groupe de sécurité „Certificate Service DCOM Access“ ait été supprimé.

3.1 Durcissement DCOM

En raison de CVE-2021-26414, Microsoft a mis en place un Mise à jour publiée pour durcir l'interface.

Si un système qui n'a pas encore installé le correctif tente de communiquer avec une autorité de certification qui a installé le correctif, l'erreur RPC_S_SERVER_UNAVAILABLE est également déclenchée et l'autorité de certification consigne l'événement no 10036 de la source DistributedCOM (nouvellement introduit par le correctif) dans le journal des événements du système :

4. interface de requête CertSrv

Si une connexion DCOM est autorisée sur l'ordinateur, il y a encore une ACL sur l'interface de requête CertSrv.

Sous „Component Services“ - „Computers“ - „My Computers“ - „DCOM Config“ se trouve maintenant l'interface de requête CertSrv, qui présente également une liste de contrôle d'accès (ACL).

Les autorisations suivantes doivent être activées dans la carte „Sécurité“ :

  • Permissions de lancement et d'activation : „Activation locale“ et „Activation à distance“ pour „Everyone“.“
  • Permissions d'accès : „Accès local“ et „Accès à distance“ pour „Everyone“.

5. autorisations sur l'autorité de certification

Enfin, le processus du serveur d'autorité de certification possède également une liste de contrôle d'accès (ACL).

N'oubliez pas non plus que le service d'autorité de certification doit bien sûr être lancé et fonctionner.

Si la connexion est parvenue jusqu'ici, mais qu'elle a été refusée en raison d'autorisations erronées, le code d'erreur CERTSRV_E_ENROLL_DENIED est retourné.

Après l'autorité de certification, il y a bien sûr encore les modèles de certificats qui possèdent également une liste de contrôle d'accès. Si aucune demande de certificat n'est possible pour un modèle de certificat donné en raison d'un manque d'autorisation, le code d'erreur CERTSRV_E_TEMPLATE_DENIED est retourné.

Si un modèle de certificat qui n'est pas connu de l'autorité de certification est demandé, il s'agit du code d'erreur CERTSRV_E_UNSUPPORTED_CERT_TYPE.

Pour une liste complète des erreurs renvoyées par l'autorité de certification en cas de refus d'une demande de certificat, voir Événement avec ID 53 de la source Microsoft-Windows-CertificationAuthority.

Les autorisations de demander des certificats auprès d'une autorité de certification sont également enregistrées dans le registre correspondant. pKIEnrollmentService dans l'Active Directory. Ainsi, ces autorisations peuvent être utilisées par exemple pour Mettre une autorité de certification intégrée à Active Directory (Enterprise Certification Authority) en mode maintenance.

Un simple test de fonctionnement

Un test de connexion avec la commande évidente „certutil -ping“ ne teste pas si les „ports hauts“ TCP sont ouverts dans le pare-feu et n'est donc pas suffisamment probant.

La séquence de commandes suivante dans Windows PowerShell permet de valider facilement toute la chaîne jusqu'à l'autorité de certification.

$ConfigString = "{Hostname-der-Zertifizierungsstelle}\{Common-Name-der-Zertifizierungsstelle}"
$CertRequest = New-Object -ComObject CertificateAuthority.Request
$CertRequest.GetCAProperty($ConfigString, 0x6, 0, 4, 0)

Il est bien sûr également possible que l'utilisateur connecté puisse s'authentifier avec succès, mais pas le compte informatique. C'est pourquoi il peut être judicieux de passer une fois (par ex. avec psexec) dans le contexte de l'ordinateur et de répéter le test à partir de là.

La variable „$ConfigString“ doit être remplie avec la chaîne de configuration pour l'autorité de certification correspondante. Celle-ci peut être facilement déterminée en tapant „certutil“ sur la ligne de commande.

En cas d'erreur, nous retrouverons le message connu ici.

En cas de succès, la commande doit renvoyer le „Common Name“ de l'autorité de certification.

Liens complémentaires :

Sources externes

Les commentaires sont fermés.

fr_FRFrançais
de_DEDeutsch en_USEnglish fr_FRFrançais