Partager via


Erreur 0x800706ba « Le serveur RPC n’est pas disponible » lorsque vous inscrivez un certificat

Lorsque vous essayez d’inscrire un certificat sur un serveur Windows Server, il échoue avec l’erreur 0x800706ba, « Le serveur RPC n’est pas disponible ». Cet article présente les étapes à suivre pour résoudre ce problème.

S’applique à : versions prises en charge de Windows Server
Numéro de base de connaissances d’origine : 4042719, 4516764, 5021150

Identifier le problème

Lorsque vous rencontrez ce problème, vous pouvez voir un ou plusieurs des symptômes suivants.

Note

Lorsque le problème se produit, si nous ajoutons le compte d’utilisateur utilisé pour demander le certificat au groupe administrateurs local sur l’autorité de certification, l’inscription réussit pour un modèle basé sur l’utilisateur. Toutefois, l’inscription sur un modèle basé sur un ordinateur retourne toujours la même erreur.

Messages d’erreur

Vous recevez des messages d’erreur qui ressemblent à ce qui suit lors de l’inscription de certificat.

Erreur 1

Une erreur s’est produite lors de l’inscription d’un certificat. Impossible de soumettre la demande de certificat à l’autorité de certification.
URL : <nom de domaine complet du serveur de> certificats\MyPKI
Erreur : le serveur RPC n’est pas disponible. 0x800706ba (WIN32 : 1322 RPC_S_SERVER_UNAVAILABLE)

Erreur 2

Capture d’écran montrant la fenêtre de progression de l’inscription de certificat.

Erreur 3

Capture d’écran montrant le message d’erreur lors de l’inscription du certificat.

Capture réseau

La trace réseau montre les requêtes LDAP (Lightweight Directory Access Protocol) réussies sur la partition de configuration dans Active Directory ; les modèles disponibles sont révélés dans la trace.

Ensuite, le serveur demandeur tente d’effectuer un appel de procédure distante (RPC) à l’autorité de certification et obtient la réponse « ACCÈS REFUSÉ ».

Par exemple :

10167 <time> <requesting server IP address> <CA IP address> ISystemActivator 918 RemoteCreateInstance request  
10174 <time> <CA IP address> <requesting server IP address> DCERPC 86 Fault: call_id: 3, Fragment: Single, Ctx: 1, status: nca_s_fault_access_denied

En outre, vous pouvez trouver la tentative de liaison MSRPC (Microsoft Remote Procedure Call) et l’erreur :

1093    <time>    92.5590216     (0)    SourceIP    52237 (0xCC0D)    DestIP    135 (0x87)    MSRPC    MSRPC:c/o Bind: IRemoteSCMActivator(DCOM) UUID{000001A0-0000-0000-C000-000000000046}  Call=0x3  Assoc Grp=0x8A9E  Xmit=0x16D0  Recv=0x16D0  
1097    <time>    92.5940283     (652)    SourceIP    135 (0x87)    DestIP    52237 (0xCC0D)    MSRPC    MSRPC:c/o Bind Nack:  Call=0x3  Reject Reason: invalid_checksum

Dans une trace réseau, vous trouvez l’erreur suivante :

État : ERREUR MSRPC :c/o : Call=0x3 Context=0x1 Status=0x5 (Accès refusé)

Par exemple :

<Certificate_Server> <Client> DCOM  DCOM:RemoteCreateInstance Request, DCOM Version=5.7  Causality Id={7CFF2CD3-3165-4098-93D6-4077D1DF7351}
<Client> <Certificate_Server> MSRPC MSRPC:c/o Fault:  Call=0x3  Context=0x1  Status=0x5  Cancels=0x0 

Journal des événements

Si l’audit est activé, une erreur DCOM (Distributed Component Object Model) peut être observée sur le serveur d’autorité de certification détaillant une tentative d’ouverture de session ANONYME :

Log Name: System  
Source: Microsoft-Windows-DistributedCOM  
Date: <date>  
Event ID: 10027  
Task Category: None  
Level: Warning  
Keywords: Classic  
User: ANONYMOUS LOGON  
Computer: <CA FQDN>

Description:  
The machine wide limit settings do not grant Remote Activation permission for COM Server applications to the user NT AUTHORITY\ANONYMOUS LOGON SID (S-1-5-7) from address <IP address> running in the application container Unavailable SID (Unavailable). This security permission can be modified using the Component Services administrative tool.

Note

L’ID d’événement 82 est consigné dans les journaux d’application si l’inscription automatique échoue avec la même erreur.

Autres symptômes et journaux d’activité

  • L’appel doit être effectué avec dce_c_authn_level_pkt_integrity niveau d’intégrité RPC qui applique Kerberos ou New Technology LAN Manager (NTLM) comme mécanisme d’authentification. Ce comportement est appliqué par défaut à partir de la version 6B.22 KB5004442 : gérer les modifications pour le contournement des fonctionnalités de sécurité windows DCOM Server (CVE-2021-26414).
  • Lorsque le client envoie une demande de KRB_AP_REQ, il est rejeté côté serveur.
  • Le serveur tente d’obtenir un jeton d’accès pour l’utilisateur qui a présenté le service TGS (Kerberos Ticket Granting Service) et échoue avec l’erreur 0xc000015b, « STATUS_LOGON_TYPE_NOT_GRANTED ».

Cause 1 : Configurations de stratégie de groupe incorrectes

Ce problème peut se produire en raison de l’une des raisons suivantes :

  1. La stratégie de groupe Accéder à cet ordinateur à partir du réseau est définie et le compte d’utilisateur utilisé pour inscrire le certificat n’est pas ajouté. Par défaut, la stratégie est remplie par les groupes : administrateurs, opérateurs de sauvegarde, tout le monde et utilisateurs.
  2. La stratégie de groupe Refuser l’accès à cet ordinateur à partir du réseau est définie, et tout le monde, utilisateurs ou groupe de sécurité auquel appartient l’utilisateur est ajouté.

Ces stratégies de groupe se localisent dans Configuration ordinateur\Paramètres Windows\Paramètres de sécurité\Stratégies locales\Affectation des droits utilisateur.

Note

Vous pouvez exécuter whoami /groups pour identifier les groupes du compte d’utilisateur ou utiliser les utilisateurs et ordinateurs Active Directory pour identifier les groupes appartenant à l’utilisateur ou au compte d’ordinateur.

Étant donné que le compte d’utilisateur utilisé pour l’inscription de certificat échoue à l’authentification à l’aide de Kerberos, le mécanisme d’authentification est rétrogradé en « ouverture de session anonyme ». L’ouverture de session échoue au niveau DCOM.

Comment identifier

  1. Ouvrez une invite de commandes avec élévation de privilèges sur le serveur de certificats.

  2. Exécutez la commande gpresult /h. Par exemple, gpresult /h appliedgpo.html.

  3. Ouvrez le fichier .html généré et passez en revue la section :
    Paramètres \ Stratégies \ Paramètres Windows \ Stratégies locales \ Attribution des droits utilisateur

    • Accéder à cet ordinateur à partir du réseau
    • Interdire l’accès à cet ordinateur à partir du réseau
  4. Notez le nom de l’objet de stratégie de groupe gagnant.

    Capture d’écran montrant la sortie gpresult.

Pour résoudre ce problème, modifiez l’objet de stratégie de groupe gagnant.

Note

Les paramètres configurés sur les objets de stratégie de groupe (GPO) sont pour une raison quelconque. Vous devez donc communiquer avec votre équipe de sécurité avant d’apporter des modifications.

Ajoutez les groupes d’utilisateurs appropriés à l’accès à cet ordinateur à partir de la stratégie de groupe réseau . Par exemple :

Capture d’écran montrant la fenêtre des propriétés de la stratégie de groupe « Accéder à cet ordinateur à partir du réseau ».

Ensuite, supprimez le groupe auquel appartient le compte d’utilisateur ou le compte d’ordinateur à partir de l’accès Refusé à cet ordinateur à partir de la stratégie de groupe réseau .

Pour plus d’informations, consultez Accéder à cet ordinateur à partir du réseau - paramètre de stratégie de sécurité.

Cause 2 : « NT Authority\Users authentifiés » manquant dans le groupe « Utilisateurs » du serveur de certificats ou toute autre autorisation par défaut

Voici les autorisations par défaut :

  • Contoso\Domain Users
  • NT AUTHORITY\Utilisateurs authentifiés
  • NT AUTHORITY\INTERACTIVE

Pour résoudre ce problème, ouvrez Utilisateurs et groupes locaux sur le serveur de certificats, recherchez le groupe Utilisateurs et ajoutez les groupes manquants.

Cause 3 : « NT AUTHORITY\Users authentifiés » manquant dans le groupe local « Certificate Service DCOM Access » du serveur de certificats

Pour résoudre ce problème, effectuez les étapes suivantes :

  1. Ouvrez les utilisateurs et groupes locaux sur le serveur de certificats.
  2. Recherchez le groupe d’accès DCOM du service de certificats.
  3. Ajoutez NT AUTHORITY\Utilisateurs authentifiés.

Cause 4 : EnableDCOM n’est pas défini sur Y sur le client et le serveur d’autorité de certification

Pour résoudre ce problème, effectuez les étapes suivantes :

  1. Recherchez cette clé HKEY_LOCAL_MACHINE\Software\Microsoft\OLEde Registre .
  2. Vérifiez si les données de la valeur de Registre EnableDCOM sont définies sur Y.
  3. S’il s’agit de N, remplacez-le par Y, puis redémarrez l’ordinateur.

Cause 5 : Les restrictions d’appel de procédure distante ne sont pas appliquées sur le serveur de certificats

Pour identifier le problème, vérifiez que l’objet de stratégie de groupe est appliqué au serveur de certificats. Effectuez les étapes suivantes :

  1. Ouvrez une invite de commandes avec élévation de privilèges sur le serveur de certificats.

  2. Exécutez la commande gpresult /h. Par exemple, gpresult /h appliedgpo.html.

  3. Ouvrez le fichier .html et identifiez l’objet de stratégie de groupe gagnant où les restrictions pour la stratégie de groupe client RPC non authentifiée sont configurées sur Non configuré.

    La stratégie de groupe localise les modèles d’administration \ Système \ Appel de procédure distante \ Restrictions pour le client RPC non authentifié.

Cause 6 : « Accès DCOM du service de certificat » manquant à partir des autorisations d’accès à la sécurité COM ou des autorisations de lancement et d’activation

Lorsque le rôle Services de certificats Active Directory est installé sur un serveur, le groupe d’accès DCOM du service de certificats local est automatiquement autorisé à accéder à l’outil d’administration des services de composants. Si ces autorisations par défaut ont été supprimées, vous pouvez rencontrer les symptômes décrits dans cet article. Pour vérifier que les autorisations appropriées sont en place, procédez comme suit :

  1. Ouvrez le composant logiciel enfichable MMC (Component Services Microsoft Management Console) sous Outils d’administration Windows.
  2. Dans le volet gauche, développez Ordinateurs des services>de composants.
  3. Cliquez avec le bouton droit sur Mon ordinateur, sélectionnez Propriétés, puis sélectionnez l’onglet Sécurité COM.
  4. Sous Autorisations d’accès, sélectionnez Modifier les limites.
  5. Vérifiez que le groupe d’accès DCOM du service de certificat local s’affiche dans la liste des noms d’utilisateurs ou de groupes et bénéficie des autorisations d’accès local et d’accès à distance. Si ce n’est pas le cas, ajoutez-le et accordez les autorisations appropriées. Sélectionnez OK pour fermer la boîte de dialogue Autorisation d’accès.
  6. Sous Lancement et autorisations d’activation, sélectionnez Modifier les limites.
  7. Vérifiez que le groupe d’accès DCOM du service de certificats local s’affiche dans la liste des noms d’utilisateurs ou de groupes et reçoit les autorisations d’activation locale et d’activation à distance. Si ce n’est pas le cas, ajoutez-le et accordez les autorisations appropriées. Sélectionnez OK pour fermer la boîte de dialogue Lancer et Autorisations d’activation.

Référence

Pour plus d’informations, consultez Restrictions pour les clients RPC non authentifiés : stratégie de groupe qui frappe votre domaine en face.