Exigences et énumération des certificats

• S’applique à:

  ✅ Windows 11, ✅ Windows 10, ✅ Windows Server 2022, ✅ Windows Server 2019, ✅ Windows Server 2016

Cette rubrique destinée aux professionnels de l’informatique et aux développeurs de cartes à puce décrit comment les certificats sont gérés et utilisés pour la connexion par carte à puce.

Lorsqu’une carte à puce est insérée, les étapes suivantes sont effectuées.

Remarque

Sauf mention contraire, toutes les opérations sont effectuées en mode silencieux (CRYPT_SILENT est passé à CryptAcquireContext).

1. La base de données du gestionnaire de ressources de carte à puce recherche le fournisseur de services de chiffrement (CSP) de la carte à puce.

2. Un nom de conteneur qualifié est construit à l’aide du nom du lecteur de carte à puce, et il est passé au fournisseur de solutions Cloud. Le format est \\.<Reader name>\

3. CryptAcquireContext est appelé pour récupérer un contexte dans le conteneur par défaut. Si une défaillance se produit, la carte à puce est inutilisable pour la connexion par carte à puce.

4. Le nom du conteneur est récupéré à l’aide du paramètre PP_CONTAINER avec CryptGetProvParam.

5. À l’aide du contexte acquis à l’étape 3, le csp est interrogé pour le paramètre PP_USER_CERTSTORE. Pour plus d’informations, consultez Architecture de carte à puce. Si l’opération réussit, le nom d’un magasin de certificats est retourné et le flux du programme passe à l’étape 8.

6. Si l’opération de l’étape 5 échoue, le contexte de conteneur par défaut de l’étape 3 est interrogé pour la clé AT_KEYEXCHANGE.

7. Le certificat est ensuite interrogé à partir du contexte de clé à l’aide de KP_CERTIFICATE. Le certificat est ajouté à un magasin de certificats en mémoire.

8. Pour chaque certificat du magasin de certificats de l’étape 5 ou 7, les vérifications suivantes sont effectuées :

   1. Le certificat doit être valide, en fonction de l’horloge du système informatique (non expiré ou valide avec une date ultérieure)
   2. Le certificat ne doit pas se trouver dans la partie AT_SIGNATURE d’un conteneur
   3. Le certificat doit avoir un nom d’utilisateur principal (UPN) valide
   4. Le certificat doit avoir l’utilisation de la clé de signature numérique
   5. Le certificat doit avoir la référence EKU d’ouverture de session de la carte à puce

   Tout certificat qui répond à ces exigences est affiché à l’utilisateur avec l’UPN du certificat (ou l’adresse de messagerie ou l’objet, selon la présence des extensions de certificat)

9. Le processus choisit ensuite un certificat et le code confidentiel est entré.

10. LogonUI.exe empaquette les informations et les envoie à Lsass.exe pour traiter la tentative de connexion

11. En cas de réussite, LogonUI.exe se ferme. Cela entraîne la publication du contexte acquis à l’étape 3

Flux de connexion par carte à puce dans Windows

La plupart des problèmes lors de l’authentification se produisent en raison de changements de comportement de session. Lorsque des modifications se produisent, l’autorité de sécurité locale (LSA) ne réacquisit pas le contexte de session ; il s’appuie plutôt sur le fournisseur de services de chiffrement pour gérer la modification de session.

Les certificats clients qui ne contiennent pas d’UPN dans le subjectAltName champ (SAN) du certificat peuvent être activés pour la connexion, ce qui prend en charge une plus grande variété de certificats et prend en charge plusieurs certificats de connexion sur la même carte.

La prise en charge de plusieurs certificats sur la même carte est activée par défaut. Les nouveaux types de certificats doivent être activés via la stratégie de groupe.

Si vous activez la stratégie Autoriser les clés de signature valides pour le fournisseur d’informations d’identification d’ouverture de session, tous les certificats disponibles sur la carte à puce avec une clé de signature uniquement sont répertoriés sur l’écran de connexion. Cela permet aux utilisateurs de sélectionner leur expérience de connexion. Si la stratégie est désactivée ou non configurée, les certificats basés sur une clé de signature de carte à puce ne sont pas répertoriés sur l’écran de connexion.

Le diagramme suivant illustre le fonctionnement de la connexion par carte à puce dans les versions prises en charge de Windows.

Flux de connexion par carte à puce

Voici les étapes qui sont effectuées lors d’une connexion par carte à puce :

1. Winlogon demande les informations d’identification de l’interface utilisateur de connexion

2. De façon asynchrone, le gestionnaire de ressources de carte à puce démarre et le fournisseur d’informations d’identification de carte à puce effectue les opérations suivantes :

   1. Obtient des informations d’identification (une liste d’informations d’identification connues ou, si aucune information d’identification n’existe, les informations du lecteur de carte à puce détectées par Windows)
   2. Obtient la liste des lecteurs de cartes à puce (à l’aide de l’API WinSCard) et la liste des cartes à puce insérées dans chacune d’elles
   3. Énumère chaque carte pour vérifier qu’un certificat de connexion contrôlé par la stratégie de groupe est présent. Si le certificat est présent, le fournisseur d’informations d’identification de carte à puce le copie dans un cache temporaire et sécurisé sur l’ordinateur ou le terminal

   Remarque

   Les entrées de cache de carte à puce sont créées pour les certificats avec un nom d’objet ou un identificateur de clé d’objet. Si le certificat a un nom d’objet, il est stocké avec un index basé sur le nom du sujet et l’émetteur du certificat. Si un autre certificat avec le même nom d’objet et le même émetteur de certificat est utilisé, il remplace l’entrée mise en cache existante. Une modification de ce comportement autorise la condition lorsque le certificat n’a pas de nom d’objet, le cache est créé avec un index basé sur l’identificateur de clé d’objet et l’émetteur du certificat. Si un autre certificat a le même identificateur de clé d’objet et l’émetteur du certificat, l’entrée de cache est remplacée. Lorsque les certificats n’ont ni nom d’objet ni identificateur de clé d’objet, aucune entrée mise en cache n’est créée.

   1. Avertit l’interface utilisateur de connexion qu’elle dispose de nouvelles informations d’identification

3. L’interface utilisateur de connexion demande les nouvelles informations d’identification auprès du fournisseur d’informations d’identification de carte à puce. En guise de réponse, le fournisseur d’informations d’identification de carte à puce fournit chaque certificat de connexion à l’interface utilisateur de connexion, et les vignettes de connexion correspondantes s’affichent. L’utilisateur sélectionne une vignette de certificat de connexion basée sur une carte à puce, et Windows affiche une boîte de dialogue code confidentiel

4. L’utilisateur entre le code confidentiel, puis appuie sur Entrée. Le fournisseur d’informations d’identification de carte à puce chiffre le code confidentiel

5. Le fournisseur d’informations d’identification qui réside dans le système LogonUI collecte le code confidentiel. Dans le cadre de l’empaquetage des informations d’identification dans le fournisseur d’informations d’identification de carte à puce, les données sont empaquetées dans une structure KERB_CERTIFICATE_LOGON. Le contenu principal de la structure KERB_CERTIFICATE_LOGON est le code confidentiel de la carte à puce, les données CSP (telles que le nom du lecteur et le nom du conteneur), le nom d’utilisateur et le nom de domaine. Le nom d’utilisateur est requis si le domaine de connexion ne se trouve pas dans la même forêt, car il permet de mapper un certificat à plusieurs comptes d’utilisateur

6. Le fournisseur d’informations d’identification encapsule les données (par exemple, le code confidentiel chiffré, le nom du conteneur, le nom du lecteur et la spécification de la clé de carte) et les renvoie à LogonUI

7. Winlogon présente les données de LogonUI à LSA avec les informations utilisateur dans LSALogonUser

8. LSA appelle le package d’authentification Kerberos (SSP Kerberos) pour créer une demande de service d’authentification Kerberos (KRB_AS_REQ), qui contient un préauthenticateur (comme spécifié dans RFC 4556 : Chiffrement à clé publique pour l’authentification initiale dans Kerberos (PKINIT)).

   Si l’authentification est effectuée à l’aide d’un certificat qui utilise une signature numérique, les données de pré-authentification se composent du certificat public de l’utilisateur et du certificat qui est signé numériquement avec la clé privée correspondante.
   Si l’authentification est effectuée à l’aide d’un certificat qui utilise le chiffrement de clé, les données de pré-authentification se composent du certificat public de l’utilisateur et du certificat chiffré avec la clé privée correspondante.

9. Pour signer la demande numériquement (conformément à la RFC 4556), un appel est effectué vers le fournisseur de solutions cloud correspondant pour une opération de clé privée. Dans ce cas, étant donné que la clé privée est stockée dans une carte à puce, le sous-système de carte à puce est appelé et l’opération nécessaire est terminée. Le résultat est renvoyé au fournisseur de support de sécurité (SSP) Kerberos.

10. Le fournisseur de services partagés Kerberos envoie une demande d’authentification pour un ticket TGT (ticket-granting-ticket) (conformément à la RFC 4556) au service centre de distribution de clés (KDC) qui s’exécute sur un contrôleur de domaine.

11. Le KDC recherche l’objet de compte de l’utilisateur dans Active Directory Domain Services (AD DS), comme indiqué dans Exigences et mappages des certificats client, et utilise le certificat de l’utilisateur pour vérifier la signature.

12. Le KDC valide le certificat de l’utilisateur (heure, chemin et état de révocation) pour s’assurer que le certificat provient d’une source approuvée. Le KDC utilise CryptoAPI pour générer un chemin de certification à partir du certificat de l’utilisateur vers un certificat d’autorité de certification racine qui réside dans le magasin racine sur le contrôleur de domaine. Le KDC utilise ensuite CryptoAPI pour vérifier la signature numérique sur l’authentificateur signé qui a été inclus dans les champs de données de pré-authentification. Le contrôleur de domaine vérifie la signature et utilise la clé publique du certificat de l’utilisateur pour prouver que la demande provient du propriétaire de la clé privée qui correspond à la clé publique. Le KDC vérifie également que l’émetteur est approuvé et apparaît dans le magasin de certificats NTAUTH.

13. Le service KDC récupère les informations de compte d’utilisateur à partir d’AD DS. Le KDC construit un TGT, qui est basé sur les informations de compte d’utilisateur qu’il récupère à partir d’AD DS. Les champs de données d’autorisation du TGT incluent l’identificateur de sécurité (SID) de l’utilisateur, les SID pour les groupes de domaines universels et globaux auxquels appartient l’utilisateur et (dans un environnement multidomaine) les SID pour tous les groupes universels dont l’utilisateur est membre.

14. Le contrôleur de domaine retourne le TGT au client dans le cadre de la réponse KRB_AS_REP.

    Remarque

    Le paquet KRB_AS_REP se compose des éléments suivants :

    • Certificat d’attribut de privilège (PAC)
    • SID de l’utilisateur
    • SID de tous les groupes dont l’utilisateur est membre
    • Une demande de service d’octroi de tickets (TGS)
    • Données de pré-authentification

    TGT est chiffré avec la clé principale du KDC, et la clé de session est chiffrée avec une clé temporaire. Cette clé temporaire est dérivée en fonction de la norme RFC 4556. À l’aide de CryptoAPI, la clé temporaire est déchiffrée. Dans le cadre du processus de déchiffrement, si la clé privée se trouve sur une carte à puce, un appel est effectué vers le sous-système de carte à puce à l’aide du fournisseur csp spécifié pour extraire le certificat correspondant à la clé publique de l’utilisateur. (Les appels programmatiques pour le certificat incluent CryptAcquireContext, CryptSetProvParam avec le code confidentiel, CryptgetUserKey et CryptGetKeyParam.) Une fois la clé temporaire obtenue, le fournisseur de services partagés Kerberos déchiffre la clé de session.

15. Le client valide la réponse du KDC (heure, chemin d’accès et état de révocation). Il vérifie d’abord la signature du KDC par la construction d’un chemin de certification à partir du certificat du KDC vers une autorité de certification racine approuvée, puis utilise la clé publique du KDC pour vérifier la signature de réponse.

16. Maintenant qu’un TGT a été obtenu, le client obtient un ticket de service, qui est utilisé pour se connecter à l’ordinateur local.

17. Avec succès, LSA stocke les tickets et retourne un message de réussite à LSALogonUser. Une fois ce message de réussite émis, le profil utilisateur de l’appareil est sélectionné et défini, l’actualisation de la stratégie de groupe est instanciée et d’autres actions sont effectuées.

18. Une fois le profil utilisateur chargé, le service de propagation de certification (CertPropSvc) détecte cet événement, lit les certificats de la carte à puce (y compris les certificats racine), puis les renseigne dans le magasin de certificats de l’utilisateur (MYSTORE)

19. La communication du gestionnaire de ressources csp à carte à puce se produit sur le canal LRPC.

20. Une fois l’authentification réussie, les certificats sont propagés au magasin de l’utilisateur de manière asynchrone par le service de propagation de certificats (CertPropSvc).

21. Lorsque la carte est supprimée, les certificats du magasin de cache sécurisé temporaire sont supprimés. Les certificats ne sont plus disponibles pour la connexion, mais ils restent dans le magasin de certificats de l’utilisateur.

Remarque

Un SID est créé pour chaque utilisateur ou groupe au moment où un compte d’utilisateur ou de groupe est créé dans la base de données des comptes de sécurité locaux ou dans AD DS. Le SID ne change jamais, même si le compte d’utilisateur ou de groupe est renommé.

Pour plus d’informations sur le protocole Kerberos, consultez Microsoft Kerberos.

Par défaut, le KDC vérifie que le certificat du client contient la référence EKU d’authentification du client de carte à puce szOID_KP_SMARTCARD_LOGON. Toutefois, s’il est activé, le paramètre de stratégie de groupe Autoriser les certificats sans utilisation de clé étendue d’attribut de certificat permet au KDC de ne pas exiger la référence EKU SC-LOGON. La référence EKU SC-LOGON n’est pas requise pour les mappages de comptes basés sur la clé publique.

Certificat KDC

Les services de certificats Active Directory fournissent trois types de modèles de certificat :

• Contrôleur de domaine
• Authentification du contrôleur de domaine
• Authentification Kerberos

Selon la configuration du contrôleur de domaine, l’un de ces types de certificats est envoyé dans le cadre du paquet AS_REP.

Exigences et mappages des certificats clients

La configuration requise pour les certificats est répertoriée par les versions du système d’exploitation Windows. Le mappage de certificat décrit comment les informations du certificat sont mappées au compte d’utilisateur.

Exigences de certificat

Composant	Conditions préalables
Emplacement du point de distribution de liste de révocation de certificats	Non requis
Utilisation de la clé	Signature numérique
Contraintes de base	Non requis
utilisation étendue des clés (EKU)	L’identificateur de l’objet de connexion à la carte à puce n’est pas obligatoire. Note Si une référence EKU est présente, elle doit contenir la référence EKU de connexion par carte à puce. Les certificats sans référence EKU peuvent être utilisés pour la connexion.
Autre nom de l’objet	L’ID de messagerie n’est pas requis pour la connexion par carte à puce.
Sujet	Non requis
Échange de clés (champ AT_KEYEXCHANGE)	Non obligatoire pour les certificats de connexion par carte à puce si un paramètre de stratégie de groupe est activé. (Par défaut, les paramètres de stratégie de groupe ne sont pas activés.)
LCR	Non requis
UPN	Non requis
Remarques	Vous pouvez activer la visibilité de n’importe quel certificat pour le fournisseur d’informations d’identification de carte à puce.

Mappages de certificats clients

Le mappage de certificat est basé sur l’UPN contenu dans le champ subjectAltName (SAN) du certificat. Les certificats clients qui ne contiennent pas d’informations dans le champ SAN sont également pris en charge.

SSL/TLS peut mapper des certificats qui n’ont pas de SAN, et le mappage est effectué à l’aide des attributs AltSecID sur les comptes clients. L’AltSecID X509, utilisé par l’authentification du client SSL/TLS, se présente sous la forme « X509 : <Issuer Name><Subject Name. Les <Issuer Name> et <Subject Name> sont extraits du certificat client, avec « \r » et « \n » remplacés par « , ».

Points de distribution de la liste de révocation de certificats

UPN dans le champ Autre nom de l’objet

Champs Objet et Émetteur

Ce mappage de compte est pris en charge par le KDC en plus de six autres méthodes de mappage. La figure suivante illustre un flux de logique de mappage de compte d’utilisateur utilisée par le KDC.

Flux de haut niveau de traitement des certificats pour la connexion

L’objet de certificat est analysé pour rechercher du contenu pour effectuer le mappage de compte d’utilisateur.

• Lorsqu’un nom d’utilisateur est fourni avec le certificat, le nom d’utilisateur est utilisé pour localiser l’objet de compte. Cette opération est la plus rapide, car la correspondance de chaîne se produit
• Lorsque seul l’objet de certificat est fourni, plusieurs opérations sont effectuées pour localiser le nom d’utilisateur afin de mapper le nom d’utilisateur à un objet de compte
• Lorsqu’aucune information de domaine n’est disponible pour l’authentification, le domaine local est utilisé par défaut. Si un autre domaine doit être utilisé pour la recherche, un indicateur de nom de domaine doit être fourni pour effectuer le mappage et la liaison

Le mappage basé sur des attributs génériques n’est pas possible, car il n’existe aucune API générique pour récupérer les attributs d’un certificat. Actuellement, la première méthode qui localise un compte arrête correctement la recherche. Toutefois, une erreur de configuration se produit si deux méthodes mappent le même certificat à des comptes d’utilisateur différents lorsque le client ne fournit pas le nom du client par le biais des indicateurs de mappage.

La figure suivante illustre le processus de mappage des comptes d’utilisateur pour la connexion dans l’annuaire en affichant différentes entrées dans le certificat.

Logique de traitement des certificats

NT_AUTH stratégie est mieux décrite dans la section paramètre CERT_CHAIN_POLICY_NT_AUTH de la fonction CertVerifyCertificateChainPolicy. Pour plus d’informations, consultez CertVerifyCertificateChainPolicy.

Connexion par carte à puce pour un seul utilisateur avec un certificat dans plusieurs comptes

Un certificat utilisateur unique peut être mappé à plusieurs comptes. Par exemple, un utilisateur peut être en mesure de se connecter à un compte d’utilisateur et également de se connecter en tant qu’administrateur de domaine. Le mappage est effectué à l’aide de l’AltSecID construit en fonction des attributs des comptes clients. Pour plus d’informations sur la façon dont ce mappage est évalué, consultez Exigences et mappages des certificats clients.

Remarque

Étant donné que chaque compte a un nom d’utilisateur différent, nous vous recommandons d’activer le paramètre de stratégie de groupe Autoriser l’indicateur de nom d’utilisateur (clé de Registre X509HintsNeeded) pour fournir les champs facultatifs qui permettent aux utilisateurs d’entrer leurs noms d’utilisateur et leurs informations de domaine pour se connecter.

En fonction des informations disponibles dans le certificat, les conditions de connexion sont les suivantes :

1. Si aucun UPN n’est présent dans le certificat :
   1. La connexion peut se produire dans la forêt locale ou dans une autre forêt si un seul utilisateur avec un certificat doit se connecter à différents comptes
   2. Un indicateur doit être fourni si le mappage n’est pas unique (par exemple, si plusieurs utilisateurs sont mappés au même certificat)
2. Si un UPN est présent dans le certificat :
   1. Le certificat ne peut pas être mappé à plusieurs utilisateurs dans la même forêt
   2. Le certificat peut être mappé à plusieurs utilisateurs dans différentes forêts. Pour qu’un utilisateur se connecte à d’autres forêts, un indicateur X509 doit être fourni à l’utilisateur

Connexion par carte à puce pour plusieurs utilisateurs dans un seul compte

Un groupe d’utilisateurs peut se connecter à un seul compte (par exemple, un compte d’administrateur). Pour ce compte, les certificats utilisateur sont mappés afin qu’ils soient activés pour la connexion.

Plusieurs certificats distincts peuvent être mappés à un seul compte. Pour que cela fonctionne correctement, le certificat ne peut pas avoir d’UPN.

Par exemple, si Certificate1 a CN=CNName1, Certificate2 a CN=User1 et Certificate3 a CN=User2, l’AltSecID de ces certificats peut être mappé à un seul compte à l’aide du mappage de noms Utilisateurs et ordinateurs Active Directory.

Connexion par carte à puce dans les forêts

Pour que le mappage de compte fonctionne dans les forêts, en particulier dans les cas où il n’y a pas suffisamment d’informations disponibles sur le certificat, l’utilisateur peut entrer un indicateur sous la forme d’un nom d’utilisateur, tel que domaine\utilisateur, ou d’un UPN complet tel que user@contoso.com.

Remarque

Pour que le champ d’indicateur apparaisse lors de la connexion par carte à puce, le paramètre de stratégie de groupe Autoriser l’indicateur de nom d’utilisateur (clé de Registre X509HintsNeededed ) doit être activé sur le client.

Prise en charge d’OCSP pour PKINIT

Le protocole OCSP (Online Certificate Status Protocol), défini dans la norme RFC 2560, permet aux applications d’obtenir en temps voulu des informations sur l’état de révocation d’un certificat. Étant donné que les réponses OCSP sont petites et bien liées, les clients contraints peuvent utiliser OCSP pour vérifier la validité des certificats Kerberos sur le KDC, éviter la transmission de listes de révocation de certificats volumineux et économiser la bande passante sur les réseaux limités. Pour plus d’informations sur les clés de Registre CRL, consultez Stratégie de groupe de cartes à puce et Paramètres du Registre.

Les KDC dans Windows tentent d’obtenir des réponses OCSP et de les utiliser lorsqu’elles sont disponibles. Ce comportement ne peut pas être désactivé. CryptoAPI pour OCSP met en cache les réponses OCSP et l’état des réponses. Le KDC prend uniquement en charge les réponses OCSP pour le certificat de signataire.

Les ordinateurs clients Windows tentent de demander les réponses OCSP et de les utiliser dans la réponse lorsqu’elles sont disponibles. Ce comportement ne peut pas être désactivé.

Conditions requises pour le certificat racine de carte à puce pour une utilisation avec la connexion au domaine

Pour que la connexion fonctionne dans un domaine basé sur une carte à puce, le certificat de carte à puce doit remplir les conditions suivantes :

• Le certificat racine KDC sur la carte à puce doit avoir un point de distribution de liste de révocation de certificats HTTP répertorié dans son certificat
• Le certificat de connexion de carte à puce doit avoir le point de distribution de liste de révocation de certificats HTTP répertorié dans son certificat
• Le point de distribution de la liste de révocation de certificats doit avoir une liste de révocation de certificats valide publiée et une liste de révocation de certificats delta, le cas échéant, même si le point de distribution de la liste de révocation de certificats est vide
• Le certificat de carte à puce doit contenir l’un des éléments suivants :
  • Champ d’objet qui contient le nom de domaine DNS dans le nom unique. Si ce n’est pas le cas, la résolution vers un domaine approprié échoue. Par conséquent, les services Bureau à distance et la connexion au domaine avec la carte à puce échouent
  • UpN où le nom de domaine est résolu en domaine réel. Par exemple, si le nom de domaine est Engineering.Corp.Contoso, l’UPN est username@engineering.corp.contoso.com. Si une partie du nom de domaine est omise, le client Kerberos ne peut pas trouver le domaine approprié

Pour autoriser la connexion par carte à puce à un domaine dans ces versions, procédez comme suit :

1. Activer les points de distribution de la liste de révocation de certificats HTTP sur l’autorité de certification
2. Redémarrer l’autorité de certification
3. Réémettre le certificat KDC
4. Émettre ou réémettre le certificat de connexion par carte à puce
5. Propager le certificat racine mis à jour à la carte à puce que vous souhaitez utiliser pour la connexion au domaine

La solution de contournement consiste à activer le paramètre de stratégie de groupe Autoriser l’indicateur de nom d’utilisateur (clé de Registre X509HintsNeeded ), qui permet à l’utilisateur de fournir un indicateur dans l’interface utilisateur des informations d’identification pour la connexion au domaine.

Si l’ordinateur client n’est pas joint au domaine ou s’il est joint à un autre domaine, l’ordinateur client peut résoudre le domaine serveur uniquement en examinant le nom unique sur le certificat, et non l’UPN. Pour que ce scénario fonctionne, le certificat nécessite un objet complet, y compris DC=<DomainControllerName>, pour la résolution de noms de domaine.

Pour déployer des certificats racines sur une carte à puce pour le domaine actuellement joint, vous pouvez utiliser la commande suivante :

certutil.exe -scroots update

Pour plus d’informations sur cette option pour l’outil en ligne de commande, consultez -SCRoots.