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 nos billets de blog sur l’authentification multifacteur obligatoire Azure : phase 2 à partir d’octobre 2025 et annonce de l’authentification multifacteur obligatoire pour la connexion Azure. 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.

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'application inclut le moment où l'application de l'authentification est planifiée, quelles applications prévoient de mettre en œuvre l'authentification multifacteur, les applications qui sont hors du champ d'application et les comptes qui ont une exigence obligatoire d'authentification multifacteur.

Phases d’application

L’application de l’authentification multifacteur pour les applications est déployée en deux phases.

Applications de phase 1

À compter d’octobre 2024, l’authentification multifacteur est requise pour les comptes qui se connectent au portail Azure, au Centre d’administration Microsoft Entra et au Centre d’administration Microsoft Intune pour effectuer une opération CRUD (Create, Read, Update ou Delete). 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. La phase 1 n’affecte pas d’autres clients Azure tels qu’Azure CLI, Azure PowerShell, l’application mobile Azure ou les outils IaC.

Applications de phase 2

À compter du 1er octobre 2025, l’application de l’authentification multifacteur commence progressivement pour les comptes qui se connectent à Azure CLI, à Azure PowerShell, à l’application mobile Azure, aux outils IaC et aux points de terminaison d’API REST pour effectuer n’importe quelle opération de création, de mise à jour ou de suppression. Les opérations de lecture ne nécessitent pas l’authentification multifacteur.

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.

ID d’application et URL

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

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

Accounts

Tous les comptes qui se connectent pour effectuer des opérations mentionnées dans la section applications doivent effectuer l’authentification multifacteur lorsque l'application de cette obligation 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 sont également requis pour se connecter avec l’authentification multifacteur une fois l’application commencée. 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 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.

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

Nous vous recommandons de découvrir les comptes d’utilisateur utilisés en tant que comptes de service et 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 :

• Se connecter à Azure avec une identité managée à l’aide d’Azure CLI
• Se connecter à Azure avec un principal de service à l’aide d’Azure CLI
• Se connecter à Azure PowerShell de manière non interactive pour les scénarios d'automatisation (inclut des recommandations pour les cas d’usage avec identité managée ou principal de service)

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.

Migrer un fournisseur d’identité fédéré vers des méthodes d’authentification externes

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.

Préparer l’application obligatoire de l’authentification multifacteur

Pour préparer l’application de l’authentification multifacteur, configurez une stratégie d’accès conditionnel qui oblige les utilisateurs à se connecter avec MFA. Si vous avez configuré des exceptions ou des exclusions dans la stratégie, elles ne s’appliquent plus. Si vous avez des stratégies d’accès conditionnel plus restrictives qui ciblent Azure et nécessitent une authentification plus forte, comme l’authentification multifacteur résistante au hameçonnage, elles restent appliquées.

L’accès conditionnel nécessite une licence Microsoft Entra ID P1 ou P2. Si vous ne pouvez pas utiliser l’accès conditionnel, activez les paramètres de sécurité par défaut.

Vous pouvez appliquer automatiquement l’authentification multifacteur à l’aide de définitions intégrées dans Azure Policy. Pour en savoir plus et suivre un guide étape par étape pour appliquer ces attributions de stratégie dans votre environnement, consultez Tutoriel : Appliquer l'autogestion de l’authentification multifacteur via Azure Policy.

Pour une expérience de compatibilité optimale, vérifiez que les utilisateurs de votre locataire utilisent Azure CLI version 2.76 et Azure PowerShell version 14.3 ou ultérieure. Sinon, vous pouvez vous attendre à voir les messages d’erreur comme expliqué dans ces rubriques :

• Résoudre les erreurs MFA dans Azure PowerShell
• Résoudre les erreurs MFA dans Azure CLI

Demander plus de temps pour préparer la mise en œuvre de l'AMF de la phase 1

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 de la phase 1 pour 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.

Faire la demande de plus de temps pour préparer l’application de la Phase 2 de l’authentification multifacteur

Microsoft permet aux clients ayant des environnements complexes ou des obstacles techniques de reporter l’application de la phase 2 pour leurs locataires jusqu’au 1er juillet 2026. Vous pouvez demander un délai supplémentaire pour vous préparer à la phase 2 d’application de l’authentification multifacteur à l'adresse https://aka.ms/postponePhase2MFA. Choisissez une autre date de début, puis cliquez sur Appliquer.

Confirmer l’application obligatoire de l’authentification multifacteur

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

Les journaux de connexion à l’ID Microsoft Entra indiquent l’application qui a appliqué l’authentification multifacteur comme source de l’exigence de l’authentification multifacteur.

FAQs

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 à partir du locataire de ressource partenaire ou du locataire de base de l’utilisateur s’il est configuré correctement pour envoyer des revendications MFA au locataire de ressource à l’aide de l’accès interlocataire.

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 à la sécurité et à la 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 votre authentification multifacteur via le processus de configuration 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 connexe

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

• Comment reporter l’application d’un locataire où les utilisateurs ne peuvent pas se connecter
• Comment vérifier que les utilisateurs sont configurés pour l’authentification multifacteur obligatoire
• Tutoriel : Sécuriser les événements de connexion utilisateur avec l’authentification multifacteur Microsoft Entra
• Sécuriser les évènements de connexion avec l’authentification multifacteur Microsoft Entra
• Planifier un déploiement d’authentification multifacteur Microsoft Entra
• Méthodes d’authentification multifacteur résistantes au hameçonnage
• Authentification multifacteur Microsoft Entra
• Méthodes d’authentification