Active Directory Authentification par cartes à puce CPX

— Rôles Active Directory —

Installation du rôle ADCS | Gestion des certificats | Authentification par cartes à puce

---

Installation du rôle ADDS | Sécuriser son environnement Active Directory | Windows LAPS | gMSA

---

Archives : Contrôleur de domaine Windows Server 2003 | Intégration Client Ubuntu sur AD Windows Server 2003 | Windows Server 2008

Prérequis

Infrastructure d’authentification

Pour pouvoir mettre en place une authentification par carte à puce, vous devez disposer :

• D’au moins un serveur Active Directory. Dans notre cas, il s’agit du serveur SRVDC1. Le domaine Active Directory s’appelle CNLABS (CNLABS.lan).
• D’une autorité de certification racine d’entreprise pleinement opérationnelle. Dans notre cas, il s’agit du serveur SRVDC1. L’autorité de certification s’appelle CNLABS-CA.

Au niveau des postes clients, il sera nécessaire de disposer :

• De la dernière version cryptolib à jour.
• D’un lecteur de carte à puce compatible.

L’infrastructure présentée ci-dessus – pour illustrer la présente documentation – est purement fictive.

Certificats de l’autorité racine émettant les cartes à puces

1. Se rendre sur le site web de l’autorité de certification IGC-Santé accessible depuis le lien http://igc-sante.esante.gouv.fr.
2. Télécharger les 8 certificats mis à disposition par l’autorité de certification et correspondant.
3. Vérifier les certificats téléchargés :
   • ACI-EL-ORG.cer : certificat d’autorité de certification intermédiaire gamme élémentaire domaine organisations.
   • ACI-EL-PP.cer : certificat d’autorité de certification intermédiaire gamme élémentaire domaine personnes.
   • ACI-FO-PP.cer : certificat d’autorité de certification intermédiaire gamme fort domaine personnes.
   • ACI-ST-ORG.cer : certificat d’autorité de certification intermédiaire gamme standard domaine organisations.
   • ACI-ST-PP.cer : certificat d’autorité de certification intermédiaire gamme standard domaine personnes.
   • ACR-EL.cer : certificat d’autorité de certification racine gamme élémentaire.
   • ACR-FO.cer : certificat d’autorité de certification racine gamme fort.
   • ACR-ST.cer : certificat d’autorité de certification racine gamme standard.

Installation des certificats de l’IGC-Santé

Les certificats racines et intermédiaires de l’autorité de certification de l’IGC-Santé doivent être installés :

• Sur les contrôleurs de domaine via une GPO.
• Sur le serveur de l’autorité de certification d’entreprise si ce dernier est sur un serveur dédié via une GPO.
• Sur les postes clients via une GPO.

Dans notre usage, nous allons créer la GPO O_WINDOWS_SMARTCARD qui sera liée au groupe Domain Controllers ainsi qu’à la racine de l’organisation.

1. Ouvrir une console MMC puis ajouter le composant logiciel enfichable Gestion des stratégies de groupe.
2. Créer la GPO O_WINDOWS_SMARTCARD à la racine du domaine de l’organisation (ou créer une nouvelle GPO pour cette occasion). Dans notre cas, cette GPO est liée aux contenants :
   1. CNLABS : qui contient l’ensemble des objets pour notre entité (utilisateurs, ordinateur, organisation).
   2. Domain Controllers : qui est le groupe Active Directory contenant les serveurs Active Directory.
      
3. Editer la stratégie de groupe sélectionnée puis rechercher la clé Configuration ordinateur / Stratégies / Paramètres Windows / Paramètres de sécurité / Stratégies de clé publique / Autorités de certification racines de confiance.
   1. Faire un clic droit sur cette clé, puis Importer et sélectionner le certificat ACR-EL.cer.
   2. Répéter cette opération pour les 7 certificats restants (ACR-FO.cer, ACR-ST.cer, ACI-EL-ORG.cer, ACI-EL-PP.cer, ACI-FO-PP.cer, ACI-ST-ORG.cer et ACI-ST-PP.cer).
      
4. Sur l’ensemble des contrôleurs de domaines effectuer les opérations suivantes pour vérifier la bonne propagation des certificats :
   1. Ouvrir un terminal de commande CMD puis exécuter la commande :
      
      gpupdate /force
   2. Une fois l’exécution de la commande terminée, ouvrir une console MMC puis ajouter le composant logiciel enfichable Certificats.
   3. Vérifier la présence des 8 certificats racines et intermédiaires dans le dossier Autorité de certification racines de confiance.
      
   4. Copier les 8 certificats racines et intermédiaires puis les coller dans le dossier Personnel. Cette action est à réaliser sur les Contrôleurs de domaine et l’Autorité de Certification Entreprise (si cette dernière est sur un serveur dédié).
      

Paramétrage réseau

Pour vérifier la validité d’un certificat, les serveurs Active Directory ainsi que l’Autorité de Certification d’Entreprise doivent pouvoir communiquer avec les serveurs de l’Autorité de Certification Racine de l’IGC-Santé.

Interrogation directe

Identification des flux à autoriser

Les flux suivants doivent être autorisés en sortie (depuis serveur Active Directory vers Internet):

• Accès au serveur LDAP de l’IGC-Santé : http://annuaire-igc.esante.fr.
• Accès au serveur web OCSP de l’IGC-Santé : http://ocsp.esante.gouv.fr.
• Accès au serveur web du portail de l’Autorité Racine de l’IGC-Santé : http://igc-sante.esante.gouv.fr.

Paramètres proxy

Si le réseau nécessite un accès Internet via un proxy, il sera nécessaire de paramétrer ce dernier sur les serveurs Active Directory ainsi que l’Autorité de Certification d’Entreprise. Par défaut, Windows utilise les paramètres proxy de la session courante. Dans le cas de la phase d’authentification, c’est le processus système lsass.exe qui va essayer de dialoguer avec l’IGC-Santé. Il faut donc basculer sur une configuration proxy par machine.

1. Ouvrir l’utilitaire d’édition du registre Regedit.
2. Rechercher la clé :
   HKLM\SOFTWARE\Policies\Microsoft\Windows\CurrentVersion\Internet Settings.
   1. Puis, créer la valeur DWORD ProxySettingsPerUser.
   2. Et y affecter la valeur 00000000.
3. Ouvrir un terminal de commande CMD puis exécuter la commande
   gpupdate /force
   pour appliquer les paramètres.
4. Ouvrir la fenêtre de Propriétés de : Internet depuis la commande inetcpl.cpl.
5. Cliquer sur l’onglet Connexions puis sur le bouton Paramètres réseau.
   1. Si elle est cochée, décocher les cases Détecter automatiquement les paramètres de connexion et Utiliser un script de configuration automatique.
   2. Cocher la case Utiliser un serveur proxy puis renseigner dans le champ Adresse l’adresse IP du serveur proxy puis dans le champ Port le numéro du port d’écoute TCP du serveur proxy.
   3. Cliquer sur le bouton OK pour enregistrer les paramètres.
      
6. Ouvrir un terminal de commande Powershell puis exécuter la commande :
   netsh winhttp set proxy IP_PROXY:PORT_PROXY bypass-list=”SRVWSUS”
   en remplaçant :
   • IP_PROXY : par l’adresse IP du serveur proxy.
   • PORT_PROXY : par le port TCP d’écoute du serveur proxy.
   • LIST_EXCLUSION : par l’adresse du serveur de mise à jour WSUS.

Paramétrage de l’authentification

Ajout des certificats dans le magasin NTAuthCertificates

Le magasin de certificat NTAuthCertificates permet au processus d’authentification Kerberos :

• D’identifier les utilisateurs présentant un certificat signé par une autorité de certification racine.
• Seulement si le certificat de cette autorité de certification racine est présente dans le magasin NTAuthCertificates.

De ce fait, il est donc nécessaire d’ajouter les certificats d’autorité racine et d’autorité racine intermédiaire de l’autorité IGC-Santé dans le magasin NTAuthCertificates de l’Autorité de Certification d’Entreprise.

Dans le cas où l’Autorité de Certification d’Entreprise est installée sur un serveur dédié. Les actions ci-dessous sont donc à réaliser depuis ce serveur. Le cas échéant, ces actions sont à réaliser sur le contrôleur de domaine.

1. Ouvrir une console MMC puis ajouter le composant logiciel enfichable PKI d’entreprise.
2. Effectuer un clic droit sur l’item PKI d’entreprise puis cliquer sur Gérer les conteneurs Active Directory….
3. Cliquer sur l’onglet Conteneur NTAuthCertificates puis sur le bouton Ajouter….
   
4. Depuis la fenêtre Ouvrir, rechercher et sélectionner le certificat ACR-EL.cer puis cliquer sur le bouton Ouvrir.
5. Le certificat nouvellement ajouté doit apparaître dans la liste avec le statut OK.
   • Si ce n’est pas le cas : Passer en revue les opérations décrites dans la section Installation des certificats de l’IGC-Santé .
     
6. Répéter les étapes _3_ à _5_ pour les certificats ACR-FO.cer, ACR-ST.cer, ACI-EL-PP.cer, ACI-FO-PP.cer, ACI-ST-ORG.cer et ACI-ST-PP.cer.
   
7. Sur l’ensemble des contrôleurs de domaines ainsi que l’Autorité de Certification Entreprise, effectuer les opérations suivantes pour vérifier la bonne propagation des certificats :
   1. Ouvrir un terminal de commande CMD puis exécuter la commande :
      
      gpupdate /force
   2. Une fois l’exécution de la commande terminée, ouvrir l’éditeur de registre REGEDIT.
   3. Rechercher la clé :
      HKLM\SOFTWARE\Microsoft\EnterpriseCertificates\NTAuth\Certificates
      Puis vérifier la présence des clés relatives aux certificats de l’IGC-Santé :
      

Authentification basée sur des comptes AD existants

Désactivation du SAN (subjectAltName)

Par défaut, pour pouvoir s’authentifier à l’aide d’un certificat, il est nécessaire de créer un compte utilisateur Active Directory spécifique sur le contrôleur de domaine. Ici, nous souhaitons greffer l’authentification par certificat sur des comptes Active Directory existant.

1. Ouvrir l’utilitaire d’édition du registre Regedit.
2. Rechercher la clé :
   HKLM\SYSTEM\CurrentControlSet\Services\kdc
   1. Puis, créer la valeur DWORD : UseSubjectAltName.
   2. Et y affecter la valeur : 00000000.
      
3. Rechercher la clé :
   HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters
   1. Puis, créer la valeur DWORD : UseSubjectAltName.
   2. Et y affecter la valeur : 00000000 .
      

Activation de l’indication du nom d’utilisateur

Par défaut, pour pouvoir s’authentifier à l’aide d’un certificat, il est nécessaire de créer un compte Active Directory spécifique sur le contrôleur de domaine. Ici, nous souhaitons greffer l’authentification par certificat sur des comptes Active Directory existant.

Dès lors, lors de l’ouverture d’une session à l’aide d’un certificat, il faudra renseigner le nom d’utilisateur Windows pour permettre à Kerberos de vérifier la correspondance entre le certificat présenté et le certificat de l’utilisateur Active Directory enregistré dans l’annuaire.

1. Ouvrir une console MMC puis ajouter le composant logiciel enfichable Gestion des stratégies de groupe.
2. Créer une GPO spécifique qui va permettre de personnaliser le paramétrage du composant Carte à puce de Windows. Cette GPO devra être appliquée à l’ensemble des postes clients.
3. Editer la stratégie de groupe nouvellement créée puis rechercher la clé Configuration ordinateur / Stratégies / Modèle d’administration / Composants Windows / Carte à puce / Autoriser l’indication du nom d’utilisateur.
   1. Faire un clic droit sur cette clé puis Modifier.
   2. Sélectionner l’option Activé puis cliquer sur le bouton OK.
4. Sur l’ensemble des contrôleurs de domaines ainsi que l’Autorité de Certification Entreprise, effectuer les opérations suivantes pour forcer l’application des paramètres :
   1. Ouvrir un terminal de commande CMD puis exécuter la commande :
      
      gpupdate /force

Association d’un certificat à un compte AD

Structure de la chaîne de certificat

• Adapter la chaîne d’information de certificat suivante :
  X509:<I>C=FR,O=ASIP-SANTE,OU=0002 987654321,OU=IGC-SANTE,CN=AC IGC-SANTE FORT PERSONNES<SR>SERIAL
  Avec les éléments suivants :
  • SERIAL : Numéro de série du certificat de la carte CPS.

Récupération du numéro de série de la CPS

1. Insérer la carte CPS dans le lecteur de carte à puce de l’ordinateur.
2. Après quelques instants, ouvrir la console Gérer les certificats utilisateur de Windows.
3. Depuis la console, développer l’arborescence Certificats – Utilisateur actuel / Personnel / Certificat.
4. Accéder aux Propriétés du certificat de la carte CPS ayant pour rôle Authentification du client.
5. Depuis la boîte de dialogue de Certificat, cliquer sur l’onglet détail puis relever la valeur du champ Numéro de série.
   
6. Ensuite, inverser l’ordre de chaque octet composant le numéro de série. Par exemple, le numéro de série relever à l’étape précédente était :

SN	98	45	41	f5	2c	22	a2	33	08	fb	25	32	17	c4	12	15
N° Octet	01	02	03	04	05	06	07	08	09	10	11	12	13	14	15	16

Une fois sa séquence inversée, cela donne :

SN	15	12	c4	17	32	25	fb	08	33	a2	22	2c	f5	41	45	98
N° Octet	16	15	14	13	12	11	10	09	08	07	06	05	04	03	02	01

• Voici la chaîne de certificat complète qu’il faudra renseigner dans le profil utilisateur à l’étape suivante :

X509:<I>C=FR,O=ASIP-SANTE,OU=0002 987654321,OU=IGC-SANTE,CN=AC IGC-SANTE FORT PERSONNES<SR>1512c4173225fb0833a2222cf5414598

Paramétrage du compte Active Directory

1. Depuis la console Centre d’administration Active Directory, ouvrir les propriétés du compte utilisateur pour lequel on souhaite paramétrer une authentification par carte CPE.
2. Depuis le menu de navigation vertical, cliquer sur l’item Extensions :
   1. Depuis la section Extensions¹, cliquer sur l’onglet Editeur d’attributs².
   2. Cliquer sur l’attribut altSecurtyIdentities³ puis cliquer sur le bouton Modifier⁴.
      
3. Depuis la boîte de dialogue Editeur de chaînes à valeur multiples, coller la chaîne de caractère construite à l’étape Structure de la chaîne de certificat puis cliquer sur le bouton Ajouter. Cliquer sur le bouton OK pour valider le paramétrage.
   

Contrôle de validité des certificats

En dehors de la période de validité légal d’un certificat, ce dernier peut être révoqué pour les raison suivantes :

• la carte CPX a été perdue ;
• L’utilisateur de la carte CPX a quitté l’établissement ;
• le professionnel de santé a été radié.

Pour ce genre d’événements, l’autorité de certification met à disposition un fichier de certificat CRL (Certificate Revocation List) listant les certificats qui ont été révoqués avant leur date d’expiration. Sans contrôle de la CRL, il sera toujours possible de s’authentifier à l’aide d’une carte CPX pour laquelle le certificat a été révoqué. Ceci constitue une faille dans la politique de gestion des accès au SI.

Validation de la chaîne de révocation d’un certificat

L’objectif est de reproduire manuellement un test de validation de la chaîne de révocation d’un certificat. Ce test vérifie les points suivants :

• Date d’expiration du certificat ;
• Vérification de la validité de la CRL en cache ;
• Téléchargement de la CRL si besoin ;
• Vérification de la présence du certificat dans la CRL.

Récupérer le certificat de la carte CPX

1. Connecter une carte CPE/CPS sur le poste.
2. Ouvrir la console Gérer les certificats utilisateurs depuis la barre de recherche Windows 10.
3. Se rendre dans le dossier Certificats – Utilisateur actuel / Personnel / Certificats puis faire un clic droit sur le certificat ayant pour rôle Authentification du client et cliquer sur Toutes les tâches / Exporter….
   
   1. La fenêtre Assistant Exportation du certificat s’ouvre. Cliquer sur le bouton Suivant pour poursuivre.
      
   2. À l’étape Exporter la clé privée, sélectionner l’option Non, ne pas exporter la clé privée puis cliquer sur le bouton Suivant.
      
   3. À l’étape Format du fichier d’exportation, sélectionner l’option X.509 encodé base 64 (*.cer) puis cliquer sur le bouton Suivant.
      
   4. À l’étape Fichier à exporter, cliquer sur le bouton Parcourir… pour sélection un emplacement et saisir le nom du fichier souhaité. Cliquer sur le bouton Suivant pour valider.
      
   5. À l’étape Fin de l’Assistant Exportation du certificat, vérifier les informations affichées puis cliquer sur le bouton Terminer pour exporter le certificat.
      

Vérifier la chaîne de validité du certificat

• Copier le certificat récupéré à l’étape Récupérer le certificat de la carte CPX sur le contrôleur de domaine puis vérifier sa chaîne de validité à l’aide de la commande :
  
  certutil -urlfetch -verify carte_cpe.cer
• Le terminal de commande retourne les étapes du processus de validation du certificat. Le paramètre dwErrorStatus doit être à 0 systématiquement. Le cas échéant, il y a un problème de validation du certificat.

Émetteur:
    CN=AC IGC-SANTE STANDARD PERSONNES
    OU=IGC-SANTE
    OU=0002 987654321
    O=ASIP-SANTE
    C=FR
  Hachage du nom (sha1) : c1***4a***63c***cc**a4b****1***c0e***35*
  Hachage du nom (md5) : cd***dd***08***6eb4e***310***3*5
 Objet:
    G=DENNIS + SN=NEDRY + CN=3***78**69/******
    T=Personnel santé ou social
    OU=1***78**69
    O=C. HOSP. DE ***
    S=Aveyron (12)
    C=FR
  Hachage du nom (sha1) : 2***d74*24****014***9715***bdf***358***5
  Hachage du nom (md5) : ****b*e7b****cc**14b****8***c7db
Numéro de série du certificat : 0***63**71***75*0**260***e****ab

dwFlags = CA_VERIFY_FLAGS_CONSOLE_TRACE (0x20000000)
dwFlags = CA_VERIFY_FLAGS_DUMP_CHAIN (0x40000000)
ChainFlags = CERT_CHAIN_REVOCATION_CHECK_CHAIN_EXCLUDE_ROOT (0x40000000)
HCCE_LOCAL_MACHINE
CERT_CHAIN_POLICY_BASE
-------- CERT_CHAIN_CONTEXT --------
ChainContext.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
ChainContext.dwRevocationFreshnessTime: 18 Days, 12 Hours, 49 Minutes, 48 Seconds

SimpleChain.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
SimpleChain.dwRevocationFreshnessTime: 18 Days, 12 Hours, 49 Minutes, 48 Seconds

CertContext[0][0]: dwInfoStatus=102 dwErrorStatus=0
  Issuer: CN=AC IGC-SANTE STANDARD PERSONNES, OU=IGC-SANTE, OU=0002 987654321, O=ASIP-SANTE, C=FR
  NotBefore: 10/02/2021 20:01
  NotAfter: 10/02/2024 20:01
  Subject: G=DENNIS + SN=NEDRY + CN=3***78**69/******/******, T=Personnel santé ou social, OU=1***78**69, O=C. HOSP. DE ***, S=Aveyron (12), C=FR
  Serial: 984541f52c22a23308fb253217c41215
  SubjectAltName: Autre nom :Nom principal=3.1***78**69.******@carte-cps.fr
  Cert: 47***e48***113***a2f***2fa***913***aa**7
  Element.dwInfoStatus = CERT_TRUST_HAS_KEY_MATCH_ISSUER (0x2)
  Element.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
  ----------------  AIA de certificat  ----------------
  Vérifié "Certificat (0)" Heure : 0
    [0.0] http://igc-sante.esante.gouv.fr/AC/ACI-ST-PP.cer

  ----------------  CDP de certificat  ----------------
  Vérifié "Liste de révocation des certificats de base (09fe)" Heure : 4
    [0.0] http://igc-sante.esante.gouv.fr/CRL/ACI-ST-PP.crl

  Vérifié "Liste de révocation des certificats de base (09fe)" Heure : 4
    [1.0] ldap://annuaire-igc.esante.gouv.fr/cn=AC%20IGC-SANTE%20STANDARD%20PERSONNES,ou=AC%20RACINE%20IGC-SANTE%20STAND
ARD,ou=IGC-SANTE,ou=0002%187512751,o=ASIP-SANTE,c=FR?certificaterevocationlist;binary?base?objectClass=pkiCA

  ----------------  CDP de liste de révocation des certificats de base  ----------------
  Pas d’URL "Aucun" Heure : 0
  ----------------  Protocole OCSP du certificat  ----------------
  Vérifié "OCSP" Heure : 0
    [0.0] http://ocsp.esante.gouv.fr

  --------------------------------
    CRL (null):
    Issuer: CN=SERVICE OCSP IGC-SANTE STANDARD PERSONNES, OU=IGC-SANTE + OU=0002 187512751, O=ASIP-SANTE, C=FR
    ThisUpdate: 18/12/2022 22:30
    NextUpdate: 19/12/2022 23:00
    CRL: b06e19f63846e01ea51201989fbf7c465fc1969d
  Issuance[0] = 1.2.250.1.213.1.7.1.2.1.3.1
  Application[0] = 1.3.6.1.5.5.7.3.2 Authentification du client
  Application[1] = 1.3.6.1.4.1.311.20.2.2 Ouverture de session par carte à puce

CertContext[0][1]: dwInfoStatus=102 dwErrorStatus=0
  Issuer: CN=AC RACINE IGC-SANTE STANDARD, OU=IGC-SANTE, OU=0002 187512751, O=ASIP-SANTE, C=FR
  NotBefore: 25/06/2013 01:00
  NotAfter: 24/06/2033 01:00
  Subject: CN=AC IGC-SANTE STANDARD PERSONNES, OU=IGC-SANTE, OU=0002 187512751, O=ASIP-SANTE, C=FR
  Serial: 112016654c36f13671b030541f6088ea44c2
  Cert: e0d6e1d8481fed62c65c53ed9dfcda949c3d1d81
  Element.dwInfoStatus = CERT_TRUST_HAS_KEY_MATCH_ISSUER (0x2)
  Element.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
  ----------------  AIA de certificat  ----------------
  Pas d’URL "Aucun" Heure : 0
  ----------------  CDP de certificat  ----------------
  Vérifié "Liste de révocation des certificats de base (73)" Heure : 0
    [0.0] http://igc-sante.esante.gouv.fr/CRL/ACR-ST.crl

  Vérifié "Liste de révocation des certificats de base (73)" Heure : 0
    [1.0] ldap://annuaire-igc.esante.gouv.fr/CN=AC%20RACINE%20IGC-SANTE%20STANDARD,OU=IGC-SANTE,OU=0002%20187512751,O=ASIP-SANTE,C=FR?certificaterevocationlist;binary?base?objectclass=pkiCa

  ----------------  CDP de liste de révocation des certificats de base  ----------------
  Pas d’URL "Aucun" Heure : 0
  ----------------  Protocole OCSP du certificat  ----------------
  Pas d’URL "Aucun" Heure : 0
  --------------------------------
    CRL 73:
    Issuer: CN=AC RACINE IGC-SANTE STANDARD, OU=IGC-SANTE, OU=0002 187512751, O=ASIP-SANTE, C=FR
    ThisUpdate: 01/12/2022 01:00
    NextUpdate: 15/01/2023 01:00
    CRL: 7c2668dac4b660dc0f53be674dece6fcaec5680d

CertContext[0][2]: dwInfoStatus=10a dwErrorStatus=0
  Issuer: CN=AC RACINE IGC-SANTE STANDARD, OU=IGC-SANTE, OU=0002 187512751, O=ASIP-SANTE, C=FR
  NotBefore: 25/06/2013 01:00
  NotAfter: 25/06/2033 01:00
  Subject: CN=AC RACINE IGC-SANTE STANDARD, OU=IGC-SANTE, OU=0002 187512751, O=ASIP-SANTE, C=FR
  Serial: 11207f69865cdf9a675f3013640fe1a47805
  Cert: b6ba1d6d5224bceda95a67f6f37b86896edd0006
  Element.dwInfoStatus = CERT_TRUST_HAS_KEY_MATCH_ISSUER (0x2)
  Element.dwInfoStatus = CERT_TRUST_IS_SELF_SIGNED (0x8)
  Element.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
  ----------------  AIA de certificat  ----------------
  Pas d’URL "Aucun" Heure : 0
  ----------------  CDP de certificat  ----------------
  Pas d’URL "Aucun" Heure : 0
  ----------------  Protocole OCSP du certificat  ----------------
  Pas d’URL "Aucun" Heure : 0
  --------------------------------

Exclude leaf cert:
  Chain: 136fc23294346c3992f845b1dd22e1038ce7ee87
Full chain:
  Chain: 496e2f5d6dffe10de9e8b249aa81fa8198b8cb01
------------------------------------
Stratégies d’émissions vérifiées:
    1.2.250.1.213.1.7.1.2.1.3.1
Stratégies d’application vérifiées:
    1.3.6.1.5.5.7.3.2 Authentification du client
    1.3.6.1.4.1.311.20.2.2 Ouverture de session par carte à puce
Le certificat est un certificat d’entité de fin
Vérification de révocation du certificat feuille réussie
CertUtil: -verify La commande s’est terminée correctement.

• Depuis les journaux d’activité Windows, il est possible de constater le bon fonctionnement de la chaîne de vérification du certificat.
  • Ouvrir la console de l’Observateur d’événement.
  • Depuis la branche Journaux des applications et des services / Microsoft / Windows / CAPI2, faire un clic droit sur le journal Opérationnel puis Activer le journal.
  • Rejouer la commande :
    
    certutil -urlfetch -verify carte_cpe.cer
  • Puis observer les résultats dans le journal d’évènements Windows.
    

En cas d’erreur

• Vérifier que le serveur soit bien autorisé à interroger les serveurs de l’Autorité de Certification de l’IGC-Santé.
• Procéder à la purge du cache en lançant les commandes suivantes depuis une console PowerShell :

certutil -urlcache crl delete certutil -urlcache * delete certutil -urlcache crl

• Relancer la commande :
  
  certutil -urlfetch -verify carte_cpe.cer

pour vérifier la chaîne de validité du certificat. 

Comportements et stratégies de gestion de la carte à puce

Verrouillage du poste lors du retrait de la carte à puce

1. Ouvrir une console MMC puis ajouter le composant logiciel enfichable Gestion des stratégies de groupe.
2. Editer la GPO O_WINDOWS-SMARTCARD à la racine du domaine de l’organisation (ou créer une nouvelle GPO pour cette occasion).
3. Editer la stratégie de groupe sélectionnée puis rechercher la clé Configuration ordinateur / Stratégies / Paramètres Windows / Paramètres de sécurité / Stratégies locales / Options de sécurité / Ouverture de session interactive : comportement lorsque la carte à puce est retirée.
   1. Faire un clic droit sur cette clé, puis Propriétés.
   2. Activer l’option Définir ce paramètre de stratégie puis sélectionner l’option Verrouiller la station de travail. Cliquer sur le bouton OK pour enregistrer le paramètre.
      
4. Editer la stratégie de groupe sélectionnée puis rechercher la clé Configuration ordinateur / Stratégies / Paramètres Windows / Paramètres de sécurité / Services systèmes / Stratégie de retrait de la carte à puce.
   1. Faire un clic droit sur cette clé, puis Propriétés.
   2. Activer l’option Définir ce paramètre de stratégie puis sélectionner l’option Automatique. Cliquer sur le bouton OK pour enregistrer le paramètre.
      

Désactivation du contrôle de la CRL

Par défaut, Active Directory effectue un contrôle de la CRL pour toute demande d’authentification par certificat. Si ce contrôle ne peut pas être effectuée, l’authentification est rejetée.

Si le contrôleur de domaine n’est pas autorisé à interroger les serveurs de l’Autorité de Certification de l’IGC-Santé, ce problème se produira pour chaque demande d’authentification. Lors des phases de test et de validation de l’infrastructure, il peut être intéressant de désactiver temporairement ce contrôle.

1. Depuis les contrôleurs de domaine Active Directory, ouvrir l’éditeur de registre REGEDIT.
2. Rechercher la clé :
   HKLM\SYSTEM\CurrentControlSet\Services\kdc
   1. Puis, créer la valeur DWORD : UseCachedCRLOnlyAndIgnoreRevocationUnknownErrors.
   2. Et y affecter la valeur : 00000001.
3. Rechercher la clé :
   HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters
   1. Puis, créer la valeur DWORD : UseCachedCRLOnlyAndIgnoreRevocationUnknownErrors.
   2. Et y affecter la valeur : 00000001.

Installation des pilotes de périphériques clients

Installation du pilote ASIP pour cartes CPX

1. Brancher le lecteur de carte sur un port USB de libre.
2. Insérer la carte CPX dans le lecteur de carte à puce.
   
3. Effectuer un clic droit sur le périphérique Carte à puce inconnue puis cliquer sur l’item Mettre à jour le pilote depuis le menu contextuel.
   
   1. L’assistant Mettre à jour les pilotes s’affiche. Cliquer sur l’item Parcourir mon poste de travail pour rechercher les pilotes.
      
   2. Depuis l’écran Mettre à jour les pilotes, cliquer sur le bouton Parcourir… puis sélectionner le Pilotes CPS téléchargé.
      
   3. À la fin de l’installation du pilote, vérifier qu’il s’agit bien du pilote Carte de Professionnel de Sante CPS3.
      

Problèmes rencontrés

Problème d’authentification par carte à puce

CRLs invalides ou expirées

• Contexte :
  • Se produit lors de la phase d’authentification par carte à puce depuis l’écran de login Windows.

• Erreur(s) rencontré(s) :
  • L’écran d’ouverture de session interactive Windows retourne l’erreur :
    

• Analyse journaux logs CAPI2 :
  • L’annuaire Active Directory remonte une erreur lors de la phase de contrôle de la CRL après interrogation LDAP du certificat racine IGC-SANTE STANDARD PERSONNES.
    

• Reproductibilité du défaut :
  • Exécution de la requête LDAP en défaut :
    • À l’aide de l’utilitaire certutil de Microsoft nous rejouons la commande LDAP en défaut :

certutil -url "ldap://annuaire-igc.esante.gouv.fr/cn=AC%20IGC-SANTE%20STANDARD%20PERSONNES,ou=AC%20RACINE%20IGC-SANTE%20STANDARD,ou=IGC-SANTE,ou=0002%20187512751,o=ASIP-SANTE,c=FR?deltarevocationlist;binary?base?objectClass=pkiCA"

• La commande nous bascule sur l’Outil de récupération d’URL. En sélection l’option Listes CRL (de CDP) puis en cliquant sur le bouton Extraire, nous obtenons en résultat la CRL.
  
• En effectuant un double clic sur le résultat, nous accédons au détail de la CRL. Nous observons ainsi que le fichier récupéré date du 07/09/2022.
  

• Domaine de responsabilité :
  • Dans le cas présent, c'est l'autorité de certification racine IGC-SANTE qui fournit une CRL expirée.

• Solution(s) de contournement :
  • Désactiver le contrôle de CRL via l’éditeur de registre REGEDIT.
  • Etendre la durée de l’extension de la période de validité via GPO.