Microsoft Entra concepts techniques d’authentification basée sur des certificats

Cet article décrit les concepts techniques permettant d’expliquer comment fonctionne Microsoft Entra l’authentification basée sur des certificats (CBA). Obtenez les connaissances techniques pour mieux comprendre comment configurer et gérer Microsoft Entra CBA dans votre instance.

Comment fonctionne l’authentification basée sur des certificats Microsoft Entra ?

La figure suivante illustre ce qui se passe lorsqu’un utilisateur tente de se connecter à une application dans un locataire qui a configuré Microsoft Entra CBA.

Les étapes suivantes résument le processus d’Microsoft Entra CBA :

1. Un utilisateur tente d’accéder à une application, telle que le portail MyApps.

2. Si l'utilisateur n'est pas encore connecté, il est redirigé vers la page de connexion de l'utilisateur Microsoft Entra ID à https://login.microsoftonline.com/.

3. Ils entrent leur nom d’utilisateur dans la page de connexion Microsoft Entra, puis sélectionnent Next. Microsoft Entra ID termine la découverte du domaine local en utilisant le nom du locataire. Il utilise le nom d’utilisateur pour rechercher l’utilisateur dans le locataire.

   

4. Microsoft Entra ID vérifie si l'authentification basée sur des certificats est configurée pour le tenant. Si CBA est configuré, l'utilisateur voit un lien pour utiliser un certificat ou une carte à puce sur la page de mot de passe. Si l’utilisateur ne voit pas le lien de connexion, vérifiez que le CBA est configuré pour le locataire.

   Pour plus d’informations, consultez How do we turn on Microsoft Entra CBA ?.

   Remarque

   Si l'authentification basée sur les certificats (CBA) est configurée pour le locataire, tous les utilisateurs voient le lien Utiliser un certificat ou une carte à puce sur la page de connexion par mot de passe. Toutefois, seuls les utilisateurs qui sont concernés par l'authentification basée sur certificat (CBA) peuvent s’authentifier correctement pour une application qui utilise Microsoft Entra ID en tant que fournisseur d’identité.

   

   Si vous mettent à disposition d’autres méthodes d’authentification, telles que la connexion par téléphone ou les clés de sécurité, vos utilisateurs peuvent voir une boîte de dialogue de connexion différente.

   

5. Après que l’utilisateur a sélectionné CBA, le client redirige vers le point de terminaison d'authentification par certificat. Pour les Microsoft Entra ID publiques, le point de terminaison d’authentification par certificat est https://certauth.login.microsoftonline.com. Pour Azure Government, le point de terminaison d’authentification de certificat est https://certauth.login.microsoftonline.us.

   Le point de terminaison effectue une authentification mutuelle Transport Layer Security (TLS) et demande le certificat client dans le cadre de la négociation TLS. Une entrée pour cette requête apparaît dans le journal des connexions.

   Remarque

   Un administrateur doit autoriser l’accès à la page de connexion de l’utilisateur et au point de terminaison d’authentification de *.certauth.login.microsoftonline.com certificat pour votre environnement cloud. Désactivez l’inspection TLS sur le point de terminaison d’authentification par certificat afin de garantir que la demande de certificat client réussit dans le cadre de la négociation TLS.

   Assurez-vous que la désactivation de l’inspection TLS fonctionne également pour les indicateurs d’émetteur avec la nouvelle URL. Ne codez pas en dur l’URL avec l’ID de locataire. L’ID de locataire peut changer pour les utilisateurs b2B (business-to-business). Utilisez une expression régulière pour autoriser l’URL précédente et la nouvelle URL à fonctionner lorsque vous désactivez l’inspection TLS. Par exemple, en fonction du proxy, utilisez *.certauth.login.microsoftonline.com ou *certauth.login.microsoftonline.com. Dans Azure Government, utilisez *.certauth.login.microsoftonline.us ou *certauth.login.microsoftonline.us.

   Sauf si l'accès est autorisé, le processus CBA échoue si vous activez les suggestions de l'émetteur.

6. Microsoft Entra ID demande un certificat client. L’utilisateur sélectionne le certificat client, puis sélectionne OK.

   

7. Microsoft Entra ID vérifie la liste de révocation de certificats (CRL) pour vous assurer que le certificat n'est pas révoqué et qu'il est valide. Microsoft Entra ID identifie l’utilisateur en utilisant la liaison de nom d’utilisateur configurée sur le locataire pour mapper la valeur du champ du certificat à la valeur de l’attribut utilisateur.

8. Si un utilisateur unique est trouvé via une stratégie de Accès conditionnel Microsoft Entra qui nécessite l’authentification multifacteur (MFA) et que la règle de liaison d’authentification par certificat satisfait les exigences de l’authentification multifacteur, Microsoft Entra ID connecte immédiatement l’utilisateur. Si l’authentification multifacteur est requise, mais que le certificat ne satisfait qu’à un seul facteur, si l’utilisateur est déjà inscrit, la connexion sans mot de passe et FIDO2 sont proposées en tant que deuxième facteurs.

9. Microsoft Entra ID termine le processus de connexion en envoyant un jeton d’actualisation principal pour indiquer la connexion réussie.

Si la connexion de l’utilisateur réussit, l’utilisateur peut accéder à l’application.

Indications d’émetteur

Les indications d’émetteur renvoient un indicateur autorité de certification approuvée dans le cadre de la négociation TLS. La liste des autorités de certification approuvées est définie sur le sujet des autorités de certification que le locataire charge dans le magasin de confiance Microsoft Entra. Un client de navigateur ou un client d’application natif peut utiliser les indicateurs que le serveur renvoie pour filtrer les certificats affichés dans le sélecteur de certificats. Le client affiche uniquement les certificats d’authentification émis par les autorités de certification dans le magasin de confiance.

Activez les indications d’émetteur

Pour activer les indicateurs d’émetteur, cochez la case Indicateurs de l’émetteur . Un administrateur de stratégie d’authentification doit sélectionner I Acknowledge après avoir fait en sorte que le proxy sur lequel l’inspection TLS a été configurée soit correctement mis à jour, puis enregistrer les modifications.

Propagation de la mise à jour du répertoire de confiance de l'autorité de certification

Après avoir activé les indications d’émetteur et ajouté, mis à jour ou supprimé des autorités de certification du magasin de confiance, un délai pouvant aller jusqu’à 10 minutes peut se produire pendant que les indications d’émetteur sont propagées vers le client. Un administrateur de stratégie d’authentification doit se connecter avec un certificat une fois que les indicateurs de l’émetteur sont mis à disposition pour lancer la propagation.

Les utilisateurs ne peuvent pas s’authentifier à l’aide de certificats émis par de nouvelles autorités de certification tant que les indicateurs ne sont pas propagés. Les utilisateurs voient le message d’erreur suivant lorsque les mises à jour du magasin de confiance de l'AC sont propagées :

MFA avec CBA à facteur unique

Microsoft Entra CBA remplit les conditions à la fois pour l'authentification de premier facteur et l'authentification à deux facteurs.

Voici quelques combinaisons prises en charge :

• CBA (premier facteur) et clés d’accès (second facteur)
• CBA (premier facteur) et connexion téléphonique sans mot de passe (second facteur)
• CBA (premier facteur) et clés de sécurité FIDO2 (second facteur)
• Mot de passe (premier facteur) et CBA (deuxième facteur)

Les utilisateurs doivent disposer d'un moyen d'obtenir l'authentification multifacteur (MFA) et d'enregistrer une connexion sans mot de passe ou via FIDO2 avant de se connecter en utilisant Microsoft Entra CBA.

Options pour obtenir la capacité MFA avec CBA activé

Microsoft Entra CBA peut être à facteur unique ou multifacteur en fonction de la configuration du locataire. L’activation de CBA rend un utilisateur potentiellement capable de terminer une MFA. Un utilisateur disposant d’un certificat ou d’un mot de passe à facteur unique doit utiliser un autre facteur pour terminer l’authentification multifacteur.

Nous n’autorisons pas l’enregistrement d’autres méthodes sans satisfaire d’abord la MFA. Si l’utilisateur ne dispose d’aucune autre méthode MFA enregistrée et qu’il est inclus dans l’étendue pour CBA, il ne peut pas utiliser la preuve d’identité pour enregistrer d’autres méthodes d’authentification et obtenir la MFA.

Si l’utilisateur compatible CBA ne dispose que d’un certificat à facteur unique et doit effectuer l’authentification multifacteur, choisissez l’une des options suivantes pour authentifier l’utilisateur :

• L’utilisateur peut entrer un mot de passe et utiliser un certificat à facteur unique.
• Un administrateur de stratégie d’authentification peut émettre une passe d’accès temporaire.
• Un administrateur de stratégie d’authentification peut ajouter un numéro de téléphone et autoriser l’authentification de voix ou de sms pour le compte d’utilisateur.

Si l’utilisateur compatible CBA n’a pas reçu de certificat et doit terminer l’authentification multifacteur, choisissez l’une des options suivantes pour authentifier l’utilisateur :

• Un administrateur de stratégie d’authentification peut émettre une passe d’accès temporaire.
• Un administrateur de stratégie d’authentification peut ajouter un numéro de téléphone et autoriser l’authentification de voix ou de sms pour le compte d’utilisateur.

Si l’utilisateur compatible CBA ne peut pas utiliser de certificat multifacteur, par exemple s’il utilise un appareil mobile sans prise en charge de carte à puce, mais qu’il doit effectuer l’authentification multifacteur, choisissez l’une des options suivantes pour authentifier l’utilisateur :

• Un administrateur de stratégie d’authentification peut émettre une passe d’accès temporaire.
• L’utilisateur peut inscrire une autre méthode MFA (lorsque l’utilisateur peut utiliser un certificat multifacteur sur un appareil).
• Un administrateur de stratégie d’authentification peut ajouter un numéro de téléphone et autoriser l’authentification de voix ou de sms pour le compte d’utilisateur.

Configurer l'authentification sans mot de passe par téléphone avec l'authentification basée sur certificat.

Pour que la connexion par téléphone sans mot de passe fonctionne, désactivez d’abord la notification classique via l’application mobile d’un utilisateur.

1. Connectez-vous au centre d’administration Microsoft Entra en tant qu'au moins un Administrateur de stratégie d'authentification.

2. Effectuez les étapes décrites dans Activer l’authentification de connexion par téléphone sans mot de passe.

   Important

   Veillez à sélectionner l’option sans mot de passe . Pour tous les groupes que vous ajoutez à la connexion par téléphone sans mot de passe, vous devez changer la valeur du mode d’authentification en sans mot de passe. Si vous sélectionnez Any, CBA et la connexion sans mot de passe ne fonctionnent pas.

3. Sélectionnez Entra ID>Authentification multifacteur> Paramètres d’authentification multifacteur basés sur le cloud.

   

4. Sous Options de vérification, décochez la case Notification via l’application mobile , puis sélectionnez Enregistrer.

   

Flux d’authentification MFA à l’aide de certificats à facteur unique et de connexion sans mot de passe

Prenons un exemple d’utilisateur disposant d’un certificat à facteur unique et configuré pour la connexion sans mot de passe. En tant qu’utilisateur, vous effectuez les étapes suivantes :

1. Entrez votre nom d’utilisateur principal (UPN), puis sélectionnez Suivant.

   

2. Sélectionnez Utiliser un certificat ou une carte à puce.

   

   Si vous mettent à disposition d’autres méthodes d’authentification, telles que la connexion par téléphone ou les clés de sécurité, vos utilisateurs peuvent voir une boîte de dialogue de connexion différente.

   

3. Dans le sélecteur de certificats client, sélectionnez le certificat utilisateur approprié, puis sélectionnez OK.

   

4. Étant donné que le certificat est configuré pour être la force de l’authentification à facteur unique, vous avez besoin d’un deuxième facteur pour répondre aux exigences de l’authentification multifacteur. Les deuxièmes facteurs disponibles sont affichés dans la boîte de dialogue de connexion. Dans ce cas, il s’agit de la connexion sans mot de passe. Sélectionnez Approuver une demande sur l'application Microsoft Authenticator.

   

5. Vous recevez une notification sur votre téléphone. Sélectionnez Approuver la connexion ?.

6. Dans Microsoft Authenticator, entrez le numéro que vous voyez dans le navigateur ou l’application.

   

7. Sélectionnez Oui, et vous pouvez vous authentifier et vous connecter.

Stratégie de liaison d’authentification

La stratégie de liaison d’authentification permet de définir la robustesse de l’authentification comme étant à facteur unique ou multifacteur. Un administrateur de stratégie d’authentification peut changer la méthode par défaut d’un facteur unique en multifacteur. Un administrateur peut également configurer des configurations de stratégie personnalisées à l’aide IssuerAndSubject, PolicyOIDou IssuerPolicyOID dans le certificat.

Force du certificat

Les administrateurs de stratégie d’authentification peuvent déterminer si la force du certificat est un facteur unique ou multifacteur. Pour plus d’informations, consultez la documentation qui associe les niveaux d'assurance d'authentification NIST aux méthodes d'authentification de Microsoft Entra, qui s’appuie sur NIST 800-63B SP 800-63B, lignes directrices sur l'identité numérique : gestion de l'authentification et du cycle de vie.

Authentification par certificat multifacteur

Lorsqu’un utilisateur a un certificat multifacteur, il peut effectuer l’authentification multifacteur uniquement à l’aide de certificats. Toutefois, un administrateur de stratégie d’authentification doit s’assurer que les certificats sont protégés par un code confidentiel ou biométrique pour être considérés comme multifacteurs.

Règles de liaison de stratégies d'authentification multiples

Vous pouvez créer plusieurs règles de stratégie de liaison d’authentification personnalisées à l’aide de différents attributs de certificat. Par exemple, utilisez l’émetteur et l’OID de stratégie, ou simplement l’OID de stratégie, ou simplement l’émetteur.

La séquence suivante détermine le niveau de protection de l’authentification lorsque des règles personnalisées se chevauchent :

1. Les règles d’émetteur et d’OID de stratégie ont priorité sur les règles d’OID de stratégie. Les règles d'OID de politique prévalent sur les règles de l’émetteur du certificat.
2. Les règles d’émetteur et d’OID de stratégie sont évaluées en premier. Si vous avez une règle personnalisée avec l’autorité de certification émettrice CA1 et l’OID de stratégie 1.2.3.4.5 avec MFA, seul le certificat A qui satisfait à la fois la valeur de l’émetteur et l’OID de stratégie bénéficie de la MFA.
3. Les règles personnalisées qui utilisent des OID de politique sont évaluées. Si vous disposez d’un certificat A avec un OID de stratégie 1.2.3.4.5 et d’un justificatif dérivé B basé sur ce certificat avec un OID de stratégie 1.2.3.4.5.6, et que la règle personnalisée est définie comme un OID de stratégie de valeur 1.2.3.4.5 avec une authentification multifactorielle (MFA), seul le certificat A satisfait aux exigences de MFA. Les identifiants B répondent uniquement à l’authentification à un facteur. Si l’utilisateur a utilisé des informations d’identification dérivées pendant la connexion et a été configuré pour l’authentification multifacteur, l’utilisateur est invité à demander un deuxième facteur pour l’authentification réussie.
4. S’il existe un conflit entre plusieurs OID de stratégie (par exemple, lorsqu’un certificat a deux OID de stratégie, où l’un lie à l’authentification à facteur unique et à l’autre est lié à l’authentification multifacteur), traitez le certificat comme une authentification à facteur unique.
5. Les règles personnalisées qui utilisent des autorités de certification émettrices sont évaluées. Si un certificat a une OID de stratégie et des règles d'émetteur correspondantes, l'OID de stratégie est toujours vérifiée en premier. Si aucune règle de stratégie n’est trouvée, les liaisons d’émetteur sont ensuite vérifiées. L’OID de stratégie a une priorité de liaison d’authentification forte plus élevée que l’émetteur.
6. Si une autorité de certification est liée à MFA, tous les certificats utilisateur émis par l’autorité sont éligibles comme MFA. La même logique s’applique à l’authentification à facteur unique.
7. Si un OID de stratégie est attaché à l’authentification multifacteur, tous les certificats utilisateur qui incluent cet OID de stratégie parmi les OID sont éligibles en tant qu’authentification multifacteur. Un certificat utilisateur peut avoir plusieurs OID de politique.
8. Un émetteur de certificat ne peut avoir qu’une seule liaison d’authentification forte valide (autrement dit, un certificat ne peut pas être lié à l’authentification à facteur unique et à l’authentification multifacteur).

Politique de liaison de nom d’utilisateur

La politique d'association de nom d’utilisateur aide à valider le certificat de l’utilisateur. Par défaut, le nom alternatif du sujet (SAN) dans le certificat est associé à l'attribut userPrincipalName de l'objet utilisateur pour identifier l'utilisateur.

Améliorer la sécurité à l’aide de liaisons de certificat

Microsoft Entra prend en charge sept méthodes d'utilisation des liaisons de certificat. En général, les types de mappage sont considérés comme une affinité élevée s’ils sont basés sur des identificateurs que vous ne pouvez pas réutiliser, tels que SubjectKeyIdentifier (SKI) ou SHA1PublicKey. Ces identificateurs fournissent une assurance plus élevée qu’un seul certificat peut être utilisé pour authentifier un utilisateur.

Les types de mappage basés sur les noms d’utilisateur et les adresses e-mail sont considérés comme une faible affinité. Microsoft Entra ID implémente trois mappages considérés comme ayant une faible affinité en fonction des identificateurs réutilisables. Les autres sont considérés comme des liaisons à affinité élevée. Pour plus d’informations, consultez certificateUserIds.

Définir et remplacer la liaison d’affinité

Un administrateur de stratégie d’authentification peut configurer si les utilisateurs peuvent s’authentifier à l’aide d’une liaison de nom d’utilisateur à faible affinité ou à affinité élevée.

Définissez la liaison d’affinité requise pour le locataire, qui s’applique à tous les utilisateurs. Pour remplacer la valeur par défaut à l’échelle du locataire, créez des règles personnalisées en fonction de l’émetteur et de l’OID de stratégie, ou simplement de l’OID de stratégie, ou simplement de l’émetteur.

Plusieurs règles de liaison de stratégie de nom d’utilisateur

Pour résoudre plusieurs règles de liaison de stratégie de nom d’utilisateur, Microsoft Entra ID utilise la liaison de priorité la plus élevée (numéro le plus faible) :

1. Recherche l’objet utilisateur à l’aide du nom d’utilisateur ou de l’UPN.
2. Obtient la liste de toutes les liaisons de nom d’utilisateur configurées par l’administrateur de stratégie d’authentification dans la configuration de la méthode CBA ordonnée par l’attribut priority . Actuellement, la priorité n’est pas affichée dans le Centre d’administration. Microsoft Graph retourne l’attribut priority pour chaque liaison. Ensuite, les priorités sont utilisées dans le processus d’évaluation.
3. Si la liaison à affinité élevée est configurée ou si la valeur de certificat correspond à une règle personnalisée qui nécessite une liaison d’affinité élevée, supprime toutes les liaisons à faible affinité de la liste.
4. Évalue chaque liaison dans la liste jusqu’à ce qu’une authentification réussie se produise.
5. Si le champ de certificat X.509 de la liaison configurée se trouve sur le certificat présenté, Microsoft Entra ID correspond à la valeur du champ de certificat à la valeur d’attribut de l’objet utilisateur.
   • Si une correspondance est trouvée, l’authentification de l’utilisateur réussit.
   • Si aucune correspondance n’est trouvée, passe à la liaison de priorité suivante.
6. Si le champ du certificat X.509 n’est pas présent dans le certificat présenté, passe à la liaison de priorité suivante.
7. Valide toutes les liaisons de nom d’utilisateur configurées jusqu’à ce que l’un d’eux entraîne une correspondance et que l’authentification utilisateur réussisse.
8. Si aucune correspondance n’est trouvée sur l’une des liaisons de nom d’utilisateur configurées, l’authentification utilisateur échoue.

Sécuriser la configuration de Microsoft Entra à l’aide de plusieurs liaisons de noms d’utilisateur

Chacun des attributs d’objet utilisateur Microsoft Entra disponibles pour lier des certificats à des comptes d’utilisateur Microsoft Entra (userPrincipalName, onPremiseUserPrincipalName et certificateUserIds) a une contrainte unique pour s’assurer qu’un certificat ne correspond qu’à un seul compte d’utilisateur Microsoft Entra. Cependant, Microsoft Entra CBA prend en charge plusieurs méthodes de liaison dans la stratégie de liaison de nom d’utilisateur. Un administrateur de stratégie d’authentification peut prendre en charge un certificat utilisé dans plusieurs configurations de comptes d’utilisateur Microsoft Entra.

Par exemple, vous avez deux liaisons de nom d’utilisateur sur PrincipalName mappées à UPN, et SubjectKeyIdentifier (SKI) est mappée à certificateUserIds. Si vous souhaitez qu’un certificat soit utilisé pour un seul compte, un administrateur de stratégie d’authentification doit s’assurer que le compte dispose de l’UPN présent dans le certificat. Ensuite, l’administrateur implémente le SKI mapping dans l’attribut certificateUserIds du même compte.

Prise en charge de plusieurs certificats avec un compte d’utilisateur Microsoft Entra (M :1)

Dans certains scénarios, une organisation émet plusieurs certificats pour une identité unique. Il peut s’agir d’informations d’identification dérivées pour un appareil mobile, mais il peut également s’agir d’une carte à puce secondaire ou d’un appareil compatible avec le titulaire d’informations d’identification X.509 tel qu’un YubiKey.

Comptes cloud uniquement (M :1)

Pour les comptes cloud uniquement, vous pouvez mapper jusqu’à cinq certificats à utiliser en remplissant le certificateUserIds champ avec des valeurs uniques pour identifier chaque certificat. Pour mapper les certificats, dans le Centre d’administration, accédez à l’onglet Informations d’autorisation .

Si l’organisation utilise des liaisons à affinité élevée comme IssuerAndSerialNumber, les valeurs certificateUserIds peuvent ressembler à l’exemple suivant :

X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>cD2eF3gH4iJ5kL6mN7-oP8qR9sT
X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>eF3gH4iJ5kL6mN7oP8-qR9sT0uV

Dans cet exemple, la première valeur représente X509Certificate1. La deuxième valeur représente X509Certificate2. L’utilisateur peut présenter l’un ou l’autre certificat lors de la connexion. Si la liaison de nom d'utilisateur CBA est définie pour pointer vers le champ certificateUserIds afin de rechercher le type de liaison spécifique (dans cet exemple, IssuerAndSerialNumber), l'utilisateur se connecte correctement.

Comptes synchronisés hybrides (M :1)

Pour les comptes synchronisés, vous pouvez mapper plusieurs certificats. Dans Active Directory local, renseignez le champ altSecurityIdentities avec les valeurs qui identifient chaque certificat. Si votre organisation utilise des liaisons à affinité élevée (c’est-à-dire une authentification forte), IssuerAndSerialNumberles valeurs peuvent ressembler à ces exemples :

X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>cD2eF3gH4iJ5kL6mN7-oP8qR9sT
X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>eF3gH4iJ5kL6mN7oP8-qR9sT0uV

Dans cet exemple, la première valeur représente X509Certificate1. La deuxième valeur représente X509Certificate2. Les valeurs doivent ensuite être synchronisées avec le champ certificateUserIds dans Microsoft Entra ID.

Prise en charge d'un même certificat avec plusieurs comptes d'utilisateur Microsoft Entra (M:1)

Dans certains scénarios, une organisation exige qu’un utilisateur utilise le même certificat pour s’authentifier dans plusieurs identités. Il peut s’agir d’un compte administratif, d’un compte développeur ou d’un compte temporaire.

Dans Active Directory local, le champ altSecurityIdentities remplit les valeurs de certificat. Un indicateur est utilisé lors de la connexion pour diriger Active Directory vers le compte prévu pour vérifier la connexion.

Microsoft Entra CBA a un processus différent et aucun indicateur n’est inclus. À la place, la découverte du domaine d’origine identifie le compte cible et vérifie les valeurs du certificat. Microsoft Entra CBA applique également l’unicité dans le champ certificateUserIds. Deux comptes ne peuvent pas remplir les mêmes valeurs de certificat.

Comptes cloud uniquement (1 :M)

Pour les comptes cloud uniquement, créez plusieurs liaisons de nom d’utilisateur et mappez des valeurs uniques à chaque compte d’utilisateur qui utilise le certificat. L’accès à chaque compte est authentifié à l’aide d’une liaison de nom d’utilisateur différente. Ce niveau d’authentification s’applique à la limite d’un répertoire ou d’un locataire unique. Un administrateur de stratégie d’authentification peut mapper le certificat pour l’utiliser dans un autre répertoire ou locataire si les valeurs restent uniques par compte.

Remplissez le certificateUserIds champ avec une valeur unique qui identifie le certificat. Pour remplir le champ, dans le centre d’administration, accédez à l’onglet Informations d’autorisation .

Si l’organisation utilise des liaisons à affinité élevée (c’est-à-dire une authentification forte) comme IssuerAndSerialNumber et SKI, les valeurs pourraient ressembler à l’exemple suivant :

Liaisons de nom d’utilisateur :

• IssuerAndSerialNumber > certificateUserIds
• SKI > certificateUserIds

Valeurs du compte certificateUserIds d’utilisateur :
X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>aB1cD2eF3gH4iJ5kL6-mN7oP8qR
X509:<SKI>cD2eF3gH4iJ5kL6mN7-oP8qR9sT

À présent, lorsque l’un des utilisateurs présente le même certificat lors de la connexion, l’utilisateur se connecte correctement, car son compte correspond à une valeur unique sur ce certificat. Un compte est authentifié à l’aide de IssuerAndSerialNumber, et l’autre à l’aide de la liaison SKI.

Comptes synchronisés hybrides (1 :M)

Les comptes synchronisés nécessitent une approche différente. Bien qu’un administrateur de stratégie d’authentification puisse mapper des valeurs uniques à chaque compte d’utilisateur qui utilise le certificat, la pratique courante de remplir toutes les valeurs à chaque compte dans Microsoft Entra ID rend cette approche difficile. Au lieu de cela, Microsoft Entra Connect doit filtrer les valeurs par compte en valeurs uniques renseignées dans le compte dans Microsoft Entra ID. La règle d’unicité s’applique à la limite d’un répertoire ou d’un locataire unique. Un administrateur de stratégie d’authentification peut mapper le certificat pour l’utiliser dans un autre répertoire ou locataire si les valeurs restent uniques par compte.

L’organisation peut également disposer de plusieurs forêts Active Directory qui alimentent les utilisateurs dans un seul locataire Microsoft Entra. Dans ce cas, Microsoft Entra Connect applique le filtre à chacune des forêts Active Directory avec le même objectif : remplissez uniquement une valeur unique spécifique au compte cloud.

Remplissez le champ altSecurityIdentities dans Active Directory avec les valeurs qui identifient le certificat. Incluez la valeur de certificat spécifique pour ce type de compte d’utilisateur (par detailedexemple, , adminou developer). Sélectionnez un attribut clé dans Active Directory. L’attribut indique à la synchronisation quel type de compte d’utilisateur l’utilisateur évalue (par msDS-cloudExtensionAttribute1exemple). Remplissez cet attribut avec la valeur de type utilisateur que vous souhaitez utiliser, comme detailed, admin ou developer. Si le compte est le compte principal de l’utilisateur, la valeur peut être vide ou NULL.

Vérifiez que les comptes ressemblent à ces exemples :

Forêt 1 : Account1 (bob@woodgrove.com) :
X509:<SKI>aB1cD2eF3gH4iJ5kL6mN7oP8qR
X509:<SHA1-PUKEY>cD2eF3gH4iJ5kL6mN7oP8qR9sT
X509:<PN>bob@woodgrove.com

Forest 1 : Compte 2 (bob-admin@woodgrove.com) :
X509:<SKI>aB1cD2eF3gH4iJ5kL6mN7oP8qR
X509:<SHA1-PUKEY>cD2eF3gH4iJ5kL6mN7oP8qR9sT
X509:<PN>bob@woodgrove.com

Forêt 2 : ADAccount1 (bob-tdy@woodgrove.com) :
X509:<SKI>aB1cD2eF3gH4iJ5kL6mN7oP8qR
X509:<SHA1-PUKEY>cD2eF3gH4iJ5kL6mN7oP8qR9sT
X509:<PN>bob@woodgrove.com

Vous devez ensuite synchroniser ces valeurs avec le champ certificateUserIds dans Microsoft Entra ID.

Pour effectuer la synchronisation avec certificateUserIds:

1. Configurez Microsoft Entra Connect pour ajouter le champ alternativeSecurityIds au métaverse.
2. Pour chaque forêt Active Directory local, configurez une nouvelle règle de trafic entrant personnalisé avec une priorité élevée (un nombre faible, inférieur à 100). Ajoutez une Expression transformation avec le altSecurityIdentities champ comme source. L’expression cible utilise l’attribut clé que vous avez sélectionné et rempli, et utilise le mappage aux types d’utilisateurs que vous avez définis.

Par exemple :

IIF((IsPresent([msDS-cloudExtensionAttribute1]) && IsPresent([altSecurityIdentities])), 
    IIF((InStr(LCase([msDS-cloudExtensionAttribute1]),LCase("detailee"))>0), 
    Where($item,[altSecurityIdentities],(InStr($item, "X509:<SHA1-PUKEY>")>0)), 
        IIF((InStr(LCase([msDS-cloudExtensionAttribute1]),LCase("developer"))>0), 
        Where($item,[altSecurityIdentities],(InStr($item, "X509:<SKI>")>0)), NULL) ), 
    IIF(IsPresent([altSecurityIdentities]), 
    Where($item,[altSecurityIdentities],(BitAnd(InStr($item, "X509:<I>"),InStrRev($item, "<SR>"))>0)), NULL) 
)

Dans cet exemple, altSecurityIdentities et l’attribut clé msDS-cloudExtensionAttribute1 sont d’abord vérifiés pour voir s’ils sont renseignés. S'ils ne sont pas peuplés, altSecurityIdentities est vérifié pour voir s'il est peuplé. S’il est vide, définissez-le sur NULL. Sinon, le compte est dans le scénario par défaut.

Dans cet exemple également, filtrez uniquement sur le mappage IssuerAndSerialNumber. Si l’attribut de clé est rempli, la valeur est vérifiée pour voir si elle est égale à l’un de vos types d’utilisateurs définis. Dans l’exemple, si cette valeur est detailed, filtrez sur la valeur SHA1PublicKey provenant de altSecurityIdentities. Si la valeur est developer, filtrez selon la valeur de SubjectKeyIssuer issue de altSecurityIdentities.

Vous pouvez rencontrer plusieurs valeurs de certificat d’un type spécifique. Par exemple, vous pouvez voir plusieurs valeurs PrincipalName, plusieurs valeurs SKI, ou plusieurs valeurs SHA1-PUKEY. Le filtre obtient toutes les valeurs et les synchronise dans Microsoft Entra ID, pas seulement le premier qu’il trouve.

Voici un deuxième exemple qui montre comment envoyer (push) une valeur vide si l’attribut de contrôle est vide :

IIF((IsPresent([msDS-cloudExtensionAttribute1]) && IsPresent([altSecurityIdentities])), 
    IIF((InStr(LCase([msDS-cloudExtensionAttribute1]),LCase("detailee"))>0), 
    Where($item,[altSecurityIdentities],(InStr($item, "X509:<SHA1-PUKEY>")>0)), 
        IIF((InStr(LCase([msDS-cloudExtensionAttribute1]),LCase("developer")>0), 
        Where($item,[altSecurityIdentities],(InStr($item, "X509:<SKI>")>0)), NULL) ), 
    IIF(IsPresent([altSecurityIdentities]), 
    AuthoritativeNull, NULL) 
) 

Si la valeur dans altSecurityIdentities ne correspond à aucune des valeurs de recherche dans l’attribut de contrôle, une valeur AuthoritativeNull est passée. Cette valeur garantit que les règles antérieures ou suivantes qui remplissent alternativeSecurityId sont ignorées. Le résultat est vide dans Microsoft Entra ID.

Pour synchroniser une valeur vide :

1. Configurez une nouvelle règle de trafic sortant personnalisé avec une priorité faible (un nombre élevé, supérieur à 160, mais en bas de la liste).
2. Ajoutez une transformation directe avec le alternativeSecurityIds champ comme source et le certificateUserIds champ comme cible.
3. Exécutez un cycle de synchronisation pour terminer la population des données dans Microsoft Entra ID.

Assurez-vous que CBA dans chaque locataire est configuré avec des liaisons de nom d’utilisateur pointant vers le champ certificateUserIds pour les types de champs que vous avez mappés à partir du certificat. À présent, l’un de ces utilisateurs peut présenter le certificat lors de la connexion. Une fois la valeur unique du certificat validée par rapport au certificateUserIds champ, l’utilisateur est correctement connecté.

Étendue de l’autorité de certification

L’étendue de l’autorité de certification dans Microsoft Entra permet aux administrateurs clients de restreindre l’utilisation d’autorités de certification spécifiques aux groupes d’utilisateurs définis. Cette fonctionnalité améliore la sécurité et la facilité de gestion de l’autorité de certification en garantissant que seuls les utilisateurs autorisés peuvent s’authentifier à l’aide de certificats émis par des autorités de certification spécifiques.

L’étendue de l’autorité de certification est utile dans les scénarios multi-PKI ou B2B où plusieurs autorités de certification sont utilisées dans différentes populations d’utilisateurs. Il permet d’empêcher l’accès involontaire et de prendre en charge la conformité avec les stratégies organisationnelles.

Principaux avantages

• Limite l’utilisation du certificat à des groupes d’utilisateurs spécifiques
• Prend en charge des environnements PKI complexes via plusieurs autorités de certification
• Fournit une protection renforcée contre l’utilisation incorrecte ou la compromission des certificats
• Offre une visibilité sur l’utilisation de l’accès conditionnel via les journaux de connexion et les outils de surveillance.

Un administrateur peut utiliser l'étendue CA pour définir des règles associant une CA (identifiée par son SKI) à un groupe spécifique de Microsoft Entra. Lorsqu’un utilisateur tente de s’authentifier à l’aide d’un certificat, le système vérifie si l’autorité de certification émettrice pour le certificat est étendue à un groupe qui inclut l’utilisateur. Microsoft Entra remonte la chaîne d’autorités de certification. Elle applique toutes les règles d’étendue jusqu’à ce que l’utilisateur se trouve dans l’un des groupes de toutes les règles d’étendue. Si l’utilisateur n’est pas dans le groupe délimité, l’authentification échoue, même si le certificat est sinon valide.

Configurer la fonctionnalité d’étendue des autorités de certification

1. Connectez-vous au Centre d’administration Microsoft Entra en tant qu’administrateur des stratégies d’authentification au minimum.

2. Accédez aux méthodes d'Entra ID>authentification>Authentification par certificat.

3. Sous Configurer, accédez à la stratégie d’étendue de l’émetteur de certificat.

   

4. Sélectionnez Ajouter une règle.

   

5. Sélectionnez Filtrer les autorités de certification par PKI.

   Autorités de certification classiques affiche toutes les autorités de certification du magasin classique. La sélection d’une infrastructure à clé publique spécifique affiche toutes les autorités de certification de l’infrastructure à clé publique sélectionnée.

6. Sélectionnez une infrastructure à clé publique.

   

7. La liste de l’émetteur de certificat affiche toutes les autorités de certification de l’infrastructure à clé publique sélectionnée. Sélectionnez une autorité de certification pour créer une règle de portée.

   

8. Sélectionnez Ajouter un groupe.

   

9. Sélectionnez un groupe.

   

10. Sélectionnez Ajouter pour enregistrer la règle.

    

11. Cochez la case I Acknowledge , puis sélectionnez Enregistrer.

    

12. Pour modifier ou supprimer une stratégie d’étendue des autorités de certification, sélectionnez "...” sur la ligne de la règle. Pour modifier la règle, sélectionnez Modifier. Pour supprimer la règle, sélectionnez Supprimer.

    

Limitations connues

• Un seul groupe peut être attribué à chaque autorité de certification.
• Un maximum de 30 règles de portée est pris en charge.
• L'application de la délimitation est imposée au niveau de l'autorité de certification intermédiaire.
• Une configuration incorrecte peut entraîner un blocage des utilisateurs si aucune règle d’étendue valide n’existe.

Entrées du journal de connexion

• Le journal de connexion indique le succès. Dans l’onglet Détails supplémentaires, le SKI de l’autorité de certification issu de la règle de stratégie d’étendue apparaît.

  

• Lorsqu’un CBA échoue en raison d’une règle d’étendue des autorités de certification, l’onglet Informations de base du journal de connexion affiche le code d’erreur 500189.

  

  Les utilisateurs finaux voient le message d’erreur suivant :

  

Fonctionnement de l’authentification basée sur les certificats avec une stratégie d’accès conditionnel de force d’authentification

Vous pouvez utiliser la robustesse d’authentification Microsoft Entra intégrée MFA résistante au phishing pour créer une stratégie d’authentification d’accès conditionnel qui spécifie l’utilisation de CBA pour accéder à une ressource. La stratégie autorise uniquement les méthodes d’authentification résistantes à l’hameçonnage, telles que L’ABA, les clés de sécurité FIDO2 et les Windows Hello Entreprise.

Vous pouvez également créer un niveau d’authentification personnalisé pour autoriser uniquement le CBA à accéder aux ressources sensibles. Vous pouvez autoriser CBA en tant qu'authentification à facteur unique, MFA ou les deux. Pour plus d’informations, consultez Force d’authentification de l’accès conditionnel.

Robustesse CBA avec options avancées

Dans la stratégie de méthode CBA, un administrateur de stratégie d’authentification peut déterminer la force du certificat à l’aide d’une stratégie de liaison d’authentification sur la méthode CBA. À présent, vous pouvez exiger qu’un certificat spécifique soit utilisé en fonction des OID d’émetteur et de stratégie lorsque les utilisateurs effectuent un CBA pour accéder à certaines ressources sensibles. Lorsque vous créez une force d’authentification personnalisée, accédez aux options Avancées. La fonctionnalité fournit une configuration plus précise pour déterminer les certificats et les utilisateurs qui peuvent accéder aux ressources. Pour plus d’informations, consultez : Options avancées pour la force d’authentification de l’accès conditionnel.

Historique de connexions

Les journaux de connexion fournissent des informations sur les connexions et la façon dont vos ressources sont utilisées dans l’organisation. Pour plus d’informations, consultez les journaux de connexion dans Microsoft Entra ID.

Ensuite, envisagez deux scénarios. Dans un scénario, le certificat satisfait à l’authentification à facteur unique. Dans le second scénario, le certificat satisfait la MFA.

Pour les scénarios de test, sélectionnez un utilisateur disposant d’une stratégie d’accès conditionnel qui requiert l’authentification multifacteur.

Configurez la stratégie de liaison utilisateur en mappant le Nom alternatif de sujet et le nom principal à l’objet utilisateur .

Le certificat utilisateur doit être configuré comme l’exemple illustré dans cette capture d’écran :

Résoudre les problèmes de connexion liés aux variables dynamiques dans les journaux de connexion

Bien que les journaux de connexion fournissent généralement toutes les informations dont vous avez besoin pour déboguer un problème de connexion, des valeurs spécifiques sont parfois requises. Les journaux de connexion ne prennent pas en charge les variables dynamiques. Dans certains cas, les journaux de connexion n’ont pas les informations dont vous avez besoin pour le débogage.

Par exemple, la raison de l’échec dans les journaux de connexion peut s’afficher "The Certificate Revocation List (CRL) failed signature validation. Expected Subject Key Identifier <expectedSKI> doesn't match CRL Authority Key <crlAK>. Request your tenant administrator to check the CRL configuration." Dans ce scénario, <expectedSKI> et <crlAKI> ne sont pas remplies avec des valeurs correctes.

Lorsque la connexion de l’utilisateur avec l’authentification basée sur certificat (CBA) échoue, vous pouvez copier les détails du journal de connexion à partir du lien Plus de détails sur la page d’erreur. Pour plus d’informations, consultez Comprendre la page d’erreur CBA.

Tester l’authentification à un facteur

Pour le premier scénario de test, configurez la stratégie d’authentification où la règle satisfait à l’authentification IssuerAndSubject à facteur unique.

1. Connectez-vous au Centre d’administration Microsoft Entra en tant qu’utilisateur de test à l’aide de l’authentification basée sur les certificats. La stratégie d’authentification est définie dans laquelle la règle satisfait à l’authentification IssuerAndSubject à facteur unique.

2. Recherchez, puis sélectionnez Journaux de connexion.

   La figure suivante montre certaines des entrées que vous pouvez trouver dans les journaux de connexion.

   La première entrée demande le certificat X.509 à l’utilisateur. L'état Interrompu signifie que Microsoft Entra ID a validé que l'authentification basée sur des certificats (CBA) est configurée pour le locataire. Un certificat est demandé pour l’authentification.

   

   Les détails de l’activité indiquent que la demande fait partie du flux de connexion attendu dans lequel l’utilisateur sélectionne un certificat.

   

   Des détails supplémentaires affichent les informations de certificat.

   

   Les autres entrées indiquent que l’authentification est terminée, qu’un jeton d’actualisation principal est renvoyé au navigateur et que l’utilisateur est autorisé à accéder à la ressource.

   

Tester l’authentification multifacteur

Pour le scénario de test suivant, configurez la stratégie d’authentification dans laquelle la règle policyOID répond à l’authentification multifactorielle.

1. Connectez-vous au centre d’administration Microsoft Entra à l’aide de l’authentification basée sur des certificats (CBA). Étant donné que la stratégie a été définie pour satisfaire l’authentification multifacteur, la connexion de l’utilisateur réussit sans un deuxième facteur.

2. Recherchez puis sélectionnez Connexions.

   Plusieurs entrées dans les journaux de connexion s’affichent, notamment une entrée avec un état interrompu .

   

   Les détails de l’activité indiquent que la demande fait partie du flux de connexion attendu dans lequel l’utilisateur sélectionne un certificat.

   

   L’entrée avec un état interrompu affiche des informations de diagnostic supplémentaires sous l’onglet Détails supplémentaires .

   

   Le tableau suivant contient une description de chaque champ.

   Champ	Descriptif
   Nom de l’objet du certificat utilisateur	Fait référence au champ du nom du sujet dans le certificat.
   Liaison de certificat utilisateur	Certificat : PrincipalName; attribut utilisateur : userPrincipalName; ; Rang : 1 Ce champ indique le champ de certificat SAN PrincipalName mappé à l’attribut userPrincipalName utilisateur et la priorité 1.
   Niveau d’authentification par certificat utilisateur	multiFactorAuthentication
   Type de niveau d’authentification par certificat utilisateur	PolicyId Ce champ indique que l’OID de stratégie a été utilisé pour déterminer la force d’authentification.
   Identificateur de niveau d’authentification par certificat utilisateur	1.2.3.4 Cela montre la valeur de l’OID de stratégie de l’identificateur du certificat.

Page d'erreur CBA

CBA peut échouer pour plusieurs raisons. Par exemple, un certificat non valide, l’utilisateur a sélectionné le certificat incorrect ou un certificat expiré, ou un problème de liste de révocation de certificats se produit. Lorsque la validation du certificat échoue, l’utilisateur voit ce message d’erreur :

Si l'authentification par certificat échoue sur un navigateur, même si l'échec est dû au fait que vous annulez le sélecteur de certificats, fermez la session du navigateur. Ouvrez une nouvelle session pour réessayer CBA. Une nouvelle session est requise, car les navigateurs cachent des certificats. Lorsqu'une authentification basée sur un certificat (CBA) est réessayée, le navigateur envoie un certificat mis en cache lors du défi TLS, ce qui entraîne ensuite un échec de la connexion et une erreur de validation.

1. Pour obtenir des informations de journalisation à envoyer à un administrateur de stratégie d’authentification pour plus d’informations à partir des journaux de connexion, sélectionnez Plus de détails.

   

2. Sélectionnez d’autres façons de vous connecter et essayez d’autres méthodes d’authentification disponibles pour vous connecter.

   

Réinitialiser le choix du certificat dans Microsoft Edge

Le navigateur Microsoft Edge a ajouté une fonctionnalité qui resets la sélection du certificat sans redémarrer le navigateur.

L’utilisateur effectue les étapes suivantes :

1. Lorsqu'un échec CBA se produit, la page d'erreur apparaît.

   

2. À gauche de l’URL de l’adresse, sélectionnez l’icône de verrouillage, puis sélectionnez Vos choix de certificat.

   

3. Sélectionnez Réinitialiser les choix de certificat.

   

4. Sélectionnez Réinitialiser les choix.

   

5. Sélectionnez d’autres façons de vous connecter.

   

6. Sélectionnez Utiliser un certificat ou une carte à puce et continuer avec l’authentification CBA.

CBA dans les méthodes MostRecentlyUsed

Après qu’un utilisateur s’est authentifié avec succès à l’aide de CBA, la méthode d’authentification MostRecentlyUsed (MRU) de l’utilisateur est définie sur CBA. La prochaine fois que l’utilisateur entre son UPN et sélectionne Suivant, il voit la méthode CBA et n’a pas besoin de sélectionner Utiliser le certificat ou la carte à puce.

Pour réinitialiser la méthode MRU, annulez le sélecteur de certificats, puis sélectionnez Autres façons de se connecter. Sélectionnez une autre méthode disponible, puis terminez l’authentification.

La méthode d’authentification MRU est définie au niveau de l’utilisateur. Si un utilisateur se connecte avec succès sur un autre appareil à l’aide d’une méthode d’authentification différente, la MRU est réinitialisée pour l’utilisateur à la méthode d'authentification actuellement utilisée.

Prise en charge des identités externes

Un utilisateur invité B2B d’identité externe peut utiliser CBA sur le locataire d’origine. Si les paramètres inter-locataires du locataire de ressource sont configurés pour faire confiance à la MFA du locataire d’origine, le CBA de l’utilisateur sur le locataire d’origine est pris en compte. Pour en savoir plus, veuillez consulter la section Configurer l’accès inter-locataires pour la collaboration B2B. Actuellement, CBA sur un locataire de ressource n’est pas pris en charge.

Contenu connexe

• Vue d'ensemble de Microsoft Entra CBA
• Analyse technique approfondie pour Microsoft Entra CBA
• How to configure Microsoft Entra CBA
• Microsoft Entra liste de révocation des certificats CBA
• Microsoft Entra CBA sur les appareils Android
• Connexion par carte à puce Windows à l’aide de Microsoft Entra CBA
• ID des utilisateurs du certificat
• Comment migrer des utilisateurs fédérés
• FORUM AUX QUESTIONS
• Microsoft Entra liste de révocation des certificats CBA
• Microsoft Entra CBA sur les appareils Android
• Connexion par carte à puce Windows à l’aide de Microsoft Entra CBA
• ID des utilisateurs du certificat
• Comment migrer des utilisateurs fédérés
• FORUM AUX QUESTIONS