Partager via


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

Votre organisation peut implémenter l’authentification par hameçonnage, moderne et sans mot de passe via des certificats X.509 utilisateur à l’aide de l’authentification basée sur les certificats Microsoft Entra (CBA).

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 dans les plans Office 365 Enterprise et US Government. 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 l’ID Microsoft Entra.
  • 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 CRL configurée, Microsoft Entra ID n’effectue pas de vérification de liste CRL, 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 en matière de chiffrement Microsoft, notamment le choix de l’algorithme, de la longueur de clé 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, Les points de terminaison Azure et 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 dans Azure et Microsoft 365. Le point de terminaison Microsoft Entra que Microsoft Entra utilise est 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. Il élimine les algorithmes de chiffrement obsolètes, améliore la sécurité sur les versions antérieures et chiffre autant que possible 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 Microsoft Entra permet aux certificats émis par ces autorités de certification d’authentifier n’importe quel utilisateur dans l’ID Microsoft Entra.

    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 illustré 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.

Importante

Microsoft vous recommande d’utiliser des rôles avec le moins d’autorisations. Cette pratique permet d’améliorer la sécurité de votre organisation. Le rôle Administrateur général est hautement privilégié et doit être limité aux scénarios d’urgence ou lorsque vous ne pouvez pas utiliser un autre rôle existant.

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.

Une fois toutes les configurations terminées, activez Microsoft Entra CBA sur le locataire.

Diagramme montrant une vue d’ensemble des étapes requises pour activer l’authentification basée sur des certificats Microsoft Entra.

É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’approbation d’autorité de certification basé sur une infrastructure à clé publique. Le magasin d’approbations conserve les autorités de certification à l’intérieur d’un objet conteneur pour chaque infrastructure à clé publique. Les administrateurs peuvent gérer les autorités de certification dans un conteneur en fonction de l’infrastructure à clé publique plus facilement qu’elles ne peuvent gérer une liste plate d’autorités de certification.

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 d’approbations 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 d’approbations classiques pour configurer des autorités de certification, nous vous recommandons vivement de configurer un magasin d’approbations basé sur une infrastructure à clé publique. 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 d’approbations basé sur une infrastructure à clé publique est attribué au rôle Administrateur d’authentification privilégié .

La fonctionnalité de chargement PKI du magasin d’approbations basé sur l’infrastructure à clé publique est disponible uniquement avec une licence Microsoft Entra ID P1 ou P2. Toutefois, avec la licence gratuite Microsoft Entra, un administrateur peut charger tous les autorités de certification individuellement au lieu de charger un fichier PKI. Ensuite, ils peuvent configurer le magasin d’approbations basé sur l’infrastructure à clé publique et ajouter leurs fichiers d’autorité de certification 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 affecté au rôle Administrateur d’authentification privilégié .

  2. Accédez à l’infrastructuredeclé publique Entra ID >Identity Secure Score>.

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

  4. Pour le nom complet, entrez un nom.

  5. Cliquez sur Créer.

    Diagramme montrant les étapes requises pour créer une infrastructure à clé publique.

  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.

Diagramme montrant les étapes requises pour supprimer une infrastructure à clé publique.

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 l’URL de liste de révocation de certificats, entrez 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, 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 indicateurs d’émetteur, désactivez les indicateurs de l’é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.

    Diagramme montrant comment supprimer un certificat d’autorité de certification.

  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 tous les autorités de certification dans un objet conteneur PKI

Pour charger en bloc tous les autorités de certification dans un conteneur à clé publique :

  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 de point de terminaison de la liste de révocation de certificats d’autorité de certification chargé est mis à jour avec la première URL HTTP disponible du certificat d’autorité de certification répertoriée comme attribut de points de distribution de la liste de révocation de certificats. Vous devez mettre à jour manuellement les certificats 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 de liste de révocation de certificats, l’URL de liste de révocation de certificats delta ou l’indicateur d’indicateur d’émetteur selon vos besoins.
  3. Sélectionnez Enregistrer.

Modifier en bloc l’attribut indicateurs 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 Indicateurs d’émetteur pour toutes les autorités de certification sélectionnées ou désactivez la sélection pour désactiver l’indicateur activé des indicateurs d’émetteur 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 indicateurs d’émetteur renvoient un indicateur d’autorité de certification approuvé dans le cadre de la négociation TLS (Transport Layer Security). 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. 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 isIssuerHintEnabledtrueindicateur de l’émetteur sur .

Le serveur peut renvoyer au client TLS une réponse maximale de 16 Ko pour les indicateurs d’émetteur (le nom de l’objet 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 la valeur 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 des 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 autorités de certification à 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 d’autorité de certification

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

Mettre à jour un indicateur d’indicateur d’émetteur d’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 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
    
  3. Connectez-vous au locataire et acceptez tout :

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

Hiérarchisation entre un magasin d’approbations basé sur une infrastructure à clé publique et un magasin d’autorité de certification classique

Si une autorité de certification existe dans un magasin d’autorité de certification PKI et dans un magasin d’autorité de certification classique, le magasin d’approbations PKI est hiérarchisé.

Un magasin d’autorité de certification classique est hiérarchisé dans ces scénarios :

  • Une autorité de certification existe sur les deux magasins, le magasin PKI n’a pas de liste de révocation de certificats, mais l’autorité de certification du magasin classique a une liste de révocation de certificats valide.
  • Une autorité de certification existe sur les deux magasins, et la liste de révocation de certificats de l’autorité de certification du magasin PKI est différente de la liste de révocation de certificats d’autorité de certification du magasin classique.

Journal de connexion

Une entrée de journal de connexion Microsoft Entra a deux attributs sous Détails supplémentaires pour indiquer si le magasin d’approbations classique ou hérité a été utilisé à tout moment pendant l’authentification.

  • Le magasin hérité utilisé a la valeur 0 pour indiquer qu’un magasin basé sur une infrastructure à clé publique 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é.

Capture d’écran montrant une entrée de journal de connexion pour l’utilisation d’un magasin PKI ou d’un magasin d’autorité de certification classique

Journal d’audit

Toutes les opérations CRUD que vous exécutez sur une infrastructure à clé publique ou une autorité de certification à l’intérieur du magasin d’approbations apparaissent dans les journaux d’audit Microsoft Entra.

Capture d’écran montrant le volet Journaux d’audit.

Migrer d’un magasin d’autorité de certification classique vers un magasin basé sur une infrastructure à clé publique

Un administrateur de locataire peut charger toutes les autorités de certification dans le magasin basé sur l’infrastructure à clé publique. 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é qu’aucune indication dans les journaux de connexion que le magasin classique ou hérité a été utilisé.

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 (250 autorités de certification et 8 Ko pour chaque objet d’autorité de certification).

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 l’administrateur de base de données pour le locataire

Importante

Un utilisateur est considéré comme capable de terminer l’authentification multifacteur lorsque l’utilisateur est désigné comme étant dans l’étendue de l’administrateur de base de données dans la stratégie de méthodes d’authentification. Cette exigence de stratégie signifie qu’un utilisateur ne peut pas utiliser la preuve d’identité dans le cadre de son authentification pour inscrire d’autres méthodes disponibles. Si l’utilisateur n’a pas accès aux certificats, il est verrouillé et ne peut pas inscrire d’autres méthodes pour l’authentification multifacteur. Les administrateurs auxquels le rôle Administrateur de stratégie d’authentification est attribué doivent activer l’administrateur de base de données uniquement pour les utilisateurs disposant de certificats valides. N’incluez pas Tous les utilisateurs pour la CBA. Utilisez uniquement des groupes d’utilisateurs qui ont des certificats valides disponibles. Pour en savoir plus, consultez Utilisation de l’authentification multifacteur Microsoft Entra.

Pour activer l’administrateur CBA via le Centre d’administration Microsoft Entra :

  1. Connectez-vous au Centre d’administration Microsoft Entra avec un compte affecté au moins au rôle 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 à l’authentification par certificatdes méthodes>d’authentificationd’ID> Entra.

  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.

    Capture d’écran montrant comment activer l’administrateur de base de données.

Une fois l’administrateur de base de données activé pour le locataire, tous les utilisateurs du locataire voient l’option permettant de se connecter à l’aide d’un certificat. Seuls les utilisateurs capables d’utiliser l’administrateur de base de données peuvent s’authentifier à l’aide d’un certificat X.509.

Note

L’administrateur réseau doit autoriser l’accès au point de terminaison d’authentification de certificat pour l’environnement cloud de l’organisation en plus du login.microsoftonline.com point de terminaison. 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.

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

Une stratégie de liaison d’authentification permet de définir la force de l’authentification sur un facteur unique ou sur 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 sur le locataire sont définis sur MFA. De même, la liaison d’affinité au niveau du locataire 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.

Importante

Un administrateur doit définir le locataire par défaut sur une valeur applicable à la plupart des certificats. Créez des règles personnalisées uniquement pour des certificats spécifiques qui ont besoin d’un niveau de protection ou d’une liaison d’affinité différent de la valeur par défaut du locataire. Toutes les configurations de méthode d’authentification se trouvent dans le même fichier de stratégie. La création de plusieurs règles redondantes peut dépasser la limite de taille de fichier de stratégie.

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 spécifié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 affecté au moins au rôle Administrateur de stratégie d’authentification.

  2. Accédez aux stratégies desméthodes>d’authentification Entra ID>.

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

    Capture d’écran montrant comment définir une stratégie d’authentification.

  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.

    Capture d’écran montrant comment modifier la stratégie d’authentification par défaut en MFA.

  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 mappent 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, supposons que la valeur par défaut du locataire est l’authentification multifacteur et faible pour la liaison d’affinité.

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

    Capture d’écran montrant comment ajouter une règle personnalisée.

    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 À cocher I Acknowledge pour ajouter la règle.

      Capture d’écran montrant comment mapper une stratégie MFA à une liaison à affinité élevée.

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

    1. Sélectionnez OID de stratégie.

    2. Pour l’OID de stratégie, entrez une valeur.

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

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

    5. Sélectionnez Ajouter.

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

      Capture d’écran montrant le mappage à l’OID de stratégie avec une liaison à faible affinité.

    Pour créer une règle par l’émetteur et l’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.

      Capture d’écran montrant comment sélectionner une liaison à faible affinité.

      Capture d’écran montrant comment ajouter une liaison à faible affinité.

    6. Authentifiez-vous auprès d’un certificat disposant d’un OID de stratégie et 3.4.5.6 émis par CN=CBATestRootProd. Vérifiez que l’authentification passe pour une revendication 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 stratégie exige que tout certificat émis par CN=CBATestRootProd un OID de stratégie ne 1.2.3.4.6 nécessite que la liaison d’affinité élevée. L’émetteur et le numéro de série sont utilisés.

      Capture d’écran montrant l’émetteur et le numéro de série ajoutés dans le Centre d’administration Microsoft Entra.

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

      Capture d’écran montrant comment sélectionner l’émetteur et le numéro de série.

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

      Capture d’écran montrant comment ajouter l’émetteur et le numéro de série.

    4. Sélectionnez Enregistrer.

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

      Capture d’écran montrant les détails du journal de connexion.

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

Importante

Entrez l’OID de stratégie à l’aide du format d’identificateur d’objet. Par exemple, si la stratégie de certificat indique Toutes les stratégies d’émission, entrez l’OID de stratégie 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 n’a aucun 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 d’un utilisateur. Par défaut, pour déterminer l’utilisateur, vous mappez le nom du principal dans le certificat à userPrincipalName 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.

Importante

Si une stratégie de liaison de nom d’utilisateur utilise des attributs synchronisés tels que certificateUserIds, onPremisesUserPrincipalNameet l’attribut userPrincipalName de l’objet utilisateur, les comptes disposant d’autorisations d’administration dans Windows Server Active Directory local peuvent apporter des modifications qui affectent ces attributs dans l’ID Microsoft Entra. Par exemple, les comptes disposant de droits délégués sur des objets utilisateur ou un rôle d’administrateur sur Microsoft Entra Connect Server peuvent apporter ces types de modifications.

  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.

    Capture d’écran montrant une stratégie de liaison de nom d’utilisateur.

    Si le champ de certificat X.509 spécifié se trouve sur le certificat, mais que l’ID Microsoft Entra 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 :

Capture d’écran montrant la configuration finale.

Étape 5 : Tester votre configuration

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

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).

    Capture d’écran montrant le nom d’utilisateur principal.

  2. Sélectionnez Suivant.

    Capture d’écran montrant une connexion à l’aide d’un certificat.

    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.

    Capture d’écran montrant une autre boîte de dialogue de connexion.

  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.

    Capture d’écran montrant l’interface utilisateur du sélecteur de certificats.

  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.
  • L’ID Microsoft Entra est configuré correctement 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 d’objet émetteur avec un niveau de protection d’authentification à facteur unique. Définissez la valeur sur la valeur de votre objet d’autorité de certification.

    Par exemple :

    CN=WoodgroveCA

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

    Capture d’écran montrant la règle OID de stratégie.

  3. Créez une stratégie d’accès conditionnel Microsoft Entra pour que l’utilisateur nécessite l’authentification multifacteur. 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.

    Capture d’écran montrant le nom d’utilisateur principal.

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

    Capture d’écran montrant la connexion à l’aide d’un certificat.

    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.

    Capture d’écran montrant l’autre connexion.

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

    Capture d’écran montrant le sélecteur de client.

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

    Capture d’écran montrant l’émetteur.

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

    Capture d’écran montrant les détails de l’authentification.

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

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

Étant donné que la règle OID de stratégie est prioritaire sur la règle d’émetteur, le certificat satisfait à l’authentification multifacteur.

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 de 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 de nom d’utilisateur :

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

Par défaut, l’ID Microsoft Entra mappe le nom du principal dans le certificat à userPrincipalName 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 :

Importante

Le format des valeurs de l’émetteur, de l’objet et du numéro de série doit être dans l’ordre inverse de son format dans le certificat. N’ajoutez aucun espace dans les valeurs Émetteur ou Objet .

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

Capture d’écran montrant le mappage manuel de la valeur de l’émetteur.

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 :

Capture d’écran montrant la valeur de l’émetteur lorsqu’elle est utilisée avec plusieurs liaisons.

La valeur Objet est la suivante :

Capture d’écran montrant la valeur Subject.

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 :

Capture d’écran montrant une autre valeur Objet.

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 affecté au moins au rôle Administrateur de stratégie d’authentification.

  2. Accédez aux stratégies desméthodes>d’authentification Entra ID>.

  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 d’affinité élevée, les utilisateurs du locataire peuvent être verrouillés.

    Capture d’écran montrant comment définir la liaison d’affinité requise.

  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.

    Capture d’écran montrant comment ajouter une liaison d’affinité.

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

    Capture d’écran montrant une liaison d’affinité terminée.

  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.

    Capture d’écran montrant une liaison d’authentification personnalisée.

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

    Capture d’écran montrant une règle personnalisée.

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

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

Configurer l’administrateur de base de données à l’aide des API Microsoft Graph

Pour configurer l’administrateur de base de données et configurer des liaisons de nom d’utilisateur à l’aide des API Microsoft Graph :

  1. Accédez à l’Afficheur Microsoft Graph.

  2. Sélectionnez Se connecter à l’Explorateur Graph et connectez-vous à votre 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 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
            }
        ]
    }
    
  7. Vérifiez qu’un 204 No content code de réponse retourne. 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’administrateur de base de données à 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"