L’accès conditionnel Microsoft Entra ID est le moteur « si … alors » qui décide, à chaque tentative de connexion, ce qu’on autorise et ce qu’on refuse en fonction du contexte. Sans lui, Microsoft 365 fonctionne avec un mot de passe et une authentification multifacteur, sans possibilité d’imposer un appareil conforme, de bloquer une zone géographique ou d’exiger une connexion depuis le réseau de l’entreprise. Ce tutoriel met en place le socle minimal : quatre politiques qui couvrent les risques les plus fréquents pour une PME.

Article principal : Microsoft 365 pour PME — architecture et gouvernance.

Prérequis

Une licence Microsoft Entra ID P1 par utilisateur impacté. P1 est inclus dans Microsoft 365 Business Premium et dans les plans Enterprise E3/E5. Sans P1, l’accès conditionnel n’est pas disponible — on reste sur Security Defaults.
Au moins un compte d’urgence (break-glass) configuré et exclu de toutes les politiques. Sans cette précaution, une politique mal configurée peut verrouiller toute l’organisation y compris les administrateurs.
Un compte avec le rôle Administrateur de l’accès conditionnel ou Administrateur de la sécurité.
Niveau attendu : administrateur Microsoft 365 ou ingénieur sécurité avec une compréhension de l’identité.
Temps : 2 heures la première fois, dont 7 jours de mode « rapport seul » avant activation effective.

Étape 1 — Créer les comptes break-glass d’urgence

Le compte break-glass est l’assurance vie de l’administration Entra ID. Il s’agit d’un compte à très haut privilège (Administrateur global), au mot de passe extrêmement long et stocké hors ligne, exclu de toutes les politiques d’accès conditionnel, et utilisé uniquement en cas de blocage généralisé. Sans ce compte, une politique mal calibrée peut empêcher tous les administrateurs de se connecter et créer une situation où l’on doit ouvrir un ticket Microsoft pour récupérer la main.

La pratique recommandée est de créer deux comptes break-glass — pas un seul, parce que la perte du seul compte est tout aussi grave que l’absence. Chacun a un nom neutre, un mot de passe de 64 caractères généré aléatoirement, stocké dans un coffre-fort physique ou un gestionnaire de mots de passe d’entreprise distinct. La MFA est activée par enregistrement d’une clé matérielle FIDO2, pas par téléphone — un téléphone perdu rend le compte inutilisable.

# Création d'un compte break-glass
Connect-MgGraph -Scopes "User.ReadWrite.All","RoleManagement.ReadWrite.Directory"
$pwd = -join ((33..126) | Get-Random -Count 64 | ForEach-Object { [char]$_ })
$user = New-MgUser -DisplayName "BreakGlass 01" -UserPrincipalName "breakglass-01@exemple.onmicrosoft.com" -MailNickname "breakglass-01" -PasswordProfile @{ Password = $pwd; ForceChangePasswordNextSignIn = $false } -AccountEnabled
$role = Get-MgDirectoryRole | Where-Object { $_.DisplayName -eq "Global Administrator" }
New-MgDirectoryRoleMemberByRef -DirectoryRoleId $role.Id -BodyParameter @{ "@odata.id" = "https://graph.microsoft.com/v1.0/directoryObjects/$($user.Id)" }
Write-Host "Mot de passe (à stocker hors ligne) : $pwd"

Le script génère un mot de passe long, crée le compte avec le suffixe onmicrosoft.com pour ne pas dépendre du domaine personnalisé (qui pourrait être mal configuré dans le DNS le jour J), désactive la rotation forcée du mot de passe, et attribue le rôle Global Administrator. La sortie affiche le mot de passe une seule fois : on le copie dans le coffre-fort physique et on le supprime de la console PowerShell. Une rotation annuelle du mot de passe est de bonne pratique — pas plus fréquente, sinon on multiplie les opportunités de mauvaise transcription.

Étape 2 — Désactiver Security Defaults

Security Defaults et l’accès conditionnel ne se cumulent pas. Tant que Security Defaults est actif, certaines politiques d’accès conditionnel sont silencieusement ignorées. La première action une fois P1 disponible est donc de désactiver Security Defaults.

# Désactivation Security Defaults
Connect-MgGraph -Scopes "Policy.ReadWrite.AuthenticationMethod"
$body = @{ isEnabled = $false } | ConvertTo-Json
Invoke-MgGraphRequest -Method PATCH -Uri "https://graph.microsoft.com/v1.0/policies/identitySecurityDefaultsEnforcementPolicy" -Body $body -ContentType "application/json"

L’appel renvoie un statut 204 No Content. L’effet immédiat est que l’authentification multifacteur n’est plus imposée par le mécanisme de Security Defaults — il faut la réinstaurer via une politique d’accès conditionnel dans la minute qui suit, sinon les utilisateurs se connectent sans MFA. C’est pour cette raison qu’on enchaîne directement avec l’étape 3.

Étape 3 — Politique 1 : MFA pour tous les utilisateurs

Cette politique impose la MFA à tout utilisateur sur toute application cloud. C’est le socle absolu ; toutes les autres politiques s’empilent dessus. On la crée dans le centre Entra → Protection → Accès conditionnel → Nouvelle politique. Le contenu cible Tous les utilisateurs, en exclusion les comptes break-glass (étape 1) et le compte de service de synchronisation Entra Connect le cas échéant. La cible est Toutes les applications cloud. Le contrôle d’accès est Accorder, exiger une authentification multifacteur. La fréquence de réauthentification se laisse à la valeur par défaut (90 jours, configurée par session).

La politique est créée d’abord en mode Rapport seul. Pendant 7 jours, Entra journalise dans le centre Surveillance → Connexions ce que la politique aurait fait sans l’appliquer : combien d’utilisateurs auraient dû faire MFA, combien auraient été bloqués faute de méthode enregistrée. On exploite ce rapport pour identifier les utilisateurs sans méthode MFA active et leur en faire enregistrer une avant le passage en mode actif. Depuis le retrait par Microsoft de la période de grâce de 14 jours en juillet 2024, un utilisateur sans méthode est bloqué dès la première connexion ; la phase rapport seul devient le seul moyen propre d’identifier ces utilisateurs avant l’activation. Cette discipline est le cœur de la mise en place sereine de l’accès conditionnel — l’omettre, c’est verrouiller des utilisateurs un lundi matin.

Étape 4 — Politique 2 : MFA renforcée pour les administrateurs

Les comptes administrateurs subissent un régime plus strict. La politique 2 impose la MFA à chaque connexion (pas tous les 90 jours, mais à chaque demande de jeton) pour les utilisateurs porteurs d’un rôle Entra ID privilégié : Global Administrator, Security Administrator, Conditional Access Administrator, Exchange Administrator, SharePoint Administrator, Privileged Role Administrator, User Administrator, Application Administrator, Cloud Application Administrator, Authentication Administrator, Helpdesk Administrator, Billing Administrator, Password Administrator.

Cette liste de rôles à inclure se sélectionne directement dans l’interface de création de la politique, sous Affectations → Identités cibles → Rôles d’annuaire. La cible reste Toutes les applications cloud. Le contrôle est Accorder, exiger MFA, et on ajoute un contrôle de session Fréquence de connexion → Chaque fois. Cette dernière option oblige les administrateurs à refaire l’authentification multifacteur à chaque session admin, ce qui réduit drastiquement la fenêtre d’exploitation d’un jeton volé.

On exclut là aussi les comptes break-glass de cette politique. C’est la seule exclusion : tous les autres administrateurs subissent la règle, y compris l’administrateur principal de l’organisation. La rigueur sur ce point conditionne la sécurité globale — les comptes administrateurs sont la cible privilégiée du phishing ciblé.

Étape 5 — Politique 3 : Bloquer l’authentification héritée

L’authentification héritée regroupe les protocoles qui ne supportent pas la MFA : POP, IMAP, SMTP basique, EWS basique, ActiveSync basique. Tant qu’ils sont autorisés, n’importe quel attaquant peut tenter du credential stuffing en boucle sans déclencher la MFA, parce que le serveur accepte simplement le couple identifiant/mot de passe. Bloquer ces protocoles est le geste de sécurité le plus rentable ; il ferme à lui seul environ 90 % des compromissions de boîtes mail observées par Microsoft.

La politique cible Tous les utilisateurs avec exclusion des comptes break-glass et de tout compte de service identifié comme dépendant d’un protocole hérité (à inventorier au préalable et à migrer vers une authentification moderne avant la mise en production de la politique). La cible est Toutes les applications cloud. La condition est Applications clientes → Clients d’authentification hérités, en cochant Clients Exchange ActiveSync et Autres clients. Le contrôle d’accès est Bloquer l’accès.

Avant l’activation, on consulte le rapport Connexions → Filtre Application cliente → Authentification héritée sur les 30 derniers jours. Si des utilisateurs apparaissent, on remonte la chaîne : téléphone Android avec un client mail générique au lieu d’Outlook, scanner réseau qui envoie via SMTP basique, application métier ancienne. Chaque cas se traite individuellement en migrant vers Outlook mobile, en passant le scanner sur SMTP avec OAuth, ou en créant une exception nominative pour l’application métier le temps de la moderniser.

Étape 6 — Politique 4 : Restriction géographique

La quatrième politique restreint les connexions à un ensemble de pays opérationnels. Pour une PME dont les collaborateurs travaillent au Sénégal, en Côte d’Ivoire et en France (déplacements professionnels), on autorise ces trois pays et on bloque les autres. Cette politique ne remplace pas la MFA ; elle empile une restriction géographique qui bloque les attaques de credential stuffing depuis des géographies improbables.

On commence par créer un emplacement nommé dans Entra → Sécurité → Accès conditionnel → Emplacements nommés → Nouvel emplacement. On choisit Pays et on coche les pays autorisés. On nomme cet emplacement Pays opérationnels. La politique d’accès conditionnel cible Tous les utilisateurs sauf break-glass, Toutes les applications cloud, condition Emplacements → N’importe quel emplacement en exclusion Pays opérationnels. Le contrôle d’accès est Bloquer l’accès.

Les voyageurs qui se déplacent ponctuellement hors des pays opérationnels demandent une exception nominative en amont. La pratique courante consiste à créer un groupe de sécurité Voyageurs internationaux exclu de cette politique géographique, et à y ajouter temporairement les collaborateurs en déplacement. À leur retour, on les retire. Ce processus manuel est volontairement frictionnel — il rend visible chaque exception au lieu de l’automatiser.

Étape 7 — Mode rapport seul, période d’observation

Les quatre politiques sont créées en mode Rapport seul. Pendant 7 jours, on consulte chaque jour le rapport Surveillance → Connexions avec le filtre Politique appliquée → Rapport seul. Le rapport montre, pour chaque connexion observée, quelles politiques se seraient appliquées et avec quel résultat. On vérifie quatre choses : aucun compte break-glass n’apparaît dans les résultats des politiques (il doit être totalement exclu), les administrateurs touchent bien la politique 2, l’authentification héritée est bien identifiée par la politique 3, les pays exotiques sont bien identifiés par la politique 4.

Les ajustements se font sans contrainte pendant cette période — on retouche les exclusions, on ajoute un emplacement, on revoit la liste des rôles. Au bout de 7 jours sans surprise, on bascule chaque politique de Rapport seul à Activé dans cet ordre : politique 1 (MFA pour tous), politique 2 (MFA admin renforcée), politique 3 (blocage authentification héritée), politique 4 (restriction géographique). On ne bascule pas tout en même temps : une politique par jour pendant 4 jours, en surveillant le centre des connexions après chaque activation.

Étape 8 — Vérification post-activation

Une fois les politiques actives, on contrôle leur effet réel.

# Inventaire des politiques d'accès conditionnel actives
Connect-MgGraph -Scopes "Policy.Read.All"
Get-MgIdentityConditionalAccessPolicy |
  Where-Object { $_.State -eq "enabled" } |
  Select-Object DisplayName, State, @{n='Users';e={$_.Conditions.Users.IncludeUsers -join ","}}, @{n='Apps';e={$_.Conditions.Applications.IncludeApplications -join ","}} |
  Format-Table -AutoSize

Le rapport doit afficher les quatre politiques en état enabled. Si l’une d’elles apparaît en enabledForReportingButNotEnforced, c’est qu’elle est encore en mode rapport seul — on la bascule. Le test pratique consiste à se connecter avec un compte utilisateur ordinaire : la MFA doit être demandée, et un test de connexion en SMTP basique doit échouer immédiatement avec une erreur d’authentification refusée. Une connexion depuis un VPN qui sort dans un pays exclu (par exemple un VPN en Russie) doit être bloquée avec un message indiquant Accès refusé en raison d’une politique d’accès conditionnel.

Erreurs fréquentes

Erreur	Cause	Solution
Tous les administrateurs verrouillés	Aucun compte break-glass exclu, ou inversion des inclusions/exclusions	Toujours créer le break-glass AVANT toute politique, l’exclure de toutes les politiques
Politiques en conflit silencieux	Security Defaults toujours actif	Désactiver Security Defaults dès qu’on configure l’accès conditionnel
Comptes de service bloqués par MFA	Les comptes de service ne peuvent pas faire MFA	Migrer vers identités gérées Azure ou créer une exclusion ciblée
Authentification héritée toujours utilisée par un scanner	Inventaire incomplet avant blocage	Inventorier 30 jours en amont, migrer chaque cas avant activation
Voyage à l’étranger non préparé	Pas de processus d’exception géographique	Groupe Voyageurs exclu, ajout/retrait à chaque déplacement
Trop de fenêtres MFA jugées intrusives	Fréquence de connexion trop courte	14 jours pour les utilisateurs ordinaires, à chaque session pour les admins

FAQ

Que faire si l’accès conditionnel n’est pas disponible (pas de licence P1) ?

On reste sur Security Defaults, qui impose la MFA aux administrateurs et la rend disponible pour les utilisateurs. C’est mieux que rien, mais on ne peut ni bloquer l’authentification héritée précisément, ni imposer une MFA à chaque connexion admin, ni restreindre par géographie. Pour une PME qui manipule des données sensibles, le palier P1 (Microsoft 365 Business Premium) est l’investissement minimal recommandé.

Combien de politiques peut-on avoir au maximum ?

La limite documentée est de 195 politiques actives par locataire. En pratique, un environnement bien gouverné fonctionne avec 10 à 20 politiques. Au-delà de 30, la maintenance devient pénible et les conflits silencieux entre politiques se multiplient.

Comment tester une politique sans risquer de se verrouiller ?

Outre le mode Rapport seul, l’outil What If dans le centre Entra simule l’application des politiques pour un utilisateur, une application et un contexte donnés. Avant chaque modification importante, on lance What If sur un compte test pour vérifier que le comportement attendu est bien celui qu’on obtient.

L’accès conditionnel s’applique-t-il aux applications hors Microsoft 365 ?

Oui, à condition que l’application soit fédérée à Entra ID via SAML, OIDC ou la galerie d’applications Entra. Une fois fédérée, elle apparaît dans la liste des applications cloud sélectionnables dans une politique. Les applications qui ont leur propre annuaire et ne s’authentifient pas via Entra ID restent hors du périmètre.

Quelle différence avec l’accès conditionnel basé sur le risque ?

L’accès conditionnel basé sur le risque utilise le score de risque calculé par Microsoft Entra ID Protection (utilisateur compromis, connexion suspecte, voyage impossible, fuite d’identifiants). Cette fonctionnalité requiert Entra ID P2 (incluse dans Microsoft 365 E5, en supplément des plans Business). Pour une PME, P2 est rarement nécessaire au démarrage ; les quatre politiques de ce tutoriel couvrent l’essentiel sans P2.

Accès conditionnel Microsoft Entra ID : 4 politiques de référence