Conditional Access : imposer le MFA dans Microsoft Entra ID

Introduction : pourquoi aller au-delà des Security Defaults

Les Security Defaults constituent une excellente porte d'entrée pour les organisations qui démarrent leur stratégie d'authentification multifacteur dans Microsoft Entra ID. Faciles à activer, sans configuration requise, ils couvrent les scénarios les plus critiques. Mais à mesure que votre environnement se complexifie — comptes de service, exigences de conformité par application, règles basées sur la localisation — leurs limites deviennent vite un frein opérationnel.

Cet article est le second volet d'une série dédiée à la sécurisation de Microsoft Entra ID via le MFA et les politiques d'accès conditionnel. Nous y analysons les insuffisances des Security Defaults, décortiquons l'anatomie d'une politique d'accès conditionnel, et guidons pas à pas la création et l'activation de votre première politique dans le portail Entra ID.

Contexte de la série

Cet article fait suite à une introduction sur le MFA dans Microsoft Entra ID. Si vous débutez sur ce sujet, nous vous recommandons de consulter d'abord les fondamentaux de l'authentification multifacteur dans M365 avant de poursuivre.

Pourquoi les Security Defaults atteignent leurs limites

Les Security Defaults sont conçus pour la simplicité — c'est leur force, mais aussi leur contrainte principale. Voici ce qu'ils ne permettent pas de faire :

Exclure des utilisateurs ou des groupes spécifiques (comptes de service, comptes break-glass)
Cibler des applications cloud individuelles (Exchange Online, SharePoint, etc.)
Adapter les exigences selon le contexte : localisation géographique, état du poste, niveau de risque à la connexion

En résumé, les Security Defaults fonctionnent en mode tout-ou-rien. Pour une petite organisation aux besoins homogènes, ce compromis est acceptable. Dès qu'un compte de service ne peut pas s'enregistrer au MFA, ou qu'une exigence de conformité ne s'applique qu'à certaines applications, l'accès conditionnel s'impose comme la solution adaptée.

Référence Microsoft : Présentation des Security Defaults

Licences requises pour l'accès conditionnel

Avant de créer votre première politique, vérifiez votre éligibilité. L'accès conditionnel nécessite Microsoft Entra ID P1 ou P2, inclus dans les plans suivants :

Microsoft 365 Business Premium
Microsoft 365 E3 et E5
Azure AD Premium P1 / P2 en licence autonome
Essai temporaire disponible dans la plupart des tenants

Astuce

Pour vérifier les licences actives dans votre tenant, accédez au panneau Licences dans le portail Microsoft Entra ID avant de commencer toute configuration.

Référence Microsoft : Conditions de licence pour l'accès conditionnel

Security Defaults et accès conditionnel : une coexistence impossible

C'est un point fondamental à comprendre avant toute chose : Security Defaults et politiques d'accès conditionnel ne peuvent pas fonctionner simultanément. La transition implique de désactiver les Security Defaults en premier, ce qui crée une fenêtre temporaire sans enforcement MFA. Il est donc impératif d'enchaîner les étapes rapidement pour minimiser cette exposition.

Important

Désactiver les Security Defaults sans activer immédiatement une politique d'accès conditionnel expose votre tenant à une période sans MFA obligatoire. Planifiez cette transition avec soin et préférez une plage horaire à faible activité.

L'anatomie d'une politique d'accès conditionnel

Toute politique d'accès conditionnel repose sur une logique if-then : si ces conditions sont remplies, alors appliquer ces contrôles. Elle s'articule autour de trois composants fondamentaux.

Assignments (Affectations)

Définissent à qui et à quoi s'applique la politique :

Utilisateurs : tous les utilisateurs, des groupes spécifiques, ou des rôles annuaire (ex. Administrateur général)
Exclusions : possibilité d'exclure des comptes individuels ou des groupes — fonctionnalité absente des Security Defaults, indispensable pour les comptes break-glass
Ressources cibles : toutes les applications cloud, ou des applications spécifiques comme Exchange Online ou SharePoint

Conditions

Définissent quand et comment la politique s'applique. C'est ici que l'accès conditionnel démontre toute sa puissance :

Niveau de risque à la connexion (sign-in risk)
Localisation géographique de l'utilisateur
Plateforme de l'appareil (Windows, iOS, Android...)
Type d'application cliente (navigateur, client natif, etc.)
Conformité ou jonction Entra ID de l'appareil

Pour une première politique, ces conditions peuvent rester à leurs valeurs par défaut pour un enforcement universel.

Access Controls (Contrôles d'accès)

Définissent ce qui se passe lorsque la politique est déclenchée :

Accorder l'accès avec des exigences : MFA, appareil conforme, force d'authentification spécifique
Bloquer l'accès entièrement

Référence Microsoft : Composants d'une politique d'accès conditionnel

Le mode Report-Only : votre filet de sécurité

Avant d'activer toute politique d'accès conditionnel, il est indispensable de comprendre le mode Report-Only. C'est l'une des fonctionnalités les plus précieuses de l'accès conditionnel, et la raison pour laquelle aucune politique ne doit être activée directement sans phase de test.

En mode Report-Only, la politique évalue chaque connexion réelle et journalise ce qu'elle aurait fait — sans rien imposer aux utilisateurs. Vous obtenez une visibilité complète sur l'impact potentiel avant toute mise en production. C'est le mécanisme qui vous protège contre les mauvaises configurations et les risques de verrouillage de compte.

Attention

Ne jamais activer directement une nouvelle politique en mode On sans l'avoir préalablement validée en mode Report-Only. Un mauvais paramétrage peut verrouiller des utilisateurs légitimes, voire l'administrateur lui-même.

Référence Microsoft : Résultats d'évaluation en mode Report-Only

Déploiement de votre première politique MFA : guide pas à pas

Bon à savoir

Ces étapes sont à réaliser idéalement dans un environnement de test ou laboratoire avant toute modification en production.

Désactiver les Security Defaults

Connectez-vous au portail Azure et accédez à Microsoft Entra ID.

Sélectionnez Propriétés dans le menu Gérer
Faites défiler jusqu'en bas et cliquez sur Gérer les paramètres de sécurité par défaut
Basculez le toggle sur Désactivé
Sélectionnez la raison appropriée (ex. : Mon organisation prévoit d'utiliser l'accès conditionnel)
Cliquez sur Enregistrer

Disable Security Defaults

Créer la politique d'accès conditionnel

Dans le portail Entra ID, naviguez vers Sécurité > Accès conditionnel > Stratégies, puis cliquez sur Nouvelle stratégie.

Nom : Utilisez une convention de nommage claire, par exemple Require MFA for All Users. Un standard de nommage cohérent devient crucial lorsque le nombre de politiques augmente.
Assignments > Utilisateurs : Sélectionnez Tous les utilisateurs. Utilisez l'onglet Exclure pour ajouter les comptes break-glass ou de service.
Ressources cibles : Sélectionnez Toutes les ressources
Réseau et Conditions : Laissez les valeurs par défaut pour cette première politique
Contrôles d'accès > Accorder : Cochez Exiger l'authentification multifacteur, puis cliquez sur Sélectionner
Activer la stratégie : Définissez sur Report uniquement
Cliquez sur Créer

Create Conditional Access Policy

Analyser les journaux en mode Report-Only

Une fois la politique en mode Report-Only et après avoir généré de l'activité de connexion :

Ouvrez les Journaux de connexion depuis le panneau Accès conditionnel > Supervision
Ouvrez une entrée de journal et accédez à l'onglet Accès conditionnel
Le statut affichera Non applicable tant que la politique n'est pas activée
Consultez l'onglet Report uniquement pour voir le détail : correspondance des affectations, conditions évaluées, action qui aurait été requise

Cette analyse vous permet de valider le comportement de la politique avant toute mise en production.

Utiliser l'outil What If

L'outil What If permet de simuler l'application des politiques pour un utilisateur spécifique sans attendre une connexion réelle.

Depuis le panneau Stratégies d'accès conditionnel, cliquez sur What If en haut de l'écran
Sélectionnez un utilisateur cible
Définissez l'application cible, le type d'appareil et l'application cliente
Cliquez sur What If pour visualiser les politiques qui s'appliqueraient et les contrôles qui seraient imposés

Cet outil est particulièrement utile pour valider le comportement attendu pour les comptes administrateurs ou les utilisateurs disposant d'exclusions.

Activer la politique en production

Une fois la politique validée en mode Report-Only :

Retournez dans la liste des stratégies et ouvrez la politique créée
Basculez Activer la stratégie de Report uniquement à Activé
Lisez attentivement l'avertissement de verrouillage. Il est recommandé de conserver l'utilisateur actuel dans les exclusions pendant cette étape pour éviter tout verrouillage du tenant.
Cliquez sur Enregistrer

Enable the Policy

Une fois la politique active, tout utilisateur non exclu sera invité à s'authentifier avec le MFA à sa prochaine connexion. Les utilisateurs non encore enregistrés seront guidés à travers le processus d'enregistrement directement lors de la connexion.

Récapitulatif des composants clés

Fonctionnalité	Security Defaults	Accès conditionnel
Activation	Bascule simple	Configuration manuelle
Exclusions d'utilisateurs	Non	Oui
Ciblage par application	Non	Oui
Règles basées sur la localisation	Non	Oui
Évaluation du risque	Non	Oui (P2)
Mode Report-Only	Non	Oui
Licence requise	Aucune	Entra ID P1/P2

Prochaines étapes vers une posture Zero Trust

Avec votre première politique d'accès conditionnel en place et le MFA enforced sur l'ensemble du tenant, vous posez les fondations d'une architecture Zero Trust. Mais cette première politique n'est que le point de départ. Les scénarios à adresser ensuite incluent :

Blocage de l'authentification héritée (legacy authentication) — un vecteur d'attaque fréquemment exploité
Restrictions d'accès par localisation nommée pour limiter les connexions depuis des zones géographiques non autorisées
Protection renforcée des comptes privilégiés via des politiques dédiées aux rôles administrateurs
Configuration des comptes break-glass pour garantir un accès d'urgence au tenant en cas de blocage

Référence Microsoft : Planification d'un déploiement d'accès conditionnel