Supposons le scénario suivant :
- Un modèle de certificat est configuré pour la demande automatique de certificats (auto-inscription).
- Le modèle de certificat est publié sur une autorité de certification intégrée à Active Directory (Enterprise Certification Authority).
- Les utilisateurs ou les ordinateurs configurés pour la demande automatique de certificats ne demandent toutefois pas les certificats comme prévu.
Vous trouverez ci-dessous un guide de dépannage.
Cet article décrit le dépannage de Inscription automatique via RPC/DCOM. Bon nombre des déclarations peuvent également s'appliquer à la Demande de certificat via WSTEP (CEP/CES) transférer.
Délimiter le domaine problématique
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.
Il faut tout d'abord déterminer dans quel contexte l'erreur se produit.
- Agit-il pour le compte d'un utilisateur pour obtenir des certificats ?
- Est-il responsable des certificats d'un ordinateur ?
Pour rechercher les erreurs lors de la demande de certificats utilisateur, il est généralement nécessaire de se connecter à la session de l'utilisateur concerné. Si l'erreur survient dans le contexte d'un ordinateur, il est souvent possible de travailler sur le système avec un identifiant administratif sans l'utilisateur.
Possibilités de dépannage à distance
Les méthodes suivantes permettent donc d'accéder au système concerné pour le dépannage :
- Partage d'écran (avec et dans le contexte de l'utilisateur final)
- Connexion administrative / interactive (console/bureau à distance)
- Administratif / via console à distance via PSExec Remoting (non recommandé)
- Administratif / via console à distance via PowerShell Remoting
Il n'est généralement pas recommandé de se connecter à un système client avec un compte de domaine administratif, car le risque de vol d'identifiants est très élevé.
Étant donné que le plus petit dénominateur commun est souvent la ligne de commande, le dépannage sera également effectué à l'aide de celle-ci.
Classification du type d'erreur
En principe, les erreurs d'inscription automatique peuvent être classées dans les catégories suivantes, qui sont décrites plus en détail ci-dessous :
- La demande de certificat n'est pas effectuée.
- La demande de certificat est effectuée, mais n'arrive pas à l'autorité de certification.
- La demande de certificat est effectuée, elle parvient à l'organisme de certification, mais y est refusée.
La demande de certificat n'est pas effectuée.
Si la demande de certificat n'est pas faite, les points suivants doivent être examinés :
- Existe-t-il déjà un certificat correspondant au modèle de certificat concerné ?
- L'inscription automatique est-elle activée sur le client ?
- Le processus d'inscription automatique est-il déclenché ?
- Le compte concerné est-il autorisé à demander un certificat ?
- Le client peut-il établir la chaîne de confiance avec l'autorité de certification ?
- Le client peut-il générer une paire de clés ?
Détails : existe-t-il déjà un certificat correspondant au modèle de certificat concerné ?
Pour le contexte de l'utilisateur :
certutil -user -store my
Pour le contexte informatique :
certutil -store my
Cette commande affiche également les certificats archivés. Il est donc plus clair d'utiliser Windows PowerShell.
Pour le contexte de l'utilisateur :
Get-ChildItem -Path Cert:\CurrentUser\My
Pour le contexte informatique :
Get-ChildItem -Path Cert:\LocalMachine\My
Détails : l'inscription automatique est-elle activée sur le client ?
Si l'inscription automatique n'est pas activée sur le client, cela se traduit généralement par l'absence de demande de certificat malgré les déclencheurs clairs.
La configuration de l'inscription automatique est généralement définie par une stratégie de groupe. Cependant, le simple fait qu'une stratégie de groupe existe, soit configurée et liée ne signifie pas pour autant qu'elle a été transmise au client.
Une cause possible peut être, par exemple, une connectivité de domaine manquante ou un filtrage basé sur un groupe de sécurité ou un autre critère.
Veuillez également noter que aucune stratégie de groupe n'est appliquée lors de l'exécution d'un processus via RunAs et, par conséquent, dans certaines circonstances (par exemple lors de la première connexion via RunAs), aucune auto-inscription n'aura lieu.
- L'activation du processus d'inscription automatique („ Configuration model “) entraîne tout d'abord le chargement d'une réplique de l'objet „ Public Key Services “ à partir de la partition de configuration d'Active Directory. Elle doit au moins être activée pour que les autres options puissent être utilisées.
- Le paramètre „Renouveler les certificats expirés, mettre à jour les certificats en attente et révoquer les certificats révoqués“ provoque le renouvellement automatique des certificats expirés, à condition qu'ils aient été émis par une autorité de certification intégrée à Active Directory. De plus, les demandes de certificats approuvées sont récupérées auprès des autorités de certification, si elles sont disponibles. Les certificats révoqués sont archivés.
- Le paramètre „Mettre à jour les certificats qui utilisent des modèles de certificat“ permet de demander automatiquement les certificats qui sont validés pour l'auto-inscription du demandeur. Elle doit donc être activée sur le client afin que les certificats puissent être demandés automatiquement.
La configuration de l'inscription automatique est enregistrée localement dans le registre :
Pour le contexte de l'utilisateur :
HKCU\Software\Policies\Microsoft\Cryptography\AutoEnrollment\AEPolicy
Pour le contexte informatique :
HKLM\Software\Policies\Microsoft\Cryptography\AutoEnrollment\AEPolicy
Les différentes options de configuration pour „ AEPolicy “ sont décrites ci-dessous.
| Valeur | Description | Résultat |
|---|---|---|
| 0x00000000 ou non disponible | Le processus d'auto-enrôlement est active „Mise à jour des certificats qui utilisent des modèles de certificats" est désactivé | pas de demande automatique de certificats pas de renouvellement automatique des certificats expirés pas de collecte automatique des demandes de certificats approuvées pas de archivage automatique des certificats révoqués |
| 0x00000001 | Le processus d'auto-enrôlement est active „Mise à jour des certificats qui utilisent des modèles de certificats" est active „Renouveler les certificats expirés, mettre à jour les certificats en attente et révoquer les certificats révoqués" est désactivé | demande automatique de certificats pas de renouvellement automatique des certificats expirés pas de collecte automatique des demandes de certificats approuvées pas de archivage automatique des certificats révoqués |
| 0x00000006 | Le processus d'auto-enrôlement est active „Mise à jour des certificats qui utilisent des modèles de certificats" est désactivé „Renouveler les certificats expirés, mettre à jour les certificats en attente et révoquer les certificats révoqués" est active | pas de demande automatique de certificats renouvellement automatique des certificats expirés collecte automatique des demandes de certificats approuvées archivage automatique des certificats révoqués |
| 0x00000007 | Le processus d'auto-enrôlement est active „Mise à jour des certificats qui utilisent des modèles de certificats" est active „Renouveler les certificats expirés, mettre à jour les certificats en attente et révoquer les certificats révoqués" est active | demande automatique de certificats renouvellement automatique des certificats expirés collecte automatique des demandes de certificats approuvées archivage automatique des certificats révoqués |
| 0x00008000 | AutoEnrollment est désactivé | pas de demande automatique de certificats pas de renouvellement automatique des certificats expirés pas de collecte automatique des demandes de certificats approuvées pas de archivage automatique des certificats révoqués |
Pour que la demande de certificat automatique puisse être effectuée, „ AEPolicy “ doit donc avoir la valeur 0x1 ou plutôt la valeur 0x7 . La valeur peut être consultée à l'aide des commandes suivantes.
Pour le contexte de l'utilisateur :
certutil -v -user -getreg -GroupPolicy enroll\AEPolicy
Il est également possible de lire directement la clé dans le registre :
reg query HKCU\Software\Policies\Microsoft\Cryptography\AutoEnrollment /v AEPolicy
Pour le contexte machine :
certutil -v -getreg -GroupPolicy enroll\AEPolicy
Il est également possible de lire directement la clé dans le registre :
reg query HKLM\Software\Policies\Microsoft\Cryptography\AutoEnrollment /v AEPolicy
La valeur peut également être consultée dans le registre via Windows PowerShell.
Pour le contexte de l'utilisateur :
(Get-ItemProperty -Path HKCU:\Software\Policies\Microsoft\Cryptography\AutoEnrollment).AEPolicy
Pour le contexte machine :
(Get-ItemProperty -Path HKLM:\Software\Policies\Microsoft\Cryptography\AutoEnrollment).AEPolicy
Les paramètres peuvent également être définis sans stratégie de groupe à l'aide des commandes suivantes. La valeur du code d'exemple doit être ajustée si nécessaire à l'aide du tableau ci-dessus.
Pour le contexte de l'utilisateur :
New-Item -Path HKCU:\Software\Policies\Microsoft\Cryptography\AutoEnrollment
Set-ItemProperty -Path HKCU:\Software\Policies\Microsoft\Cryptography\AutoEnrollment -Name AEPolicy -Value 0x7 -Force
Pour le contexte machine :
New-Item -Path HKLM:\Software\Policies\Microsoft\Cryptography\AutoEnrollment
Set-ItemProperty -Path HKLM:\Software\Policies\Microsoft\Cryptography\AutoEnrollment -Name AEPolicy -Value 0x7 -Force
Détails : le processus d'inscription automatique est-il déclenché ?
Les déclencheurs de l'exécution du processus d'auto-enrollment sur les membres du domaine sont
- à l'ouverture de session de l'utilisateur (sur les ordinateurs, lorsque le compte de l'ordinateur se connecte, c'est-à-dire au démarrage du système)
- Par minuterie toutes les 8 heures.
- Lors d'une mise à jour de la stratégie de groupe, à condition qu'il y ait eu un changement.
Dans le planificateur de tâches, les tâches correspondantes se trouvent sous „ Microsoft “ – „ Windows “ – „ CertificateServicesClient “.
Il est donc tout à fait possible qu'aucun déclencheur n'ait encore été activé pour la demande de certificat (voir également l'article „Aucun certificat n'est demandé via l'inscription automatique lorsqu'un utilisateur est connecté via un réseau privé virtuel (VPN).„ ).
Le processus peut être lancé manuellement à l'aide des commandes suivantes.
Pour le contexte de l'utilisateur :
certutil -pulse -user
Pour le contexte informatique :
certutil -pulse
Le statut des tâches dans le planificateur de tâches permet de déterminer si le processus a été lancé. Cela peut également être effectué via Windows PowerShell :
Pour le contexte de l'utilisateur :
Get-ScheduledTask ` -TaskPath \Microsoft\Windows\CertificateServicesClient\ ` -TaskName UserTask | Select-Object -Property State
Pour le contexte informatique :
Get-ScheduledTask ` -TaskPath \Microsoft\Windows\CertificateServicesClient\ ` -TaskName SystemTask | Select-Object -Property State
Remarque : il se peut également que le processus s'exécute en permanence et ne se termine jamais. C'est le cas, par exemple, lorsqu'une intervention manuelle de l'utilisateur est nécessaire, mais que celui-ci ne procède pas à cette interaction.
La dernière heure d'exécution et le résultat de la tâche peuvent également être consultés via Windows PowerShell.
Pour le contexte de l'utilisateur :
Get-ScheduledTaskInfo ` -TaskPath \Microsoft\Windows\CertificateServicesClient\ ` -TaskName UserTask
Pour le contexte informatique :
Get-ScheduledTaskInfo ` -TaskPath \Microsoft\Windows\CertificateServicesClient\ ` -TaskName SystemTask
Détails : le compte concerné est-il autorisé à demander un certificat ?
Pour qu'une demande de certificat puisse être effectuée, l'utilisateur ou l'ordinateur doit être autorisé à deux endroits :
- Dans les autorisations de sécurité du modèle de certificat concerné
- Dans les paramètres de sécurité de l'autorité de certification qui propose le modèle de certificat
Ces deux informations sont enregistrées dans Active Directory. Si l'utilisateur n'est pas autorisé, aucune demande de certificat n'est effectuée.
Soyez prudent lorsque vous utilisez des groupes de sécurité pour attribuer des autorisations : le fait que l'utilisateur ou l'ordinateur soit membre d'un groupe de sécurité dans Active Directory ne signifie pas nécessairement que cela a déjà été appliqué dans le ticket Kerberos. Si l'utilisateur ne s'est pas reconnecté depuis son ajout au groupe ou si l'ordinateur n'a pas été redémarré, l'appartenance au groupe n'a pas encore été appliquée.
Le client d'inscription automatique n'inspecte pas le ticket Kerberos local, mais les autorisations d'accès dans Active Directory. Par conséquent, le phénomène suivant se produirait : une demande de certificat serait déclenchée, mais elle serait rejetée par l'autorité de certification en raison d'un manque d'autorisation (Événement n° 53 avec le code d'erreur CERTSRV_E_TEMPLATE_DENIED sur l'autorité de certification).
Les commandes suivantes permettent de vérifier si l'appartenance au groupe a déjà été représentée localement.
Pour le contexte de l'utilisateur :
gpresult /R /Scope:User
Pour le contexte informatique :
gpresult /R /Scope:Computer
Les autorisations pour la demande de certificat peuvent également être vérifiées à l'aide de la commande suivante :
certutil -config "Hostname-der-CA\Common-Name-der-CA" -catemplates
Dans les paramètres par défaut, le droit de demander des certificats auprès de l'autorité de certification est garanti par une entrée correspondante pour les „ utilisateurs authentifiés “.
Cette information est synchronisée dans Active Directory. Les clients peuvent ainsi s'informer sur leurs autorisations avant même de déposer leur demande. S'ils ne sont pas autorisés, aucune demande de certificat n'est déposée.
Les causes typiques de l'absence d'autorisations sur l'autorité de certification sont décrites dans les articles suivants :
- Mettre une autorité de certification intégrée à Active Directory (Enterprise Certification Authority) en mode maintenance
- La demande de certificat échoue avec le message d'erreur "A valid certification authority (CA) configured to issue certificates based on this template cannot be located, or the CA does not support this operation, or the CA is not trusted".
Détails : le client peut-il établir la chaîne de confiance avec l'autorité de certification ?
Si l'on tente de demander le certificat via la console de gestion Microsoft (certmgr.msc pour le contexte utilisateur et certlm.msc pour le contexte de l'ordinateur), et que le modèle de certificat s'affiche mais n'est pas sélectionnable avec le message d'erreur „ Une autorité de certification (CA) valide configurée pour émettre des certificats basés sur ce modèle est introuvable, ou la CA ne prend pas en charge cette opération, ou la CA n'est pas fiable. “, il est possible que le client ne connaisse pas l'autorité de certification émettrice correspondante, c'est-à-dire qu'il ne puisse pas établir la chaîne de confiance.
Dans ce cas, il convient de vérifier les points suivants :
- L'autorité de certification racine (angl. "Root CA") est-elle enregistrée dans le magasin d'autorités de certification racine de confiance correspondant ?
- Toutes les autorités de certification intermédiaires (si elles existent) sont-elles stockées dans la liste des certificats d'autorités de certification intermédiaires ? (Cette liste est automatiquement remplie sur les clients de domaine à partir de l'objet "AIA" du Public Key Services Container dans l'Active Directory. Il convient donc de vérifier si les certificats y sont également déposés).
Voir aussi à ce sujet
Détails : le client peut-il générer une paire de clés ?
La paire de clés ne peut pas être générée, par exemple parce que le Fournisseur de services cryptographiques ou fournisseur de stockage de clés n'existe pas ou ne fonctionne pas (sur le client, le Événement n° 57 déclencher).
La commande suivante permet de vérifier si un fournisseur de stockage de clés donné peut être utilisé sur le client.
certutil -csp "Microsoft Platform Crypto Provider" -csptest
En cas de succès, le message suivant serait généré :
CertUtil: -csptest-Befehl wurde erfolgreich ausgeführt.
En cas d'erreur, un message similaire au suivant serait généré :
CertUtil: -csptest command FAILED: 0x80090030 (-2146893776 NTE_DEVICE_NOT_READY)
CertUtil: The device that is required by this cryptographic provider is not ready for use.
Il est également possible de créer un certificat auto-signé à l'aide de Windows PowerShell en utilisant le fournisseur de stockage de clés approprié :
New-SelfSignedCertificate ` -Provider "Microsoft Platform Crypto Provider" ` -KeyLength 2048 ` -Subject "CN=Test" ` -CertStoreLocation Cert:\CurrentUser\My
Voir aussi l'article „ Il n'est pas possible de demander un certificat, car le modèle de certificat ne s'affiche pas. Le message d'erreur suivant s'affiche : „ Impossible de trouver un CSP valide sur l'ordinateur local. “„ .
La demande de certificat est effectuée, mais n'arrive pas à l'autorité de certification.
Si la demande de certificat est effectuée mais n'arrive pas à l'autorité de certification, les points suivants doivent être examinés :
- L'organisme de certification est-il joignable et peut-on s'y authentifier ?
- Un certificat peut-il être demandé manuellement à partir du modèle de certificat concerné ?
L'organisme de certification est-il accessible et peut-on s'y authentifier ?
Les erreurs pouvant survenir en raison d'un problème de connexion réseau ou d'authentification au niveau de l'interface RPC/DCOM génèrent le code d'erreur RPC_S_SERVER_UNAVAILABLE.
Voir à ce sujet l'article „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)"„ .
Avec le service Web d'enregistrement de certificats (CES), le client renvoie le même code d'erreur lorsque le service serveur est en cours d'exécution, mais ne parvient pas à se connecter à l'autorité de certification. Cependant, si le service serveur ne peut pas démarrer parce que l'autorité de certification n'est pas accessible à ce moment-là, le code d'erreur WS_E_ENDPOINT_FAILURE mais qui, dans la plupart des cas, peut être décomposé en RPC_S_SERVER_UNAVAILABLE dans le backend.
La séquence de commandes suivante dans Windows PowerShell permet de valider facilement l'ensemble de la chaîne jusqu'à l'autorité de certification (via RPC/DCOM).
$ConfigString = "{Hostname-der-Zertifizierungsstelle}\{Common-Name-der-Zertifizierungsstelle}"
$CertRequest = New-Object -ComObject CertificateAuthority.Request
$CertRequest.GetCAProperty($ConfigString, 0x6, 0, 4, 0)
En cas de succès, la commande doit renvoyer le nom commun de l'autorité de certification.
Pour le contexte informatique, il faut d'abord passer à celui-ci (NT-AUTHORITY\SYSTEM). Cela peut se faire par exemple via psexec :
psexec -s -i powershell.exe
La commande précédente peut ensuite être exécutée dans le contexte du compte informatique.
Détails : un certificat peut-il être demandé manuellement à partir du modèle de certificat concerné ?
La demande de certificat pour un modèle de certificat spécifique peut être déclenchée manuellement (c'est-à-dire sans auto-inscription) à l'aide de la commande suivante.
Pour le contexte de l'utilisateur :
certreq -q -enroll "Name-der-Zertifikatvorlage"
Pour le contexte informatique :
certreq -q -machine -enroll "Name-der-Zertifikatvorlage"
L'appel de la commande sans le paramètre -q ouvre une boîte de dialogue GUI. Dans une connexion shell distante, cela entraîne l'arrêt du processus.
Si la demande de certificat échoue avec le code d'erreur „ CERTSRV_E_UNSUPPORTED_CERT_TYPE “, consultez l'article „La demande de certificat échoue avec le message d'erreur „The requested certificate template is not supported by this CA. 0x80094800 (-2146875392 CERTSRV_E_UNSUPPORTED_CERT_TYPE)“.“„ .
Autres causes possibles
- L'autorité de certification ne parvient pas à établir la connexion requise (dans le cas des certificats de contrôleur de domaine). Voir à ce sujet l'article „La demande de certificat pour les contrôleurs de domaine échoue avec le message d'erreur "The RPC server is unavailable. 0x800706ba (WIN32 : 1722 RPC_S_SERVER_UNAVAILABLE)"..
- Les autorisations de sécurité du système d'exploitation de l'autorité de certification ne permettent pas de demander un certificat. Voir à ce sujet l'article „La demande de certificat échoue avec le message d'erreur „ La demande n'est pas prise en charge. 0x80070032 (WIN32 : 50 ERROR_NOT_SUPPORTED) “.“„ .
La demande de certificat est effectuée, elle parvient à l'organisme de certification, mais y est refusée.
Si la demande de certificat parvient à l'autorité de certification, mais qu'elle y est refusée, celle-ci enregistrera l'événement n° 53. Causes possibles et solutions sont décrits dans l'article correspondant.
Augmenter le niveau de journalisation pour l'inscription automatique sur le client
Pour mieux cerner un problème, il peut être utile d'augmenter le niveau de journalisation pour l'inscription automatique sur le client (voir également l'article „Activer la journalisation pour la demande automatique de certificat (auto-enrollment)„ ).
La commande suivante permet d'activer la journalisation pour le contexte utilisateur et le contexte système (tous les événements de type „ Error “, „ Warning “ et „ Information “ sont affichés) :
certutil –setreg Enroll\LogLevel 4
Les modifications sont activées immédiatement, sans nouvelle connexion ni redémarrage.
Une demande de certificat peut ensuite être déclenchée. Les événements correspondants devraient désormais figurer dans le journal des événements de l'application.
Structure d'une séquence d'événements habituelle
Une séquence habituelle se présente comme suit :
| Source | numéro | Texte de l'événement |
|---|---|---|
| Microsoft-Windows-CertificateServicesClient-AutoEnrollment | 2 | Enregistrement automatique du certificat pour %1 démarré. |
| Microsoft-Windows-CertificateServicesClient-AutoEnrollment | 4 | L'inscription automatique au certificat pour %1 a invoqué l'API d'inscription. |
| Client des services de certificats Microsoft Windows | 1 | Le client des services de certificats a été démarré avec succès. |
| Client des services de certificats Microsoft Windows | 3 | Le client des services de certificats a détecté une connectivité réseau. |
| Microsoft-Windows-CertificateServicesClient-CertEnroll | 65 | L'inscription du certificat pour %1 est authentifiée avec succès par le serveur de stratégie %2 à l'aide du mécanisme d'authentification %5 (informations d'identification : %4). ID de stratégie : %3 |
| Microsoft-Windows-CertificateServicesClient-CertEnroll | 64 | Enregistrement du certificat pour %1 : chargement réussi de la stratégie à partir du serveur de stratégies %2 |
| (le cas échéant, autres) | ||
| Microsoft-Windows-CertificateServicesClient-AutoEnrollment | 5 | Inscription automatique du certificat pour %1 renvoyée depuis l'API d'inscription. |
| Microsoft-Windows-CertificateServicesClient-AutoEnrollment | 3 | Inscription automatique au certificat pour %1 terminée. |
| Client des services de certificats Microsoft Windows | 2 | Le client des services de certificats a été arrêté. |
Interrogation des événements
La commande Windows PowerShell suivante permet de lire les événements :
Get-WinEvent -FilterHashtable @{
Logname='Application'
ProviderName=@('Microsoft-Windows-CertificateServicesClient-AutoEnrollment','Microsoft-Windows-CertificateServicesClient','Microsoft-Windows-CertificateServicesClient-CertEnroll')
StartTime=(Get-Date -Hour 0 -Minute 0 -Second 0)
} | Sort-Object -Property TimeCreated -Descending
Les critères suivants sont appliqués :
- Source : événements des trois catégories concernées
- Période : les événements d'aujourd'hui
- Tri : par date décroissante
Enregistrer les événements dans un fichier
Les événements peuvent également être enregistrés au format CSV afin d'effectuer l'analyse en dehors du système défectueux :
... | Select-Object -Property TimeCreated,Id,LevelDisplayName,Message | Export-Csv -Path .\$($env:Computername)_ClientEvents.csv -Encoding Unicode -NoTypeInformation
Après filtrage, l'exportation vers un fichier .evt ou .evtx n'est plus possible.
Liens complémentaires :
- Principes de base : fournisseur de services cryptographiques (CSP) et fournisseur de stockage de clés (KSP)
- Règles de pare-feu requises pour Active Directory Certificate Services
- Détails de l'événement ID 53 de la source Microsoft-Windows-CertificationAuthority
- Bases de la demande manuelle et automatique de certificats via Lightweight Directory Access Protocol (LDAP) et Remote Procedure Call / Distributed Common Object Model (RPC/DCOM)
Sources externes
- Dépannage de l'inscription automatique (Microsoft)
- Comment dépanner l'inscription de certificats dans le composant logiciel enfichable Certificats MMC (Microsoft)
- Dépannage des services de certificats Active Directory (AD CS) : inscription automatique des certificats (Microsoft)
- Configurer l'inscription automatique des certificats (Microsoft)
- Dépannage de l'inscription au certificat (Microsoft, lien archive)
- Mettre à jour l'appartenance à un groupe informatique sans redémarrer (shellandco.net)
- Comment actualiser l'appartenance à des groupes AD sans redémarrer/se déconnecter ? (Hub Windows OS)
- certutil (Microsoft)
Français 
Deutsch 
English
Les commentaires sont fermés.