Objectif
Créer une stratégie d’accès conditionnel Microsoft Entra avec un périmètre pilote contrôlé, la placer d’abord en mode report-only, vérifier son effet dans les journaux de connexion et l’outil What If, puis l’activer par étapes en conservant des comptes d’accès d’urgence exclus et testés.
Prérequis
- Licence Microsoft Entra ID permettant Conditional Access pour les utilisateurs ciblés.
- Rôle Conditional Access Administrator ou privilège équivalent.
- Deux comptes d’accès d’urgence cloud-only protégés et surveillés selon la politique de l’organisation.
- Groupe pilote avec quelques utilisateurs représentatifs et méthodes MFA déjà enregistrées si la stratégie les exige.
- Accès aux sign-in logs et, si utilisé, au classeur Insights and Reporting.
Procédure pas à pas
Définir le contrôle précis à tester
Écrivez l’objectif en une phrase : exiger MFA pour une population, imposer un appareil conforme, bloquer un type de plateforme ou protéger une application. Une policy doit rester compréhensible. Évitez de combiner trop de conditions lors du premier pilote, car il deviendrait difficile de savoir quelle condition provoque un échec.
- Le cas d’usage et le résultat attendu sont mesurables.
Valider les comptes d’accès d’urgence
Connectez-vous avec les comptes break-glass avant le changement et confirmez qu’ils ne dépendent pas du même mécanisme MFA ou du même appareil que les comptes ordinaires, selon votre design de résilience. Placez-les dans une exclusion explicite de la future stratégie. Surveillez leur utilisation et n’en faites pas des comptes d’administration quotidiens.
- Au moins un chemin d’administration d’urgence est réellement testé et exclu.
Créer un groupe pilote représentatif
Utilisez un groupe contenant quelques utilisateurs et appareils couvrant les principaux scénarios : poste géré, mobile, utilisateur distant, application cible. Ne commencez pas par All users. Ajoutez un compte de test dédié afin de reproduire facilement un échec sans perturber un utilisateur métier.
- Le groupe pilote permet de tester les conditions principales sans toucher toute l’organisation.
Créer la stratégie avec un nom explicite
Dans Microsoft Entra admin center, ouvrez Entra ID > Conditional Access > Policies et créez une nouvelle policy. Utilisez une convention comme CA-PILOT-MFA-AllResources-v1. Ciblez le groupe pilote et excluez les comptes d’urgence. Choisissez les ressources, conditions et contrôles d’octroi conformément à l’objectif. Évitez de recopier une policy trouvée ailleurs sans vérifier votre tenant.
- Le ciblage inclut uniquement le pilote et les exclusions de secours sont visibles.
Enregistrer d’abord en Report-only
Positionnez Enable policy sur Report-only. Microsoft recommande ce mode pour évaluer l’impact avant activation. La stratégie sera évaluée dans les connexions mais ne bloquera pas l’utilisateur ni ne lui imposera réellement le contrôle. Laissez générer suffisamment de connexions réelles pour obtenir des données pertinentes.
- La policy apparaît en Report-only et aucune enforcement involontaire n’a lieu.
Utiliser What If et les sign-in logs
Testez plusieurs combinaisons utilisateur/application/emplacement dans l’outil What If, puis ouvrez les sign-in logs d’utilisateurs pilotes. Dans chaque connexion, consultez l’onglet Conditional Access et les résultats Report-only. Cherchez les cas Success, Failure, Not applied et les raisons. Comparez avec les autres policies qui peuvent déjà imposer MFA ou conformité.
- Chaque scénario du plan de test possède un résultat attendu et observé.
Corriger le ciblage avant enforcement
Si des utilisateurs ou applications inattendus sont concernés, modifiez la policy elle-même plutôt que d’ajouter immédiatement des exclusions individuelles. Vérifiez les groupes dynamiques, les rôles, les plateformes et les ressources ciblées. Pour une exigence MFA, confirmez que les utilisateurs pilotes disposent d’une méthode enregistrée et d’un parcours de secours conforme.
- Aucun impact inattendu connu ne subsiste dans les résultats report-only.
Activer la policy uniquement pour le pilote
Lorsque les résultats sont stables, passez la policy à On en conservant le groupe pilote comme seul périmètre. Informez les utilisateurs pilotes et prévoyez un canal de support. Testez une connexion propre, une session déjà ouverte et les applications mobiles ou clients lourds concernés. Ne généralisez pas immédiatement après un seul succès.
- Le contrôle s’applique réellement aux comptes pilotes et les applications critiques restent utilisables.
Étendre progressivement et surveiller
Ajoutez les groupes par vagues après une période d’observation. Microsoft recommande un déploiement progressif et l’analyse des sign-in logs. Suivez le taux d’échec, les tickets et les applications qui ne supportent pas le contrôle choisi. Conservez la policy originale lisible plutôt que de créer de nombreuses variantes quasi identiques.
- Chaque vague est validée avant la suivante et le support connaît la procédure de rollback.
Exporter la configuration et documenter le rollback
Conservez la description, le propriétaire, le ticket, les exclusions et les critères d’activation. Si vous automatisez l’inventaire via Graph, exportez régulièrement les policies pour disposer d’un état de référence. Le rollback standard d’une policy nouvellement déployée consiste à la désactiver ou, pour un cas ciblé, à exclure temporairement un groupe de confiance pendant la correction.
- La policy a un propriétaire, un motif, des exclusions justifiées et une procédure de désactivation.
Validation
La procédure est validée lorsque :
- Les comptes break-glass sont exclus et testés.
- La policy a été observée en report-only avant enforcement.
- What If et les sign-in logs confirment le périmètre et le résultat attendu.
- Le groupe pilote est fonctionnel après passage à On.
- L’extension à d’autres groupes est progressive et mesurée.
Retour arrière
- Passer immédiatement la policy à Off si un verrouillage généralisé ou un impact critique apparaît.
- Pour un incident limité, exclure temporairement le groupe concerné plutôt qu’un ensemble d’utilisateurs non maîtrisé, puis corriger la condition.
- Utiliser un compte d’urgence uniquement pour restaurer l’accès administratif, puis analyser pourquoi la policy a bloqué les comptes normaux.
- Conserver les sign-in logs de l’incident avant de modifier plusieurs stratégies à la fois.
Dépannage / erreurs fréquentes
- Policy Not applied : vérifier groupe, ressource, plateforme, emplacement et exclusions.
- Report-only Failure sans blocage réel : comportement normal ; le contrôle n’est pas appliqué en report-only.
- Utilisateur pilote bloqué alors que la nouvelle policy est en report-only : une autre policy active impose probablement le contrôle.
- MFA impossible : vérifier l’enregistrement des méthodes, Authentication Methods Policy et les autres conditions Conditional Access.
- Accès d’urgence également bloqué : utiliser le second compte de secours puis corriger immédiatement l’exclusion.