Imposer l’authentification multifacteur (MFA) à votre locataire partenaire

Rôles appropriés : Agent d’administration | Agent commercial | Agent du support technique | Administrateur de facturation | Administrateur de sécurité

Une meilleure sécurité et des garanties de sécurité et de confidentialité continue sont parmi nos priorités principales, et nous continuons à aider les partenaires à protéger leurs clients et locataires.

Pour aider les partenaires à protéger leurs entreprises et clients contre le vol d’identité et l’accès non autorisé, nous avons activé des protections de sécurité supplémentaires pour les locataires partenaires. Ces garanties garantissent le mandat et vérifient l’authentification multifacteur. L’attribution de l’authentification multifacteur aide les partenaires à sécuriser leur accès aux ressources client contre la compromission des informations d’identification.

Cet article fournit des exemples détaillés et des conseils pour imposer l’authentification multifacteur (MFA) dans l’Espace partenaires.

Les partenaires sont tenus d’appliquer MFA à tous les comptes d’utilisateur de leur locataire partenaire, y compris les utilisateurs invités. Les utilisateurs doivent effectuer la vérification MFA pour les domaines suivants :

• Espace partenaires
• API espace partenaires
• Administration déléguée de partenaire

Options MFA prises en charge

• Partenaires qui utilisent l’authentification multifacteur Microsoft Entra prise en charge par Microsoft. Pour plus d’informations, consultez Plusieurs façons d’activer l’authentification multifacteur Microsoft Entra (MFA prise en charge)
• Partenaires qui ont implémenté l’authentification fédérée MFA intégrée. Ces utilisateurs partenaires sont autorisés à accéder à l’Espace partenaires et à gérer les clients à l’aide de GDAP. Consultez les fournisseurs MFA intégrés avec les offres MFA disponibles avec AD FS : Configurer des méthodes pour AD FS.

Espace partenaires et API

À compter du 1er avril 2026, toute utilisation des API App+User de Partner Center imposera l’utilisation de l’authentification multifacteur.

Les options suivantes sont disponibles pour les partenaires :

• Utilisez les méthodes d’authentification intégrées de Microsoft pour répondre aux exigences de l’authentification multifacteur.
• Si vous utilisez un fournisseur d’identité fédéré, vérifiez que la fédération est configurée pour accepter l’authentification multifacteur fédérée.
• Si vous souhaitez utiliser ADFS pour configurer le deuxième facteur externe, consultez les fournisseurs tiers avec des offres MFA disponibles avec AD FS : Configurer les méthodes d’authentification pour AD FS
• Implémenter l’authentification multifacteur : activez immédiatement l’authentification multifacteur via les paramètres de sécurité par défaut ou l’accès conditionnel en suivant les instructions relatives à la sécurité par défaut.

Pour vous préparer à cette exigence, à partir d’octobre 2025, les API rechercheront le jeton MFA et fourniront la confirmation de sa présence dans la réponse. Pour plus d’informations, consultez Validation des appels d’API intégrés à l’authentification multifacteur.

Exemples de vérification

Pour illustrer le fonctionnement de la vérification dans l’Espace partenaires, tenez compte des exemples suivants.

Exemple 1 : Le partenaire a implémenté l’authentification multifacteur Microsoft Entra

1. Alejandra travaille pour un fournisseur de solutions Cloud nommé Contoso. Contoso a implémenté l’authentification multifacteur pour tous ses utilisateurs sous le locataire partenaire Contoso à l’aide de l’authentification multifacteur Microsoft Entra.

2. Alejandra démarre une nouvelle session de navigateur et accède à la page de vue d’ensemble de l’Espace partenaires. L’Espace partenaires redirige Alejandra vers l’ID Microsoft Entra pour se connecter.

3. En raison de la configuration existante de l’authentification multifacteur Microsoft Entra par Contoso, Alejandra est tenu d’effectuer la vérification MFA. Une fois la connexion réussie et la vérification MFA effectuées, Alejandra est redirigé vers la page de vue d’ensemble de l’Espace partenaires.

4. Alejandra tente d’accéder à l’Espace partenaires. Étant donné que Alejandra a effectué la vérification MFA au cours de la connexion précédemment, Alejandra peut accéder à l’Espace partenaires protégé par l’authentification multifacteur sans être obligé de passer à nouveau par la vérification MFA.

Exemple 2 : Le partenaire a implémenté non-Microsoft MFA à l’aide de la fédération d’identité

1. Prashob travaille pour un CSP nommé Wingtip. Wingtip a implémenté l’authentification multifacteur pour tous ses utilisateurs sous le locataire partenaire Wingtip à l’aide de l’authentification multifacteur non-Microsoft, qui est intégrée à Microsoft Entra ID via la fédération d’identité.

2. Prashob démarre une nouvelle session de navigateur et accède à la page de vue d’ensemble de l’Espace partenaires. L’Espace partenaires redirige Prashob vers l’ID Microsoft Entra pour se connecter.

3. Étant donné que Wingtip a configuré la fédération d’identité, l’ID Microsoft Entra redirige Prashob vers le fournisseur d’identité fédéré pour terminer la connexion et la vérification MFA. Une fois la connexion réussie et la vérification MFA effectuées, Prashob est redirigé vers l’ID Microsoft Entra, puis vers la page de vue d’ensemble de l’Espace partenaires.

4. Prashob tente d’accéder à l’Espace partenaires. Étant donné que Prashob a déjà effectué la vérification MFA au cours de la connexion antérieure, il peut accéder à l’Espace partenaires sans être obligé de passer à nouveau par la vérification MFA.

5. Prashob accède ensuite à la page de gestion des services pour ajouter des utilisateurs dans l’ID Microsoft Entra de Contoso. Étant donné que Prashob a utilisé le fournisseur d’authentification compatible Entra avec une authentification forte, il peut accéder au locataire du client sans aucun problème.

Dans cet exemple, la recommandation de Prashob consiste à utiliser la solution d’authentification multifacteur Microsoft Entra ou un fournisseur d’authentification compatible Entra, afin qu’il puisse gérer correctement le locataire du client.

Exemple 3 : Le partenaire n’a pas implémenté l’authentification multifacteur

1. Un partenaire CSP appelé Fabrikam n’a pas encore implémenté l’authentification multifacteur. Microsoft exige qu’ils implémentent une solution MFA prise en charge par l’ID Microsoft Entra.

2. John travaille pour Fabrikam. Fabrikam n’a pas implémenté l’authentification multifacteur pour les utilisateurs sous le locataire partenaire Fabrikam.

3. John démarre une nouvelle session de navigateur et accède à la page de vue d’ensemble de l’Espace partenaires. L’Espace partenaires redirige John vers l’ID Microsoft Entra pour vous connecter.

4. Étant donné que John n’a pas terminé la vérification MFA, l’Espace partenaires redirige John vers l’ID Microsoft Entra pour effectuer la vérification MFA. Étant donné que c’est la première fois que John est tenu de terminer l’authentification multifacteur, John est également invité à s’inscrire à l’authentification multifacteur. Une fois l’inscription MFA réussie et la vérification MFA effectuées, John peut accéder à la page protégée par MFA.

5. Un autre jour, avant que Fabrikam n’implémente l’authentification multifacteur pour n’importe quel utilisateur, John démarre une nouvelle session de navigateur et accède à la page de présentation de l’Espace partenaires. L’Espace partenaires redirige John vers l’ID Microsoft Entra pour se connecter pour effectuer la vérification MFA. Étant donné que John a déjà enregistré l’authentification multifacteur, cette fois-ci, il lui est simplement demandé de compléter la vérification.

Exemple 4 : Le partenaire a implémenté non-Microsoft MFA qui n’est pas compatible avec Microsoft Entra

1. Trent travaille pour un CSP nommé Wingtip. Wingtip a implémenté l'authentification multifactorielle pour tous ses utilisateurs au sein du locataire partenaire Wingtip, en utilisant l'authentification multifactorielle non-Microsoft dans leur environnement cloud avec accès conditionnel.

2. Trent démarre une nouvelle session de navigateur et accède à la page de vue d’ensemble de l’Espace partenaires. L’Espace partenaires redirige Trent vers l’ID Microsoft Entra pour se connecter.

3. Étant donné que Wingtip a utilisé une intégration non-Microsoft MFA qui n’est pas compatible avec l’ID Microsoft Entra et n’a pas d’authentification forte, Trent est bloqué pour accéder à l’Espace partenaires et à toutes les API de l’Espace partenaires. Trent est tenu de présenter l’authentification multifacteur avec Strong Auth pour accéder aux pages protégées par l’authentification multifacteur.

Les partenaires doivent utiliser un fournisseur d’authentification compatible avec l’ID Microsoft Entra qui prend en charge la revendication de méthode d’informations d’identification (« revendication amr » dans la référence de revendications de jeton d’accès - Plateforme d’identités Microsoft, reflétant le type d’informations d’identification réel fourni pendant l’authentification.

API d’Espace partenaires

L’API de l’Espace partenaires prend en charge à la fois l’authentification d’application uniquement et l’authentification d’application et d’utilisateur (Application+Utilisateur).

Lorsque l’authentification app+utilisateur est utilisée, l’Espace partenaires nécessite la vérification MFA. Plus précisément, lorsqu’une application partenaire envoie une demande d’API à l’Espace partenaires, elle doit inclure un jeton d’accès dans l’en-tête d’autorisation de la demande.

Lorsque l’Espace partenaires reçoit une demande d’API avec un jeton d’accès obtenu à l’aide de l’authentification App+Utilisateur, l’API espace partenaires vérifie la présence de la valeur MFA dans la revendication AMR (Authentication Method Reference). Vous pouvez utiliser un décodeur JWT pour vérifier si un jeton d’accès contient la valeur de référence de méthode d’authentification (AMR) attendue ou non :

{
  "aud": "https://api.partnercenter.microsoft.com",
  "iss": "https://sts.windows.net/df845f1a-7b35-40a2-ba78-6481de91f8ae/",
  "iat": 1549088552,
  "nbf": 1549088552,
  "exp": 1549092452,
  "acr": "1",
  "amr": [
    "pwd",
    "mfa"
  ],
  "appid": "00001111-aaaa-2222-bbbb-3333cccc4444",
  "appidacr": "0",
  "family_name": "Adminagent",
  "given_name": "CSP",
  "ipaddr": "127.0.0.1",
  "name": "Adminagent CSP",
  "oid": "aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb",
  "scp": "user_impersonation",
  "tenant_region_scope": "NA",
  "tid": "aaaabbbb-0000-cccc-1111-dddd2222eeee",
  "unique_name": "Adminagent.csp@testtestpartner.onmicrosoft.com",
  "upn": "Adminagent.csp@testtestpartner.onmicrosoft.com",
  "ver": "1.0"
}

• Si cette valeur est présente, l’Espace partenaires conclut que la vérification MFA a été effectuée et traite la demande d’API.

• Si la valeur n’est pas présente, l’API espace partenaires rejette la demande avec la réponse suivante :

  HTTP/1.1 401 Unauthorized - MFA required
  Transfer-Encoding: chunked
  Request-Context: appId=cid-v1:11112222-bbbb-3333-cccc-4444dddd5555
  WWW-Authenticate: Bearer error="invalid_token"
  Date: Thu, 14 Feb 2019 21:54:58 GMT
  

Lors de l’appel des API de l’Espace partenaires, les jetons d’accès uniquement aux applications sont pris en charge uniquement pour les opérations qui ne nécessitent pas d’attributions de rôles GDAP dans un locataire client.

Pour en savoir plus sur les meilleures pratiques, consultez l’authentification et l’autorisation de l’API - Vue d’ensemble.

Administration déléguée de partenaire

Les locataires partenaires doivent utiliser des privilèges d’administrateur délégué granulaires (GDAP) pour gérer les ressources des clients via les portails Microsoft Online Services (portal.azure.com ou admin.microsoft.com), l’interface de ligne de commande (CLI) et les API (à l’aide de l’authentification app+utilisateur). Pour plus d’informations, consultez les options MFA prises en charge.

Utilisation des portails de service

Les partenaires CSP peuvent administrer leurs clients à partir du portail de l’Espace partenaires via l’interface gestion des services. Les partenaires peuvent accéder au client et sélectionner Gestion des services pour pouvoir administrer un service spécifique pour le client. Les partenaires doivent suivre les instructions du rôle GDAP pour obtenir le rôle GDAP le moins privilégié approprié pour gérer leurs clients.

Lors de l’accès aux portails Microsoft Online Services à l’aide de privilèges d’administrateur délégués partenaires (Admin-On-Behalf-Of) pour gérer les ressources client, la plupart de ces portails nécessitent que le compte partenaire s’authentifie de manière interactive, avec le client Microsoft Entra défini comme contexte d’authentification. Le compte partenaire est requis pour se connecter au locataire du client.

L’authentification Microsoft Entra ID nécessite qu’un utilisateur effectue la vérification MFA s’il existe une stratégie nécessitant l’authentification multifacteur. Il existe deux expériences utilisateur possibles, selon que le compte de partenaire est une identité managée ou fédérée :

• Si le compte partenaire est une identité managée , l’ID Microsoft Entra invite directement l’utilisateur à effectuer la vérification MFA. Si le compte partenaire n’a pas déjà inscrit l’authentification multifacteur avec l’ID Microsoft Entra, l’utilisateur est invité à effectuer l’inscription MFA en premier.

• Si le compte partenaire est une identité fédérée , l’expérience dépend de la façon dont l’administrateur partenaire a configuré la fédération dans Microsoft Entra ID. Lors de la configuration de la fédération dans Microsoft Entra ID, l’administrateur partenaire peut indiquer à Microsoft Entra ID si le fournisseur d’identité fédéré prend en charge MFA ou non.

  • Dans ce cas, Microsoft Entra ID redirige l’utilisateur vers le fournisseur d’identité fédéré pour effectuer la vérification MFA.
  • Si ce n’est pas le cas, Microsoft Entra ID invite directement l’utilisateur à effectuer la vérification MFA. Si le compte partenaire n’a pas déjà inscrit l’authentification multifacteur avec l’ID Microsoft Entra, l’utilisateur est invité à effectuer l’inscription MFA en premier.

L’expérience globale est semblable au scénario dans lequel un client final a implémenté l’authentification multifacteur pour ses administrateurs. Par exemple, le locataire client a activé les paramètres de sécurité Microsoft Entra par défaut, ce qui nécessite que tous les comptes disposant de droits d’administration se connectent au client avec la vérification MFA, y compris les agents d’administration et les agents du support technique.

À des fins de test, les partenaires peuvent activer les paramètres de sécurité Microsoft Entra par défaut dans le client client, puis essayer d’utiliser les privilèges d’administration délégués (GDAP) du partenaire pour accéder au locataire client.

Expérience d’inscription MFA

Lors de la vérification MFA, si le compte partenaire n’a pas déjà été inscrit pour l’authentification multifacteur, Microsoft Entra ID invite l’utilisateur à terminer l’inscription MFA en premier.

Consultez plus d’informations sur la méthode Microsoft Authenticator :

Capture d’écran de la première étape de l’inscription MFA.

Une fois que l’utilisateur a sélectionné Suivant, il est invité à choisir parmi une liste de méthodes de vérification.

Capture d’écran de la deuxième étape de l’inscription MFA.

Une fois l’inscription réussie, l’utilisateur doit effectuer la vérification MFA à l’aide de sa méthode de vérification choisie.

Problèmes courants

Pour comprendre si votre demande est valide, passez en revue la liste des problèmes courants signalés par d’autres partenaires.

Problème 1 : Le partenaire a besoin de plus de temps pour implémenter l’authentification multifacteur pour ses agents partenaires

Un partenaire n’a pas démarré ou est toujours en cours d’implémentation de l’authentification multifacteur (MFA) pour leurs agents de partenaires qui ont besoin d’accéder aux portails des services en ligne Microsoft à l’aide de privilèges granulaires d'administration déléguée pour gérer les ressources des clients. Le partenaire a besoin de plus de temps pour effectuer la mise en œuvre de l’authentification multifacteur. Cela est-il une raison valable pour demander une exception technique ?

Réponse : Non. Un partenaire doit planifier l’implémentation de l’authentification multifacteur pour ses utilisateurs afin d’éviter toute interruption.

Problème 2 : Le partenaire n’a pas implémenté l’authentification multifacteur, car il n’a pas besoin d’accéder à la gestion des clients

Un partenaire dispose de certains utilisateurs de leurs locataires partenaires qui n’ont pas besoin d’accéder aux portails Microsoft Online Services pour gérer les ressources client à l’aide des privilèges d’administration délégués granulaires du partenaire. Le partenaire est en phase de mise en œuvre de l’authentification multifacteur pour ces utilisateurs et il a besoin de plus de temps. Cela est-il une raison valable pour demander une exception technique ?

Réponse : Non. Étant donné que ces comptes d'utilisateur n'utilisent pas les privilèges granulaires de délégation d'administration du partenaire pour gérer les ressources du client, ils n'auront pas besoin de se connecter au tenant du client. Tous les utilisateurs doivent disposer de l’authentification multifacteur pour accéder à l’Espace partenaires ou aux charges de travail client pour gérer les ressources du client.

Problème 3 : Le partenaire n’a pas implémenté l’authentification multifacteur pour les comptes de service utilisateur

Un partenaire a des comptes d’utilisateur dans ses locataires partenaires, qui sont utilisés par les appareils comme comptes de service. Ces comptes à faible privilège n’ont pas besoin d’accéder à l’Espace partenaires ni aux portails Microsoft Online Services pour gérer les ressources client à l’aide des privilèges d’administration délégués granulaires du partenaire. S’agit-il d’une raison valable pour une exception technique ?

Réponse : Non. Étant donné que ces comptes d’utilisateur n’utilisent pas de privilèges d'administration déléguée granulaires par le partenaire pour gérer les ressources client, il n'est pas nécessaire qu'ils se connectent au locataire du client. Si l’API ou le portail a requis l’authentification utilisateur+application+ utilisateur, chaque utilisateur est tenu d’utiliser l’authentification MFA.

Problème 4 : Le partenaire ne peut pas implémenter l’authentification multifacteur à l’aide de l’application Microsoft Authenticator

Un partenaire a une politique de « bureau propre », qui ne permet pas aux employés d’apporter leurs appareils mobiles personnels à leur domaine de travail. Sans accéder à leurs appareils mobiles personnels, les employés ne peuvent pas installer l’application Microsoft Authenticator, qui est la seule vérification MFA prise en charge par les paramètres de sécurité Microsoft Entra par défaut. Cela est-il une raison valable pour demander une exception technique ?

Réponse : Non. Le partenaire doit envisager l’alternative suivante afin que ses employés puissent toujours effectuer la vérification MFA lors de l’accès à l’Espace partenaires :

• Le partenaire peut également s’inscrire à l’ID Microsoft Entra P1 ou P2, ou utiliser des solutions MFA non-Microsoft compatibles avec l’ID Microsoft Entra qui peuvent fournir davantage de méthodes de vérification. Pour plus d’informations, consultez les méthodes d’authentification prises en charge.

Problème 5 : Le partenaire ne peut pas implémenter l’authentification multifacteur en raison de l’utilisation de protocoles d’authentification hérités

Un partenaire a des agents partenaires qui utilisent encore des protocoles d’authentification hérités, qui ne sont pas compatibles avec l’authentification multifacteur. Par exemple, les utilisateurs utilisent encore Outlook 2010, qui est basé sur des protocoles d’authentification hérités. L’activation de l’authentification multifacteur pour ces agents partenaires perturbera l’utilisation des protocoles d’authentification hérités. Cela est-il une raison valable pour demander une exception technique ?

Réponse : Non. Les partenaires sont encouragés à s’éloigner de l’utilisation des protocoles d’authentification hérités en raison d’implications de sécurité potentielles, car ces protocoles ne peuvent pas être protégés par la vérification MFA et sont beaucoup plus vulnérables à la compromission des informations d’identification. Nous vous recommandons de déprécier toute authentification héritée et d’utiliser les paramètres de sécurité par défaut ou l’accès conditionnel. Pour vous préparer à quitter l’authentification héritée, passez en revue les connexions à l’aide du classeur d’authentification hérité et des instructions sur la façon de bloquer l’authentification héritée.

Pour comprendre le dernier plan de prise en charge de l’authentification héritée pour Outlook, lisez le billet sur l’authentification de base et Exchange Online et suivez le blog de l’équipe Exchange pour obtenir les nouvelles à venir.

Problème 6 : Le partenaire a implémenté une authentification multifacteur non-Microsoft qui n’est pas reconnue par l’ID Microsoft Entra

Un partenaire a implémenté l’authentification multifacteur pour ses utilisateurs à l’aide d’une solution MFA non-Microsoft. Toutefois, le partenaire ne parvient pas à configurer correctement la solution MFA non-Microsoft pour relayer à Microsoft Entra ID que la vérification MFA a été effectuée lors de l’authentification utilisateur. Cela est-il une raison valable pour demander une exception technique ?

Réponse : Non, les partenaires doivent utiliser un fournisseur d’authentification compatible avec l’ID Microsoft Entra qui prend en charge la revendication de méthode d’identification (« AMR »), référence de revendications de jeton d’accès - Plateforme d’identités Microsoft, reflétant le type d’informations d’identification réel fourni lors de l’authentification.

Nous demandons aux partenaires d’implémenter une solution MFA compatible avec l’ID Microsoft Entra pour éviter toute interruption.

Contenu connexe

• État des exigences de sécurité des partenaires