Immersion technique avec l’authentification basée sur les certificats Microsoft Entra

Cet article explique comment fonctionne l’authentification basée sur des certificats Microsoft Entra et présente des détails techniques sur les configurations d’authentification basée sur des certificats Microsoft Entra.

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

L’image suivante décrit ce qu’il se passe lorsqu’un utilisateur tente de se connecter à une application dans un locataire où l’authentification basée sur les certificats Microsoft Entra est activé.

Nous allons maintenant parcourir chaque étape :

1. L’utilisateur tente d’accéder à une application, par exemple le portail MyApps.

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

3. L’utilisateur entre son nom d’utilisateur dans la page de connexion Microsoft Entra, puis sélectionne Suivant. Microsoft Entra ID effectue la découverte du domaine d’origine à l’aide du nom du locataire et le nom d’utilisateur est utilisé pour rechercher l’utilisateur dans le locataire.

   

4. Microsoft Entra ID vérifie si l’authentification basée sur les certificats est activée pour le locataire. Si l’authentification basée sur les certificats est activée, l’utilisateur voit un lien vers Utiliser un certificat ou une carte à puce dans la page du mot de passe. Si l’utilisateur ne voit pas le lien de connexion, assurez-vous que l’authentification basée sur les certificats est activée sur le locataire. Pour plus d’informations, consultez Comment activer l’authentification basée sur les certificats Microsoft Entra.

   Note

   Si l’authentification basée sur les certificats est activée sur le locataire, tous les utilisateurs voient le lien vers Utiliser un certificat ou une carte à puce dans la page du mot de passe. Toutefois, seuls les utilisateurs dans le cadre de l’authentification basée sur les certificats peuvent s’authentifier sur une application qui utilise Microsoft Entra ID comme fournisseur d’identité (IdP).

   

   Si vous avez activé d’autres méthodes d’authentification comme la connexion par téléphone ou les clés de sécurité, les utilisateurs peuvent obtenir un écran de connexion différent.

   

5. Une fois que l’utilisateur sélectionne l’authentification basée sur les certificats, le client est redirigé vers le point de terminaison certauth, qui est https://certauth.login.microsoftonline.com pour Entra ID public. Pour Azure Government, le point de terminaison certauth est https://certauth.login.microsoftonline.us.

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

   Note

   L’administrateur réseau doit autoriser l’accès à la page de connexion utilisateur et au *.certauth.login.microsoftonline.com du point de terminaison certauth pour l’environnement cloud du client. Désactivez l’inspection TLS sur le point de terminaison certauth pour vérifier que la demande de certificat client a bien abouti dans le cadre de la connexion TLS.

   Assurez-vous que la désactivation de l’inspection TLS fonctionne également pour la nouvelle URL avec des Indicateurs d’émetteur. Ne codez pas l’URL en dur avec tenantId, car il peut changer pour les utilisateurs B2B. Utilisez une expression régulière pour permettre à l’ancienne et à la nouvelle URL de fonctionner pour la désactivation de 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é, l’authentification basée sur un certificat échoue si vous activez la fonctionnalité à venir d’indicateurs d’autorité de certification approuvée.

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

   Note

   Les indicateurs CA approuvés ne sont pas pris en charge, donc la liste des certificats ne peut pas être plus affinée. Nous cherchons à ajouter cette fonctionnalité à l’avenir.

   

7. Microsoft Entra ID vérifie la liste de révocation de certificats pour s’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é avec une stratégie d’accès conditionnel qui a besoin d’une authentification multifacteur et que la règle de liaison d’authentification de certificat répond à MFA, Microsoft Entra ID connecte l’utilisateur immédiatement. Si une MFA est requise mais que le certificat ne satisfait qu’un seul facteur, la connexion sans mot de passe ou FIDO2 est proposée en tant que deuxième facteur s’ils sont déjà inscrits.

9. Microsoft Entra ID effectue le processus de connexion en renvoyant un jeton d’actualisation principal pour indiquer la réussite de la connexion.

10. Si l’utilisateur parvient à se connecter, il peut accéder à l’application.

L’authentification basée sur les certificats est compatible avec l’authentification multifacteur (MFA)

L’authentification basée sur les certificats Microsoft Entra est capable d’une authentification multifacteur (MFA). L’authentification basée sur les certificats Microsoft Entra peut être à facteur unique (SF) ou multifacteur (MF) en fonction de la configuration du locataire. L’activation de l’authentification basée sur les certificats rend un utilisateur potentiellement capable d’effectuer l’authentification multifacteur. Un utilisateur peut avoir besoin d’une configuration supplémentaire pour compléter la MFA et de s’authentifier pour enregistrer d’autres méthodes d’authentification lorsque l’utilisateur est dans l’étendue de l’authentification basée sur les certificats.

Si l’utilisateur compatible avec l’authentification basée sur les certificats a uniquement un certificat à facteur unique (SF) et doit effectuer l’authentification multifacteur :

1. Utilisez un mot de passe et un certificat SF.
2. Délivrez un passe d’accès temporaire.
3. L’administrateur de stratégie d’authentification ajoute un numéro de téléphone et autorise l’authentification vocale/par SMS pour le compte d’utilisateur.

Si l’utilisateur compatible avec l’authentification basée sur les certificats n’a pas encore reçu de certificat et doit effectuer l’authentification multifacteur :

1. Délivrez un passe d’accès temporaire.
2. L’administrateur de stratégie d’authentification ajoute un numéro de téléphone et autorise l’authentification vocale/par SMS pour le compte d’utilisateur.

Si l’utilisateur compatible avec l’authentification basée sur les certificats ne peut pas utiliser un certificat MF, par exemple sur un appareil mobile sans prise en charge de carte à puce et doit effectuer l’authentification multifacteur :

1. Délivrez un passe d’accès temporaire.
2. L’utilisateur doit inscrire une autre méthode MFA (lorsque l’utilisateur peut utiliser le certificat MF).
3. Utilisez le mot de passe et le certificat MF (lorsque l’utilisateur peut utiliser le certificat MF).
4. L’administrateur de stratégie d’authentification ajoute un numéro de téléphone et autorise l’authentification vocale/par SMS pour le compte d’utilisateur.

MFA avec l’authentification à un seul facteur basée sur un certificat (Preview)

Vous pouvez utiliser l’authentification basée sur les certificats (CBA) de Microsoft Entra en tant que deuxième facteur pour répondre aux exigences de l’authentification MFA avec des certificats à facteur unique. Parmi les combinaisons prises en charge, on peut citer :

1. Connexion basée sur les certificats (premier facteur) et par téléphone sans mot de passe (connexion sans mot de passe en tant que deuxième facteur)
2. CBA (premier facteur) et clés de sécurité FIDO2 (deuxième facteur)
3. Mot de passe (premier facteur) et CBA (deuxième facteur)

Les utilisateurs doivent avoir un autre moyen d’obtenir l’authentification MFA et de s’inscrire à la connexion sans mot de passe ou FIDO2 avant de se connecter avec l’authentification Microsoft Entra CBA.

Important

Un utilisateur est considéré comme compatible MFA lorsqu’il est inclus dans les paramètres de la méthode CBA. Cela signifie que l’utilisateur ne peut pas utiliser la preuve dans le cadre de son authentification pour l’inscription des autres méthodes disponibles. Assurez-vous que les utilisateurs sans certificat valide ne sont pas inclus dans les paramètres de la méthode CBA. Pour plus d’informations sur le fonctionnement de l’authentification, consultez Authentification multifacteur Microsoft Entra.

Étapes pour configurer une connexion par téléphone sans mot de passe (PSI) avec CBA

Pour que la connexion sans mot de passe fonctionne, les utilisateurs doivent désactiver les notifications héritées via leur application mobile.

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

2. Suivez les étapes dans Activer l’authentification avec une connexion par téléphone sans mot de passe.

   Important

   Dans la configuration précédente, assurez-vous de choisir l’option Sans mot de passe. Vous devez modifier le Mode d’authentification pour tous les groupes ajoutés à la PSI pour Sans mot de passe. Si vous choisissez Tous, CBA et PSI ne fonctionnent pas.

3. Sélectionnez Protection>Authentification multifacteur>Paramètres d’authentification multifacteur supplémentaires basés sur le cloud.

   

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

   

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

Prenons comme exemple un utilisateur qui dispose d’un certificat à un seul facteur et qui a configuré une connexion sans mot de passe.

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

   

2. Sélectionnez Se connecter avec un certificat.

   

   Si vous avez activé d’autres méthodes d’authentification comme la connexion par téléphone ou les clés de sécurité FIDO2, les utilisateurs peuvent obtenir un écran de connexion différent.

   

3. Sélectionnez le certificat d’utilisateur approprié dans le sélecteur de certificat client, puis sélectionnez OK.

   

4. Étant donné que le certificat est configuré pour être une force d’authentification à facteur unique, l’utilisateur a besoin d’un deuxième facteur pour répondre aux exigences MFA. L’utilisateur voit les deuxièmes facteurs disponibles, qui sont dans ce cas la connexion sans mot de passe. Sélectionner Approuver une demande sur mon application Microsoft Authenticator.

   

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

6. Entrez le numéro affiché sur l’écran du navigateur ou de l’application dans Microsoft Authenticator.

   

7. Sélectionnez Oui et l’utilisateur peut s’authentifier et se connecter.

Présentation de la stratégie de liaison d’authentification

La stratégie de liaison d’authentification permet de déterminer la force de l’authentification comme étant à un facteur ou à plusieurs facteurs. Un administrateur peut changer la valeur par défaut en passant d’un facteur à plusieurs facteurs ou définir des configurations de stratégie personnalisées par le biais des champs de sujet d’émetteur ou d’OID de stratégie ou d’OID d’émetteur et de stratégie dans le certificat.

Forces du certificat

Un administrateur peut déterminer si les certificats sont monofacteur ou multifacteur. Pour plus d’informations, consultez la documentation associée aux niveaux d’assurance d’authentification NIST pour les méthodes d’authentification Microsoft Entra, qui s’appuie sur la documentation NIST 800-63B SP 800-63B, Digital Identity Guidelines: Authentication and Lifecycle Mgmt (en anglais).

Authentification par certificat multifacteur

Lorsqu’un utilisateur a un certificat multifacteur, il peut effectuer l’authentification multifacteur uniquement avec des certificats. Toutefois, l’administrateur de la politique d’authentification doit s’assurer que les certificats sont protégés par un code PIN ou la biométrie pour être considérés comme multifactoriels.

Comment Microsoft Entra ID résout plusieurs règles de liaison de stratégie d’authentification

Étant donné que plusieurs règles de stratégie de liaison d’authentification personnalisées peuvent être créées avec différents champs de certificat tels que l’utilisation d’OID de stratégie + émetteur, ou simplement l’OID de stratégie ou simplement l’émetteur. voici les étapes utilisées pour déterminer le niveau de protection de l’authentification lorsque des règles personnalisées se chevauchent. Les voici :

1. Les règles d’OID de stratégie + émetteur prévalent sur les règles d’OID d’émetteur. Les règles d’OID de stratégie prévalent sur les règles d’émetteur de certificat.
2. Les règles d’OID de stratégie + émetteur sont évaluées en premier. Si vous disposez d’une règle personnalisée avec l’OID de stratégie + émetteur CA1 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 recevra le MFA.
3. Ensuite, les règles personnalisées utilisant des OID de stratégie sont évaluées. Si vous avez un certificat A avec l’OID de stratégie 1.2.3.4.5 et que les informations d’identification B dérivées basées sur ce certificat ont un OID de stratégie 1.2.3.4.5.6 et que la règle personnalisée est définie comme OID de stratégie avec la valeur 1.2.3.4.5 avec MFA, seul le certificat A répond à MFA. Les informations d’identification B ne répondent qu’à une authentification à un facteur. Si l’utilisateur s’est servi des informations d’identification dérivées pendant la connexion et qu’elles ont été configurées pour avoir MFA, il est invité à répondre à un second facteur pour réussir à s’authentifier.
4. En cas de conflit entre plusieurs OID de stratégie (par exemple, lorsqu’un certificat a deux OID de stratégie, l’un lié à l’authentification à un facteur et l’autre à MFA), traitez le certificat comme authentification à un facteur.
5. Ensuite, les règles personnalisées utilisant l’autorité de certification de l’émetteur sont évaluées.
6. Si un certificat correspond à la fois à l’OID de stratégie et aux règles de l’émetteur, l’OID de stratégie est toujours vérifié en premier, et si aucune règle de la stratégie n’est trouvée, les liaisons de l’émetteur sont vérifiées. L’OID de stratégie a une priorité de liaison d’authentification forte supérieure à celle de l’émetteur.
7. 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 à une authentification à un facteur.
8. Si un OID de stratégie est lié à MFA, tous les certificats utilisateur qui incluent cet OID de stratégie comme un des OID (un certificat utilisateur peut avoir plusieurs OID de stratégie) sont éligibles comme MFA.
9. Un éditeur de certificat ne peut avoir qu’une seule liaison d’authentification forte valide (c’est-à-dire qu’un certificat ne peut pas être lié à la fois à un facteur unique et à MFA).

Important

Il existe un problème connu où un administrateur de locataire Entra configure une règle de stratégie d’authentification CBA à l’aide de l’émetteur et de l’OID de stratégie, ce qui a un impact sur certains scénarios d’inscription d’appareil, notamment :

• Inscription à Windows Hello Entreprise
• Inscription de clé de sécurité Fido2
• Connexion Windows par téléphone sans mot de passe

L’inscription de l’appareil avec les scénarios de jointure d’appareil Workplace Join, Entra ID et Hybrid Entra ID n’est pas affectée. Les règles de stratégie d’authentification CBA utilisant l’OID de stratégie d’émetteur OU de stratégie ne sont pas affectées. Pour atténuer, les administrateurs doivent :

• Modifiez actuellement les règles de stratégie d’authentification basées sur les certificats à l’aide des options OID émetteur et stratégie, puis supprimez l’exigence d’émetteur ou d’OID et enregistrez. OR
• Supprimez la règle de stratégie d’authentification actuellement à l’aide de l’émetteur et de l’OID de stratégie et créez des règles seulement à l’aide de l’émetteur ou de l’OID de stratégie

Nous œuvrons à corriger ce problème.

Présentation de la stratégie de liaison de nom d’utilisateur

La stratégie de liaison de nom d’utilisateur permet de valider le certificat de l’utilisateur. Par défaut, le nom principal de l’autre nom du sujet (SAN, Subject alternate name) dans le certificat est mappé à l’attribut UserPrincipalName de l’objet utilisateur pour déterminer l’utilisateur.

Améliorer la sécurité avec les liaisons de certificat

Il existe sept méthodes prises en charge pour les liaisons de certificat. En règle générale, les types de mappage sont considérés comme ayant une affinité élevée s’ils sont basés sur des identificateurs que vous ne pouvez pas réutiliser, tels que les identificateurs de clé d’objet ou la clé publique SHA-1. Ces identifiants donnent une plus grande assurance qu’un seul certificat peut être utilisé pour authentifier l’utilisateur concerné.

Les types de mappage basés sur les noms d’utilisateur et les adresses e-mail sont considérés comme ayant une faible affinité. Microsoft Entra ID implémente trois mappages considérés comme à 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.

Champ de mappage de certificat	Exemples de valeurs dans certificateUserIds	Attributs d’objet utilisateur	Type
Nom principal	X509:<PN>bob@woodgrove.com	userPrincipalName onPremisesUserPrincipalName certificateUserIds	faible affinité
RFC822Name	X509:<RFC822>user@woodgrove.com	userPrincipalName onPremisesUserPrincipalName certificateUserIds	faible affinité
Émetteur et sujet (aperçu)	X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<S>DC=com,DC=contoso,OU=UserAccounts,CN=mfatest	certificateUserIds	faible affinité
Objet (préversion)	X509:<S>DC=com,DC=contoso,OU=UserAccounts,CN=mfatest	certificateUserIds	faible affinité
SKU	X509:<SKI>123456789abcdef	certificateUserIds	affinité élevée
SHA1PublicKey	X509:<SHA1-PUKEY>123456789abcdef	certificateUserIds	affinité élevée
IssuerAndSerialNumber (preview)	X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>b24134139f069b49997212a86ba0ef48 Pour obtenir la valeur correcte pour le numéro de série, exécutez cette commande et stockez la valeur affichée dans CertificateUserIds : Syntaxe : Certutil –dump –v [~certificate path~] >> [~dumpFile path~] Exemple : certutil -dump -v firstusercert.cer >> firstCertDump.txt	certificateUserIds	affinité élevée

Définir la liaison Affinity au niveau du locataire et la remplacer par des règles personnalisées (Preview)

Avec cette fonctionnalité, un administrateur de stratégie d’authentification peut configurer si un utilisateur peut être authentifié à l’aide d’une liaison de nom d’utilisateur à faible affinité ou à affinité élevée. Vous pouvez définir la Liaison d’affinité requise pour le locataire, qui s’applique à tous les utilisateurs. Vous pouvez également écraser la valeur par défaut à l’échelle du locataire en créant des règles personnalisées basées sur l’émetteur et l’OID de stratégie, ou l’OID de stratégie ou l’émetteur.

Comment Microsoft Entra ID résout plusieurs règles de liaison de stratégie de nom d’utilisateur

Utilisez la liaison de priorité la plus élevée (nombre le plus bas).

1. Recherchez l’objet utilisateur à l’aide du nom d’utilisateur ou du nom d’utilisateur principal.
2. Obtenez la liste de toutes les liaisons de nom d’utilisateur configurées par l’admin client dans la configuration de la méthode d’authentification CBA, classées selon l’attribut « priorité ». Aujourd’hui, le concept de priorité n’est pas exposé dans l’expérience utilisateur du portail. Le graphique vous renvoie l’attribut de priorité pour chaque liaison et ces attributs sont utilisés dans le processus d’évaluation.
3. Si la liaison à affinité élevée est activée pour le client ou si les valeurs du certificat correspondent à une règle personnalisée exigeant une liaison à affinité élevée, supprimez de la liste toutes les liaisons à affinité faible.
4. Évaluez 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 fait correspondre la valeur du champ du certificat à la valeur d’attribut de l’objet utilisateur.
   1. Si une correspondance est trouvée, l’authentification de l’utilisateur réussit.
   2. Si aucune correspondance n’est trouvée, passez à la liaison de priorité suivante.
6. Si le champ du certificat X.509 n’est pas sur le certificat présenté, passez à la liaison de priorité suivante.
7. Validez toutes les liaisons de nom d’utilisateur configurées jusqu’à ce que l’une d’elles 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écurisation de la configuration Microsoft Entra avec plusieurs liaisons de nom d’utilisateur

Chacun des attributs de l’objet utilisateur Microsoft Entra (userPrincipalName, onPremiseUserPrincipalName, certificateUserIds) disponibles pour lier des certificats aux comptes d’utilisateur Microsoft Entra a une contrainte d’unicité pour garantir qu’un certificat correspond uniquement à un seul compte d’utilisateur Microsoft Entra. Toutefois, Microsoft Entra CBA prend en charge plusieurs méthodes de liaison dans la stratégie de liaison de nom d’utilisateur qui permet à un administrateur de prendre en charge un certificat pour plusieurs configurations de comptes d’utilisateur Entra.

Important

Si vous configurez plusieurs liaisons, l’authentification basée sur des certificats Microsoft Entra est aussi sécurisée que votre liaison à faible affinité, car le CBA valide chacune des liaisons pour authentifier l’utilisateur. Pour empêcher un scénario où un seul certificat correspond à plusieurs comptes Microsoft Entra, un administrateur de stratégie d’authentification peut :

• Configurez une méthode de liaison unique dans la stratégie de liaison de nom d’utilisateur.
• Si un locataire a dispose de plusieurs méthodes de liaison configurées et ne veut pas autoriser le mappage d’un certificat pour plusieurs comptes, l’administrateur de stratégie d’authentification doit s’assurer que toutes les méthodes autorisées configurées dans la stratégie correspondent au même compte Microsoft Entra. Tous les comptes d’utilisateur doivent avoir des valeurs correspondant à toutes les liaisons.
• Si un client dispose de plusieurs méthodes de liaison configurées, l’administrateur de stratégie d’authentification doit s’assurer qu’il n’a pas plusieurs liaisons à faible affinité.

Par exemple, supposons que vous disposez de deux liaisons de nom d’utilisateur sur PrincipalName mappées avec UPN et SubjectKeyIdentifier (SKI) vers certificateUserIds. Si vous souhaitez qu’un certificat soit utilisé uniquement 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 et implémenter le mappage SKI dans l’attribut certificateUserId du même compte.

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

Il existe des scénarios où une organisation émet plusieurs certificats pour une identité unique. La plupart du temps, il peut s’agir d’identifiant dérivé pour un appareil mobile ou d’une carte à puce secondaire ou d’un appareil capable de contenir un identifiant d’identité x509, tel qu’un Yubikey.

Comptes cloud uniquement Pour les comptes cloud uniquement, vous pouvez mapper plusieurs certificats (jusqu’à 5) à utiliser en remplissant le champ certificateUserIds (informations d’autorisation dans le portail utilisateur) avec des valeurs uniques identifiant chaque certificat. Si l’organisation utilise des liaisons d’affinité élevée, par exemple Émetteur + SerialNumber, les valeurs dans CertificateUserIds peuvent ressembler à ce qui suit :

X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>b24134139f069b49997212a86ba0ef48
X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>c11154138u089b48767212a86cd0ef76

Dans cet exemple, la première valeur représente X509Certificate1 et la deuxième valeur représente X509Certificate2. L’utilisateur peut présenter un certificat à la connexion et tant que la liaison de nom d’utilisateur CBA est définie pour pointer vers le champ certificateUserIds pour rechercher le type de liaison particulier (par exemple, Issuer+SerialNumber dans cet exemple), l’utilisateur se connecte avec succès.

Comptes synchronisés hybrides Pour les comptes synchronisés, vous pouvez mapper plusieurs certificats à utiliser en remplissant le champ altSecurityIdentities dans AD, les valeurs identifiant chaque certificat. Si l’organisation utilise des liaisons d’affinité élevée (c’est-à-dire une authentification stricte) par exemple Émetteur + SerialNumber, cela peut ressembler à ce qui suit :

X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>b24134139f069b49997212a86ba0ef48
X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>c11154138u089b48767212a86cd0ef76

Dans cet exemple, la première valeur représente X509Certificate1 et la deuxième valeur représente X509Certificate2. Ces valeurs doivent ensuite être synchronisées avec le champ certificateUserIds dans Azure AD.

Prise en charge d’un certificat avec plusieurs comptes d’utilisateur Entra (1:M)

Il existe des scénarios où une organisation a besoin que l’utilisateur utilise le même certificat pour s’authentifier dans les identités multiples. Le plus souvent, il s’agit de comptes administrateurs. Il peut également s’agir de comptes de développeur ou de comptes de droits temporaires. Dans AD traditionnel, le champ altSecurityIdentities est utilisé pour remplir les valeurs de certificat et un indicateur est utilisé lors de la connexion pour diriger AD vers le compte souhaité afin de vérifier la connexion. Avec Microsoft Entra CBA, cela est différent et il n’y a pas d’indicateur. Au lieu de cela, la découverte du domaine d’origine identifie le compte souhaité pour vérifier les valeurs du certificat. L’autre différence clé est que Microsoft Entra CBA applique l’unicité dans le champ certificateUserIds. Cela signifie que deux comptes ne peuvent pas remplir les mêmes valeurs de certificat.

Important

Ce n’est pas une configuration très sûre d’utiliser le même identifiant pour s’authentifier dans différents comptes Entra ID et il est recommandé de ne pas autoriser un certificat pour plusieurs comptes d’utilisateurs Entra.

Comptes cloud uniquement Pour les comptes cloud uniquement, vous devez créer plusieurs liaisons de nom d’utilisateur et vous devez mapper des valeurs uniques à chaque compte d’utilisateur qui utilisera le certificat. Chaque compte est authentifié à l’aide d’une liaison de nom d’utilisateur différente. Cela s’applique dans la limite d’un seul annuaire/client (par exemple, l’admin client peut mapper le certificat à utiliser dans un autre annuaire/client, tant que les valeurs restent uniques par compte également).

Remplissez le champ certificateUserIds (informations d’autorisation dans le portail utilisateur) avec une valeur unique identifiant le certificat souhaité. Si l’organisation utilise des liaisons d’affinité élevée (c’est-à-dire une authentification stricte) par exemple Émetteur + SerialNumber et SKI, cela peut ressembler à ce qui suit :

Liaisons de nom d’utilisateur :

• Émetteur + numéro de série -> CertificateUserIds
• SKI -> CertificateUserIds

Valeurs des CertificateUserIds des comptes d’utilisateurs :
X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>b24134139f069b49997212a86ba0ef48
X509:<SKI>82b287a25c48af0918ea088d5293712324dfd523

Maintenant, lorsqu’un utilisateur 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 d’Émetteur+SerialNumber et un autre à l’aide de la liaison SKI.

Note

Le nombre de comptes qui peuvent être utilisés de cette façon est limité par le nombre de liaisons de nom d’utilisateur configurées sur le client. Si l’organisation utilise uniquement des liaisons d’affinité élevée, le nombre de comptes pris en charge est limité à 3. Si l’organisation utilise également des liaisons d’affinité faible, ce nombre augmente à 7 comptes (1 PrincipalName, 1 RFC822Name, 1 SubjectKeyIdentifier, 1 SHA1PublicKey, 1 Émetteur+Sujet, 1 Émetteur+SerialNumber, 1 Sujet).

Comptes synchronisés hybrides Pour les comptes synchronisés, l’approche sera différente. Bien que l’admin client puisse mapper des valeurs uniques à chaque compte d’utilisateur qui utilisera le certificat, la pratique courante de remplir toutes les valeurs à chaque compte dans Entra ID rend cela difficile. Au lieu de cela, Azure AD Connect doit filtrer les valeurs souhaitées par compte en valeurs uniques remplies dans le compte dans Entra ID. La règle d’unicité s’applique dans la limite d’un seul annuaire/client (par exemple, l’admin client peut également mapper le certificat à utiliser dans un autre annuaire/client, tant que les valeurs restent uniques par compte). En outre, l’organisation peut avoir plusieurs forêts AD qui contribuent aux utilisateurs dans un seul client Entra ID. Dans ce cas, Azure AD Connect applique le filtre à chacune de ces forêts AD avec le même objectif de remplir uniquement une valeur unique souhaitée au compte cloud.

Remplissez le champ altSecurityIdentities dans AD avec les valeurs identifiant le certificat souhaité et incluez la valeur de certificat souhaitée pour ce type de compte d’utilisateur (par exemple, detailee, administrateur, développeur, etc.). Sélectionnez un attribut de clé dans AD qui indique la synchronisation du type de compte d’utilisateur que l’utilisateur évalue (par exemple msDS-cloudExtensionAttribute1). Remplissez cet attribut avec la valeur de type utilisateur souhaitée, telle que le detailee, l’administrateur ou le développeur. S’il s’agit du compte principal de l’utilisateur, la valeur peut être laissée vide/nulle.

Les comptes peuvent ressembler à ce qui suit :

Forêt 1 - Compte1 (bob@woodgrove.com) :
X509:<SKI>82b287a25c48af0918ea088d5293712324dfd523
X509:<SHA1-PUKEY>123456789abcdef
X509:<PN>bob@woodgrove.com

Forêt 1 - Compte2 (bob-admin@woodgrove.com) :
X509:<SKI>82b287a25c48af0918ea088d5293712324dfd523
X509:<SHA1-PUKEY>123456789abcdef
X509:<PN>bob@woodgrove.com

Forêt 2 - ADAccount1 (bob-tdy@woodgrove.com) :
X509:<SKI>82b287a25c48af0918ea088d5293712324dfd523
X509:<SHA1-PUKEY>123456789abcdef
X509:<PN>bob@woodgrove.com

Ces valeurs doivent ensuite être synchronisées avec le champ certificateUserIds dans Entra ID.

Étapes de synchronisation avec certificateUserIds

1. Configurer Azure AD Connect pour ajouter le champ AlternativeSecurityIds au Métaverse
2. Pour chaque forêt AD, configurez une nouvelle règle de trafic entrant personnalisé avec une précédence élevée (nombre faible inférieur à 100). Ajoutez une transformation d’expression avec le champ altSecurityIdentities comme source. L’expression cible utilise l’attribut de clé que vous avez sélectionné et rempli, ainsi que le mappage aux types d’utilisateurs que vous avez définis.
3. 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 l’exemple ci-dessus, altSecurityIdentities et l’attribut de clé msDS-cloudExtensionAttribute1is sont d’abord vérifiés pour voir s’ils sont remplis. Si ce n’est pas le cas, altSecurityIdentities est vérifié pour voir s’il est rempli. S’il est vide, nous l’avons défini sur NUL. Sinon, le compte tombe dans le cas par défaut et dans cet exemple, nous filtrons uniquement sur le mappage Émetteur+SerialNumber. Si l’attribut de clé est rempli, la valeur est vérifiée pour voir si elle est égale à l’un de nos types d’utilisateurs définis. Dans cet exemple, si cette valeur est detailee, nous filtrons vers la valeur SHA1PublicKey depuis altSecurityIdentities. Si la valeur est développeur, nous filtrons vers la valeur SubjectKeyIssuer depuis altSecurityIdentities. Il peut y avoir plusieurs valeurs de certificat d’un type spécifique. Par exemple, plusieurs valeurs PrincipalName ou plusieurs valeurs SKI ou SHA1-PUKEY. Le filtre obtient toutes les valeurs et se synchronise avec Entra ID , pas seulement le premier qu’il trouve.

1. Deuxième exemple présentant comment envoyer une valeur vide si l’attribut de contrôle est vide est ci-dessous.

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, alors un AuthoritativeNull est transféré. Cela garantit que les règles antérieures ou suivantes qui remplissent alternativeSecurityId sont ignorées et que le résultat est vide dans Entra ID.

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

Vérifiez que CBA dans chaque client est configuré avec les 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 et après la validation de la valeur unique du certificat par rapport au champ certificateUserIds, cet utilisateur sera correctement connecté.

Présentation du processus de révocation de certificat

Le processus de révocation de certificat permet à l’administrateur de révoquer l’utilisation d’un certificat déjà émis pour les authentifications à venir. La révocation de certificat ne révoque pas les jetons déjà émis de l’utilisateur. Suivez les étapes pour révoquer manuellement les jetons dans Configurer la révocation.

Microsoft Entra ID télécharge et met en cache la liste de révocation de certificats (CRL) des clients à partir de leur autorité de certification pour vérifier si les certificats sont révoqués pendant l’authentification de l’utilisateur.

Un administrateur peut configurer le point de distribution de liste CRL lors du processus d’installation des émetteurs approuvés dans le locataire Microsoft Entra. Chaque émetteur approuvé doit avoir une liste de révocation de certificats qui peut être référencée en utilisant une URL accessible sur Internet.

Important

La taille maximale d’une liste de révocation de certificats que Microsoft Entra ID réussit à télécharger lors d’une connexion interactive et à mettre en cache est de 20 Mo dans Entra ID et de 45 Mo dans les clouds Azure US Government, et le temps nécessaire au téléchargement de cette liste ne doit pas dépasser 10 secondes. Si Microsoft Entra ID ne parvient pas à télécharger une liste de révocation de certificats, les authentifications basées sur les certificats émis par l’autorité de certification correspondante échouent. Il est recommandé de conserver les fichiers de liste de révocation de certificats dans des limites de taille, de conserver les durées de vie des certificats dans des limites raisonnables et de nettoyer les certificats ayant expiré. Pour plus d’informations, consultez La taille des listes CRL est-elle limitée ?.

Lorsqu’un utilisateur effectue une connexion interactive avec un certificat et que la liste de révocation de certificats dépasse la limite interactive pour un cloud, sa connexion initiale échoue avec l’erreur suivante :

« La liste de révocation de certificats téléchargée à partir de {uri} a dépassé la taille maximale autorisée ({size} octets) pour les listes de révocation de certificats dans Microsoft Entra ID. Réessayez dans quelques minutes. Si le problème persiste, contactez les administrateurs de votre locataire. »

Après l’erreur, Microsoft Entra ID tente de télécharger la liste de révocation de certificats soumis aux limites côté service (45 Mo dans Entra ID et 150 Mo dans les clouds Azure US Government).

Important

Si l’administrateur ignore la configuration de la liste CRL, Microsoft Entra ID ne fait aucune vérification de liste CRL pendant l’authentification basée sur les certificats de l’utilisateur. Cela peut être utile pour un premier dépannage, mais ne doit pas être envisagé pour une utilisation en production.

À partir de maintenant, nous ne prenons plus en charge le protocole OCSP (Online Certificate Status Protocol) pour des raisons de performance et de fiabilité. Au lieu de télécharger la liste CRL à chaque connexion par le navigateur client pour le protocole OCSP, Microsoft Entra ID la télécharge une fois lors de la première connexion et la met en cache, améliorant ainsi les performances et la fiabilité de la vérification de liste CRL. Nous indexons également le cache pour que la recherche soit beaucoup plus rapide à chaque fois. Les clients doivent publier les listes CRL pour la révocation des certificats.

Les étapes suivantes constituent un flux classique de la vérification de la liste de révocation de certificats :

1. Microsoft Entra ID tente de télécharger la liste CRL lors du premier événement de connexion d’un utilisateur avec un certificat de l’émetteur approuvé ou de l’autorité de certification correspondant(e).
2. Microsoft Entra ID met en cache et réutilise la liste de révocation de certificats pour toute utilisation ultérieure. Il honore la prochaine date de mise à jour et, le cas échéant, la prochaine date de publication de la liste CRL (utilisée par les autorités de certification Windows Server) dans le document de liste CRL.
3. L’authentification basée sur les certificats de l’utilisateur échoue dans les cas suivants :

   • Une liste de révocation de certificats a été configurée pour l’émetteur approuvé et Microsoft Entra ID ne peut pas la télécharger en raison de contraintes de disponibilité, de taille ou de latence.

   • Le certificat de l’utilisateur est listé comme révoqué dans la liste CRL.

     

   • Microsoft Entra ID tente de télécharger une nouvelle liste CRL à partir du point de distribution si le document de liste CRL mis en cache a expiré.

Note

Microsoft Entra ID vérifie la liste de révocation de certificats de l’autorité de certification émettrice et des autres autorités de certification de la chaîne d’approbation PKI jusqu’à l’autorité de certification racine. Nous avons une limite allant jusqu’à 10 autorités de certification du certificat client de nœud terminal pour la validation de la liste de révocation de certificats dans la chaîne PKI. La limitation vise à s’assurer qu’un mauvais acteur ne met pas le service hors service en téléchargeant une chaîne PKI avec un grand nombre d’autorités de certification et une taille de liste de révocation de certificats plus importante. Si la chaîne PKI du locataire a plus de 5 autorités de certification et en cas de compromission de l’autorité de certification, l’administrateur doit supprimer l’émetteur approuvé compromis de la configuration du locataire Microsoft Entra.

Important

En raison de la nature des cycles de mise en cache et de publication des listes CRL, il est fortement recommandé, en cas de révocation de certificat, de révoquer également toutes les sessions de l’utilisateur affecté dans Microsoft Entra ID.

Désormais, il n’existe aucun moyen de forcer ou de redéclencher manuellement le téléchargement de la liste de révocation de certificats.

Comment configurer la révocation

Pour révoquer un certificat client, Microsoft Entra ID extrait la liste de révocation de certificat (CRL) depuis les URL téléchargées dans le cadre des informations sur l’autorité de certification et la met en cache. L’horodateur de la dernière publication (propriétéEffective Date ) dans la liste de révocation de certificat permet de vérifier si la CRL est toujours valide. La CRL est référencée périodiquement pour révoquer l’accès à des certificats qui font partie de la liste.

Si une révocation plus instantanée est requise (par exemple, si un utilisateur perd un appareil), le jeton d’autorisation de l’utilisateur peut être invalidé. Pour invalider le jeton d’autorisation, définissez le champ StsRefreshTokenValidFrom pour cet utilisateur à l’aide de Windows PowerShell. Vous devez mettre à jour le champ StsRefreshTokenValidFrom pour chaque utilisateur pour lequel vous souhaitez révoquer l’accès.

Pour garantir que la révocation persiste, vous devez définir la propriété Effective Date de la CRL sur une date postérieure à la valeur définie par StsRefreshTokenValidFrom et vérifiez que le certificat en question est inclus dans la CRL.

Remarque

Les modules Azure AD et MSOnline PowerShell sont dépréciés depuis le 30 mars 2024. Pour en savoir plus, lisez les informations de dépréciation. Passé cette date, la prise en charge de ces modules est limitée à une assistance de migration vers le SDK et les correctifs de sécurité Microsoft Graph PowerShell. Les modules déconseillés continueront de fonctionner jusqu’au 30 mars 2025.

Nous vous recommandons de migrer vers Microsoft Graph PowerShell pour interagir avec Microsoft Entra ID (anciennement Azure AD). Pour explorer les questions courantes sur la migration, reportez-vous au FAQ sur la migration. Remarque : Les versions 1.0.x de MSOnline peuvent connaître une interruption après le 30 juin 2024.

Les étapes suivantes décrivent le processus de mise à jour et d’invalidation du jeton d’autorisation avec la définition du champ StsRefreshTokenValidFrom .

1. Connectez-vous à PowerShell :

   Connect-MgGraph
   

2. Récupérez la valeur StsRefreshTokensValidFrom actuelle pour un utilisateur :

           $user = Get-MsolUser -UserPrincipalName test@yourdomain.com`
           $user.StsRefreshTokensValidFrom
   

3. Configurez une nouvelle valeur StsRefreshTokensValidFrom pour l’utilisateur. Elle doit être égale à l’horodateur actuel :

           Set-MsolUser -UserPrincipalName test@yourdomain.com -StsRefreshTokensValidFrom ("03/05/2021")
   

La date que vous définissez doit être dans le futur. Si la date n’est pas dans le futur, la propriété StsRefreshTokensValidFrom n’est pas définie. Si la date est dans le futur, la propriété StsRefreshTokensValidFrom est définie sur l’heure actuelle (et non la date indiquée par la commande Set-MsolUser).

Fonctionnement de l’ABC avec une policy de force d’authentification d’accès conditionnel

Les clients peuvent créer une policy de force d’authentification d’accès conditionnel pour spécifier que l’ABC doit être utilisé pour accéder à une ressource.

Vous pouvez utiliser la force d’authentification intégrée MFA résistante au hameçonnage. Cette policy autorise uniquement les méthodes d’authentification résistantes au hameçonnage, telles que l’ABC, les clés de sécurité FIDO2 et Windows Hello Entreprise.

Vous pouvez également créer une force d’authentification personnalisée pour autoriser uniquement l’ABC à accéder aux ressources sensibles. Vous pouvez autoriser l’ABC en tant que facteur unique, multifacteur ou les deux. Pour plus d’informations, consultez Force d’authentification de l’accès conditionnel.

Force d’authentification ABC avec des options avancées

Dans la policy de méthodes d’authentification ABC, un administrateur peut déterminer la force du certificat à l’aide de la policy de liaison d’authentification sur la méthode ABC. À présent, vous pouvez configurer des options avancées lorsque vous créez une force d’authentification personnalisée pour exiger qu’un certificat spécifique soit utilisé, en fonction des OID de l’émetteur et de la policy, lorsque les utilisateurs effectuent un ABC pour accéder à certaines ressources sensibles. Cette 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.

Présentation des journaux de connexion

Les journaux de connexion fournissent des informations sur les connexions et sur la manière dont vos ressources sont utilisées par vos utilisateurs. Pour plus d’informations sur les journaux de connexion, consultez Journaux de connexion dans Microsoft Entra ID.

Suivons deux scénarios, l’un où le certificat répond à une authentification à un facteur et l’autre où le certificat répond à une authentification multifacteur.

Pour les scénarios de test, choisissez un utilisateur avec une stratégie d’accès conditionnel qui exige une authentification multifacteur. Configurez la stratégie de liaison utilisateur en mappant le nom principal SAN à UserPrincipalName.

Le certificat utilisateur doit être configuré comme cette capture d’écran :

Dépannage des problèmes de connexion avec les variables dynamiques dans les journaux d’activité de connexion

Bien que les journaux d’activité de connexion fournissent toutes les informations permettant de déboguer les problèmes de connexion d’un utilisateur, il existe des moments où des valeurs spécifiques sont requises et, étant donné que les journaux d’activité de connexion ne prennent pas en charge les variables dynamiques, les journaux d’activité de connexion ont des informations manquantes. Par exemple : la raison de la défaillance dans le journal d’activité de connexion affiche quelque chose comme « La liste de révocation de certificats a échoué à valider la signature. L’identificateur de la clé du sujet attendu {expectedSKI} ne correspond pas à la clé d’autorité de la liste de révocation de certificat {crlAK}. Demandez à votre administrateur client de vérifier la configuration de la liste de révocation de certificats. » où {expectedSKI} et {crlAKI} ne sont pas renseignés avec des valeurs correctes.

Lorsque la connexion des utilisateurs avec l’ABC échoue, copiez les détails du journal d’activité à partir du lien « Plus de détails » sur la page d’erreur. Pour plus d’informations, consultez la page d’erreur Comprendre l’ABC

Tester l’authentification à un facteur

Pour le premier scénario de test, configurez la stratégie d’authentification dans laquelle la règle du sujet d’émetteur répond à l’authentification à un facteur.

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 lorsque la règle du sujet de l’émetteur satisfait à l’authentification monofacteur.

2. Recherchez et sélectionnez Journaux de connexion.

   Observons plus en détail 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é l’activation de l’authentification basée sur les certificats dans le locataire et la demande d’un certificat pour l’authentification.

   

   Les détails de l’activité indiquent qu’il ne s’agit que d’une partie du flux de connexion attendu où l’utilisateur sélectionne un certificat.

   

   Les Détails supplémentaires montrent les informations du certificat.

   

   Ces entrées supplémentaires montrent que l’authentification est terminée et qu’un jeton d’actualisation principal est renvoyé au navigateur et que l’utilisateur a accès à la ressource.

   

Tester l’authentification multifacteur

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

1. Connectez-vous au Centre d’administration Microsoft Entra en utilisant l’authentification basée sur les certificats. Étant donné que la stratégie a été définie pour répondre à l’authentification multifacteur, la connexion utilisateur réussit sans second facteur.

2. Recherchez et sélectionnez Connexions.

   Vous verrez plusieurs entrées dans les journaux de connexion, y compris une entrée avec l’état Interrompu.

   

   Les détails de l’activité indiquent qu’il ne s’agit que d’une partie du flux de connexion attendu où l’utilisateur sélectionne un certificat.

   

   L’entrée avec l’état Interrompu contient plus d’informations de diagnostic sous l’onglet Détails supplémentaires.

   

   Le tableau suivant contient une description de chaque champ.

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

Présentation de la page d’erreur d’authentification basée sur le certificat

L’authentification basée sur des certificats peut échouer pour des raisons telles que la non-validité d’un certificat, la sélection d’un certificat erroné ou ayant expiré par l’utilisateur ou un problème de liste de révocation de certificats (CRL). Lorsque la validation du certificat échoue, l’utilisateur voit cette erreur :

Si l’authentification basée sur des certificats échoue sur un navigateur alors que la défaillance est due à l’annulation du sélecteur de certificats, vous devez fermer la session du navigateur et ouvrir une nouvelle session pour réessayer. Une nouvelle session est requise, car les navigateurs mettent en cache le certificat. Lorsque l’authentification CBA est retentée, le navigateur envoie le certificat mis en cache pendant le défi TLS, entraînant un échec de connexion et l’erreur de validation.

Sélectionnez Plus d’informations pour obtenir des informations de journalisation pouvant être envoyées à un administrateur, qui à son tour peut obtenir plus d’informations à partir des journaux de connexion.

Sélectionnez Autres méthodes pour se connecter pour tenter d’autres méthodes de connexion disponibles pour l’utilisateur.

Note

Si vous réessayez l’authentification basée sur des certificats dans un navigateur, celle-ci échoue en raison du problème de mise en cache. Les utilisateurs doivent ouvrir une nouvelle session de navigateur et se reconnecter.

Authentification basée sur des certificats dans les méthodes MostRecentlyUsed (MRU)

Une fois qu’un utilisateur s’authentifie correctement à l’aide de l’authentification basée sur des certificats, la méthode d’authentification MostRecentlyUsed (MRU) de l’utilisateur est définie sur l’authentification basée sur les certificats. La prochaine fois que l’utilisateur entre son UPN et sélectionne Suivant, il est dirigé directement vers 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, l’utilisateur doit annuler le sélecteur de certificats, sélectionner Autres méthodes pour se connecter, puis sélectionner une autre méthode disponible pour l’utilisateur et s’authentifier correctement.

Prise en charge des identités externes

Une identité externe ne peut pas effectuer l’authentification multifacteur au locataire de ressource avec l’authentification basée sur des certificats Microsoft Entra. Au lieu de cela, l’utilisateur effectue une authentification multifacteur à l’aide de l’authentification basée sur les certificats dans le locataire d’origine et configurez les paramètres interlocataires pour que le locataire de ressource approuve l’authentification multifacteur à partir du locataire d’origine.

Pour plus d’informations sur l’activation d’Approuver l’authentification multifacteur de locataires Microsoft Entra, consultez Configurer l’accès interlocataire B2B Collaboration.

Étapes suivantes

• Vue d’ensemble de l’authentification basée sur certificat Microsoft Entra
• Guide pratique pour configurer l’authentification basée sur les certificats de Microsoft Entra
• Authentification basée sur les certificats de Microsoft Entra sur les appareils iOS
• Authentification basée sur les certificats de Microsoft Entra sur les appareils Android
• Connexion par carte à puce Windows à l’aide de la CBA de Microsoft Entra
• ID des utilisateurs du certificat
• Comment migrer des utilisateurs fédérés
• FAQ
• Résoudre les problèmes de l’authentification basée sur les certificats Microsoft Entra