Utiliser Microsoft Entra MFA avec un fournisseur externe (préversion)

Cet article décrit comment un fournisseur d’authentification externe se connecte à l’authentification multifacteur Microsoft Entra (MFA).

Lorsqu’un utilisateur se connecte, les stratégies de locataire sont évaluées. Les exigences d’authentification sont déterminées en fonction de la ressource à laquelle l’utilisateur tente d’accéder.

Plusieurs stratégies peuvent s’appliquer à la connexion, en fonction de leurs paramètres. Ces paramètres incluent les utilisateurs et les groupes, les applications, la plateforme, le niveau de risque de connexion, etc.

En fonction des exigences d’authentification, l’utilisateur peut avoir besoin de se connecter avec un autre facteur pour répondre aux exigences de l’authentification multifacteur. Le type du deuxième facteur doit compléter le type de premier facteur.

L’administrateur du locataire ajoute des méthodes d’authentification externes à l’ID Microsoft Entra. Si un locataire nécessite une méthode d’authentification externe pour l’authentification multifacteur, la connexion est considérée comme conforme à la condition MFA après que l’ID Microsoft Entra valide les deux :

• Premier facteur accompli avec l’ID Microsoft Entra.
• Le deuxième facteur a été terminé avec la méthode d’authentification externe.

Cette validation répond à l’exigence MFA pour deux types de méthodes ou plus :

• Quelque chose que vous connaissez (connaissance)
• Quelque chose que vous avez (possession)
• Quelque chose que vous êtes (inhérence)

Les méthodes d’authentification externes sont implémentées sur OpenID Connect (OIDC). Cette implémentation nécessite au moins trois points de terminaison accessibles publiquement pour implémenter une méthode d’authentification externe :

• Un point de terminaison de découverte OIDC, comme décrit dans Découverte des métadonnées du fournisseur
• Un point de terminaison d’authentification OIDC valide
• Une URL dans laquelle les certificats publics du fournisseur sont publiés

Voici comment la connexion fonctionne avec une méthode d’authentification externe :

1. Un utilisateur tente de se connecter avec un premier facteur, comme un mot de passe, à une application protégée par Microsoft Entra ID.

2. Microsoft Entra ID détermine qu’un autre facteur doit être satisfait (par exemple, si une stratégie d’accès conditionnel requiert l’authentification multifacteur).

3. L’utilisateur choisit la méthode d’authentification externe comme deuxième facteur.

4. Microsoft Entra ID redirige la session de navigateur de l’utilisateur vers l’URL de la méthode d’authentification externe.

   Cette URL est découverte à partir de l’URL de découverte provisionnée par un administrateur lors de la création de la méthode d’authentification externe.

   L’application fournit un jeton expiré ou presque expiré, qui contient des informations permettant d’identifier l’utilisateur et le tenant.

5. Le fournisseur d’authentification externe valide le fait que le jeton provient de Microsoft Entra ID et vérifie le contenu du jeton.

6. Le fournisseur d’authentification externe peut appeler Microsoft Graph pour récupérer des informations supplémentaires sur l’utilisateur.

7. Le fournisseur d’authentification externe effectue toutes les actions qu’il juge nécessaires, telles que l’authentification de l’utilisateur avec des informations d’identification.

8. Le fournisseur d’authentification externe redirige l’utilisateur vers Microsoft Entra ID avec un jeton valide, y compris toutes les déclarations requises.

9. Microsoft Entra ID valide le fait que la signature du jeton provient du fournisseur d’authentification externe configuré, puis vérifie le contenu du jeton.

10. Microsoft Entra ID valide le jeton par rapport aux exigences.

11. Si la validation réussit, cela signifie que l’utilisateur a satisfait à l’exigence de l’authentification multifacteur. L’utilisateur peut également avoir à répondre à d’autres exigences de stratégie.

Configuration d’un nouveau fournisseur d’authentification externe avec Microsoft Entra ID

Pour émettre id_token_hint, les méthodes d’authentification externes ont besoin d’une application qui représente l’intégration. Vous pouvez créer l’application de deux façons :

• Dans chaque locataire qui utilise le fournisseur externe.
• En tant qu’application mutualisée. Pour activer l’intégration pour son locataire, les administrateurs de rôles privilégiés doivent accorder leur consentement.

L'utilisation d'une application mutualisée peut réduire le risque de mauvaise configuration dans chaque client. Les fournisseurs peuvent également apporter des modifications aux métadonnées (par exemple, les URL de réponse à un emplacement unique) plutôt que demander à chaque locataire d’apporter les modifications.

Pour configurer une application multitenant, l’administrateur du fournisseur doit d’abord :

1. Créez une instance Microsoft Entra ID (s'ils n'en ont pas déjà une).

2. Inscrire une application dans leur tenant.

3. Dans l’application, sous Types de comptes pris en charge, sélectionnez Comptes dans n’importe quel répertoire organisationnel (n'importe quel locataire Microsoft Entra ID - Multilocataire).

4. Ajoutez les valeurs d'autorisation déléguée openid et profile pour Microsoft Graph.

5. Ne publier aucune étendue dans cette application.

6. Ajoutez les URL valides authorization_endpoint du fournisseur d’identité externe à cette application en tant qu’URL de réponse.

   Remarque

   Dans l’inscription de l’application, ajoutez la valeur authorization_endpoint fournie dans le document de découverte du fournisseur en tant qu’URL de redirection. Sinon, vous obtenez l’erreur suivante : « ENTRA IDSTS50161 : Échec de la validation de l’URL d’autorisation du fournisseur de revendications externes ! »

Le processus d’inscription d’application crée une application avec plusieurs propriétés. Vous avez besoin de ces propriétés pour notre scénario.

Un autre modèle valide pour la prise en charge de l’intégration consiste à utiliser une application pour chaque locataire. Si vous utilisez une inscription à tenant unique, l’administrateur du tenant doit créer une inscription d’application avec les propriétés du tableau précédent pour une application à tenant unique.

Configurer des revendications facultatives

Un fournisseur peut configurer davantage de déclarations en utilisant des déclarations facultatives pour id_token.

Ajout d’une méthode d’authentification externe à l’ID Microsoft Entra

Les informations du fournisseur d’identité externe sont stockées dans la stratégie de méthodes d’authentification de chaque locataire. Les informations du fournisseur sont stockées en tant que méthode d’authentification du type externalAuthenticationMethodConfiguration.

Chaque fournisseur a une entrée dans l’objet de liste de la stratégie. Chaque entrée doit déclarer :

• Si la méthode est activée.
• Groupes inclus qui peuvent utiliser la méthode.
• Groupes exclus qui ne peuvent pas utiliser la méthode.

Pour définir l’exigence MFA pour la connexion des utilisateurs, les utilisateurs disposant du rôle Administrateur d'accès conditionnel peuvent créer une stratégie avec l'autorisation Exiger MFA. Les méthodes d’authentification externes ne sont actuellement pas prises en charge par les forces d’authentification.

En savoir plus sur l’ajout d’une méthode d’authentification externe dans le Centre d’administration Microsoft Entra.

Interaction entre Microsoft Entra ID et le fournisseur

Les sections suivantes expliquent les exigences du fournisseur et incluent des exemples pour savoir comment Microsoft Entra ID interagit avec un fournisseur.

Découverte des métadonnées du fournisseur

Un fournisseur d’identité externe doit fournir un point de terminaison de découverte OIDC. Ce point de terminaison est utilisé pour obtenir plus de données de configuration.

L’URL de découverte doit utiliser le https schéma et doit se terminer par /.well-known/openid-configuration. Vous ne pouvez pas inclure de segments de chemin d’accès supplémentaires, de chaînes de requête ou de fragments après ce segment. L’URL de découverte complète doit être incluse dans l’URL de découverte que vous configurez lorsque vous créez la méthode d’authentification externe.

Le point de terminaison retourne un document JSON de métadonnées de fournisseur hébergé là-bas. Le point de terminaison doit également retourner un en-tête de longueur de contenu valide. Le document de métadonnées doit se conformer à OpenID Connect Discovery 1.0 (incorporant errata set 2) et inclure tous les champs de métadonnées OIDC requis.

Les métadonnées du fournisseur doivent inclure les données répertoriées dans le tableau suivant. Ces valeurs sont requises pour ce scénario d’extensibilité. Le document de métadonnées JSON peut contenir plus d’informations.

Pour le document OIDC qui a les valeurs des métadonnées du fournisseur, consultez Métadonnées du fournisseur.

https://customcaserver.azurewebsites.net/v2.0/.well-known/openid-configuration
{
  "authorization_endpoint": "https://customcaserver.azurewebsites.net/api/Authorize",
  "claims_supported": [
    "email"
  ],
  "grant_types_supported": [
    "implicit"
  ],
  "id_token_signing_alg_values_supported": [
    "RS256"
  ],
  "issuer": "https://customcaserver.azurewebsites.net/v2.0",
  "jwks_uri": "https://customcaserver.azurewebsites.net/.well-known/jwks",
  "response_modes_supported": [
    "form_post"
  ],
  "response_types_supported": [
    "id_token"
  ],
  "scopes_supported": [
    "openid"
  ],
  "SigningKeys": [],
  "subject_types_supported": [
    "public"
  ]
}

https://customcaserver.azurewebsites.net/.well-known/jwks
{
  "keys": [
    {
      "kty": "RSA",
      "use": "sig",
      "kid": "A1bC2dE3fH4iJ5kL6mN7oP8qR9sT0u",
      "x5t": "A1bC2dE3fH4iJ5kL6mN7oP8qR9sT0u",
      "n": "jq277LRoE6WKM0awT3b...vt8J6MZvmgboVB9S5CMQ",
      "e": "AQAB",
      "x5c": [
        "cZa3jz...Wo0rzA="
      ]
    }
  ]
}

Exemples d’URL de découverte et d’émetteur

Les exemples suivants illustrent des combinaisons d’URL de découverte et d’émetteur valides et non valides pour cette intégration.

URL de découverte et paires d’émetteurs valides

• URL de découverte : https://example.com/.well-known/openid-configuration
  Émetteur : https://example.com
• URL de découverte : https://example.com:8443/.well-known/openid-configuration
  Émetteur : https://example.com:8443
• URL de découverte : https://example.com/tenant1/.well-known/openid-configuration
  Émetteur : https://example.com/tenant1

Exemples d’URL de découverte et d’émetteur non valides

• URL de découverte : https://example.com/.well-known/openid-configuration
  Émetteur : https://example.com:443/ (Port HTTPS par défaut explicitement ajouté dans l’émetteur.)
• URL de découverte : https://example.com:443/.well-known/openid-configuration
  Émetteur : https://example.com/ (Incompatibilité de port.)
• URL de découverte : https://example.com/.well-known/openid-configuration?client_id=0oasxuxkghOniBjlQ697
  Émetteur : https://example.com (Vous ne pouvez pas inclure de chaîne de requête dans une URL de découverte.)

Mise en cache des métadonnées du fournisseur

Pour améliorer les performances, Microsoft Entra ID met en cache les métadonnées retournées par le fournisseur, y compris les clés. La mise en cache des métadonnées du fournisseur empêche un appel de découverte chaque fois que l’ID Microsoft Entra communique avec un fournisseur d’identité externe.

Ce cache est actualisé toutes les 24 heures. Nous recommandons aux fournisseurs de suivre ces étapes pour renouveler leurs clés :

1. Publiez le certificat existant et le nouveau certificat dans jwks_uri.
2. Continuez à vous connecter avec le certificat existant jusqu’à ce que le cache d’ID Microsoft Entra soit actualisé, expiré ou mis à jour (tous les 2 jours).
3. Basculez vers la connexion avec New Cert.

Nous ne publions pas de planifications pour les effets de substitution de clés. Le service dépendant doit être prêt à gérer les effets de substitution immédiats et périodiques. Nous vous suggérons d’utiliser une bibliothèque dédiée créée à cet effet, comme azure-activedirectory-identitymodel-extensions-for-dotnet. Pour plus d’informations, consultez Effet de substitution de clé de signature dans Microsoft Entra ID.

Découverte des métadonnées Microsoft Entra ID

Les fournisseurs doivent également récupérer les clés publiques de Microsoft Entra ID pour valider les jetons émis par Microsoft Entra ID.

Points de terminaison de découverte des métadonnées Microsoft Entra ID :

• Azure global : https://login.microsoftonline.com/common/v2.0/.well-known/openid-configuration
• Azure pour le gouvernement des États-Unis : https://login.microsoftonline.us/common/v2.0/.well-known/openid-configuration
• Microsoft Azure géré par 21Vianet : https://login.partner.microsoftonline.cn/common/v2.0/.well-known/openid-configuration

Vous pouvez utiliser l’identificateur de clé publique à partir du jeton (le « kid » de la signature web JSON (JWS)) pour déterminer quelles clés récupérées à partir de la jwks_uri propriété doivent être utilisées pour valider la signature du jeton d’ID Microsoft Entra.

Validation des jetons émis par Microsoft Entra ID

Pour plus d’informations sur la validation des jetons émis par l’ID Microsoft Entra, consultez Valider un jeton d’ID. Il n’existe aucune étape spéciale pour les consommateurs de nos métadonnées de découverte.

Vous trouverez tous les détails sur la validation des jetons dans la bibliothèque de validation de jetons de Microsoft. Vous pouvez également vérifier ces détails en parcourant le code source. Pour un exemple, consultez Exemples Azure.

Une fois la validation réussie, vous pouvez utiliser la charge utile des revendications pour obtenir des détails sur l’utilisateur et son locataire.

Appel de Microsoft Entra ID au fournisseur d’identité externe

Microsoft Entra ID utilise le flux implicite OIDC pour communiquer avec le fournisseur d’identité externe. Lorsque vous utilisez ce flux, la communication avec le fournisseur se produit à l’aide uniquement du point de terminaison d’autorisation du fournisseur.

Pour informer le fournisseur de l’utilisateur pour lequel l’ID Microsoft Entra effectue la requête, l’ID Microsoft Entra transmet un jeton via le id_token_hint paramètre.

Cet appel est effectué par le biais d’une POST requête, car une grande liste de paramètres est transmise au fournisseur. Une liste volumineuse empêche l’utilisation de navigateurs qui limitent la longueur d’une GET requête.

Les paramètres de demande d’authentification sont répertoriés dans le tableau suivant.

Exemple d’URI de redirection

Les URI de redirection doivent être inscrits auprès du fournisseur hors bande. Les URI de redirection que vous pouvez envoyer sont les suivants :

• Azure global : https://login.microsoftonline.com/common/federation/externalauthprovider
• Azure pour le gouvernement des États-Unis : https://login.microsoftonline.us/common/federation/externalauthprovider
• Microsoft Azure géré par 21Vianet : https://login.partner.microsoftonline.cn/common/federation/externalauthprovider

Exemple de méthode d’authentification externe qui satisfait à l’authentification multifacteur

Voici un exemple où une méthode d’authentification externe répond aux exigences MFA. Cet exemple aide un fournisseur à connaître les revendications attendues par Microsoft Entra ID.

Microsoft Entra ID utilise la combinaison des valeurs acr et amr pour valider ce qui suit :

• La méthode d’authentification utilisée pour le deuxième facteur satisfait aux exigences de l’authentification multifacteur.
• La méthode d’authentification est un type différent de la méthode utilisée pour terminer le premier facteur de connexion à l’ID Microsoft Entra.

{
  "id_token": {
    "acr": {
      "essential": true,
      "values":["possessionorinherence"]
    },
    "amr": {
      "essential": true,
      "values": ["face", "fido", "fpt", "hwk", "iris", "otp", "pop", "retina", "sc", "sms", "swk", "tel", "vbm"]
    }
  }
}

Revendications de id_token_hint par défaut

Cette section décrit le contenu requis du jeton passé comme id_token_hint dans la demande adressée au fournisseur. Le jeton peut contenir plus de revendications que le tableau suivant.

Pour empêcher l’utilisation du jeton pour n’importe quoi d’autre qu’un indicateur, il est émis dans l’état expiré. Le jeton est signé et peut être vérifié à l’aide des métadonnées de découverte d’ID Microsoft Entra publiées.

Revendications facultatives de Microsoft Entra ID

Si un fournisseur a besoin de revendications facultatives à partir de l’ID Microsoft Entra, vous pouvez configurer les revendications facultatives suivantes pour id_token: given_name, , family_name, preferred_username. upn Pour plus d’informations, consultez Revendications facultatives.

Utilisation recommandée des revendications

Nous vous recommandons d’associer des comptes côté fournisseur au compte dans Azure à l’aide des revendications oid et tid. Ces deux revendications sont garanties pour être uniques pour le compte dans le tenant.

Exemple d'id_token_hint

Voici un exemple pour un membre de l'annuaire id_token_hint :

{
  "typ": "JWT",
  "alg": "RS256",
  "kid": "C2dE3fH4iJ5kL6mN7oP8qR9sT0uV1w"
}.{
  "ver": "2.0",
  "iss": "https://login.microsoftonline.com/aaaabbbb-0000-cccc-1111-dddd2222eeee/v2.0",
  "sub": "mBfcvuhSHkDWVgV72x2ruIYdSsPSvcj2R0qfc6mGEAA",
  "aud": "00001111-aaaa-2222-bbbb-3333cccc4444",
  "exp": 1536093790,
  "iat": 1536093791,
  "nbf": 1536093791,
  "name": "Test User 2",
  "preferred_username": "testuser2@contoso.com"
  "oid": "aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb",
  "tid": "aaaabbbb-0000-cccc-1111-dddd2222eeee"
  }.

Voici un exemple pour un utilisateur invité id_token_hint dans le client :

{
  "typ": "JWT",
  "alg": "RS256",
  "kid": "C2dE3fH4iJ5kL6mN7oP8qR9sT0uV1w"
}.{
  "ver": "2.0",
  "iss": "https://login.microsoftonline.com/9122040d-6c67-4c5b-b112-36a304b66dad/v2.0",
  "sub": "mBfcvuhSHkDWVgV72x2ruIYdSsPSvcj2R0qfc6mGEAA",
  "aud": "00001111-aaaa-2222-bbbb-3333cccc4444",
  "exp": 1536093790,
  "iat": 1536093791,
  "nbf": 1536093791,
  "name": "External Test User (Hotmail)",
  "preferred_username": "externaltestuser@hotmail.com",
  "oid": "aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb",
  "tid": "aaaabbbb-0000-cccc-1111-dddd2222eeee"
  }.

Actions suggérées pour les fournisseurs d’identité externes

Nous recommandons que les fournisseurs d’identité externes accomplissent les tâches suivantes. La liste n’est pas exhaustive et les fournisseurs doivent effectuer d’autres étapes de validation comme ils le pensent approprié.

• D'après la demande :

  • Vérifiez que le redirect_uri est publié comme décrit dans la requête à l’ID Microsoft Entra au fournisseur d’identité externe.
  • Vérifiez que l’URL de découverte configurée utilise HTTPS et se termine par /.well-known/openid-configuration. Vérifiez également qu’il n’inclut pas les paramètres de requête ou les identificateurs de fragment. Assurez-vous que la valeur de l’émetteur correspond exactement au document de découverte.
  • Assurez-vous qu’une valeur est attribuée à l’ID Microsoft Entra, par exemple ABCD.
  • Le fournisseur doit d’abord valider l’ID id_token_hint Microsoft Entra qui lui est présenté.

• D'après les revendications dans les id_token_hint:

  • (Facultatif) Appelez Microsoft Graph pour récupérer d’autres détails sur cet utilisateur. Les revendications oid et tid dans id_token_hint sont utiles à cet égard. Pour plus d’informations sur les revendications fournies dans id_token_hint, consultez Revendications par défautid_token_hint.

• Effectuez toute autre activité d’authentification pour le produit du fournisseur.

• En fonction du résultat des actions de l’utilisateur et d’autres facteurs, le fournisseur construit et renvoie une réponse à l’ID Microsoft Entra, comme expliqué dans la section suivante.

Traitement par Microsoft Entra ID de la réponse du fournisseur

Le fournisseur doit utiliser POST pour renvoyer une réponse au redirect_uri. Les paramètres suivants doivent être fournis dans une réponse réussie :

En cas de réussite, le fournisseur émet alors une id_token valeur pour l’utilisateur. Microsoft Entra ID utilise les métadonnées OIDC publiées pour vérifier que le jeton contient les revendications attendues et effectue toute autre validation de jeton requise par OIDC.

Revendications acr prises en charge

Revendications amr prises en charge

Microsoft Entra ID exige que l'authentification multifacteur (MFA) soit remplie pour émettre un jeton contenant des revendications MFA. Par conséquent, seules les méthodes avec un type différent peuvent satisfaire la deuxième exigence de facteur. Comme mentionné précédemment, les différents types de méthodes qui peuvent être utilisés pour satisfaire le deuxième facteur sont la connaissance, la possession et l’inhérence.

Microsoft Entra ID valide le mappage de type en fonction du tableau suivant.

Microsoft Entra ID considère que l’authentification multifacteur est satisfaite si aucun problème n’est trouvé avec le jeton et émet un jeton à l’utilisateur. Sinon, la demande de l’utilisateur échoue.

L’échec est indiqué par l’émission de paramètres de réponse d’erreur.

Microsoft Entra ID considère la requête réussie si id_token parameter est présent dans la réponse et si le jeton est valide. Sinon, la requête est considérée comme ayant échoué. Microsoft Entra ID échoue la tentative d’authentification d’origine en raison de l’exigence de la stratégie d’accès conditionnel.

Microsoft Entra ID abandonne unilatéralement l’état de la tentative d’authentification au bout d’environ 5 minutes après avoir effectué la redirection au fournisseur.

Gestion de la réponse aux erreurs d’ID Microsoft Entra

Les services Microsoft Azure utilisent une correlationId valeur pour mettre en corrélation les appels entre différents systèmes internes et externes. Il sert d’identificateur commun de l’ensemble de l’opération ou du flux qui implique potentiellement plusieurs appels HTTP. Lorsqu’une erreur se produit pendant l’une des opérations, la réponse contient un champ nommé ID de corrélation.

Lorsque vous contactez le support Microsoft ou un service similaire, fournissez la valeur d’ID de corrélation . Il permet d’accéder aux données de télémétrie et aux logs plus rapidement.

Par exemple :

ENTRA IDSTS70002: Error validating credentials. ENTRA IDSTS50012: External ID token from issuer 'https://sts.XXXXXXXXX.com/auth/realms/XXXXXXXXXmfa' failed signature verification. KeyID of token is 'A1bC2dE3fH4iJ5kL6mN7oP8qR9sT0u'

Trace ID: 0000aaaa-11bb-cccc-dd22-eeeeee333333

Correlation ID: aaaa0000-bb11-2222-33cc-444444dddddd

Timestamp: 2023-07-24 16:51:34Z

Contrôles personnalisés et méthodes d’authentification externe

Dans Microsoft Entra ID, les méthodes d’authentification externe et les contrôles personnalisés d’accès conditionnel peuvent fonctionner en parallèle tandis que les clients préparent et migrent vers des méthodes d’authentification externes.

Les clients qui utilisent actuellement une intégration à un fournisseur externe à l’aide de contrôles personnalisés peuvent continuer à les utiliser, de même que toutes les stratégies d’accès conditionnel qu’ils ont configurées pour gérer l’accès. Nous vous recommandons de créer un ensemble parallèle de stratégies d’accès conditionnel pendant la période de migration :

• Les stratégies doivent utiliser le contrôle d’octroi Exiger l’authentification multifacteur au lieu de l’octroi de contrôle personnalisé.

  Remarque

  Les contrôles d'autorisation basés sur les niveaux ou forces d’authentification, y compris la force MFA intégrée, ne sont pas respectés par la méthode d’authentification externe. Les stratégies ne doivent être configurées qu’avec Exiger l’authentification multifacteur.

• La nouvelle stratégie peut d’abord être testée avec un sous-ensemble d’utilisateurs. Le groupe de tests est exclu de la stratégie qui nécessite des contrôles personnalisés, et inclus dans la stratégie qui requiert l’authentification multifacteur. Lorsque l’administrateur est à l’aise que la stratégie qui nécessite l’authentification multifacteur est satisfaite par la méthode d’authentification externe, l’administrateur peut inclure tous les utilisateurs requis dans la stratégie avec l’octroi MFA. La stratégie configurée pour les contrôles personnalisés peut être déplacée vers le paramètre Désactivé .

Prise en charge de l’intégration

Si vous rencontrez des problèmes lorsque vous créez une intégration de méthode d’authentification externe à l’ID Microsoft Entra, l’éditeur de solutions indépendantes (ISV) Microsoft Customer Experience Engineering (CxE) peut être en mesure d’aider. Pour contacter l’équipe ISV CxE, envoyez une demande d’assistance.

Références

• Spécification OAuth2.0 et OIDC

Glossaire

Contenu connexe

• Pour plus d’informations sur la configuration d’une méthode d’authentification externe dans le Centre d’administration Microsoft Entra, consultez Gérer une méthode d’authentification externe dans Microsoft (préversion).