Configurer l’authentification basée sur des certificats Microsoft Entra

Votre organisation peut implémenter une authentification moderne, sans mot de passe et résistante au hameçonnage via des certificats X.509 utilisateur en utilisant l’authentification basée sur des certificats (CBA) de Microsoft Entra.

Dans cet article, découvrez comment configurer votre locataire Microsoft Entra pour autoriser ou exiger que les utilisateurs du locataire s’authentifient à l’aide de certificats X.509. Un utilisateur crée un certificat X.509 à l’aide d’une infrastructure à clé publique d’entreprise (PKI) pour la connexion à l’application et au navigateur.

Lorsque Microsoft Entra CBA est configuré, lors de la connexion, un utilisateur voit une option pour s’authentifier à l’aide d’un certificat au lieu d’entrer un mot de passe. Si plusieurs certificats correspondants se trouvent sur l’appareil, l’utilisateur sélectionne le certificat approprié et le certificat est validé par rapport au compte d’utilisateur. Si la validation réussit, l’utilisateur se connecte.

Suivez les étapes décrites dans cet article pour configurer et utiliser Microsoft Entra CBA pour les locataires des plans Office 365 Entreprise et gouvernement américain. Vous devez déjà disposer d’une infrastructure à clé publique configurée.

Prerequisites

Vérifiez que les prérequis suivants sont en place :

• Au moins une autorité de certification et toutes les autorités de certification intermédiaires sont configurées dans Microsoft Entra ID.
• L’utilisateur a accès à un certificat d’utilisateur émis à partir d’une infrastructure à clé publique approuvée configurée sur le locataire destiné à l’authentification du client dans Microsoft Entra ID.
• Chaque autorité de certification dispose d’une liste de révocation de certificats (CRL) qui peut être référencée à partir d’URL accessibles sur Internet. Si l'autorité de certification approuvée n'a pas de liste de révocation de certificats configurée, Microsoft Entra ID n'effectue aucune vérification de liste de révocation de certificats, la révocation des certificats utilisateur ne fonctionne pas et l'authentification n'est pas bloquée.

Considérations

• Assurez-vous que l’infrastructure à clé publique est sécurisée et ne peut pas être facilement compromise. Si une violation se produit, l’attaquant peut créer et signer des certificats clients et compromettre n’importe quel utilisateur du locataire, y compris les utilisateurs qui sont synchronisés à partir d’un emplacement local. Une stratégie de protection forte et d’autres contrôles physiques et logiques peut fournir une défense approfondie pour empêcher les attaquants externes ou les menaces internes de compromettre l’intégrité de l’infrastructure à clé publique. Pour plus d’informations, consultez Sécurisation de l’infrastructure à clé publique.

• Pour connaître les meilleures pratiques relatives au chiffrement Microsoft, notamment le choix de l’algorithme, de la longueur des clés et de la protection des données, consultez les recommandations Microsoft. Veillez à utiliser l’un des algorithmes recommandés, une longueur de clé recommandée et des courbes approuvées par NIST.

• Dans le cadre des améliorations de sécurité en cours, Azure et les points de terminaison Microsoft 365 ont ajouté la prise en charge de TLS 1.3. Le processus devrait prendre quelques mois pour couvrir les milliers de points de terminaison de service entre Azure et Microsoft 365. Les points de terminaison de Microsoft Entra que Microsoft Entra CBA utilise sont inclus dans la mise à jour : *.certauth.login.microsoftonline.com et *.certauth.login.microsoftonline.us.

  TLS 1.3 est la version la plus récente du protocole de sécurité le plus couramment déployé sur Internet. TLS 1.3 chiffre les données pour fournir un canal de communication sécurisé entre deux points de terminaison. Ils éliminent les algorithmes de chiffrement obsolètes, améliorent la sécurité par rapport aux anciennes versions, et chiffrent la plus grande partie possible de la négociation. Nous vous recommandons vivement de commencer à tester TLS 1.3 dans vos applications et services.

• Lorsque vous évaluez une infrastructure à clé publique, il est important de passer en revue les stratégies d’émission de certificat et l’application. Comme décrit précédemment, l’ajout d’autorités de certification à une configuration de Microsoft Entra permet aux certificats émis par ces autorités de certification d’authentifier n’importe quel utilisateur dans Microsoft Entra ID.

  Il est important de prendre en compte comment et quand les autorités de certification sont autorisées à émettre des certificats et comment elles implémentent des identificateurs réutilisables. Les administrateurs doivent uniquement s’assurer qu’un certificat spécifique peut être utilisé pour authentifier un utilisateur, mais ils doivent utiliser exclusivement des liaisons d’affinité élevée pour obtenir un niveau d’assurance plus élevé que seul un certificat spécifique peut authentifier l’utilisateur. Pour plus d’informations, consultez liaisons d’affinité élevée.

Configurer et tester Microsoft Entra CBA

Vous devez effectuer certaines étapes de configuration avant d’activer Microsoft Entra CBA.

Un administrateur doit configurer les autorités de certification approuvées qui émettent les certificats utilisateur. Comme indiqué dans le diagramme suivant, Azure utilise le contrôle d’accès en fonction du rôle (RBAC) pour s’assurer que seuls les administrateurs à privilèges minimum sont tenus d’apporter des modifications.

Si vous le souhaitez, vous pouvez configurer des liaisons d’authentification pour mapper des certificats à l’authentification à facteur unique ou à l’authentification multifacteur (MFA). Configurez les liaisons de nom d’utilisateur pour mapper le champ de certificat à un attribut de l’objet utilisateur. Un administrateur de stratégie d’authentification peut configurer les paramètres liés à l’utilisateur.

Lorsque toutes les configurations sont terminées, activez Microsoft Entra CBA sur le locataire.

Étape 1 : Configurer les autorités de certification avec un magasin d’approbations basé sur une infrastructure à clé publique

Microsoft Entra dispose d’un nouveau magasin d’autorités de certification basé sur une PKI. Le magasin de confiance conserve les autorités de certification dans un objet conteneur pour chaque PKI. Les administrateurs peuvent gérer plus facilement les autorités de certification dans un conteneur basé sur l'infrastructure à clé publique qu'ils ne peuvent gérer une liste d'autorités de certification à plat.

Le magasin d’approbations PKI a des limites plus élevées que le magasin d’approbations classique pour le nombre d’autorités de certification et la taille de chaque fichier d’autorité de certification. Un magasin de confiance basé sur une PKI prend en charge jusqu’à 250 autorités de certification et 8 Ko pour chaque objet d’autorité de certification.

Si vous utilisez le magasin de confiance classique pour configurer des autorités de certification, nous vous recommandons vivement de configurer un magasin de confiance basé sur une PKI. Le magasin d’approbations PKI est évolutif et prend en charge de nouvelles fonctionnalités, telles que les indicateurs d’émetteur.

Un administrateur doit configurer les autorités de certification approuvées qui émettent les certificats utilisateur. Seuls les administrateurs à privilèges minimum sont tenus d’apporter des modifications. Un magasin de confiance basé sur une PKI se voit attribuer le rôle Privileged Authentication Administrator (Administrateur d’authentification privilégié).

La fonctionnalité de chargement PKI du magasin de confiance basé sur une PKI est disponible uniquement avec une licence Microsoft Entra ID P1 ou P2. Toutefois, avec la licence gratuite Microsoft Entra, un administrateur peut téléverser chaque autorité de certification individuellement au lieu de téléverser un fichier PKI. Ensuite, ils peuvent configurer le magasin de confiance basé sur l’infrastructure à clé publique et ajouter leurs fichiers CA téléchargés.

Configurer des autorités de certification à l’aide du centre d'administration Microsoft Entra

Créer un objet conteneur PKI (centre d’administration Microsoft Entra)

Pour créer un objet conteneur PKI :

1. Connectez-vous au centre d’administration Microsoft Entra avec un compte auquel le rôle administrateur d’authentification Privileged Authentication administrator est attribué.

2. Accédez à Entra ID>Identity Secure Score>Public key infrastructure.

3. Sélectionnez Créer une infrastructure à clé publique.

4. Pour nom d'affichage, entrez un nom.

5. Cliquez sur Créer.

   

6. Pour ajouter ou supprimer des colonnes, sélectionnez Modifier les colonnes.

7. Pour actualiser la liste des PKIs, sélectionnez Actualiser.

Supprimer un objet conteneur PKI

Pour supprimer une PKI, sélectionnez-la et cliquez sur Supprimer. Si l’infrastructure à clé publique contient des autorités de certification, entrez le nom de l’infrastructure à clé publique pour reconnaître la suppression de toutes les autorités de certification dans l’infrastructure à clé publique. Sélectionnez Ensuite Supprimer.

Charger des autorités de certification individuelles dans un objet conteneur PKI

Pour charger une autorité de certification dans un conteneur PKI :

1. Sélectionnez Ajouter une autorité de certification.

2. Sélectionnez le fichier d’autorité de certification.

3. Si l’autorité de certification est un certificat racine, sélectionnez Oui. Sinon, sélectionnez Non.

4. Pour URL de la liste de révocation de certificats, entrez l’URL accessible sur Internet pour la CRL de base de l’autorité de certification qui contient tous les certificats révoqués. Si l’URL n’est pas définie, une tentative d’authentification à l’aide d’un certificat révoqué n’échoue pas.

5. Pour l’URL de liste de révocation de certificats Delta, entrez l’URL accessible sur Internet pour la liste de révocation de certificats qui contient tous les certificats révoqués depuis la dernière liste de révocation de certificats de base publiée.

6. Si l’autorité de certification ne doit pas être incluse dans les indications d’émetteur, désactivez les indications d’émetteur. L’indicateur indicateurs de l’émetteur est désactivé par défaut.

7. Sélectionnez Enregistrer.

8. Pour supprimer une autorité de certification, sélectionnez l’autorité de certification, puis sélectionnez Supprimer.

   

9. Pour ajouter ou supprimer des colonnes, sélectionnez Modifier les colonnes.

10. Pour actualiser la liste des PKIs, sélectionnez Actualiser.

Au départ, 100 certificats d’autorité de certification sont affichés. Plus d’informations apparaissent lorsque vous faites défiler le volet vers le bas.

Charger toutes les autorités de certification dans un objet conteneur PKI

Pour charger en masse toutes les autorités de certification dans un conteneur PKI :

1. Créez un objet conteneur PKI ou ouvrez un conteneur existant.

2. Sélectionnez Charger un fichier PKI.

3. Entrez l’URL http accessible sur Internet du .p7b fichier.

4. Entrez la somme de contrôle SHA-256 du fichier.

5. Sélectionnez le chargement.

   Le processus de chargement pKI est asynchrone. À mesure que chaque CA est chargée, elle devient disponible dans la PKI. Le chargement complet de l’infrastructure à clé publique peut prendre jusqu’à 30 minutes.

6. Cliquez sur Actualiser pour actualiser la liste de CA.

7. Chaque attribut point de terminaison CRL de l’autorité de certification chargée est mis à jour avec la première URL HTTP disponible du certificat de l’autorité de certification listée comme attribut points de distribution CRL. Vous devez mettre à jour manuellement les certificats de feuille.

Pour générer la somme de contrôle SHA-256 du fichier PKI .p7b , exécutez :

Get-FileHash .\CBARootPKI.p7b -Algorithm SHA256

Modifier une PKI

1. Sur la ligne PKI, sélectionnez ... et sélectionnez Modifier.
2. Entrez un nouveau nom d’infrastructure à clé publique.
3. Sélectionnez Enregistrer.

Modifier une CA

1. Sur la ligne de l’autorité de certification, sélectionnez ... et sélectionnez Modifier.
2. Entrez de nouvelles valeurs pour le type d’autorité de certification (racine ou intermédiaire), l’URL CRL, l’URL CRL delta ou l’indicateur d’activation des indications d’émetteur selon vos besoins.
3. Sélectionnez Enregistrer.

Modifier en bloc l’attribut indices de l’émetteur

1. Pour modifier plusieurs autorités de certification et activer ou désactiver l’attribut Activé des indicateurs d’émetteur , sélectionnez plusieurs autorités de certification.
2. Sélectionnez Modifier, puis modifiez les indicateurs de l’émetteur.
3. Activez la case à cocher Indice d'émetteur activé pour toutes les autorités de certification sélectionnées, ou décochez-la pour désactiver l'indicateur Indice d'émetteur activé pour toutes les autorités de certification sélectionnées. La valeur par défaut est Indéterminé.
4. Sélectionnez Enregistrer.

Restaurer une PKI

1. Cliquez sur l’onglet PKI supprimées.
2. Sélectionnez la PKI et cliquez sur Restaurer la PKI.

Restaurer une CA

1. Cliquez sur l’onglet CA supprimées.
2. Sélectionnez le fichier d’autorité de certification, puis restaurez l’autorité de certification.

Configurer l’attribut isIssuerHintEnabled pour une autorité de certification

Les indications d’émetteur renvoient un indicateur autorité de certification approuvée dans le cadre de la négociation Transport Layer Security (TLS). La liste des autorités de certification approuvées est définie sur le sujet des autorités de certification que le locataire charge dans le magasin de confiance Microsoft Entra. Pour plus d’informations, consultez Présentation des indicateurs d’émetteur.

Par défaut, les noms des sujets de toutes les autorités de certification (CA) dans le magasin de confiance Microsoft Entra sont envoyés sous forme d’indicateurs. Si vous souhaitez renvoyer un indicateur uniquement pour des autorités de certification spécifiques, définissez l’attribut indicateur de l’émetteur isIssuerHintEnabled sur true.

Le serveur peut renvoyer au client TLS une réponse maximale de 16 Ko pour les indications d’émetteur (le nom du sujet de l’autorité de certification). Nous vous recommandons de définir l’attribut isIssuerHintEnabled uniquement true pour les autorités de certification qui émettent des certificats utilisateur.

Si plusieurs autorités de certification intermédiaires du même certificat racine émettent des certificats utilisateur, par défaut, tous les certificats apparaissent dans le sélecteur de certificats. Si vous définissez isIssuerHintEnabled sur true pour des autorités de certification spécifiques, seuls les certificats utilisateur pertinents apparaissent dans le sélecteur de certificats.

Configurer des autorités de certification à l’aide d’API Microsoft Graph

Les exemples suivants montrent comment utiliser Microsoft Graph pour exécuter des opérations CRUD (Create, Read, Update et Delete) via des méthodes HTTP pour une infrastructure à clé publique ou une autorité de certification.

Créer un objet conteneur PKI (Microsoft Graph)

PATCH https://graph.microsoft.com/beta/directory/publicKeyInfrastructure/certificateBasedAuthConfigurations/
Content-Type: application/json
{
   "displayName": "ContosoPKI"
}

Obtenir tous les objets PKI

GET https://graph.microsoft.com/beta/directory/publicKeyInfrastructure/certificateBasedAuthConfigurations
ConsistencyLevel: eventual

Obtenir un objet PKI par ID PKI

GET https://graph.microsoft.com/beta/directory/publicKeyInfrastructure/certificateBasedAuthConfigurations/<PKI-ID>/
ConsistencyLevel: eventual

Charger des certificats de sécurité à l'aide d'un fichier .p7b

PATCH https://graph.microsoft.com/beta/directory/publicKeyInfrastructure/certificateBasedAuthConfigurations/<PKI-id>/certificateAuthorities/<CA-ID>
Content-Type: application/json
{
     "uploadUrl":"https://CBA/demo/CBARootPKI.p7b,
     "sha256FileHash": "AAAAAAD7F909EC2688567DE4B4B0C404443140D128FE14C577C5E0873F68C0FE861E6F"
}

Obtenir toutes les CA d’une PKI

GET https://graph.microsoft.com/beta/directory/publicKeyInfrastructure/certificateBasedAuthConfigurations/<PKI-ID>/certificateAuthorities
ConsistencyLevel: eventual

Obtenir une autorité de certification spécifique dans une infrastructure à clé publique par ID CA

GET https://graph.microsoft.com/beta/directory/publicKeyInfrastructure/certificateBasedAuthConfigurations/<PKI-ID>/certificateAuthorities/<CA-ID>
ConsistencyLevel: eventual

Mettre à jour l’indicateur d’indications d’émetteur d’une autorité de certification spécifique

PATCH https://graph.microsoft.com/beta/directory/publicKeyInfrastructure/certificateBasedAuthConfigurations/<PKI-ID>/certificateAuthorities/<CA-ID>
Content-Type: application/json
{
   "isIssuerHintEnabled": true
}

Configurer des autorités de certification à l’aide de PowerShell

Pour ces étapes, utilisez Microsoft Graph PowerShell.

1. Démarrez PowerShell à l’aide de l’option Exécuter en tant qu’administrateur .

2. Installez et importez le Microsoft Graph - SDK PowerShell :

   Install-Module Microsoft.Graph -Scope AllUsers
   Import-Module Microsoft.Graph.Authentication
   Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser
   

3. Connectez-vous au tenant et acceptez all :

      Connect-MGGraph -Scopes "Directory.ReadWrite.All", "User.ReadWrite.All" -TenantId <tenantId>
   

Priorisation entre un magasin de confiance basé sur une infrastructure à clé publique et un magasin d’autorité de certification classique

Si une autorité de certification existe à la fois dans un magasin d’autorités de certification basé sur une PKI et dans un magasin d’autorités de certification classique, le magasin de confiance basé sur une PKI est prioritaire.

Un magasin CA classique est priorisé dans ces scénarios :

• Une autorité de certification existe dans les deux magasins, le magasin basé sur une PKI ne comporte pas de CRL, mais l’autorité de certification du magasin classique dispose d’une CRL valide.
• Une autorité de certification existe dans les deux magasins et la CRL de l’autorité de certification du magasin basé sur une PKI est différente de celle du magasin classique.

Journal de connexion

Une entrée interrompue du journal de connexion Microsoft Entra comporte deux attributs sous Détails supplémentaires pour indiquer si le magasin de confiance classique ou hérité a été utilisé lors de l’authentification.

• Is Legacy Store Used a la valeur 0 pour indiquer qu’un magasin basé sur une PKI est utilisé. La valeur 1 indique qu’un magasin classique ou hérité est utilisé.
• Les informations d’utilisation du magasin hérité affichent la raison pour laquelle le magasin classique ou hérité est utilisé.

Journal d’audit

Toutes les opérations CRUD que vous effectuez sur une PKI ou une autorité de certification dans le magasin de confiance apparaissent dans les journaux d’audit Microsoft Entra.

Migrer d’un magasin AC classique vers un magasin basé sur une PKI

Un administrateur de locataire peut charger toutes les autorités de certification dans le magasin basé sur une PKI. Le magasin d’autorité de certification PKI a ensuite la priorité sur un magasin classique, et toutes les authentifications CBA se produisent via le magasin PKI. Un administrateur de locataire peut supprimer les autorités de certification d’un magasin classique ou hérité après avoir confirmé dans les journaux de connexion qu’aucune indication d’utilisation du magasin classique ou hérité n’est présente.

Foire aux questions

Pourquoi le chargement PKI échoue-t-il ?

Vérifiez que le fichier PKI est valide et qu’il est accessible sans problème. La taille maximale du fichier PKI est de 2 Mo (contient 250 CA et 8 Ko pour chaque objet CA).

Qu’est-ce que le contrat de niveau de service pour le chargement PKI ?

Le chargement pKI est une opération asynchrone et peut prendre jusqu’à 30 minutes.

Comment générer une somme de contrôle SHA-256 pour un fichier PKI ?

Pour générer la somme de contrôle SHA-256 du fichier PKI .p7b , exécutez cette commande :

Get-FileHash .\CBARootPKI.p7b -Algorithm SHA256

Étape 2 : Activer CBA pour le locataire

Pour activer l'authentification basée sur les certificats via le centre d'administration Microsoft Entra :

1. Connectez-vous au centre d’administration Microsoft Entra avec un compte auquel est assigné au moins le rôle d’Administrateur de stratégie d’authentification.

2. Accédez à Groupes>Tous les groupes.

3. Sélectionnez Nouveau groupe et créez un groupe pour les utilisateurs de l’administrateur de base de données.

4. Accédez aux méthodes Entra ID>Méthodes d'authentification>Authentification basée sur le certificat.

5. Sous Activer et Cibler, activez la case à cocher Activer, puis cochez la case I Acknowledge .

6. Choisissez Sélectionner des groupes>Ajouter des groupes.

7. Choisissez des groupes spécifiques, comme celui que vous avez créé, puis sélectionnez Sélectionner. Utilisez des groupes spécifiques au lieu de tous les utilisateurs.

8. Sélectionnez Enregistrer.

   

Une fois l'authentification basée sur certificat (ABC) activée pour le locataire, tous les utilisateurs du locataire voient l'option de se connecter à l'aide d'un certificat. Seuls les utilisateurs capables d’utiliser le CBA peuvent s’authentifier à l’aide d’un certificat X.509.

Étape 3 : Configurer une stratégie de liaison d’authentification

Une stratégie de liaison d’authentification permet de définir la robustesse de l’authentification sur un facteur unique ou sur une MFA. Le niveau de protection par défaut pour tous les certificats sur le locataire est l’authentification à facteur unique.

La liaison d’affinité par défaut au niveau du locataire est faible. Un administrateur de stratégie d’authentification peut modifier la valeur par défaut de l’authentification à facteur unique en MFA. Si le niveau de protection change, tous les certificats du locataire sont définis sur MFA. De même, la liaison d’affinité au niveau du tenant peut être définie sur une affinité élevée. Tous les certificats sont ensuite validés à l’aide d’attributs d’affinité élevée uniquement.

Les règles de liaison d’authentification mappent les attributs de certificat tels que l’émetteur, l’ID d’objet de stratégie (OID) et l’émetteur et l’OID de stratégie à une valeur donnée. Les règles définissent le niveau de protection par défaut et la liaison d’affinité pour cette règle.

Pour modifier les paramètres de locataire par défaut et créer des règles personnalisées via le centre d’administration Microsoft Entra :

1. Connectez-vous au centre d’administration Microsoft Entra avec un compte qui a au moins le rôle Administrateur de stratégie d’authentification assigné.

2. Accédez aux Entra ID>Méthodes d'authentification>Politiques.

3. Sous Gérer les migrations, sélectionnez Authentification>basée sur l’authentification par certificat.

   

4. Pour configurer la liaison d’authentification et la liaison de nom d’utilisateur, sélectionnez Configurer.

5. Pour remplacer la valeur par défaut par MFA, sélectionnez Authentification multifacteur. L’attribut de niveau de protection a la valeur par défaut Authentification à un facteur.

   Note

   Le niveau de protection par défaut est en vigueur si aucune règle personnalisée n’est ajoutée. Si vous ajoutez une règle personnalisée, le niveau de protection défini au niveau de la règle est respecté au lieu du niveau de protection par défaut.

   

6. Vous pouvez également configurer des règles de liaison d’authentification personnalisées pour déterminer le niveau de protection des certificats clients qui nécessitent des valeurs différentes de niveau de protection ou de liaison d’affinité par rapport à celles par défaut du système. Vous pouvez configurer les règles à l’aide de l’objet émetteur ou de l’OID de stratégie, ou des deux champs, dans le certificat.

   Les règles de liaison d'authentification associent les attributs de certificat (émetteur ou OID de stratégie) à une valeur. La valeur définit le niveau de protection par défaut pour cette règle. Plusieurs règles peuvent être créées. Dans l’exemple suivant, supposez que la valeur par défaut du locataire est Authentification multifacteur et Faible pour la liaison d’affinité.

   Pour ajouter des règles personnalisées, cliquez sur Ajouter une règle.

   

   Pour créer une règle par émetteur de certificat :

   1. Sélectionnez l’émetteur de certificat.

   2. Pour l’identificateur de l’émetteur de certificat, sélectionnez une valeur pertinente.

   3. Pour la force de l’authentification, sélectionnez Authentification multifacteur.

   4. Pour la liaison d’affinité, sélectionnez Faible.

   5. Sélectionnez Ajouter.

   6. Lorsque vous y êtes invité, cochez la case I Acknowledge pour ajouter la règle.

      

   Pour créer une règle par OID de stratégie :

   1. Sélectionnez OID de stratégie.

   2. Pour OID de politique, entrez une valeur.

   3. Pour la force de l’authentification, sélectionnez Authentification unique.

   4. Pour la liaison d'affinité, sélectionnez faible pour la liaison d'affinité.

   5. Sélectionnez Ajouter.

   6. Lorsque vous y êtes invité(e), cochez la case I Acknowledge pour ajouter la règle.

      

   Pour créer une règle par émetteur et OID de stratégie :

   1. Sélectionnez l’émetteur de certificat et l’OID de stratégie.

   2. Sélectionnez un émetteur et saisissez l’OID de stratégie.

   3. Pour la force de l’authentification, sélectionnez Authentification multifacteur.

   4. Pour la liaison d’affinité, sélectionnez Faible.

   5. Sélectionnez Ajouter.

      

      

   6. Authentifiez-vous avec un certificat qui dispose d’un OID de stratégie 3.4.5.6 et qui est émis par CN=CBATestRootProd. Vérifiez que l'authentification est réussie pour une exigence multifacteur.

   Pour créer une règle par émetteur et numéro de série :

   1. Ajoutez une stratégie de liaison d’authentification. La politique exige que tout certificat émis par CN=CBATestRootProd avec un OID de politique de 1.2.3.4.6 ne nécessite que la liaison d'affinité élevée. L’émetteur et le numéro de série sont utilisés.

      

   2. Sélectionnez le champ du certificat. Pour cet exemple, sélectionnez Émetteur et numéro de série.

      

   3. Le seul attribut utilisateur pris en charge est certificateUserIds. Sélectionnez certificateUserIds et sélectionnez Ajouter.

      

   4. Sélectionnez Enregistrer.

      Le journal de connexion indique quelle liaison a été utilisée pour la connexion ainsi que les détails du certificat.

      

7. Sélectionnez OK pour enregistrer les règles personnalisées.

Étape 4 : Configurer la stratégie de liaison de nom d’utilisateur

La politique de liaison de nom d’utilisateur permet de valider le certificat d'authentification d’un utilisateur. Par défaut, pour déterminer l’utilisateur, vous faites correspondre le nom du principal dans le certificat à l'attribut correspondant de userPrincipalName dans l’objet utilisateur.

Un administrateur de stratégie d’authentification peut remplacer la valeur par défaut et créer un mappage personnalisé. Pour plus d’informations, consultez fonctionnement de la liaison de nom d’utilisateur.

Pour d’autres scénarios qui utilisent l’attribut certificateUserIds , consultez ID utilisateur de certificat.

1. Créez la liaison de nom d’utilisateur en sélectionnant l’un des champs de certificat X.509 à lier à l’un des attributs utilisateur. L’ordre de liaison de nom d’utilisateur représente le niveau de priorité de la liaison. La première liaison de nom d’utilisateur a la priorité la plus élevée, et ainsi de suite.

   

   Si le champ de certificat X.509 spécifié se trouve sur le certificat, mais que Microsoft Entra ID ne trouve pas d'objet utilisateur ayant une valeur correspondante, l'authentification échoue. Ensuite, Microsoft Entra ID tente la liaison suivante dans la liste.

2. Sélectionnez Enregistrer.

Votre configuration finale ressemble à cet exemple :

Étape 5 : Tester votre configuration

Cette section explique comment tester votre certificat et les règles de liaison d’authentification personnalisées.

Tester votre certificat

Dans le premier test de configuration, essayez de vous connecter au portail MyApps à l’aide de votre navigateur d’appareil.

1. Entrez votre nom d’utilisateur principal (UPN).

   

2. Sélectionnez Suivant.

   

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

   

3. Sélectionnez Se connecter avec un certificat.

4. Sélectionnez le certificat utilisateur correct dans l’interface utilisateur du sélecteur de certificats client, puis sélectionnez OK.

   

5. Vérifiez que vous êtes connecté au portail MyApps.

Si votre connexion est réussie, vous savez que :

• Le certificat utilisateur est approvisionné dans votre appareil de test.
• Microsoft Entra ID est correctement configuré pour utiliser des autorités de certification approuvées.
• La liaison de nom d’utilisateur est configurée correctement. L’utilisateur est trouvé et authentifié.

Tester les règles de liaison d’authentification personnalisées

Ensuite, effectuez un scénario dans lequel vous validez l’authentification forte. Vous créez deux règles de stratégie d’authentification : une à l’aide d’un émetteur soumis à une authentification à facteur unique, et une autre en utilisant l’OID de stratégie pour satisfaire l’authentification multifacteur.

1. Créez une règle de sujet d’émetteur avec un niveau de protection d’authentification à facteur unique. Définissez la valeur sur la valeur du sujet de votre autorité de certification.

   Par exemple :

   CN=WoodgroveCA

2. Créez une règle OID de stratégie avec un niveau de protection d’authentification multifacteur. Définissez la valeur sur l’un des OID de stratégie de votre certificat. Voici un exemple 1.2.3.4: .

   

3. Créez une stratégie d’accès conditionnel Microsoft Entra pour l’utilisateur afin d’exiger une MFA. Effectuez les étapes décrites dans l’accès conditionnel - Exiger l’authentification multifacteur.

4. Accédez au portail MyApps. Saisissez votre nom d’utilisateur principal et cliquez sur Suivant.

   

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

   

   Si vous avez mis à 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.

   

6. Sélectionnez le certificat client, puis sélectionnez Informations de certificat.

   

   Le certificat s’affiche et vous pouvez vérifier les valeurs de l’émetteur et de l’OID de stratégie.

   

7. Pour afficher les valeurs OID de stratégie, sélectionnez Détails.

   

8. Sélectionnez le certificat client et cliquez sur OK.

L’OID de stratégie dans le certificat correspond à la valeur configurée de 1.2.3.4 et satisfait la MFA. L’émetteur du certificat correspond à la valeur configurée de CN=WoodgroveCA et répond aux exigences de l’authentification à facteur unique.

Comme la règle OID de stratégie a priorité sur la règle d’émetteur, le certificat satisfait la MFA.

La stratégie d’accès conditionnel pour l’utilisateur requiert l’authentification multifacteur et le certificat satisfait à l’authentification multifacteur, afin que l’utilisateur puisse se connecter à l’application.

Tester la stratégie de liaison du nom d’utilisateur

La stratégie de liaison de nom d’utilisateur permet de valider le certificat de l’utilisateur. Trois liaisons sont prises en charge pour la stratégie de liaison du nom d’utilisateur :

• IssuerAndSerialNumber > certificateUserIds
• IssuerAndSubject > certificateUserIds
• Subject > certificateUserIds

Par défaut, Microsoft Entra ID mappe Principal Name dans le certificat à userPrincipalName dans l’objet utilisateur pour déterminer l’utilisateur. Un administrateur de stratégie d’authentification peut remplacer la valeur par défaut et créer un mappage personnalisé comme décrit précédemment.

Un administrateur de stratégie d’authentification doit configurer les nouvelles liaisons. Pour préparer, ils doivent s’assurer que les valeurs correctes pour les liaisons de nom d’utilisateur correspondantes sont mises à jour dans l’attribut certificateUserIds de l’objet utilisateur :

• Pour les utilisateurs cloud uniquement, utilisez les API centre d’administration Microsoft Entra ou Microsoft Graph pour mettre à jour la valeur dans certificateUserIds.
• Pour les utilisateurs synchronisés locaux, utilisez Microsoft Entra Connect pour synchroniser les valeurs locales en suivant les règles Microsoft Entra Connect ou par synchronisation de la valeur AltSecId.

Mappage manuel de l’émetteur et du numéro de série

L’exemple suivant illustre le mappage manuel de l’émetteur et du numéro de série.

La valeur de l’émetteur à ajouter est la suivante :

C=US,O=U.SGovernment,OU=DoD,OU=PKI,OU=CONTRACTOR,CN=CRL.BALA.SelfSignedCertificate

Pour obtenir la valeur correcte du numéro de série, exécutez la commande suivante. Stockez la valeur affichée dans certificateUserIds.

Syntaxe de la commande :

certutil –dump –v [~certificate path~] >> [~dumpFile path~] 

Par exemple :

certutil -dump -v firstusercert.cer >> firstCertDump.txt

Voici un exemple pour la certutil commande :

certutil -dump -v C:\save\CBA\certs\CBATestRootProd\mfausercer.cer 

X509 Certificate: 
Version: 3 
Serial Number: 48efa06ba8127299499b069f133441b2 

   b2 41 34 13 9f 06 9b 49 99 72 12 a8 6b a0 ef 48 

La valeur du numéro de série à ajouter certificateUserId est la suivante :

b24134139f069b49997212a86ba0ef48

La certificateUserIds valeur est :

X509:<I>C=US,O=U.SGovernment,OU=DoD,OU=PKI,OU=CONTRACTOR,CN=CRL.BALA.SelfSignedCertificate<SR> b24134139f069b49997212a86ba0ef48

Mappage manuel de l’émetteur et du sujet

L’exemple suivant illustre le mappage manuel de l’émetteur et de l’objet.

La valeur de l’émetteur est la suivante :

La valeur Objet est la suivante :

La certificateUserId valeur est :

X509:<I>C=US,O=U.SGovernment,OU=DoD,OU=PKI,OU=CONTRACTOR,CN=CRL.BALA.SelfSignedCertificate<S> DC=com,DC=contoso,DC=corp,OU=UserAccounts,CN=FirstUserATCSession

Mappage manuel de la valeur Subject

L’exemple suivant illustre le mappage manuel de l’objet.

La valeur Objet est la suivante :

La certificateUserIds valeur est :

X509:<S>DC=com,DC=contoso,DC=corp,OU=UserAccounts,CN=FirstUserATCSession

Tester la liaison d’affinité

1. Connectez-vous au centre d’administration Microsoft Entra avec un compte qui a au moins le rôle Administrateur de stratégie d’authentification assigné.

2. Accédez aux Entra ID>Méthodes d'authentification>Politiques.

3. Sous Gérer, sélectionnez Authentification>basée sur le certificat.

4. Sélectionnez Configurer.

5. Définissez Liaison d’affinité requise au niveau de l’abonné.

   Importante

   Prêtez attention au paramètre d’affinité à l’échelle de l’abonné. Vous pouvez verrouiller l’intégralité du locataire si vous modifiez la valeur de liaison d’affinité requise pour le locataire et que vous n’avez pas de valeurs correctes dans l’objet utilisateur. De même, si vous créez une règle personnalisée qui s’applique à tous les utilisateurs et nécessite une liaison à forte affinité, les utilisateurs du locataire peuvent être bloqués.

   

6. Pour tester la liaison d’affinité requise, sélectionnez Faible.

7. Ajoutez une liaison à affinité élevée, comme l’identificateur de clé d’objet (SKI). Sous Liaison de nom d’utilisateur, sélectionnez Ajouter une règle.

8. Sélectionnez SKI, puis cliquez sur Ajouter.

   

   Une fois terminée, la règle ressemble à cet exemple :

   

9. Pour tous les objets utilisateur, mettez à jour l’attribut certificateUserIds avec la valeur SKI correcte à partir du certificat utilisateur.

   Pour en savoir plus, consultez Modèles pris en charge pour les identifiants CertificateUserID.

10. Créez une règle personnalisée pour la liaison d’authentification.

11. Sélectionnez Ajouter.

    

    Vérifiez que la règle terminée ressemble à cet exemple :

    

12. Mettez à jour la valeur certificateUserIds de l’utilisateur avec la valeur SKI correcte du certificat et l’OID de stratégie de 9.8.7.5.

13. Testez à l’aide d’un certificat avec un OID de politique de 9.8.7.5. Vérifiez que l’utilisateur est authentifié avec la liaison SKI et qu’il est invité à se connecter avec une MFA et uniquement le certificat.

Configurer CBA en utilisant les API Microsoft Graph

Pour configurer CBA et les liaisons de nom d’utilisateur à l’aide des API Microsoft Graph :

1. Accédez à Microsoft Graph Explorer.

2. Sélectionnez Se connecter à l’Explorateur Graph et connectez-vous à votre compte locataire.

3. Suivez les étapes pour donner votre consentement à l’autorisation Policy.ReadWrite.AuthenticationMethod déléguée.

4. Obtenez toutes les méthodes d’authentification :

   GET  https://graph.microsoft.com/v1.0/policies/authenticationmethodspolicy
   

5. Obtenez la configuration de la méthode d’authentification de certificat X.509 :

   GET https://graph.microsoft.com/v1.0/policies/authenticationmethodspolicy/authenticationMethodConfigurations/X509Certificate
   

6. Par défaut, la méthode d’authentification par certificat X.509 est désactivée. Pour permettre aux utilisateurs de se connecter à l’aide d’un certificat, vous devez activer la méthode d’authentification et configurer les stratégies d’authentification et de liaison de nom d’utilisateur via une opération de mise à jour. Pour mettre à jour la stratégie, exécutez une PATCH requête.

   Corps de la demande

   PATCH https://graph.microsoft.com/v1.0/policies/authenticationMethodsPolicy/authenticationMethodConfigurations/x509Certificate
   Content-Type: application/json
   
   {
       "@odata.type": "#microsoft.graph.x509CertificateAuthenticationMethodConfiguration",
       "id": "X509Certificate",
       "state": "enabled",
       "certificateUserBindings": [
           {
               "x509CertificateField": "PrincipalName",
               "userProperty": "onPremisesUserPrincipalName",
               "priority": 1
           },
           {
               "x509CertificateField": "RFC822Name",
               "userProperty": "userPrincipalName",
               "priority": 2
           }, 
           {
               "x509CertificateField": "PrincipalName",
               "userProperty": "certificateUserIds",
               "priority": 3
           }
       ],
       "authenticationModeConfiguration": {
           "x509CertificateAuthenticationDefaultMode": "x509CertificateSingleFactor",
           "rules": [
               {
                   "x509CertificateRuleType": "issuerSubject",
                   "identifier": "CN=WoodgroveCA ",
                   "x509CertificateAuthenticationMode": "x509CertificateMultiFactor"
               },
               {
                   "x509CertificateRuleType": "policyOID",
                   "identifier": "1.2.3.4",
                   "x509CertificateAuthenticationMode": "x509CertificateMultiFactor"
               }
           ]
       },
       "includeTargets": [
           {
               "targetType": "group",
               "id": "all_users",
               "isRegistrationRequired": false
           }
       ]
   }
   

7. Vérifiez qu'un code de réponse 204 No content est retourné. Réexécutez la GET requête pour vous assurer que les stratégies sont correctement mises à jour.

8. Testez la configuration en vous connectant à l’aide d’un certificat qui répond à la stratégie.

Configurer l'authentification basée sur un certificat à l'aide de Microsoft PowerShell

1. Ouvrez PowerShell.

2. Connectez-vous à Microsoft Graph :

   Connect-MgGraph -Scopes "Policy.ReadWrite.AuthenticationMethod"
   

3. Créez une variable à utiliser pour définir un groupe pour les utilisateurs de l’administrateur de base de données :

   $group = Get-MgGroup -Filter "displayName eq 'CBATestGroup'"
   

4. Définissez le corps de la requête :

   $body = @{
   "@odata.type" = "#microsoft.graph.x509CertificateAuthenticationMethodConfiguration"
   "id" = "X509Certificate"
   "state" = "enabled"
   "certificateUserBindings" = @(
       @{
           "@odata.type" = "#microsoft.graph.x509CertificateUserBinding"
           "x509CertificateField" = "SubjectKeyIdentifier"
           "userProperty" = "certificateUserIds"
           "priority" = 1
       },
       @{
           "@odata.type" = "#microsoft.graph.x509CertificateUserBinding"
           "x509CertificateField" = "PrincipalName"
           "userProperty" = "UserPrincipalName"
           "priority" = 2
       },
       @{
           "@odata.type" = "#microsoft.graph.x509CertificateUserBinding"
           "x509CertificateField" = "RFC822Name"
           "userProperty" = "userPrincipalName"
           "priority" = 3
       }
   )
   "authenticationModeConfiguration" = @{
       "@odata.type" = "#microsoft.graph.x509CertificateAuthenticationModeConfiguration"
       "x509CertificateAuthenticationDefaultMode" = "x509CertificateMultiFactor"
       "rules" = @(
           @{
               "@odata.type" = "#microsoft.graph.x509CertificateRule"
               "x509CertificateRuleType" = "policyOID"
               "identifier" = "1.3.6.1.4.1.311.21.1"
               "x509CertificateAuthenticationMode" = "x509CertificateMultiFactor"
           }
       )
   }
   "includeTargets" = @(
       @{
           "targetType" = "group"
           "id" = $group.Id
           "isRegistrationRequired" = $false
       }
   ) } | ConvertTo-Json -Depth 5
   

5. Exécutez la PATCH requête :

   Invoke-MgGraphRequest -Method PATCH -Uri "https://graph.microsoft.com/v1.0/policies/authenticationMethodsPolicy/authenticationMethodConfigurations/x509Certificate" -Body $body -ContentType "application/json"
   

Contenu connexe

• Vue d'ensemble de Microsoft Entra CBA
• Concepts techniques de Microsoft Entra CBA
• Limitations d’utilisation de l’Microsoft Entra CBA
• Connexion par carte à puce sous Windows à l’aide de Microsoft Entra CBA
• Microsoft Entra CBA sur les appareils mobiles (Android et iOS)
• ID des utilisateurs du certificat
• Migrer des utilisateurs fédérés
• Forum aux questions