MFA non obligatoire pour tous les utilisateurs Entra : la faille critique que les stratégies réservées aux admins laissent ouverte

MFA non obligatoire pour tous les utilisateurs Entra : ce que cela signifie vraiment

MFA non obligatoire pour tous les utilisateurs Entra : la formule désigne une faille distincte, fréquente et de sévérité Critique dans Microsoft Entra ID — et ce n'est pas le même défaut que l'absence totale d'accès conditionnel. Un tenant peut cocher toutes les cases d'une checklist « avez-vous de l'accès conditionnel ? », afficher une stratégie qui cible littéralement All users (tous les utilisateurs), et laisser malgré tout chaque compte non-administrateur accessible avec un simple mot de passe. Cela se produit lorsque le contrôle d'octroi de la stratégie exige autre chose que le MFA (la conformité de l'appareil, par exemple), ou lorsque l'application du MFA est éparpillée entre plusieurs stratégies limitées à des rôles ou à des applications, chacune solide en apparence, sans jamais totaliser une couverture générale.

C'est la variante plus étroite, plus fréquente et plus dangereuse de deux problèmes mieux connus :

• Aucune stratégie d'accès conditionnel, quelle qu'elle soit, ne cible tous les utilisateurs. C'est le défaut de couverture de base — voir Lacunes de couverture des stratégies de base d'accès conditionnel dans Entra ID pour les tenants sans aucune stratégie couvrant les rôles d'administration, tous les utilisateurs, toutes les applications cloud ou la conformité des appareils. Le présent article suppose qu'une stratégie ciblant tous les utilisateurs existe déjà ; la faille est ici plus étroite et plus facile à manquer — la stratégie existe, mais elle n'exige pas le MFA.
• MFA exigé pour les administrateurs uniquement. La plupart des chantiers de durcissement de l'accès conditionnel commencent là, et pour de bonnes raisons — voir Sécurité des identités Azure : pourquoi le MFA seul ne suffit pas. Mais une stratégie MFA limitée aux administrateurs, aussi bien construite soit-elle, est structurellement incapable de protéger les comptes auxquels elle n'a jamais été affectée. Les utilisateurs standard se connectent aux mêmes boîtes aux lettres, aux mêmes sites SharePoint et aux mêmes applications métier que les administrateurs ; ce ne sont pas des cibles de moindre valeur, ce sont simplement des cibles non protégées.

C'est aussi pourquoi la faille est facile à manquer, même pour des équipes qui ont déjà accompli un vrai travail de durcissement. Une organisation qui a déployé le MFA sur les administrateurs au titre de MFA_NOT_ENFORCED_ADMINS, ou verrouillé l'authentification des Global Admins au titre de PA_GLOBAL_ADMIN_NOT_MFA, a commencé par le travail qui paraît le plus difficile, et suppose raisonnablement que le cas plus simple et plus large — tous les utilisateurs restants — est déjà couvert par extension. Structurellement, il ne l'est pas : les stratégies limitées aux administrateurs et les stratégies tous utilisateurs reposent sur des conditions d'affectation différentes dans Entra ID, si bien qu'achever l'une laisse la couverture de l'autre exactement là où elle a commencé, à zéro.

Deux modèles distincts, deux actions Secure Score distinctes

Microsoft ne modélise pas « exiger le MFA » comme un contrôle unique. Dans la galerie de modèles d'accès conditionnel, Require multifactor authentication for admins et Require multifactor authentication for all users sont présentés comme deux modèles distincts. Tous deux figurent ensemble dans la catégorie « Secure foundation » de Microsoft — l'ensemble que Microsoft recommande explicitement de déployer comme un groupe — et tous deux réapparaissent, toujours en deux entrées distinctes, dans la catégorie « Zero Trust ». Aucune des deux descriptions de modèle ne prétend couvrir le terrain de l'autre, dans l'une ou l'autre liste.

La même séparation existe dans la notation. L'Identity Secure Score de Microsoft Entra ID suit « Require multifactor authentication (MFA) for administrative roles » et « Ensure all users can complete MFA » comme deux actions d'amélioration distinctes dans son propre catalogue. Un tenant peut maximiser la première et obtenir zéro sur la seconde ; Secure Score ne les traite pas comme redondantes, et un relecteur qui parcourt un export d'accès conditionnel ne devrait pas le faire non plus.

L'action « tous les utilisateurs » est en outre notée en pourcentage du total des utilisateurs protégés, et non en réussite/échec binaire. Dans l'exemple chiffré de Microsoft, 5 utilisateurs protégés sur 100 utilisateurs au total rapportent environ 0,53 % sur un maximum possible de 10,71 % pour ce contrôle — autrement dit, la plupart des tenants qui ont « commencé » le MFA pour tous les utilisateurs portent encore l'essentiel de l'exposition que le contrôle est censé fermer.

Comment une couverture fragmentée dissimule la faille

Le modèle MFA administrateurs et le modèle MFA tous utilisateurs ne sont pas cadrés de la même manière, et cette différence est précisément ce qui permet à une faille de survivre à une revue de stratégies rapide :

• Require multifactor authentication for admins s'affecte sous Directory roles (rôles d'annuaire), et uniquement à une liste définie de rôles intégrés — Global Administrator, Application Administrator, Authentication Administrator, Privileged Role Administrator, Security Administrator, et d'autres nommés explicitement dans la documentation de Microsoft. L'avertissement de Microsoft est direct : "Conditional Access policies support built-in roles. Conditional Access policies are not enforced for other role types including administrative unit-scoped or custom roles." Un rôle personnalisé « IT Support » doté de permissions élevées, ou un rôle affecté seulement au niveau d'une unité administrative, est invisible pour cette stratégie alors même qu'elle est activée et appliquée.
• Require multifactor authentication for all users s'affecte sous Include: All users, avec des exclusions limitées aux comptes de secours et aux comptes de service de synchronisation d'annuaire. Il n'existe aucune condition de rôle par laquelle un utilisateur pourrait passer à travers.

Parce que les deux stratégies utilisent des modèles d'affectation différents, un tenant peut accumuler plusieurs stratégies MFA réellement appliquées — une limitée aux Global Admins, une limitée à une application financière précise, une déclenchée uniquement par une connexion à risque — sans jamais avoir déployé la seule stratégie dont le champ Include vaut littéralement All users, dont Target resources vaut All resources, et dont le contrôle d'octroi exige le MFA. Chaque stratégie prise isolément est réelle ; aucune d'elles, même additionnées, n'égale la base que Microsoft recommande. Failles d'accès conditionnel Azure : le contournement du MFA traite du schéma plus large des exclusions et des décalages de portée qui laissent un jeu d'accès conditionnel paraître complet tout en laissant une exposition réelle en production. Accès privilégié Azure : trop d'administrateurs globaux traite du défaut parallèle côté privilèges, où les rôles d'administration permanents et les lacunes de PIM aggravent la même faiblesse sous-jacente par l'autre bout.

Détection

Confirmer cette faille ne demande pas de deviner — Microsoft Entra ID journalise l'étape d'authentification exacte atteinte à chaque connexion, par utilisateur et par application.

Selon les recommandations de Microsoft pour repérer les lacunes de MFA des administrateurs : "Any sign-in where Authentication requirement is Single-factor authentication means there was no multifactor authentication policy that was required for the sign-in." Ces recommandations sont rédigées pour les administrateurs en particulier, mais le champ lui-même n'est pas limité aux rôles — c'est une propriété de l'événement de connexion, si bien que le même contrôle s'applique à n'importe quelle population d'utilisateurs, administrateurs ou non.

authenticationRequirement est exposé sur la ressource signIn du point de terminaison beta de Microsoft Graph — il n'est pas présent sur la ressource signIn stable v1.0 — et il accepte $filter avec les opérateurs eq et startsWith :

GET https://graph.microsoft.com/beta/auditLogs/signIns?$filter=authenticationRequirement%20eq%20%27singleFactorAuthentication%27

Le filtre est encodé en pourcentage — %20 pour les espaces, %27 pour les apostrophes — de sorte que la requête fonctionne aussi bien collée dans un client en ligne de commande que dans Graph Explorer. Laissés non encodés, les espaces bruts font rejeter l'URL localement par des outils comme curl, avant même qu'elle ne soit envoyée.

Ou avec le module beta du SDK PowerShell Microsoft Graph :

Import-Module Microsoft.Graph.Beta.Reports
Connect-MgGraph -Scopes "AuditLog.Read.All","Directory.Read.All"

Get-MgBetaAuditLogSignIn `
  -Filter "authenticationRequirement eq 'singleFactorAuthentication'" `
  -Top 50 `
  -Property UserPrincipalName, AppDisplayName, CreatedDateTime, AuthenticationRequirement

Remediation

1. Déployer le modèle MFA tous utilisateurs de Microsoft

Vérifiez d'abord si Microsoft n'en a pas déjà placé un dans le tenant. Les stratégies Microsoft-managed sont créées et déployées par Microsoft directement dans les tenants éligibles, et l'une d'elles porte le nom Multifactor authentication for all users — elle "covers all users in your organization and requires them to use multifactor authentication whenever they sign in." Elle arrive inerte : "The policy is automatically created in your tenant in a Report-only state." Microsoft l'active ensuite "no less than 30 days after they're introduced in your tenant if they're left in the Report-only state," en prévenant les tenants deux semaines à l'avance. Filtrez sur Microsoft dans la colonne Created by avant de construire un doublon.

Sinon, utilisez la galerie de modèles d'accès conditionnel, ou construisez la stratégie équivalente directement :

• Sous Assignments → Users, définissez Include: All users.
• Sous Exclude, n'ajoutez que les comptes d'accès d'urgence « break-glass » documentés de votre organisation et, si vous utilisez la synchronisation d'identité hybride, le rôle Directory Synchronization Accounts — et non une large exclusion « équipe IT » qui recrée discrètement la faille.
• Sous Target resources, définissez Include: All resources, sans aucune exclusion d'application.
• Sous Grant, choisissez Require authentication strength et sélectionnez la force intégrée Multifactor authentication strength.

2. Déployer en mode rapport seul, et vérifier qu'on en sort vraiment

Examinez l'impact projeté via Policy impact ou le classeur Conditional Access Insights and Reporting avant de basculer Enable policy sur On — c'est ainsi que vous attrapez un compte de secours, de service ou d'authentification héritée qui se retrouverait autrement bloqué à l'improviste. Une stratégie laissée indéfiniment en mode rapport seul, ou une liste d'exclusions qui a discrètement débordé de sa portée d'origine, n'applique rien tout en affichant toujours « On » — vérifiez-le après le déploiement, pas seulement à la création.

3. Valider la couverture avec l'outil What If

Exécutez l'outil What If sur un échantillon d'utilisateurs ordinaires, non administrateurs — pas seulement sur les comptes d'administration déjà couverts par l'autre stratégie — afin de confirmer que la nouvelle stratégie s'applique réellement à eux. Les stratégies activées et les stratégies en mode rapport seul sont toutes deux incluses dans une exécution d'évaluation : une stratégie encore en attente en mode rapport seul apparaîtra donc ici. Lisez le résultat comme une simulation plutôt que comme une garantie : Microsoft note que l'outil "doesn't test for Conditional Access service dependencies," et que les conditions que vous laissez non renseignées sont des conditions qu'il ne peut pas évaluer.

4. Ne pas substituer ce chantier au MFA des administrateurs, ni l'inverse

Si la stratégie MFA limitée aux administrateurs n'est pas non plus déployée, traitez-la comme une seconde action, distincte. Voir Sécurité des identités Azure : pourquoi le MFA seul ne suffit pas et Accès privilégié Azure : trop d'administrateurs globaux. Déployer l'une des stratégies ne remplace pas l'autre ; toutes deux figurent sur la liste « Secure foundation » de Microsoft, et ce n'est pas un hasard.

5. Dépasser le MFA de base une fois la couverture stable

Une fois la couverture MFA large appliquée et stabilisée, passez de la force de base Multifactor authentication strength à des méthodes résistantes au hameçonnage ou sans mot de passe pour les utilisateurs qui peuvent les prendre en charge — voir Entra ID : le changement d'inscription au MFA sans mot de passe.

Comment EtcSec détecte ce problème

L'audit Azure/Entra d'EtcSec recherche spécifiquement MFA_NOT_ENFORCED_ALL : une configuration d'accès conditionnel où aucune stratégie ciblant tous les utilisateurs et toutes les applications cloud (ou la quasi-totalité) ne porte de contrôle d'octroi exigeant le MFA ou une force d'authentification équivalente au MFA. Elle est évaluée indépendamment de MFA_NOT_ENFORCED_ADMINS, PA_GLOBAL_ADMIN_NOT_MFA et CA_NO_POLICY_ALL_USERS — lever l'un de ces contrôles ne lève pas celui-ci.