Concepts techniques de l’authentification basée sur des certificats Microsoft Entra

Cet article décrit les concepts techniques permettant d’expliquer le fonctionnement de l’authentification basée sur des certificats (CBA) Microsoft Entra. Obtenez l’arrière-plan technique pour mieux savoir comment configurer et gérer Microsoft Entra CBA dans votre locataire.

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

L’illustration suivante illustre ce qui se passe lorsqu’un utilisateur tente de se connecter à une application dans un locataire sur lequel Microsoft Entra CBA est configuré.

Les étapes suivantes résument le processus 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 à l’adresse https://login.microsoftonline.com/.

3. Ils entrent leur nom d’utilisateur sur la page de connexion Microsoft Entra, puis sélectionnez Suivant. Microsoft Entra ID termine la découverte du domaine d’accueil à l’aide du nom du locataire. Il utilise le nom d’utilisateur pour rechercher l’utilisateur dans le locataire.

   

4. Microsoft Entra ID vérifie si l’administrateur de base de données est configuré pour le locataire. Si l’administrateur de base de données 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 l’administrateur de base de données est configuré pour le locataire.

   Pour plus d’informations, consultez Comment activer Microsoft Entra CBA ?.

   Remarque

   Si l’administrateur de base de données est configuré pour le locataire, tous les utilisateurs voient le lien Utiliser un certificat ou une carte à puce dans la page de connexion par mot de passe. Toutefois, seuls les utilisateurs qui sont dans l’étendue de l’administrateur de base de données peuvent s’authentifier correctement pour une application qui utilise l’ID Microsoft Entra comme 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. Une fois que l’utilisateur a sélectionné l’autorité de certification, le client redirige vers le point de terminaison d’authentification de certificat. Pour l’ID Microsoft Entra public, le point de terminaison d’authentification par certificat est https://certauth.login.microsoftonline.com. Pour Azure Government, le point de terminaison d’authentification par certificat est https://certauth.login.microsoftonline.us.

   Le point de terminaison effectue l’authentification mutuelle TLS (Transport Layer Security) et demande le certificat client dans le cadre de l’établissement d’une liaison 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 de certificat pour vous assurer 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é, l’administrateur de base de données échoue si vous activez les indicateurs 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 d’accès conditionnel Microsoft Entra qui nécessite une authentification multifacteur (MFA) et que la règle de liaison d’authentification par certificat satisfait à l’authentification multifacteur, Microsoft Entra ID se 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 effectue le processus de connexion en renvoyant un jeton d’actualisation principal pour indiquer la réussite de la connexion.

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

Indicateurs de l’émetteur (préversion)

Les indicateurs d’émetteur renvoient un indicateur d’autorité de certification approuvé dans le cadre de l’établissement d’une liaison TLS. La liste d’autorité de certification approuvée est définie sur l’objet 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.

Activer les indicateurs de l’é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.

Remarque

Si votre organisation dispose de pare-feu ou de proxys qui utilisent l’inspection TLS, reconnaissez que vous avez désactivé l’inspection TLS du point de terminaison d’autorité de certification capable de correspondre à n’importe quel nom sous [*.]certauth.login.microsoftonline.com, personnalisé en fonction du proxy spécifique en cours d’utilisation.

Remarque

Une fois que vous avez activé les indicateurs d’émetteur, l’URL de l’autorité de certification a le format <tenantId>.certauth.login.microsoftonline.com.

Propagation des mises à jour du magasin de confiance d’autorité de certification

Après avoir activé les indicateurs d’émetteur et ajouté, mis à jour ou supprimer des autorités de certification du magasin d’approbations, un délai pouvant atteindre 10 minutes peut se produire pendant que les indicateurs d’émetteur se propagent au 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 d’approbation d’autorité de certification sont propagées :

MFA avec CBA à facteur unique

Microsoft Entra CBA se qualifie à la fois pour l’authentification de premier facteur et l’authentification second facteur.

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 (second facteur) (préversion)

Remarque

Actuellement, l’utilisation de cBA comme deuxième facteur sur iOS présente des problèmes connus et est bloquée sur iOS. Nous travaillons à résoudre les problèmes.

Les utilisateurs doivent avoir un moyen d’obtenir l’authentification multifacteur et d’inscrire la connexion sans mot de passe ou FIDO2 avant la connexion à l’aide de Microsoft Entra CBA.

Important

Un utilisateur est considéré comme compatible MFA si son nom d’utilisateur apparaît dans les paramètres de méthode CBA. Dans ce scénario, l’utilisateur ne peut pas utiliser son identité dans le cadre de son authentification pour inscrire d’autres méthodes disponibles. Assurez-vous que les utilisateurs sans certificat valide ne sont pas inclus dans les paramètres de méthode CBA. Pour plus d’informations sur le fonctionnement de l’authentification, consultez Authentification multifacteur Microsoft Entra.

Options permettant d’obtenir la fonctionnalité MFA avec l’authentification multifacteur activée

Microsoft Entra CBA peut être à facteur unique ou multifacteur en fonction de la configuration du locataire. L’activation de l’authentification multifacteur rend un utilisateur potentiellement capable de terminer l’authentification multifacteur. 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’autorisez pas l’inscription d’autres méthodes sans d’abord satisfaire l’authentification multifacteur. Si l’utilisateur n’a pas d’autre méthode MFA inscrite et est dans l’étendue de l’administrateur de base de données, l’utilisateur ne peut pas utiliser la preuve d’identité pour inscrire d’autres méthodes d’authentification et obtenir l’authentification multifacteur.

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 la connexion par téléphone sans mot de passe avec L’administrateur de base de données

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

1. Connectez-vous au Centre d’administration Microsoft Entra au moins en tant qu’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 remplacer la valeur du mode d’authentificationpar 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 supplémentaires 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électionner Approuver une demande sur mon 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 force de l’authentification en tant que 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 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 à 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égie 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 OID d’émetteur et de stratégie sont prioritaires sur les règles d’OID de stratégie. Les règles d’OID de stratégie prévalent sur les règles d’émetteur de certificat.
2. Les règles OID d’émetteur et de stratégie sont évaluées en premier. Si vous avez une règle personnalisée avec l’OID 1.2.3.4.5 de l’émetteur CA1 et la stratégie avec MFA, seul le certificat A qui satisfait à la fois la valeur de l’émetteur et l’OID de stratégie est donné MFA.
3. Les règles personnalisées qui utilisent des OID de stratégie sont évaluées. Si vous disposez d’un certificat A avec l’OID de 1.2.3.4.5 stratégie et d’informations d’identification dérivées B basées sur ce certificat disposant d’un OID de 1.2.3.4.5.6stratégie, et que la règle personnalisée est définie comme un OID de stratégie qui a la valeur 1.2.3.4.5 avec MFA, seul le certificat A satisfait à l’authentification multifacteur. Les informations d’identification B répondent uniquement à l’authentification à facteur unique. 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 d’émetteur sont évaluées. Si un certificat a des règles d’OID et d’émetteur de stratégie correspondantes, l’OID de stratégie est toujours vérifié en premier. Si aucune règle de 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 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 lié à L’AUTHENTIFICATION multifacteur, tous les certificats utilisateur qui incluent cet OID de stratégie comme l’un des OID de stratégie sont éligibles en tant qu’AUTHENTIFICATION multifacteur. (Un certificat utilisateur peut avoir plusieurs OID de stratégie.)
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).

Important

Actuellement, dans un problème connu qui est résolu, si un administrateur de stratégie d’authentification crée une règle de stratégie CBA à l’aide de l’émetteur et de l’OID de stratégie, certains scénarios d’inscription d’appareil sont affectés.

Les scénarios concernés sont les suivants :

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

L’inscription d’appareils avec Workplace Join, Microsoft Entra ID et les scénarios de jointure hybride Microsoft Entra ne sont pas affectés. Les règles de stratégie CBA qui utilisent l’émetteur ou l’OID de stratégie ne sont pas affectées.

Pour atténuer le problème, un administrateur de stratégie d’authentification doit effectuer l’une des options suivantes :

• Modifiez la règle de stratégie CBA qui utilise actuellement l’émetteur et l’OID de stratégie pour supprimer l’émetteur ou l’ID de stratégie requis.
• Supprimez la règle de stratégie d’authentification qui utilise actuellement l’émetteur et l’OID de stratégie, puis créez une règle qui utilise uniquement l’émetteur ou l’OID de stratégie.

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’objet (SAN) dans le certificat est mappé à 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 pour utiliser 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 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	Catégorie
PrincipalName	X509:<PN>bob@woodgrove.com	userPrincipalName onPremisesUserPrincipalName certificateUserIds	Faible affinité
RFC822Name	X509:<RFC822>user@woodgrove.com	userPrincipalName onPremisesUserPrincipalName certificateUserIds	Faible affinité
IssuerAndSubject	X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<S>DC=com,DC=contoso,OU=UserAccounts,CN=mfatest	certificateUserIds	Faible affinité
Subject	X509:<S>DC=com,DC=contoso,OU=UserAccounts,CN=mfatest	certificateUserIds	Faible affinité
SKI	X509:<SKI>aB1cD2eF3gH4iJ5kL6-mN7oP8qR=	certificateUserIds	Affinité élevée
SHA1PublicKey	X509:<SHA1-PUKEY>aB1cD2eF3gH4iJ5kL6-mN7oP8qR La SHA1PublicKey valeur (hachage SHA1 de l’ensemble du contenu du certificat, y compris la clé publique) se trouve dans la propriété Thumbprint du certificat.	certificateUserIds	Affinité élevée
IssuerAndSerialNumber	X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>cD2eF3gH4iJ5kL6mN7-oP8qR9sT Pour obtenir la valeur correcte du numéro de série, exécutez cette commande et stockez la valeur indiquée dans certificateUserIds: Syntaxe : certutil –dump –v [~certificate path~] >> [~dumpFile path~] Exemple : certutil -dump -v firstusercert.cer >> firstCertDump.txt	certificateUserIds	Affinité élevée

Important

Vous pouvez utiliser le CertificateBasedAuthentication module PowerShell pour rechercher la valeur correcte certificateUserIds d’un utilisateur dans un certificat.

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 (nombre le plus bas) :

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 fait correspondre la valeur du champ du 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 de certificat X.509 n’est pas sur 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 nom d’utilisateur

Chacun des attributs d’objet utilisateur Microsoft Entra disponibles pour lier des certificats à des comptes d’utilisateur Microsoft Entra (userPrincipalNameet onPremiseUserPrincipalNamecertificateUserIds) a une contrainte unique 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. Un administrateur de stratégie d’authentification peut prendre en charge un certificat utilisé dans plusieurs configurations de comptes d’utilisateur Microsoft Entra.

Important

Si vous configurez plusieurs liaisons, l’authentification Microsoft Entra CBA est aussi sécurisée que votre liaison d’affinité la plus faible, car l’administrateur de base de données valide chaque liaison 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 plusieurs méthodes de liaison configurées et ne souhaite pas autoriser un certificat à mapper à plusieurs comptes, un administrateur de stratégie d’authentification doit s’assurer que toutes les méthodes autorisées configurées dans le mappage de stratégie au même compte Microsoft Entra. Tous les comptes d’utilisateur doivent avoir des valeurs qui correspondent à toutes les liaisons.
• Si un locataire a plusieurs méthodes de liaison configurées, un administrateur de stratégie d’authentification doit s’assurer qu’il n’a pas plusieurs liaisons à faible affinité.

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 mappage 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 de l’administrateur de base de données est définie sur le certificateUserIds champ pour rechercher le type de liaison spécifique (dans cet exemple, ), IssuerAndSerialNumberl’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 altSecurityIdentities champ 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 certificateUserIds champ dans l’ID Microsoft Entra.

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

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 ou d’un compte de droit temporaire ou d’un développeur.

Dans Active Directory local, le altSecurityIdentities champ 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. Au lieu de cela, la découverte du domaine d’accueil identifie le compte prévu et vérifie les valeurs du certificat. Microsoft Entra CBA applique également l’unicité dans le certificateUserIds champ. Deux comptes ne peuvent pas remplir les mêmes valeurs de certificat.

Important

L’utilisation des mêmes informations d’identification pour s’authentifier dans différents comptes Microsoft Entra n’est pas une configuration sécurisée. Nous vous recommandons de ne pas autoriser l’utilisation d’un seul certificat pour plusieurs comptes d’utilisateur Microsoft Entra.

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) et IssuerAndSerialNumberSKIque les valeurs peuvent 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 IssuerAndSerialNumber et l’autre à l’aide de SKI la liaison.

Remarque

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 à affinité élevée, le nombre maximal de comptes pris en charge est de trois. Si l’organisation utilise également des liaisons à faible affinité, le nombre augmente à sept comptes : un , un PrincipalNameRFC822Name, un SKI, un SHA1PublicKey, un IssuerAndSubject, un , un , un IssuerAndSerialNumberet un Subject.

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 de 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 l’ID Microsoft Entra. 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 avoir plusieurs forêts Active Directory qui contribuent aux utilisateurs à 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 altSecurityIdentities champ 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, par detailedexemple , adminou 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 : Compte1 (bob@woodgrove.com) :
X509:<SKI>aB1cD2eF3gH4iJ5kL6mN7oP8qR
X509:<SHA1-PUKEY>cD2eF3gH4iJ5kL6mN7oP8qR9sT
X509:<PN>bob@woodgrove.com

Forêt 1 : Compte2 (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 certificateUserIds champ dans Microsoft Entra ID.

Pour effectuer la synchronisation avec certificateUserIds:

1. Configurez Microsoft Entra Connect pour ajouter le alternativeSecurityIds champ au métaverse.
2. Pour chaque forêt Active Directory locale, 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 msDS-cloudExtensionAttribute1 clé est d’abord vérifié pour voir s’ils sont renseignés. S’ils ne sont pas remplis, altSecurityIdentities est vérifié pour voir s’il est rempli. S’il est vide, définissez-le sur NULL. Sinon, le compte est un scénario par défaut.

Dans cet exemple, filtrez uniquement sur le IssuerAndSerialNumber mappage. 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 SHA1PublicKey valeur de altSecurityIdentities. Si la valeur est developer, filtrez la SubjectKeyIssuer valeur de altSecurityIdentities.

Vous pouvez rencontrer plusieurs valeurs de certificat d’un type spécifique. Par exemple, vous pouvez voir plusieurs PrincipalName valeurs ou plusieurs SKI valeurs.SHA1-PUKEY Le filtre obtient toutes les valeurs et les synchronise dans l’ID Microsoft Entra, 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 laquelle elle ne correspond à aucune des valeurs de recherche dans l’attribut de contrôle, une AuthoritativeNull valeur 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 l’ID Microsoft Entra.

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 l’ID Microsoft Entra.

Vérifiez que l’administrateur de base de données dans chaque locataire est configuré avec les liaisons de nom d’utilisateur pointant vers le certificateUserIds champ 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 (CA) (préversion)

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’autorité de certification via les journaux de connexion et les outils de surveillance

Un administrateur peut utiliser l’étendue de l’autorité de certification pour définir des règles qui associent une autorité de certification (identifiée par son SKI) à un groupe Microsoft Entra spécifique. 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 poursuit la chaîne d’autorité 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 de l’autorité de certification

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

2. Accédez à l’authentification par certificatdes méthodes>d’authentification> Entra.

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 infrastructure à clé publique.

   Les autorités de certification classiques affichent toutes les autorités de certification du magasin d’autorité de certification 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 d’étendue.

   

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 d’autorité de certification, sélectionnez « ... » sur la ligne de 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 affecté par autorité de certification.
• Un maximum de 30 règles d’étendue est pris en charge.
• L’étendue est appliquée au niveau de l’autorité de certification intermédiaire.
• Une configuration incorrecte peut entraîner des verrouillages utilisateur si aucune règle d’étendue valide n’existe.

Entrées du journal de connexion

• Le journal de connexion affiche la réussite. Sous l’onglet Détails supplémentaires , le ski de l’autorité de certification à partir de la règle de stratégie d’étendue s’affiche.

  

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

  

  Les utilisateurs finaux voient le message d’erreur suivant :

  

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

Vous pouvez utiliser la force d’authentification MFA intégrée de Microsoft Entra Hameçonnage pour créer une stratégie d’authentification par accès conditionnel qui spécifie d’utiliser l’administrateur de base de données pour accéder à une ressource. La stratégie autorise uniquement les méthodes d’authentification qui sont résistantes au hameçonnage, telles que l’authentification CBA, 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’authentification multifacteur en tant qu’authentification à facteur unique, MFA ou les deux. Pour plus d’informations, consultez Force d’authentification de l’accès conditionnel.

Force de l’adaptateur de base de données avec des 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 deuxième scénario, le certificat satisfait à l’authentification multifacteur.

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 de l’objet de remplacement et le nom principal à l’objet userPrincipalName 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 et<expectedSKI><crlAKI> ne sont pas remplies avec des valeurs correctes.

Lorsque la connexion de l’utilisateur avec l’administrateur de base de données échoue, vous pouvez copier les détails du journal à partir du lien Plus de détails sur la page d’erreur. Pour plus d’informations, consultez la page Présentation de la page d’erreur de l’administrateur de base de données.

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’administrateur de base de données est configuré 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 satisfait à l’authentification policyOID multifacteur.

1. Connectez-vous au Centre d’administration Microsoft Entra à l’aide de l’administrateur 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 de nom de 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 de l’administrateur de base de données

L’administrateur de base de données 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’administrateur de base de données é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 d’administrateur de base de données. Une nouvelle session est requise, car les navigateurs cachent des certificats. Lorsque l’administrateur de base de données est retenté, le navigateur envoie un certificat mis en cache pendant la demande TLS, ce qui provoque ensuite l’échec de connexion et l’erreur de validation.

1. Pour obtenir des informations de journalisation à envoyer à un administrateur de stratégie d’authentification pour plus d’informations dans les 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 réinitialise la sélection du certificat sans redémarrer le navigateur.

L’utilisateur effectue les étapes suivantes :

1. En cas d’échec de l’administrateur de base de données, la page d’erreur s’affiche.

   

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

Une fois qu’un utilisateur s’authentifie correctement à l’aide de l’authentification CBA, la méthode d’authentification de l’utilisateur MostRecentlyUsed 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 autre méthode d’authentification, l’unité d’utilisation est réinitialisée pour l’utilisateur à la méthode actuellement connectée.

Prise en charge des identités externes

Un utilisateur invité B2B d’identité externe peut utiliser l’administrateur de base de données sur le locataire domestique. Si les paramètres interlocataires du locataire de ressource sont configurés pour approuver l’authentification multifacteur à partir du locataire domestique, l’administrateur de base de données de l’utilisateur sur le locataire de base est respecté. Pour plus d’informations, consultez Configurer l’accès interlocataire B2B Collaboration. Actuellement, l’administrateur de base de données sur un locataire de ressource n’est pas pris en charge.

Contenu connexe

• Vue d’ensemble de l’authentification basée sur certificat Microsoft Entra
• Configurer Microsoft Entra CBA
• Liste de révocation de certificats Microsoft Entra CBA
• 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 à la carte à puce Windows à l’aide de Microsoft Entra CBA
• ID des utilisateurs du certificat
• Migrer des utilisateurs fédérés
• FORUM AUX QUESTIONS
• Résoudre les problèmes de l’authentification basée sur les certificats Microsoft Entra