Comment configurer l’authentification Microsoft Entra basée sur certificat

Article
12/03/2024

L’authentification basée sur certificat (CBA/Certificate-based Authentication) Microsoft Entra permet aux organisations de configurer leurs locataires Microsoft Entra pour autoriser ou demander aux utilisateurs de s’authentifier avec des certificats X.509 créés par l’infrastructure à clé publique (Public Key Infrastructure/PKI) de leur entreprise afin de se connecter aux applications et aux navigateurs. Cette fonctionnalité permet aux organisations d’adopter une authentification sans mot de passe moderne résistante au hameçonnage en utilisant un certificat X.509.

Lors de la connexion, une option permettant aux utilisateurs de s’authentifier avec un certificat au lieu d’entrer un mot de passe s’affiche également. Si plusieurs certificats correspondants sont présents sur l’appareil, l’utilisateur peut choisir celui à utiliser. Le certificat est validé par rapport au compte d'utilisateur et, en cas de succès, il se connecte.

Suivez ces instructions pour configurer et utiliser Microsoft Entra CBA pour les locataires des plans Office 365 Entreprise et US Government. Vous devriez déjà avoir une infrastructure à clé publique (PKI) configurée.

Prérequis

Assurez-vous que les conditions préalables suivantes sont en place :

Configurez au moins une autorité de certification (CA pour Certification Authority) et des CA intermédiaires dans Microsoft Entra ID.
L’utilisateur doit avoir accès à un certificat utilisateur (émis à partir d’une infrastructure à clé publique approuvée configurée sur le locataire) destiné à l’authentification client pour s’authentifier auprès de Microsoft Entra ID.
Chaque autorité de certification doit avoir 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.

Important

Assurez-vous que l’infrastructure à clé publique est sécurisée et qu’elle ne peut pas être compromise facilement. En cas de compromission, l’attaquant peut créer et signer des certificats client et compromettre n’importe quel utilisateur dans le locataire, à la fois les utilisateurs qui sont synchronisés à partir des locaux et les utilisateurs cloud seul. Toutefois, une stratégie de protection de clé forte, ainsi que d’autres contrôles physiques et logiques, tels que des cartes d’activation HSM ou des jetons pour le stockage sécurisé des artefacts, peuvent fournir une défense en profondeur 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.

Important

Veuillez consulter les recommandations Microsoft pour les meilleures pratiques pour Microsoft Cryptographic concernant le choix de l'algorithme, la longueur de la clé et la protection des données. Assurez-vous d'utiliser l'un des algorithmes recommandés, la longueur de clé et les courbes approuvées par le NIST.

Important

Dans le cadre des améliorations en cours en matière de sécurité, les points de terminaison Azure/M365 ajoutent la prise en charge de TLS1.3 et ce processus devrait prendre quelques mois pour couvrir les milliers de points de terminaison de service dans Azure/M365. Cela inclut le point de terminaison Microsoft Entra utilisé par l’authentification par certificat Microsoft Entra (CBA) *.certauth.login.microsoftonline.com et *.certauth.login.microsoftonline.us. TLS 1.3 est la dernière version du protocole de sécurité le plus déployé d’Internet, qui chiffre les données pour fournir un canal de communication sécurisé entre deux points de terminaison. TLS 1.3 élimine les algorithmes de chiffrement obsolètes, améliore la sécurité sur les versions antérieures et vise à chiffrer autant que possible l’établissement d'une liaison. Nous vous recommandons vivement aux développeurs de commencer à tester TLS 1.3 dans leurs applications et services.

Remarque

Lors de l’évaluation d’une infrastructure à clé publique, il est important de passer en revue les stratégies d’émission de certificats et l’application. Comme mentionné, l’ajout d’autorités de certification (CA) à la configuration Microsoft Entra permet aux certificats émis par ces autorités de certification d’authentifier tout utilisateur dans Microsoft Entra ID. Pour cette raison, 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. Lorsque les administrateurs doivent s’assurer qu’un certificat spécifique est en mesure d’être utilisé pour authentifier un utilisateur, les administrateurs doivent exclusivement utiliser des liaisons d’affinité élevée pour obtenir un niveau plus élevé d’assurance que seul un certificat spécifique est en mesure d’authentifier l’utilisateur. Pour plus d’informations, consultez liaisons d’affinité élevée.

Étapes de configuration et de test de Microsoft Entra CBA

Quelques étapes de configuration nécessaires avant d’activer Microsoft Entra CBA. Tout d’abord, un administrateur doit configurer les autorités de certification approuvées qui émettent les certificats utilisateur. Comme indiqué dans le diagramme suivant, nous utilisons le contrôle d’accès en fonction du rôle pour nous assurer que seuls les administrateurs dotés de privilèges minimum sont nécessaires pour apporter des changements.

Un administrateur général est nécessaire pour gérer cette fonctionnalité.

Si vous le souhaitez, vous pouvez aussi configurer des liaisons d’authentification pour mapper les certificats à une authentification multifacteur ou à facteur unique et configurer des liaisons de nom d’utilisateur pour mapper un champ de certificat à un attribut d’objet utilisateur. Les administrateurs de stratégie d’authentification peuvent configurer les paramètres liés à l’utilisateur. Une fois toutes les configurations terminées, activez Microsoft Entra CBA sur le locataire.

Diagramme des étapes requises pour activer l’authentification basée sur certificat Microsoft Entra.

Étape 1 : Configurer les autorités de certification avec un magasin de confiance PKI (préversion)

Entra dispose d’un nouveau magasin de confiance des autorités de certification (CA) basé sur une infrastructure à clé publique (PKI pour Public Key Infrastructure). Un magasin de confiance des CA basé sur une PKI conserve les autorités de certification au sein d’un objet conteneur pour chaque PKI distincte. Les administrateurs peuvent gérer les CA dans un conteneur basé sur une PKI plus facilement qu’avec une liste plate de CA.

Les limites d’un magasin de confiance basé sur une PKI sont élevées concernant le nombre de CA et la taille de chaque fichier de CA. Un magasin de confiance basé sur une PKI supporte jusqu’à 250 CA et 8 Ko pour chaque objet de CA. Nous recommandons vivement d’utiliser le nouveau magasin de confiance basé sur une PKI pour le stockage des CA, qui est évolutif et propose de nouvelles fonctionnalités comme les indicateurs d’émetteur.

Remarque

Si vous utilisez l’ancien magasin de confiance pour configurer les CA , nous recommandons de configurer un magasin d’approbations basé sur une PKI.

Un administrateur doit configurer les CA approuvées qui émettent les certificats utilisateur. Pour apporter des modifications, les administrateurs doivent seulement disposer de privilèges minimums. Un magasin de confiance basé sur une PKI dispose de rôles RBAC Administrateur d’authentification privilégié et Administrateur d’authentification.

Pour charger la fonctionnalité PKI du magasin de confiance basé sur une PKI, vous devez disposer d’une licence Microsoft Entra ID P1 ou P2. Toutefois, les administrateurs avec une licence gratuite peuvent également charger l’ensemble des CA individuellement (à la place du fichier PKI) et configurer le magasin de confiance basé sur une PKI.

Configurer les autorités de certification via le centre d’administration Microsoft Entra

Créer un objet conteneur PKI

Créez un objet conteneur PKI.
Connectez-vous au centre d’administration Microsoft Entra a minima en tant qu’Administrateur de stratégie d’authentification.
Accédez à Protection > Afficher plus > Centre de sécurité (ou Score d'identité sécurisée) > Infrastructure à clé publique (préversion).
Cliquez sur + Créer une PKI.
Entrez Nom d’affichage.
Cliquez sur Créer.
Sélectionnez Colonnes pour ajouter ou supprimer des colonnes.
Sélectionnez Actualiser pour actualiser la liste des PKI.

Supprimer un objet conteneur PKI

Pour supprimer une PKI, sélectionnez-la et cliquez sur Supprimer. Si la PKI contient des CA, saisissez le nom de la PKI pour confirmer la suppression de toutes les CA, puis cliquez sur Supprimer.

Charger des CA individuellement dans un objet conteneur PKI

Pour charger une CA dans un conteneur PKI :
1. Cliquez sur + Ajouter une autorité de certification.
2. Sélectionnez le fichier d’autorité de certification.
3. Sélectionnez Oui si l’autorité de certification est un certificat racine. Sinon, sélectionnez Non.
4. Pour URL de liste de révocation de certificats, définissez l’URL accessible sur Internet pour la liste de révocation de certificats de base de l’autorité de certification qui contient tous les certificats révoqués. Si l’URL n’est pas définie, l’authentification avec des certificats révoqués n’échoue pas.
5. Pour URL de liste de révocation de certificats Delta, définissez 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. Les indicateurs d’émetteur sont activés par défaut. Désactivez les indicateurs d’émetteur pour ne pas inclure la CA aux indicateurs d’émetteur.
7. Cliquez sur Enregistrer.
8. Pour supprimer un certificat d’autorité de certification, sélectionnez le certificat et sélectionnez Supprimer.
9. Sélectionnez Colonnes pour ajouter ou supprimer des colonnes.
10. Sélectionnez Actualiser pour actualiser la liste des CA.

Charger toutes les CA en chargeant la PKI dans un objet conteneur PKI

Pour charger simultanément toutes les CA dans un conteneur PKI :
1. Créez un objet conteneur PKI (ou ouvrez-en un).
2. Sélectionnez Charger une PKI.
3. Entrez l’URL HTTP accessible sur Internet où se trouve le fichier .p7b.
4. Saisissez la somme de contrôle SHA256 du fichier.
5. Cliquez sur Charger.
6. Le chargement d’une PKI est un processus asynchrone. Dès qu’une CA est chargée, elle est disponible dans la PKI. Le chargement d’une PKI peut prendre jusqu’à 30 minutes.
7. Sélectionnez Actualiser pour actualiser les CA.
Pour générer la somme de contrôle SHA256 du fichier .p7b de la PKI, exécutez cette commande :
```
Get-FileHash .\CBARootPKI.p7b -Algorithm SHA256
```

Modifier une PKI

Pour modifier une PKI, sélectionnez ... sur la ligne PKI, puis cliquez sur Modifier.
Entrez un nouveau nom de PKI et sélectionnez Enregistrer.

Modifier une CA

Pour modifier une CA, sélectionnez ... sur la ligne CA, puis cliquez sur Modifier.
Entrez de nouvelles valeurs pour le type d’autorité de certification (racine/intermédiaire), l’URL de la liste de révocation de certificats, l’URL de la liste de révocation de certificats Delta et le marqueur des indicateurs d’émetteur activés (le cas échéant), puis sélectionnez Enregistrer.

Restaurer une PKI

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

Restaurer une CA

Sélectionnez l’onglet CA supprimées.
Sélectionnez le fichier de CA et cliquez sur Restaurer l’autorité de certification.

Comprendre l’attribut isIssuerHintEnabled d’une CA

Les indicateurs d’émetteur renvoient une indication de CA approuvée dans le cadre de l’établissement d’une liaison TLS (pour Transport Layer Security). La liste des CA approuvées est définie sur l’objet des CA chargées par le locataire dans le magasin de confiance Entra. Pour plus d’informations sur les indicateurs d’émetteur, consultez Comprendre les indicateurs d’émetteur.

Par défaut, les noms d’objet de toutes les CA du magasin de confiance Microsoft Entra sont envoyés sous forme d’indicateurs. Pour renvoyer un indicateur associé uniquement à certaines CA, définissez l’attribut d’indicateur d’émetteur isIssuerHintEnabled sur true.

Il existe une limite de caractères de 16 Ko pour les indicateurs d’émetteur (nom d’objet de la CA) que le serveur peut renvoyer au client TLS. Pour une bonne pratique, définissez l’attribut isIssuerHintEnabled sur true uniquement pour les CA qui émettent des certificats d’utilisateur.

Si plusieurs CA intermédiaires d’un même certificat racine émettent les certificats d’utilisateur final, par défaut, tous les certificats s’affichent dans le sélecteur de certificats. Toutefois, si vous définissez isIssuerHintEnabled sur true pour des CA spécifiques, seuls les certificats d’utilisateur appropriés apparaissent dans le sélecteur de certificats. Pour activer isIssuerHintEnabled, modifiez la CA et mettez à jour la valeur sur true.

Configurer des CA via les API Microsoft Graph

Les API MS Graph peuvent être utilisées pour configurer les CA. Les exemples suivants montrent comment utiliser Microsoft Graph pour exécuter des opérations CRUD (pour Create, Read, Update et Delete) pour une PKI ou une CA.

Créer un objet conteneur PKI

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 avec PKI-id

GET https://graph.microsoft.com/beta/directory/publicKeyInfrastructure/certificateBasedAuthConfigurations/{PKI-id}/
ConsistencyLevel: eventual

Charger des CA avec 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 CA spécifique au sein d’une PKI avec CA-id

GET https://graph.microsoft.com/beta/directory/publicKeyInfrastructure/certificateBasedAuthConfigurations/{PKI-id}/certificateAuthorities/{CA-id}
ConsistencyLevel: eventual

Mettre à jour un marqueur d’indicateur d’émetteur de CA spécifique

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

Configurez les CA via PowerShell. Pour cette configuration, vous pouvez utiliser [Microsoft Graph PowerShell] (/powershell/microsoftgraph/installation).

Démarrez PowerShell avec les privilèges administrateur.

Installez et importez le Kit de développement logiciel (SDK) Microsoft Graph PowerShell.

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

Connectez-vous au locataire et acceptez tout.

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

Journal d’audit

Toutes les opérations CRUD sur une PKI ou une CA du magasin de confiance sont consignées dans les journaux d’audit Microsoft Entra.

Diagramme des journaux d'audit.

FAQ

Question : Pourquoi le chargement de la PKI ?

Réponse: Vérifiez si le fichier PKI est valide et accessible. La taille maximale du fichier PKI doit être

Question : Quel est le contrat de niveau de service (SLA) pour le chargement de PKI ?

Réponse : le chargement de PKI est une opération asynchrone qui peut prendre jusqu’à 30 minutes.

Question : Comment générer la somme de contrôle SHA256 pour un fichier PKI ?

Réponse : Pour générer la somme de contrôle SHA256 du fichier .p7b de la PKI, exécutez cette commande :

Get-FileHash .\CBARootPKI.p7b -Algorithm SHA256

Étape 2 : Activer l’authentification basée sur les certificats sur le locataire

Important

Un utilisateur est considéré comme éligible à l’Authentification multifacteur dans l’étendue de l’Authentification par certificat dans la stratégie des méthodes d’authentification. Cette exigence de stratégie signifie qu’un utilisateur ne peut pas utiliser la preuve dans le cadre de son authentification pour l’inscription des autres méthodes disponibles. Si les utilisateurs n’ont pas accès aux certificats, ils sont verrouillés et ne peuvent plus inscrire d’autres méthodes pour l’authentification multifacteur (MFA). Les administrateurs de stratégie d’authentification doivent activer l’authentification basée sur les certificats (CBA) uniquement pour les utilisateurs disposant d’un certificat valide. N’autorisez pas Tous les utilisateurs à utiliser la CBA. Désignez uniquement des groupes d’utilisateurs disposant d’un certificat valide. Pour plus d’informations, consultez Authentification multifacteur Microsoft Entra.

Pour activer la CBA dans le centre d'administration Microsoft Entra, procédez comme suit :

Connectez-vous au Centre d'administration Microsoft Entra au minimum en tant qu’Administrateur de stratégie d’authentification.
Accédez à Groupes > Tous les groupes>, sélectionnez Nouveau groupe et créez un groupe pour les utilisateurs de la CBA.
Accédez à Protection>Méthodes d’authentification>Authentification basée sur les certificats.
Sous Activer et cibler, cliquez sur Activer.
Sélectionnez Tous les utilisateurs pour sélectionner des groupes spécifiques comme celui que vous avez créé. Utilisez des groupes spécifiques plutôt que l’option Tous les utilisateurs.

Une fois l’authentification basée sur les certificats activée sur le locataire, l’option de connexion avec un certificat s’affiche pour tous les utilisateurs du locataire. Seuls les utilisateurs autorisés à utiliser la CBA peuvent s’authentifier avec un certificat X.509.

Remarque

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

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

La stratégie de liaison d’authentification permet de définir la force de l’authentification sur un facteur, ou sur plusieurs. Le niveau de protection par défaut pour les certificats sur le locataire est l’authentification à facteur unique.

Un administrateur de stratégie d’authentification peut modifier la valeur par défaut en passant par exemple d’une authentification à facteur unique à une authentification multifacteur et configurer des règles de stratégie personnalisées. Les règles de liaison d’authentification mappent les attributs de certificat (comme Émetteur de certificat ou ID d’objet de stratégie [OID], ou Émetteur de certificat et OID de stratégie) à une valeur et sélectionnent le niveau de protection par défaut pour cette règle. Vous pouvez créer plusieurs règles.

Pour modifier les paramètres par défaut du locataire dans le Centre d’administration Microsoft Entra, procédez comme suit :

Connectez-vous au Centre d'administration Microsoft Entra au moins en tant qu’Administrateur de stratégie d’authentification.
Accédez à Protection>Méthodes d’authentification>Stratégies.
Sous Gérer, sélectionnez Méthodes d’authentification>Authentification basée sur les certificats.
Sélectionnez Configurer pour configurer la liaison d’authentification et la liaison de nom d’utilisateur.
L’attribut de niveau de protection a la valeur par défaut Authentification à un facteur. Sélectionnez Authentification multifacteur pour remplacer la valeur par défaut par l’authentification multifacteur.

Remarque

La valeur de niveau de protection par défaut est en vigueur si aucune règle personnalisée n’est ajoutée. Si des règles personnalisées sont ajoutées, le niveau de protection défini au niveau de la règle est respecté à la place.
Vous pouvez également définir des règles de liaison d’authentification personnalisées pour aider à déterminer le niveau de protection pour les certificats clients. Il peut être configuré à l’aide des champs Sujet d’émetteur ou OID de stratégie dans le certificat.

Les règles de liaison d’authentification mappent les attributs de certificat (émetteur ou OID de stratégie) à une valeur, et sélectionnent le niveau de protection par défaut pour cette règle. Plusieurs règles peuvent être créées.

Pour ajouter des règles personnalisées, sélectionnez Ajouter une règle.

Pour créer une règle par l’émetteur du certificat, sélectionnez Émetteur de certificat.
1. Sélectionnez un Identificateur d’émetteur de certificat dans la zone de liste.
2. Sélectionnez Authentification multifacteur, Liaison d’affinité faible, puis cliquez sur Ajouter. Lorsque vous y êtes invité, cliquez sur j’accepte pour terminer l’ajout de la règle.
Pour créer une règle par OID de stratégie, sélectionnez OID de stratégie.
1. Entrez une valeur pour l’OID de stratégie.
2. Sélectionnez Authentification multifacteur, Liaison d’affinité faible, puis cliquez sur Ajouter. Lorsque vous y êtes invité, cliquez sur J’accepte pour terminer l’ajout de la règle.
Pour créer une règle par l’émetteur et l’OID de stratégie :
1. Sélectionnez Émetteur de certificat et stratégie OID.
2. Sélectionnez un émetteur et saisissez l’OID de stratégie.
3. Pour la force de l’authentification, sélectionnez authentification à facteur unique ou authentification multifacteur.
4. Pour la liaison d’affinité, sélectionnez Faible.
5. Sélectionnez Ajouter.
6. Authentifiez-vous avec un certificat disposant de la stratégie OID 3.4.5.6 et émis par CN=CBATestRootProd. L’authentification doit passer et obtenir une revendication multifacteur.

Important

Il existe un problème connu dans lequel un administrateur de stratégie d’authentification de locataire Microsoft Entra configure une règle de stratégie d’authentification basée sur un certificat en utilisant à la fois l’émetteur et l’OID de la stratégie. Ce problème affecte certains scénarios d’enregistrement de dispositifs, y compris :

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

L’inscription de l’appareil avec Workplace Join, Microsoft Entra ID et les scénarios de jonction d’appareils Microsoft Entra hybrides ne sont pas affectés. Les règles d’authentification CBA utilisant l’Émetteur OU l’OID de stratégie ne sont pas affectées. Pour atténuer cela, les administrateurs doivent :

Modifier les règles de stratégie d’authentification basée sur les certificats qui utilisent les options Émetteur et OID de stratégie. Supprimer l’exigence de l’Émetteur ou l’OID de stratégie, puis Enregistrer. -Ou-
Supprimer la règle de stratégie d’authentification qui utilise à la fois l’Émetteur et l’OID de stratégie. Créer des règles qui utilisent uniquement l’Émetteur ou l’OID de stratégie.

Nous travaillons à la résolution de ce problème.

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

Ajouter une stratégie de liaison d’authentification. La stratégie exige que tout certificat émis par CN=CBATestRootProd avec policyOID 1.2.3.4.6 nécessite uniquement une liaison d’affinité élevée. L’Émetteur et le Numéro de série sont utilisés.
Sélectionnez le champ Certificat. Dans cet exemple, nous allons sélectionner Émetteur et Numéro de série.
Le seul attribut utilisateur pris en charge est CertificateUserIds. Sélectionnez Ajouter.
Cliquez sur Enregistrer.

Le journal des connexions indique quelle liaison a été utilisée pour se connecter et les détails du certificat.
Cliquez sur OK pour enregistrer les règles personnalisées.

Important

Entrez PolicyOID à l’aide du format d’identificateur d’objet. Par exemple, si la stratégie de certificat indique Toutes les stratégies d’émission, saisissez l’OID comme 2.5.29.32.0 lorsque vous ajoutez la règle. La chaîne Toutes les stratégies d’émission n’est pas valide pour l’éditeur de règles et ne prend pas effet.

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

La stratégie de liaison de nom d’utilisateur permet de valider le certificat de l’utilisateur. Par défaut, nous mappons le nom de principal du 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é. Pour déterminer comment configurer la liaison du nom d’utilisateur, consultez Comment fonctionne la liaison de nom d’utilisateur.

Pour d’autres scénarios utilisant l’attribut certificateUserIds, consultez Identifiants utilisateur du certificat.

Important

Si une stratégie de liaison de nom d’utilisateur utilise des attributs synchronisés, tels que certificateUserIds, onPremisesUserPrincipalName et l’attribut userPrincipalName de l’objet utilisateur, sachez que les comptes disposant de privilèges d’administration dans Active Directory (tels que ceux avec des droits délégués sur des objets utilisateur ou des droits d’administration sur le serveur Microsoft Entra Connect) peuvent apporter des modifications qui affectent ces attributs dans Microsoft Entra ID.

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. Le premier a la priorité la plus élevée, et ainsi de suite.

Si le champ du certificat X.509 spécifié est trouvé sur le certificat, mais que Microsoft Entra ID ne trouve pas d’objet utilisateur utilisant cette valeur, l’authentification échoue. Microsoft Entra ID tente la liaison suivante dans la liste.
Sélectionnez Enregistrer pour enregistrer les modifications.

La configuration finale doit ressembler à cette image :

Capture d’écran de la configuration finale.

Étape 5 : Tester votre configuration

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

Tester votre certificat

Dans le cadre d’un premier test de configuration, vous devez essayer de vous connecter au portail MyApps à l’aide de votre navigateur sur appareil.

Entrez votre nom d’utilisateur principal (UPN).
Cliquez sur Suivant.

Si vous avez activé d’autres méthodes d’authentification comme la connexion par téléphone ou FIDO2, les utilisateurs risquent de voir un écran de connexion différent.
Sélectionnez Se connecter avec un certificat.
Sélectionnez le certificat d’utilisateur approprié dans l’interface utilisateur du sélecteur de certificat client, puis sélectionnez OK.
Les utilisateurs doivent être connectés au portail MyApps.

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

Le certificat d’utilisateur a été provisionné sur votre appareil de test.
Microsoft Entra ID est configuré correctement avec les autorités de certification approuvées.
La liaison de nom d’utilisateur est correctement configurée et l’utilisateur est trouvé et authentifié.

Test des règles de liaison d’authentification personnalisées

Examinons un scénario dans lequel nous validons l’authentification forte. Nous allons créer deux règles de stratégie d’authentification, une à l’aide de l’émetteur soumis pour satisfaire l’authentification à facteur unique, et une autre en utilisant l’OID de stratégie pour satisfaire l’authentification multifacteur.

Créez une règle de sujet d’émetteur avec le niveau de protection d’une authentification à facteur unique et la valeur définie avec la valeur de votre sujet d’autorités de certificat. Par exemple :

CN = WoodgroveCA
Créez une règle d’OID de stratégie avec le niveau de protection d’une authentification multifacteur et la valeur définie avec l’un des OID de stratégie de votre certificat. Par exemple, 1.2.3.4.
Créez une stratégie d’accès conditionnel pour l’utilisateur afin d’exiger une authentification multifacteur en suivant les étapes dans Accès conditionnel - Exiger MFA.
Accédez au portail MyApps. Entrez votre nom d’utilisateur principal et sélectionnez Suivant.
Sélectionnez Se connecter avec un certificat.

Si vous avez activé d’autres méthodes d’authentification telles que la connexion par téléphone ou les clés de sécurité, les utilisateurs peuvent voir un autre écran de connexion.
Sélectionnez le certificat client et sélectionnez Informations sur le certificat.
Le certificat s’affiche, et vous pouvez vérifier les valeurs de l’émetteur et de l’OID de stratégie.
Pour voir les valeurs de l’OID de stratégie, sélectionnez Détails.
Sélectionnez le certificat client et sélectionnez OK.
L’OID de stratégie dans le certificat correspond à la valeur configurée de 1.2.3.4 et répond à l’authentification multifacteur. De même, l’émetteur dans le certificat correspond à la valeur configurée de CN=WoodgroveCA et répond à l’authentification à un facteur.
Étant donné que la règle d’OID de stratégie est prioritaire sur la règle d’émetteur, le certificat répond à l’authentification multifacteur.
La stratégie d’accès conditionnel pour l’utilisateur exige MFA et le certificat répond à l’authentification multifacteur, donc l’utilisateur peut se connecter à l’application.

Test de 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. Il y a trois liaisons prises en charge pour la stratégie de liaison de nom d’utilisateur :

IssuerAndSerialNumber > CertificateUserIds
IssuerAndSubject > CertificateUserIds
Subject > CertificateUserIds

Par défaut, Microsoft Entra ID mappe le nom de principal du 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 expliqué précédemment.

Un administrateur de stratégie d’authentification doit activer les nouvelles liaisons. Ils doivent au préalable 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 du cloud uniquement, utilisez le centre d’administration Microsoft Entra ou les API Microsoft Graph pour mettre à jour la valeur de CertificateUserIds.
Pour les utilisateurs synchronisés locaux, utilisez Microsoft Entra Connect pour synchroniser les valeurs en local en suivant les Règles Microsoft Entra Connect ou en synchronisant la valeur AltSecId.

Important

Le format des valeurs Émetteur, Objet et Numérodesérie doivent être dans l’ordre inverse de leur format dans le certificat. N’ajoutez pas d’espace dans Émetteur ou Objet.

Mappage manuel Émetteur et Numéro de série

Voici un exemple de mappage manuel Émetteur et Numéro de série. La valeur Émetteur à ajouter est :

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

Capture d'écran de la valeur Émetteur.

Pour obtenir la valeur correcte pour le numéro de série, exécutez la commande suivante et 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 commande CertUtil :

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 Numérodesérie à ajouter dans CertificateUserId est :

b24134139f069b49997212a86ba0ef48

CertificateUserId :

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

Mappage manuel Émetteur et Objet

Voici un exemple de mappage manuel Émetteur et Objet. La valeur Émetteur est :

Capture d’écran de la valeur Émetteur en cas d’utilisation avec plusieurs liaisons.

La valeur Objet est :

Capture d’écran de la valeur Objet.

CertificateUserId :

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 Objet

Voici un exemple de mappage manuel Objet. La valeur Objet est :

Capture d’écran d’une autre valeur Objet.

CertificateUserId :

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

Test de liaison d’affinité

Connectez-vous au Centre d'administration Microsoft Entra au moins en tant qu’Administrateur de stratégie d’authentification.
Accédez à Protection>Méthodes d’authentification>Stratégies.
Sous Gérer, sélectionnez Méthodes d’authentification>Authentification basée sur les certificats.
Sélectionnez Configurer.
Définir la liaison d’affinité requise au niveau du locataire.

Important

attention au paramètre d’affinité à l’échelle du locataire. Vous pouvez verrouiller l'ensemble du locataire si vous modifiez la liaison d'affinité requise pour le locataire et que vous n'avez pas les valeurs appropriées 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.
Pour faire un test, définissez Liaison d’affinité requise sur Basse.
Ajouter une liaison à haute affinité comme SKI. Sélectionnez Ajouter règle sous Liaison de nom d'utilisateur.
Sélectionnez SKI, puis Ajouter.

Une fois terminée, la règle doit ressembler à celle de la capture d’écran :
Mettre à jour l'attribut CertificateUserIds de tous les objets utilisateurs pour qu'il contienne la valeur correcte du SKI du certificat de l'utilisateur. Pour plus d'informations, voir Modèles pris en charge pour CertificateUserIDs.
Créer une règle personnalisée pour la liaison d’authentification.
Sélectionnez Ajouter.

Une fois terminée, la règle doit ressembler à celle de la capture d’écran :
Mettre à jour les CertificateUserIds de l'utilisateur avec la valeur SKI correcte du certificat avec l'OID de stratégie 9.8.7.5.
Testez avec un certificat avec l'OID de stratégie 9.8.7.5 et l'utilisateur devrait être authentifié avec la liaison SKI et obtenir l'Authentification multifacteur avec seulement le certificat.

Automatiser le CBA à l’aide de l’API Microsoft Graph

Pour activer l’authentification basée sur les certificats et configurer les liaisons de nom d’utilisateur avec l’API Graph, effectuez les étapes suivantes.

Accédez à Microsoft Graph Explorer.
Sélectionnez Vous connecter à Graph Explorer et connectez-vous à votre locataire.
Suivez les étapes pour consentir à l’autorisation déléguée Policy.ReadWrite.AuthenticationMethod.

Obtenez (GET) toutes les méthodes d’authentification :

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

Obtenez (GET) la configuration pour la méthode d’authentification x509 :

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

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

Corps de la requête :

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
        }
    ]
}

Vous obtenez un code de réponse 204 No content. Réexécutez la requête GET pour vous assurer que les stratégies sont correctement mises à jour.
Testez la configuration en vous connectant à l’aide d’un certificat qui répond à la stratégie.

Activer la CBA via Microsoft PowerShell

Ouvrez PowerShell.

Connectez-vous à Microsoft Graph :

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

Créer une variable pour définir un groupe pour les utilisateurs de la CBA :
```
$group = Get-MgGroup -Filter "displayName eq 'CBATestGroup'"
```

Définir le corps de la demande :

$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

Exécuter la requête PATCH :

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

Partager via

Comment configurer l’authentification Microsoft Entra basée sur certificat

Prérequis

Étapes de configuration et de test de Microsoft Entra CBA

Étape 1 : Configurer les autorités de certification avec un magasin de confiance PKI (préversion)

Configurer les autorités de certification via le centre d’administration Microsoft Entra

Créer un objet conteneur PKI

Supprimer un objet conteneur PKI

Charger des CA individuellement dans un objet conteneur PKI

Charger toutes les CA en chargeant la PKI dans un objet conteneur PKI

Modifier une PKI

Modifier une CA

Restaurer une PKI

Restaurer une CA

Comprendre l’attribut isIssuerHintEnabled d’une CA

Configurer des CA via les API Microsoft Graph

Créer un objet conteneur PKI

Obtenir tous les objets PKI

Obtenir un objet PKI avec PKI-id

Charger des CA avec un fichier .p7b

Obtenir toutes les CA d’une PKI

Obtenir une CA spécifique au sein d’une PKI avec CA-id

Mettre à jour un marqueur d’indicateur d’émetteur de CA spécifique

Journal d’audit

FAQ

Étape 2 : Activer l’authentification basée sur les certificats sur le locataire

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

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

Étape 5 : Tester votre configuration

Tester votre certificat

Test des règles de liaison d’authentification personnalisées

Test de stratégie de liaison de nom d’utilisateur

Mappage manuel Émetteur et Numéro de série

Mappage manuel Émetteur et Objet

Mappage manuel Objet

Test de liaison d’affinité

Automatiser le CBA à l’aide de l’API Microsoft Graph

Corps de la requête :

Activer la CBA via Microsoft PowerShell

Étapes suivantes

Commentaires

Ressources supplémentaires