Partager via

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

  • Article

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 participant au programme fournisseur de solutions Cloud (CSP), aux fournisseurs Panneau de configuration (CPV) et aux conseillers doivent implémenter les exigences de sécurité des partenaires pour rester conformes.

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

Certaines pages de l’Espace partenaires sont protégées par MFA, notamment :

  • Toutes les pages sous l’onglet Clients (autrement dit, toutes les pages avec une URL commençant par https://partner.microsoft.com/commerce/*)
  • Toutes les pages sous l’onglet Demandes client du support>technique (par exemple, toutes les pages consultées avec une URL commençant par )https://partner.microsoft.com/dashboard/v2/support/customers/*
  • Toutes les pages de l’onglet Facturation

D’autres pages de l’Espace partenaires, telles que la page Vue d’ensemble et la page De vérification de l’état d’intégrité du service, ne nécessitent pas d’authentification multifacteur.

Le tableau suivant indique quels types d’utilisateurs sont autorisés à accéder à ces pages protégées par l’authentification multifacteur (et qui sont affectés par cette fonctionnalité).

Page protégée par MFA Agents d’administration Agents commerciaux Agents du support technique Administrateur de sécurité Administrateur de facturation
Toutes les pages sous l’onglet Clients x x x
Toutes les pages sous l’onglet Demandes client du support > technique x x
Page Facturation x x x
Espace de travail de sécurité x x

Pour accéder à ces pages, vous devez d’abord effectuer la vérification MFA.

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.

Important

Les partenaires sont tenus d’utiliser un fournisseur d’authentification compatible avec la revendication MFA intégrée de Microsoft Entra ID. La revendication intégrée indique le type d’informations d’identification réel fourni pendant l’authentification. Les partenaires doivent utiliser l’authentification multifacteur intégrée pour gérer les locataires clients avec GDAP.

Espace partenaires et API

Pour les API de l’Espace partenaires suivantes, l’accès app+utilisateur et l’authentification multifacteur microsoft Entra ID sont nécessaires :

  • Découverte (prix/catalogue/promotion)
  • Transaction et gestion
  • Facturation et rapprochement
  • Gestion des clients avec accès délégué/AOBO
  • Attribution d’utilisateurs et de licences (avec DAP uniquement)
  • Attribution d’utilisateurs et de licences (avec GDAP uniquement)
  • Demande de relations d’administration granulaires et attribution d’accès

Les options suivantes sont disponibles pour les partenaires :

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 (qui n’est pas protégée par MFA). 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’une des pages protégées par l’authentification multifacteur dans l’Espace partenaires. Étant donné que Alejandra a effectué la vérification MFA au cours de la connexion plus tôt, Alejandra peut accéder à la page protégée par l’authentification multifacteur sans avoir à 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 (qui n’est pas protégée par MFA). 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’une des pages protégées par authentification multifacteur dans 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 à la page protégée par MFA 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 recommande 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 (qui n’est pas protégée par l’authentification multifacteur). L’Espace partenaires redirige John vers l’ID Microsoft Entra pour vous connecter.

  4. Une fois connecté, John est redirigé vers la page de présentation de l’Espace partenaires, car il n’a pas terminé la vérification MFA.

  5. John tente d’accéder à l’une des pages protégées par authentification multifacteur dans l’Espace partenaires. É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.

  6. Un autre jour, avant que Fabrikam n’implémente l’authentification multifacteur pour tout utilisateur, John démarre une nouvelle session de navigateur et accède à la page de vue d’ensemble de l’Espace partenaires (qui n’est pas protégée par MFA). L’Espace partenaires redirige John vers l’ID Microsoft Entra pour se connecter sans invite MFA.

  7. John tente d’accéder à l’une des pages protégées par authentification multifacteur dans l’Espace partenaires. É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 John a inscrit l’authentification multifacteur, cette fois-ci, il n’a demandé qu’à effectuer la vérification de l’authentification multifacteur.

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 multifacteur pour tous ses utilisateurs sous le locataire partenaire Wingtip à l’aide de l’authentification multifacteur 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 (qui n’est pas protégée par MFA). 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 sera bloqué pour accéder à toutes les pages et API protégées par MFA dans l’Espace partenaires.

Étant donné que Trent accède aux pages protégées par l’authentification multifacteur, il 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.

Nous encourageons vivement les partenaires CSP à implémenter l’authentification multifacteur compatible avec l’ID Microsoft Entra immédiatement pour augmenter la base de référence de sécurité de votre locataire.

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.

Remarque

Le modèle d’application sécurisé est un framework scalable pour l’authentification des partenaires CSP et des CPV par le biais de l’architecture Microsoft Azure MFA lors de l’appel des API de l’Espace partenaires. Vous devez implémenter cette infrastructure lors de l’utilisation de l’authentification multifacteur dans l’automatisation des services.

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.

Remarque

Tous les portails microsoft Online Service ne nécessitent pas que les comptes partenaires se connectent au locataire client lors de l’accès aux ressources client à l’aide de GDAP. Au lieu de cela, certains nécessitent uniquement que les comptes partenaires se connectent au locataire partenaire. Le Centre d’administration Exchange en est un exemple. Au fil du temps, nous nous attendons à ce que ces portails exigent que les comptes partenaires se connectent au locataire client lors de l’utilisation de GDAP.

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 phase de mise en œuvre de l’authentification multifacteur pour ses agents partenaires qui nécessitent un accès aux portails Microsoft Online Services à l’aide des privilèges d’administration déléguée de partenaire pour gérer les ressources client. 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.

Remarque

Même si un partenaire n’a pas implémenté l’authentification multifacteur pour ses agents partenaires, les agents partenaires peuvent toujours accéder aux portails Microsoft Online Services à l’aide des privilèges d’administration délégués du partenaire s’ils peuvent effectuer l’inscription MFA et la vérification MFA lorsqu’ils sont invités lors de la connexion au client. La réalisation de l’inscription MFA ne permet pas automatiquement à l’utilisateur d’utiliser l’authentification multifacteur.

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 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 de privilèges d’administration délégués partenaires pour gérer les ressources client, ils ne seront pas nécessaires pour se connecter au locataire du client. Ils ne seront pas affectés par l’ID Microsoft Entra nécessitant une vérification MFA lors de la connexion au 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 ne nécessitent pas d’accéder à l’Espace partenaires ni aux portails Microsoft Online Services pour gérer les ressources des clients à l’aide des privilèges d’administration délégués 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és partenaires pour gérer les ressources client, ils ne sont pas nécessaires pour se connecter au locataire du client. Ils ne seront pas affectés par l’ID Microsoft Entra nécessitant une vérification MFA lors de la connexion au 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 vous encourageons vivement à implémenter l’authentification multifacteur compatible avec l’ID Microsoft Entra immédiatement pour augmenter la base de référence de sécurité de votre locataire.

Contenu connexe