Si tu administres un tenant Microsoft Entra ID, une échéance mérite ton attention avant l’été : à partir du 15 juin 2026, Microsoft change la façon dont les Conditional Access policies gèrent les exclusions de ressources. Le changement corrige une vraie faille de sécurité, mais il peut aussi bloquer des applications qui fonctionnaient sans souci jusque-là si tu ne l’anticipes pas. Voici ce qui change, pourquoi, et comment vérifier que ton tenant est prêt.
Le problème que ce changement corrige
Jusqu’à présent, quand une Conditional Access policy ciblait « All resources » (toutes les ressources) tout en excluant certaines applications, ces applications exclues échappaient aussi à l’enforcement sur ce que Microsoft appelle les baseline scopes — des permissions considérées comme peu sensibles par défaut : lecture du profil de l’utilisateur (User.Read, profile, openid…), appartenance aux groupes, informations de base sur les collègues.
Concrètement, ça veut dire qu’une application desktop comme Azure CLI ou VS Code, qui ne demande que ces scopes basiques, pouvait passer complètement à côté de tes politiques MFA — même sur un tenant où la MFA est censée être obligatoire pour tout le monde. À partir du 15 juin 2026, ces baseline scopes sont évalués comme un accès normal à l’annuaire, et donc soumis aux Conditional Access policies même en présence d’exclusions.
Qui est concerné ?
- Les applications qui ne demandent que des baseline scopes (OIDC :
email,offline_access,openid,profile; annuaire :User.Read,User.Read.All,User.ReadBasic.All,People.Read,People.Read.All,GroupMember.Read.All,Member.Read.Hidden) - Les policies ciblant « All resources » avec des exclusions de ressources configurées
Si tes applications demandent déjà des scopes plus larges (Mail.Read, Files.ReadWrite, etc.), rien ne change pour toi : elles étaient déjà soumises à l’enforcement.
Comment vérifier si ton tenant est concerné
1. Repérer les policies à risque
Dans le portail Entra, filtre tes Conditional Access policies pour identifier celles qui ciblent « All resources » avec au moins une exclusion d’application. Ce sont les seules concernées par le changement.
2. Auditer les connexions réelles avec Microsoft Graph
Pour savoir quelles applications de ton tenant s’appuient sur ces exclusions, tu peux interroger les logs de connexion via l’API Microsoft Graph :
GET https://graph.microsoft.com/beta/auditLogs/signIns?$filter=createdDateTime ge 2026-05-26T00:00:00Z and createdDateTime lt 2026-05-27T00:00:00Z and conditionalAccessAudiences/any(a:a eq '<ton-app-id>')&$select=createdDateTime,appId,appDisplayName,userDisplayName,userPrincipalName,ipAddress,conditionalAccessStatusSi tu préfères scripter cet audit plutôt que de passer par des requêtes REST brutes, le module PowerShell Microsoft Graph (Microsoft.Graph.Reports) permet de faire la même chose avec des cmdlets plus lisibles à intégrer dans un script de contrôle régulier — on détaille les bases de l’automatisation PowerShell côté administration système dans notre guide complet PowerShell pour administrateurs.
3. Tester avant le 15 juin
Microsoft permet d’activer l’enforcement dès maintenant, avant la bascule automatique, pour tester son impact dans un tenant de test ou avec un groupe pilote. C’est l’option la plus sûre : tu identifies les applications qui vont réclamer un défi MFA avant que ça n’arrive en production sans prévenir.
Tes trois options
Option A — Activer l’enforcement (recommandé)
Depuis les paramètres Baseline scopes, connecte-toi avec un rôle Conditional Access Administrator, sélectionne « Enable enforcement », puis confirme. C’est l’option qui referme la faille de sécurité pour de bon.
Option B — Personnaliser par application (approche hybride)
Si une application métier a vraiment besoin de rester exclue, crée une application « placeholder » dédiée dans Entra ID, exclus-la explicitement des policies concernées, puis configure ce comportement personnalisé dans les paramètres Baseline scopes plutôt que de désactiver l’enforcement pour tout le monde.
Option C — Désactiver l’enforcement
Techniquement possible, mais déconseillé : ça revient à conserver la faille corrigée par ce changement. À réserver aux cas de blocage critique le temps de trouver une solution propre.
Et si tu ne fais rien ?
L’enforcement s’active automatiquement à partir du 15 juin 2026, en rollout progressif sur plusieurs semaines. Si tu n’as pas d’exclusions configurées sur tes policies « All resources », ce changement ne te concerne tout simplement pas. Si tu en as, mieux vaut avoir testé et anticipé plutôt que de découvrir un blocage de connexion un lundi matin.
FAQ
Ce changement s’applique-t-il à toutes les licences Entra ID ?
Les Conditional Access policies nécessitent Microsoft Entra ID P1 au minimum ; le changement d’enforcement s’applique à tout tenant utilisant déjà ce type de policies avec des exclusions de ressources, quelle que soit la volumétrie.
Comment savoir si mes comptes de secours (break-glass) sont concernés ?
Les comptes d’urgence doivent rester exclus de toutes tes policies Conditional Access par principe, y compris de celle-ci — ce changement ne remet pas en cause cette bonne pratique fondamentale, tant que l’exclusion reste documentée et surveillée.
Où suivre les prochaines évolutions des Conditional Access policies ?
Le blog officiel Microsoft Entra sur Tech Community et la documentation Microsoft Learn dédiée à ce changement sont mis à jour au fil du rollout.
En résumé
Ce changement d’enforcement referme une faille bien réelle, mais il demande une vérification active de ta part avant le 15 juin 2026 si tes policies « All resources » comportent des exclusions. Prends le temps d’auditer tes applications, de tester en mode pilote, et de documenter les exceptions que tu choisis de garder. Pour construire tes politiques Conditional Access sur des bases solides dès le départ, la documentation Microsoft Learn sur la planification du déploiement reste la référence à suivre, phase par phase.
Laisser un commentaire