Partager via

Planification de l’authentification multifacteur obligatoire pour Azure et d'autres portails d’administration

Chez Microsoft, nous nous engageons à offrir à nos clients le plus haut niveau de sécurité. L’une des mesures de sécurité les plus efficaces à leur disposition est l’authentification multifacteur (MFA). Les recherches effectuées par Microsoft montrent que l’authentification multifacteur peut bloquer plus de 99,2% d’attaques de compromission de compte.

C’est pourquoi, à compter de 2024, nous appliquerons l’authentification multifacteur obligatoire pour toutes les tentatives de connexion Azure. Pour plus d’informations sur cette exigence, consultez notre billet de blog . Cette rubrique présente les applications et comptes concernés, la manière dont cette mesure sera déployée au sein des locataires, ainsi que les réponses aux questions fréquentes.

Importante

Si un utilisateur ne peut pas se connecter à Azure et à d’autres portails d’administration après le lancement de l’authentification multifacteur obligatoire, un administrateur général peut exécuter un script pour reporter l’exigence MFA et autoriser les utilisateurs à se connecter. Pour plus d’informations, consultez Comment reporter l'application de la mesure pour un locataire lorsque les utilisateurs ne peuvent pas se connecter après le lancement de l’exigence d’authentification multifacteur obligatoire (MFA) pour le portail Azure, le Centre d’administration Microsoft Entra ou le Centre d’administration Microsoft Intune.

Aucun changement n’est à prévoir pour les utilisateurs si votre organisation applique déjà l’authentification multifacteur ou s’ils se connectent à l’aide de méthodes plus sécurisées, comme l’authentification sans mot de passe ou les clés d’accès (FIDO2). Pour vérifier que l’authentification multifacteur est activée, consultez Comment vérifier que les utilisateurs sont configurés pour l’authentification multifacteur obligatoire.

Périmètre de la mise en application

L'étendue de l'exécution inclut les applications pour lesquelles l'application de l'authentification multifacteur est prévue, les applications hors du champ d'application, quand l'application est prévue, et quels comptes ont une exigence obligatoire d'authentification multifacteur.

Applications logicielles

Remarque

La date d’application de la phase 2 a changé au 1er septembre 2025.

Le tableau suivant répertorie les applications, les ID d’application et les URL affectés pour Azure.

Nom de l’application ID d’application Début de la mise en application
Portail Azure c44b4083-3bb0-49c1-b47d-974e53cbdf3c Deuxième semestre 2024
Centre d’administration Microsoft Entra c44b4083-3bb0-49c1-b47d-974e53cbdf3c Deuxième semestre 2024
Centre d’administration Microsoft Intune c44b4083-3bb0-49c1-b47d-974e53cbdf3c Deuxième semestre 2024
Interface de ligne de commande Azure (Azure CLI) 04b07795-8ddb-461a-bbee-02f9e1bf7b46 1er septembre 2025
Azure PowerShell 1950a258-227b-4e31-a9cf-717495945fc2 1er septembre 2025
Azure mobile app 0c1307d4-29d6-4389-a11c-5cbe7f65d7fa 1er septembre 2025
Outils IaC (Infrastructure as Code) Utilisent les ID Azure CLI ou Azure PowerShell 1er septembre 2025
API REST (plan de contrôle) N/A 1er septembre 2025
Kit de développement logiciel (SDK) Azure N/A 1er septembre 2025

Le tableau suivant répertorie les applications et URL affectées pour Microsoft 365.

Nom de l’application URL Début de la mise en application
Centre d’administration Microsoft 365 https://portal.office.com/adminportal/home Février 2025
Centre d’administration Microsoft 365 https://admin.cloud.microsoft Février 2025
Centre d’administration Microsoft 365 https://admin.microsoft.com Février 2025

Comptes

Tous les utilisateurs qui se connectent aux applications répertoriées précédemment pour effectuer une opération de création, lecture, mise à jour ou suppression (CRUD) doivent effectuer l’authentification multifacteur lorsque l'application de cette exigence commence. Les utilisateurs ne seront pas tenus d’utiliser l’authentification multifacteur pour accéder à d’autres applications, sites web ou services hébergés sur Azure. Chaque propriétaire d’application, de site ou de service mentionné précédemment définit ses propres exigences en matière d’authentification.

Les comptes d’accès d’urgence ou de secours devront eux aussi utiliser l’authentification multifacteur dès le début de sa mise en application. Nous vous recommandons de mettre à jour ces comptes afin d’utiliser la clé d'accès (FIDO2) ou de configurer l’authentification basée sur des certificats pour l'authentification multifacteur. Les deux méthodes répondent aux exigences de l’authentification multifacteur.

Les identités de charge de travail, comme les identités managées et les principaux de service, ne sont pas concernées par les deux phases de la mise en application de l’authentification multifacteur. En revanche, si des identités utilisateur sont utilisées comme comptes de service pour exécuter des tâches automatisées (scripts, automatisations, etc.), elles devront se connecter par authentification multifacteur dès sa mise en application. L’usage d’identités utilisateur n’est pas recommandé à des fins d’automatisation. Vous devez migrer ces identités utilisateur vers des identités de charge de travail.

Bibliothèques clientes

Le flux d'octroi de jetons ROPC (Resource Owner Password Credentials) OAuth 2.0 est incompatible avec l'authentification multifactorielle. Une fois l’authentification multifacteur activée dans votre compte Microsoft Entra, les API ROPC utilisées dans vos applications génèrent des exceptions. Pour plus d’informations sur la migration à partir d’API basées sur ROPC dans les bibliothèques d’authentification Microsoft (MSAL), consultez Comment migrer à partir de ROPC. Pour obtenir des instructions MSAL spécifiques à la langue, consultez les onglets suivants.

Les modifications sont requises si vous utilisez le package Microsoft.Identity.Client et l’une des API suivantes dans votre application :

Les mêmes conseils MSAL généraux s’appliquent aux bibliothèques Azure Identity. La UsernamePasswordCredential classe fournie dans ces bibliothèques utilise des API BASÉEs sur MSAL ROPC. Pour obtenir des conseils spécifiques à la langue, consultez les onglets suivants.

Les modifications sont requises si vous utilisez le package Azure.Identity et effectuez l’une des opérations suivantes dans votre application :

Migrer les comptes de service basés sur des identités utilisateur vers des identités de charge de travail

Nous recommandons aux clients d’identifier les comptes utilisateur utilisés comme comptes de service, puis de commencer à les migrer vers des identités de charge de travail. Cette migration implique généralement la mise à jour des scripts et des processus d’automatisation afin d’utiliser ces nouvelles identités.

Examinez comment vérifier que les utilisateurs sont configurés pour l’authentification multifacteur obligatoire pour identifier tous les comptes d’utilisateur, y compris les comptes d’utilisateur utilisés comme comptes de service, qui se connectent aux applications.

Pour plus d’informations sur la migration des comptes de service basés sur l’utilisateur vers des identités de charge de travail dans le cadre de l’authentification à ces applications, consultez les ressources suivantes :

Certains clients appliquent des stratégies d’accès conditionnel à des comptes de service basés sur l’utilisateur. Dans ce cas, vous pouvez récupérer la licence utilisateur associée et la remplacer par une licence d’identités de charge de travail afin de continuer à appliquer l’accès conditionnel pour les identités de charge de travail.

Implémentation

Cette exigence pour l’authentification multifacteur lors de la connexion est implémentée pour les portails d’administration et d’autres applications. Les journaux de connexion de Microsoft Entra ID indiquent cela comme la source de l'exigence d'authentification multifacteur.

L’authentification multifacteur obligatoire n’est pas configurable. Il est implémenté séparément de toute politique d’accès configurée dans le client.

Par exemple, si votre organisation a choisi de conserver les paramètres de sécurité par défaut de Microsoft et que vous avez actuellement activé les paramètres de sécurité par défaut, vos utilisateurs ne voient aucune modification, car l’authentification multifacteur est déjà requise pour la gestion Azure. Si votre locataire utilise des stratégies d’accès conditionnel dans Microsoft Entra et que vous disposez déjà d’une stratégie d’accès conditionnel via laquelle les utilisateurs se connectent à Azure avec MFA, vos utilisateurs ne voient pas de modification. Enfin, les stratégies d’accès conditionnel restrictives visant Azure et nécessitant une authentification renforcée, comme une authentification multifacteur résistant au hameçonnage, continueront également d’être appliquées, sans impact visible pour les utilisateurs.

Phases de mise en application

Remarque

La date d’application de la phase 2 a changé au 1er septembre 2025.

L’application obligatoire de l’authentification multifacteur se fera en deux phases :

  • Phase 1 : À compter d’octobre 2024, l’authentification multifacteur est requise pour se connecter au portail Azure, au Centre d’administration Microsoft Entra et au Centre d’administration Microsoft Intune. L’application sera progressivement déployée sur tous les clients dans le monde entier. À partir de février 2025, l'application de l'authentification multifacteur pour la connexion au Centre d'administration Microsoft 365 commencera progressivement. Cette première phase n’aura pas d’impact sur d’autres clients Azure tels que Azure CLI, Azure PowerShell, Azure mobile app ou les outils IaC.

  • Phase 2 : À compter du 1er septembre 2025, l’application de l’authentification multifacteur commencera progressivement pour Azure CLI, Azure PowerShell, l’application mobile Azure, les outils IaC et les points de terminaison d’API REST. Certains clients utilisent un compte utilisateur Microsoft Entra ID comme compte de service. Il est recommandé de migrer ces comptes de service basés sur l’utilisateur vers des comptes de service cloud sécurisés avec des identités de charge de travail.

Canaux de notification

Microsoft informera tous les administrateurs généraux Microsoft Entra par les canaux suivants :

  • E-mail : les administrateurs généraux ayant configuré une adresse e-mail recevront un e-mail les informant de l’application prochaine de l’authentification multifacteur obligatoire ainsi que des actions à entreprendre pour s’y préparer.

  • Notification d’intégrité du service : les administrateurs généraux reçoivent une notification d’intégrité de service via le portail Azure, avec l’ID de suivi 4V20-VX0. Cette notification contient les mêmes informations que l’e-mail. Les administrateurs généraux peuvent également s’abonner pour recevoir ces notifications d’intégrité du service par e-mail.

  • Notification du portail : une notification s’affiche lors de la connexion au portail Azure, au centre d’administration Microsoft Entra et au centre d’administration Microsoft Intune. Cette notification renverra vers cette rubrique pour plus d’informations sur la mise en application obligatoire de l’authentification multifacteur.

  • Centre de messages Microsoft 365 : un message s’affiche dans le centre de messages Microsoft 365 avec l’ID de message : MC862873. Ce message contient les mêmes informations que l’e-mail et que la notification d’intégrité du service.

Après l’application, une bannière s’affiche dans le portail Azure :

Capture d’écran d’une bannière dans l’authentification multifacteur Microsoft Entra montrant l’authentification multifacteur obligatoire appliquée.

Méthodes d’authentification externes et fournisseurs d’identité

La prise en charge des solutions MFA externes est en version préliminaire avec des méthodes d’authentification externes, et peut être utilisée pour satisfaire aux exigences en matière de MFA. La préversion des contrôles personnalisés d’accès conditionnel hérités ne répond pas à l'exigence de l’authentification multifacteur. Il est recommandé de migrer vers la préversion des méthodes d’authentification externes pour utiliser une solution externe avec Microsoft Entra ID.

Si vous utilisez un fournisseur d’identité fédéré (IdP), comme Active Directory Federation Services, et que votre fournisseur d’authentification multifacteur est directement intégré à cet IdP fédéré, ce dernier doit être configuré pour transmettre une revendication d’authentification multifacteur. Pour plus d’informations, consultez Assertions entrantes attendues pour Microsoft Entra MFA.

Demander un délai supplémentaire pour préparer la mise en application

Nous comprenons que certains clients peuvent avoir besoin de plus de temps pour se préparer à cette exigence d’authentification multifacteur. Microsoft permet aux clients ayant des environnements complexes ou des obstacles techniques de reporter l'application des mesures concernant leurs locataires jusqu'au 30 septembre 2025.

Pour chaque locataire pour lequel ils souhaitent reporter la date de début de l’application, un Administrateur global peut se rendre sur la https://aka.ms/managemfaforazure pour sélectionner une date de début. Si vous avez reporté la date de début de la phase 1, l’application de la phase 2 ne commence pas avant la date de début que vous choisissez. Les administrateurs généraux doivent élever l’accès et utiliser l’authentification multifacteur avant de pouvoir reporter la date de début de l’application de l’authentification multifacteur.

Avertissement

En reportant la date de mise en application, vous prenez un risque supplémentaire, car les comptes ayant accès à des services Microsoft tels que le portail Azure sont des cibles très prisés par les acteurs malveillants. Nous recommandons vivement à tous les locataires de configurer l’authentification multifacteur dès à présent pour sécuriser leurs ressources cloud.

Si vous ne vous êtes jamais connecté au portail Azure avec MFA, vous serez invité à compléter l’authentification multifacteur pour vous connecter ou à reporter cette démarche. Cet écran ne s’affiche qu’une seule fois. Pour plus d’informations sur la configuration de l’authentification multifacteur, consultez Comment vérifier que les utilisateurs sont configurés pour l’authentification multifacteur obligatoire.

Capture d’écran de l’invite pour confirmer l’authentification multifacteur obligatoire.

Si vous sélectionnez Reporter l’authentification multifacteur, la date de mise en œuvre de l’authentification multifacteur sera fixée à un mois dans le futur, ou au 30 septembre 2025, selon la première éventualité. Une fois connecté, vous pouvez modifier la date à https://aka.ms/managemfaforazure. Pour confirmer que vous souhaitez poursuivre la demande de report, cliquez sur Confirmer le report.

Capture d’écran montrant comment reporter l’authentification multifacteur obligatoire.

Vous pouvez demander ce délai supplémentaire pour la Phase 2 de la mise en application de l'authentification multifacteur en vous rendant sur https://aka.ms/postponePhase2MFA. Pour reporter l’application de l’authentification multifacteur de la phase 2, choisissez une autre date de début, puis cliquez sur Appliquer.

Capture d’écran montrant comment reporter l’authentification multifacteur obligatoire pour la phase 2.

Foire aux questions

Question : Si le locataire est uniquement utilisé à des fins de tests, l’authentification multifacteur est-elle obligatoire ?

Réponse : Oui, chaque locataire Azure nécessite l’authentification multifacteur, sans exception pour les environnements de test.

Question : Comment cette exigence a-t-elle un impact sur le Centre d’administration Microsoft 365 ?

Réponse : L’authentification multifacteur obligatoire sera déployée dans le Centre d’administration Microsoft 365 à partir de février 2025. En savoir plus sur l’exigence d’authentification multifacteur obligatoire pour le Centre d’administration Microsoft 365 sur le billet de blog Annonce de l’authentification multifacteur obligatoire pour le Centre d’administration Microsoft 365.

Question : L’authentification multifacteur est-elle obligatoire pour tous les utilisateurs ou uniquement les administrateurs ?

Réponse : tous les utilisateurs qui se connectent à l’une des applications répertoriées précédemment sont tenus de terminer l’authentification multifacteur, quels que soient les rôles d’administrateur activés ou éligibles pour eux, ou toute exclusion d’utilisateur activée pour eux.

Question : Dois-je terminer l’authentification multifacteur si je choisit l’option Rester connecté ?

Réponse : Oui, même si vous choisissez Rester connecté, vous devez terminer l’authentification multifacteur avant de pouvoir vous connecter à ces applications.

Question : L’application s’applique-t-elle aux comptes invités B2B ?

Réponse : Oui, l’authentification multifacteur doit être respectée soit par le locataire de la ressource partenaire, soit par le locataire de base de l’utilisateur, si celui-ci est correctement configuré pour envoyer des revendications d’authentification multifacteur au locataire de la ressource via l’accès interlocataires.

Question : Cette mesure s'applique-t-elle à Azure pour le gouvernement des États-Unis ou aux clouds souverains Azure ?

Réponse : Microsoft applique l’authentification multifacteur obligatoire uniquement dans le cloud Azure public. Microsoft n’applique actuellement pas l’authentification multifacteur dans Azure pour le gouvernement des États-Unis ou d’autres clouds souverains Azure.

Question : Comment pouvons-nous nous conformer si nous appliquons l’authentification multifacteur à l’aide d’un autre fournisseur d’identité ou d’une solution MFA, et que nous ne l’appliquons pas à l’aide de Microsoft Entra MFA ?

Réponse : L’authentification multifacteur tierce peut être intégrée directement à l’ID Microsoft Entra. Pour plus d’informations, consultez la référence du fournisseur de méthodes externes d’authentification multifacteur Microsoft Entra. L’ID Microsoft Entra peut être configuré éventuellement avec un fournisseur d’identité fédéré. Si c’est le cas, la solution du fournisseur d’identité doit être configurée correctement pour envoyer la revendication multipleauthn à l’ID Microsoft Entra. Pour plus d'informations, consultez Satisfaire les contrôles d'authentification multifacteur (MFA) Microsoft Entra ID avec des revendications MFA provenant d'un IdP fédéré.

Question : L’authentification multifacteur obligatoire aura-t-elle un impact sur ma capacité à se synchroniser avec Microsoft Entra Connect ou Microsoft Entra Cloud Sync ?

Réponse : Non. Le compte de service utilisé pour la synchronisation n’est pas concerné par cette exigence d’authentification multifacteur obligatoire. Seules les applications répertoriées précédemment nécessitent l’authentification multifacteur pour la connexion.

Question : Est-ce que je serai en mesure de refuser ?

Réponse : Il n’y a aucun moyen de refuser. Ce mouvement de sécurité est essentiel à toute sécurité et sécurité de la plateforme Azure et est répété entre les fournisseurs de cloud. Par exemple, consultez Secure by Design : AWS pour améliorer les exigences de l’authentification multifacteur en 2024.

Une option de report de la date de mise en application est disponible pour les clients. Les administrateurs généraux peuvent se rendre sur le portail Azure pour reporter la date de début de l'application pour leur client. Les administrateurs généraux doivent disposer d’un accès élevé avant de reporter la date de début de l’application de l’authentification multifacteur sur cette page. Ils doivent répéter l’opération pour chaque locataire concerné.

Question : Puis-je tester l’authentification multifacteur avant qu’Azure applique la politique afin de m’assurer qu'il n’y a pas de problèmes ?

Réponse : Oui, vous pouvez tester leur authentification multifacteur via le processus d’installation manuelle de l’authentification multifacteur. Nous vous encourageons à le faire. Si vous utilisez l’accès conditionnel pour appliquer l’authentification multifacteur, vous pouvez utiliser les modèles d’accès conditionnel pour tester vos stratégies. Pour plus d’informations, consultez Exiger une authentification multifacteur pour les administrateurs accédant aux portails d’administration Microsoft. Si vous exécutez une édition gratuite de Microsoft Entra ID, vous pouvez activer les paramètres de sécurité par défaut.

Question : Que se passe-t-il si j’ai déjà activé l’authentification multifacteur, que se passe-t-il ensuite ?

Réponse : les clients qui nécessitent déjà l’authentification multifacteur pour leurs utilisateurs qui accèdent aux applications répertoriées précédemment ne voient aucune modification. Si l’authentification multifacteur est actuellement requise uniquement pour un sous-ensemble d’utilisateurs, tous ceux qui ne l’utilisaient pas devront désormais l’appliquer pour se connecter aux applications.

Question : Comment puis-je examiner l’activité MFA dans Microsoft Entra ID ?

Réponse : Pour consulter les détails sur le moment où un utilisateur est invité à se connecter avec MFA, utilisez les journaux de connexion Microsoft Entra. Pour plus d’informations, consultez les détails de l’événement de connexion pour l’authentification multifacteur Microsoft Entra.

Question : Que se passe-t-il en cas de scénario de secours ?

Réponse : nous vous recommandons de mettre à jour ces comptes afin d’utiliser la clé secrète (FIDO2) ou de configurer l’authentification basée sur un certificat pour MFA. Les deux méthodes répondent aux exigences de l’authentification multifacteur.

Question : Que se passe-t-il si je ne reçois pas d’e-mail sur l’activation de l’authentification multifacteur avant son application, puis je suis verrouillé. Comment dois-je le résoudre ?

Réponse : Les utilisateurs ne doivent pas être verrouillés, mais ils peuvent recevoir un message qui les invite à activer l’authentification multifacteur (MFA) une fois que la mise en application pour leur locataire a démarré. En cas de blocage, d’autres problèmes peuvent être en cause. Pour plus d’informations, consultez Compte verrouillé.

Contenu associé

Passez en revue les rubriques suivantes pour en savoir plus sur la configuration et le déploiement de l’authentification multifacteur :