05 · Planifier, implémenter et gérer Microsoft Entra Conditional Access

Version : 1.1 · Date : 2026-10-22 · Domaine 2 de l'examen : Implement authentication and access management (25 à 30 %)

En une phrase : au niveau administrateur, Conditional Access se pilote comme un produit : un jeu de stratégies conçu par personas, créé depuis des templates ou en code, testé en Report-only et avec What If, dépanné dans les sign-in logs, et protégé lui-même par des protected actions.

Le principe (signaux, décision, application), l'ordre d'évaluation, le Report-only et la CAE sont expliqués dans SC-500 · 3. Conditional Access. Ce chapitre ne les redit pas : il va au niveau de l'administrateur qui conçoit, déploie et dépanne.

Note sur le poids : le guide SC-300 annonce 25 à 30 % pour ce domaine dans « Skills at a glance » et 20 à 25 % dans le titre de la section détaillée. Le cours retient 25 à 30 %.

Ce que l'examen demande#

Bloc Plan, implement, and manage Microsoft Entra Conditional Access du guide d'étude SC-300 (compétences au 28/10/2026) :

1. Les bases d'administration#

2. Plan Conditional Access policies#

2.1 Penser personas, pas applications#

Créer une stratégie par application ne tient pas à l'échelle (et bute vite sur la limite de 240). Microsoft recommande de regrouper les applications qui ont les mêmes exigences pour les mêmes utilisateurs, et de raisonner par persona : tous les utilisateurs, administrateurs, guests, mobiles, comptes à risque, workload identities.

Microsoft propose un déploiement en trois phases, chaque stratégie passant au moins une semaine en Report-only :

2.2 Les questions à se poser pour chaque stratégie#

• Qui : quels users, groups, directory roles ou workload identities sont inclus, lesquels sont exclus ?
• Quoi : une application, une user action ou un authentication context ? Le filter for applications (sur des custom security attributes posés sur les enterprise apps) évite de lister les apps une par une et de dépasser la taille maximale du JSON d'une stratégie.
• Dans quelles conditions : plateformes, réseaux, types de client, attributs d'appareil, risque.
• Quel contrôle : Block, ou Grant avec quelles exigences, et quels session controls.

2.3 Le piège de la combinaison : un jeton est émis par défaut#

Si aucune stratégie ne déclenche de contrôle, le jeton est émis. Exemple Microsoft : une stratégie « FINANCE GROUP → PAYROLL APP → MFA » oblige les membres de Finance à faire la MFA, mais laisse les autres utilisateurs accéder sans MFA. Pour réserver l'application à Finance, il faut une deuxième stratégie : All users, exclude FINANCE GROUP → PAYROLL APP → Block.

Bonne pratique : au moins une stratégie sur chaque application, idéalement une base All users · All resources · MFA sans exclusion de ressource. Attention à Block + All resources dans une même stratégie : risque de verrouiller les administrateurs, et certaines ressources comme Microsoft Graph ne peuvent pas être exclues.

2.4 Les exclusions#

Tester les exclusions : un utilisateur exclu d'une stratégie MFA peut quand même recevoir une invite MFA à cause d'une autre stratégie.

2.5 Nommage et stratégies de secours#

Un nom doit dire, sans ouvrir la stratégie : un numéro, les apps, la réponse, qui, quand. Comme les stratégies n'ont pas d'attribut « propriétaire », on encode l'équipe dans le nom et on tient un registre à part. Exemple : CA10-AllApps-PhishingResistantMFA-Admins.

Les stratégies de secours (resilient access controls) sont créées désactivées et nommées pour sortir du lot : EM01 - ENABLE IN EMERGENCY: MFA Disruption [1/4] - Exchange SharePoint: Require Microsoft Entra hybrid join For VIP users.

3. Les assignments#

3.1 Users or workload identities#

Une stratégie qui cible des rôles ou des groupes n'est évaluée qu'à l'émission d'un jeton (SC-500 · 3.3).

3.2 Target resources#

Conditional Access s'applique aux ressources, pas aux clients publics (Outlook, Teams desktop) : on ne peut pas sélectionner une application cliente native. Exception : un confidential client qui demande un ID token est lui-même évalué.

3.3 Network : named locations#

Le condition Location a été renommée Network (sans changement de comportement). Choix possibles : Any network or location, All trusted networks and locations, All Compliant Network locations (Global Secure Access), Selected networks and locations.

Proxy ou VPN cloud : l'IP évaluée est celle du proxy ; l'en-tête X-Forwarded-For n'est pas utilisé. Microsoft recommande plutôt les contrôles d'appareil (compliant, hybrid joined) ou la source IP restoration de Global Secure Access.

Quand la location est-elle réévaluée ? À la connexion, puis à chaque renouvellement du jeton d'accès (environ toutes les heures) pour les apps à authentification moderne.

3.4 Conditions#

Protocol tracking : une session ouverte par device code flow ou authentication transfer reste marquée ; les renouvellements suivants, même par un autre flux, restent soumis aux stratégies Authentication flows. Erreur typique : AADSTS530036. Indice dans les sign-in logs : la propriété Original transfer method. Exclure la ressource Device Registration Service d'une stratégie qui bloque le device code flow sur All resources si ce flux sert à inscrire des appareils (Teams Rooms, par exemple).

4. Les grant controls#

Plusieurs contrôles : Require all the selected controls (par défaut, ET) ou Require one of the selected controls (OU). Pour une workload identity, Block access est le seul contrôle disponible.

5. Session management#

5.1 Sign-in frequency#

• Défaut Entra : fenêtre glissante de 90 jours ; Entra ne redemande rien tant que la posture de la session ne change pas (mot de passe changé, compte désactivé, appareil non conforme révoquent la session).
• Valeur en heures ou jours, ou Every time : réauthentification complète quand la session est évaluée, avec 5 minutes de tolérance d'horloge. À réserver aux cas sensibles (élévation PIM, inscription Intune, risque, Azure Virtual Desktop). Every time sans MFA peut créer une boucle de connexion.
• Sign-in frequency s'applique aussi à la MFA. Sur un appareil joint ou hybrid joined, le PRT est rafraîchi au plus toutes les 4 heures au déverrouillage, ce qui explique des invites « décalées ».
• Désactiver Remember MFA on trusted devices avant d'utiliser sign-in frequency.
• La configurable token lifetime pour les refresh et session tokens est retirée (30/01/2021) au profit de ces contrôles.

5.2 Persistent browser session#

Réponse à l'invite Stay signed in? : Always persistent ou Never persistent. Les cookies persistants restent utilisables jusqu'à expiration du jeton : Never persistent pour les appareils non gérés. L'invite elle-même se règle dans le Company branding.

5.3 Les autres session controls#

6. Device-enforced restrictions#

6.1 Exiger un appareil géré#

Deux grant controls imposent l'état de l'appareil : compliant (Intune) et Microsoft Entra hybrid joined. Le template Require compliant or Microsoft Entra hybrid joined device or multifactor authentication for all users les combine en OU avec la MFA. Attention : sur Mac, iOS et Android, une stratégie compliant device peut demander de choisir un certificat d'appareil.

6.2 App enforced restrictions pour les appareils non gérés#

Pour limiter plutôt que bloquer (lecture web seule, pas de téléchargement), on combine :

1. une stratégie CA avec le session control Use app enforced restrictions (template Use application enforced restrictions for unmanaged devices) ;
2. le réglage côté SharePoint admin center › Policies › Access control › Unmanaged devices (Allow limited, web-only access ou Block access), qui crée lui-même une stratégie CA ;
3. au besoin, site par site :

# SharePoint Online Management Shell : limiter un site sensible depuis les appareils non gérés
Set-SPOSite -Identity https://contoso.sharepoint.com/sites/finance -ConditionalAccessPolicy AllowLimitedAccess
# ou BlockAccess ; un site ne peut pas être plus permissif que le réglage de l'organisation

Les liens « Anyone » ne sont pas concernés par ces stratégies : les désactiver sur les sites protégés.

6.3 Filter for devices#

Règles à connaître :

• Un appareil non inscrit a tous ses attributs vides : un filtre à opérateur positif ne s'applique pas, un opérateur négatif s'applique. Pour viser les appareils non inscrits, utiliser un opérateur négatif.
• Les extensionAttributes ne sont lus que si l'appareil est géré par Intune, conforme ou hybrid joined.
• Au moins une propriété système ou configurée par l'administrateur ; règle de 3 072 caractères au plus.
• Exemple Microsoft pour les postes d'administration (PAW / SAW) : stratégie 1 « admins → Azure management → MFA et compliant » ; stratégie 2 « admins → Azure management → Block, en excluant les appareils extensionAttribute1 -eq "SAW" ».

7. Tester et dépanner#

7.1 Report-only et Policy impact#

En Report-only, la stratégie est évaluée sans être appliquée. Les résultats possibles :

Trois façons de lire l'impact : l'onglet Report-only d'une connexion dans les sign-in logs ; la vue Policy impact (Security Reader, sur 24 heures, 7 jours ou 1 mois) ; le Conditional Access Insights and reporting workbook.

Bonne pratique pour modifier une stratégie active : en créer une copie en Report-only avec la modification, comparer, puis mettre à jour l'originale. Passer une stratégie de On à Report-only désactive son application.

7.2 Le workbook Insights and reporting#

Il affiche le résumé d'impact (Total, Success, Failure, User action required, Not applied), la répartition par condition (device state, platform, client app, location, application, sign-in risk) et les connexions d'un utilisateur, sur 4 heures à 90 jours.

// Connexions bloquées par une stratégie Conditional Access, les 7 derniers jours (exemple construit sur les colonnes
// ConditionalAccessStatus et ConditionalAccessPolicies de SigninLogs)
SigninLogs
| where TimeGenerated > ago(7d)
| where ConditionalAccessStatus == "failure"
| mv-expand Policy = ConditionalAccessPolicies
| where tostring(Policy.result) == "failure"
| summarize Echecs = count() by Strategie = tostring(Policy.displayName), AppDisplayName
| order by Echecs desc

7.3 What If#

Entra ID › Conditional Access › Policies › What If. Il simule une connexion pour un user, une agent identity (preview) ou un service principal single tenant, et liste les stratégies qui s'appliquent (avec leurs contrôles) et celles qui ne s'appliquent pas (avec la première condition non remplie).

• Conditions obligatoires : identité, ressource cible, device platform, client app ; les autres valent none par défaut.
• N'évalue que les stratégies On ou Report-only.
• Indiquer l'App ID : les groupes d'apps (Office 365, Microsoft Admin Portals) ne correspondent pas.
• Ne teste pas les service dependencies (Teams → Exchange).
• Le nouvel outil s'appuie sur une API Graph publique (What If evaluation API) et demande tous les paramètres : une stratégie avec une condition non renseignée dans la simulation est donnée comme non applicable.
• Il signale aussi s'il reste des classic policies.

7.4 Les sign-in logs#

1. Collecter : UPN, nom, OS, horodatage, application, type de client, Correlation ID (bouton More details de la page d'erreur).
2. Entra ID › Monitoring & health › Sign-in logs (Reports Reader au minimum) : filtrer par Correlation ID, Conditional Access, utilisateur, date, ressource.
3. Onglet Conditional Access : chaque stratégie avec son résultat. Statut global : Success, Failure, Not applied ; par stratégie : Success, Failure, Not applied, Not enabled.
4. Onglet Troubleshooting and support : la cause est souvent explicite (appareil non conforme).
5. Audience : toutes les ressources réellement demandées pendant la connexion ; explique pourquoi une stratégie SharePoint s'applique à une connexion « Teams ».
6. Pour un service principal : onglet Service principal sign-ins.

Cas classiques : Windows Hello for Business et les scénarios d'amorçage (device registration, compliance) apparaissent Not applied ; une stratégie peut afficher Failure alors que la connexion réussit (Report-only, contrôles en OU, session control non applicable sur ce client).

flowchart TD
    A["Utilisateur bloqué"] --> B["Correlation ID via More details"]
    B --> C["Sign-in logs : onglet Conditional Access"]
    C --> D{"Une stratégie en Failure ?"}
    D -- "Oui" --> E["Ouvrir la stratégie : contrôle non satisfait ou Block"]
    D -- "Non" --> F["Vérifier l'Audience : service dependency ?"]
    E --> G{"Comportement attendu ?"}
    G -- "Non" --> H["Corriger la stratégie en Report-only, valider avec What If"]
    G -- "Oui" --> I["Accompagner l'utilisateur : inscription MFA, conformité"]
    F --> H

8. Continuous access evaluation (CAE)#

Le fonctionnement (événements critiques, jetons jusqu'à 28 heures, 15 minutes de propagation) est dans SC-500 · 3.4. Côté administrateur :

Déploiement du mode strict : stratégie de location testée sur un petit groupe, puis vérification de la colonne IP address (seen by resource) des sign-in logs (vide quand les deux IP sont identiques) et du workbook Continuous Access Evaluation Insights, ajout des IP de sortie manquantes aux named locations, et élargissement par vagues. À éviter avec des IP de sortie partagées ou inconnues, ou quand du trafic non Microsoft 365 passe par Global Secure Access.

# Révoquer toutes les sessions d'un utilisateur compromis (Microsoft Graph PowerShell)
Connect-MgGraph -Scopes "User.RevokeSessions.All"
Revoke-MgUserSignInSession -UserId "[email protected]"

9. Authentication context#

Un authentication context est une étiquette (c1 à c99) qu'une application ou un service demande au moment d'accéder à une donnée ou une action sensible ; la stratégie CA qui cible cette étiquette impose ses exigences à ce moment-là (step-up).

• Un authentication context fonctionne avec des users ou des workload identities, mais pas les deux dans la même stratégie.
• Pour supprimer un contexte : plus aucune stratégie assignée et Publish to apps décoché.
• Choisir des noms réutilisables (Trusted devices, Phishing-resistant) pour limiter le nombre de redirections.
• L'ID du contexte est la valeur émise dans la claim acrs du jeton d'accès, que l'application vérifie. La page Conditional Access dit « jusqu'à 99 authentication context definitions (c1-c99) » (réponse d'examen) ; la référence de la ressource Graph authenticationContextClassReference (v1.0) indique encore c1 à c25 : retenir que l'ID est de la forme cN.

# Créer (ou mettre à jour) l'authentication context c1 (Microsoft Graph PowerShell, v1.0)
Connect-MgGraph -Scopes "AuthenticationContext.ReadWrite.All"
$params = @{ displayName = "Phishing-resistant"; description = "Actions sensibles"; isAvailable = $true }   # isAvailable = Publish to apps
Update-MgIdentityConditionalAccessAuthenticationContextClassReference -AuthenticationContextClassReferenceId "c1" -BodyParameter $params

10. Protected actions#

Une protected action est une permission Microsoft Entra à laquelle on associe un authentication context : la stratégie CA s'applique au moment où l'administrateur exécute l'action, quel que soit le rôle qui lui donne la permission.

Mise en place, dans cet ordre (sinon boucle de réauthentification) :

1. rôle Conditional Access Administrator ou Security Administrator ;
2. créer l'authentication context et la stratégie CA qui le cible (ex. passwordless ou phishing-resistant MFA, en excluant un compte d'urgence) ;
3. Entra ID › Roles & admins › Protected actions : associer le contexte aux permissions ;
4. tester en effectuant l'action.

Protected actions ou PIM ? L'authentication context sur l'activation PIM protège l'obtention du rôle ; la protected action protège une action précise, indépendamment du rôle. Les deux se combinent. Une protected action ne sert pas à interdire une permission à quelqu'un : c'est le rôle qui décide qui a le droit. Licence : P1.

Bonnes pratiques Microsoft : migrer les stratégies de risque d'ID Protection vers Conditional Access et utiliser des named locations plutôt que les MFA trusted IPs, car ces anciens réglages ne passent pas par les permissions protégées.

sequenceDiagram
    actor A as Conditional Access Administrator
    participant P as Entra admin center
    participant E as Microsoft Entra ID
    A->>P: Modifier une stratégie CA
    P->>E: PATCH conditionalAccessPolicies
    E-->>P: Claims challenge, authentication context c1 requis
    P->>A: Invite de step-up
    A->>E: Clé FIDO2 (phishing-resistant MFA)
    E-->>P: Jeton avec acrs c1
    P->>E: PATCH rejoué
    E-->>P: Stratégie modifiée

11. Templates, Microsoft-managed policies et security defaults#

11.1 Créer depuis un template#

Entra ID › Conditional Access › Create new policy from templates. Catégories : Secure foundation, Zero Trust, Remote work, Protect administrator, Emerging threats, AI Agents.

Templates à connaître : Require MFA for admins · Securing security info registration · Block legacy authentication · Require MFA for admins accessing Microsoft admin portals · Require MFA for all users · Require MFA for Azure management · Require compliant or hybrid joined device or MFA · Require compliant device · Require MFA for guest access · MFA for risky sign-ins (P2) · Require password change for high-risk users (P2) · Block unknown or unsupported device platform · No persistent browser session · Require approved client apps or app protection policies · Use application enforced restrictions for unmanaged devices · Require phishing-resistant MFA for administrators · Block access for users with insider risk (Microsoft Purview).

11.2 Classic policies#

Les classic policies ne s'appliquent plus depuis le 10/07/2024. Migration : Conditional Access › Classic policies, documenter la configuration, la recréer (template ou custom, testée en Report-only), puis Disable (impossible de la réactiver ensuite).

11.3 Microsoft-managed policies#

Microsoft crée certaines stratégies dans les tenants éligibles, en Report-only, puis les active au plus tôt 30 jours après (préavis de 2 semaines par e-mail et Message center). On peut les activer plus tôt, les passer à Off ou exclure des utilisateurs, mais ni les renommer ni les supprimer. Exemples : Block legacy authentication · Block device code flow · MFA for admins accessing Microsoft Admin Portals · MFA for all users · MFA for per-user MFA users · MFA and reauthentication for risky sign-ins · Block access for high-risk users · Require remediation for high-risk users · Block all high risk agents (preview).

11.4 Passer des security defaults à Conditional Access#

1. Entra ID › Overview › Properties › Manage security defaults › Disabled (Conditional Access Administrator au minimum).
2. Recréer la base : MFA pour tous, MFA (ou phishing-resistant MFA) pour les admins, Block legacy authentication, MFA pour Azure management, ou s'appuyer sur les Microsoft-managed policies.
3. Avec P2 : ajouter les stratégies de risque.
4. Les utilisateurs en per-user MFA apparaissent Disabled dans la page d'état MFA quand la MFA vient des security defaults ou de Conditional Access : c'est normal. Voir aussi SC-500 · 11.8 et le chapitre 04.

11.5 Conditional Access Optimization Agent#

Avec Microsoft Security Copilot (SCU provisionnées) et P1, l'agent analyse les stratégies, signale les trous de couverture et propose des stratégies, au besoin créées en Report-only puis approuvées par un administrateur.

12. Gérer Conditional Access en code#

Démarche « policy as code » recommandée par Microsoft : source control, revue, intégration continue, retour arrière possible ; et les protected actions pour que personne ne modifie une stratégie sans step-up.

# Stratégie en Report-only : MFA résistante au hameçonnage pour les administrateurs (azuread ~> 3.10)
resource "azuread_conditional_access_policy" "admins_phishing_resistant" {
  display_name = "CA10-AllApps-PhishingResistantMFA-Admins"
  state        = "enabledForReportingButNotEnforced"

  conditions {
    client_app_types = ["all"]

    applications {
      included_applications = ["All"]
    }

    users {
      included_roles  = ["62e90394-69f5-4237-9190-012177145e10"] # Global Administrator (role template ID)
      excluded_groups = [var.groupe_comptes_urgence_id]           # comptes d'accès d'urgence
    }
  }

  grant_controls {
    operator                          = "OR"
    authentication_strength_policy_id = "/policies/authenticationStrengthPolicies/00000000-0000-0000-0000-000000000004" # Phishing-resistant MFA (built-in)
  }
}

Points d'attention du fournisseur : permissions Policy.ReadWrite.ConditionalAccess et Policy.Read.All (service principal) ou rôle Conditional Access Administrator ; limite de 1 requête par seconde sur cette API ; client_applications (service principals) demande des licences Workload ID Premium ; un filter d'applications demande le rôle Attribute Definition Reader.

L'ID …0004 de la force Phishing-resistant MFA intégrée est celui que l'on retrouve dans les exemples Microsoft Graph ; le vérifier dans le tenant (Get-MgPolicyAuthenticationStrengthPolicy) avant de l'utiliser.

13. Labs conseillés#

À faire dans un tenant de test (essai Microsoft Entra ID P1 / P2 de 30 jours), avec un compte d'urgence exclu de tout.

1. Jeu de base en Report-only
   • Créer depuis les templates Secure foundation : Require MFA for all users, Block legacy authentication, Require MFA for admins.
   • Ajouter le groupe des comptes d'urgence aux exclusions.
   • Se connecter avec un utilisateur de test, puis ouvrir la connexion › onglet Report-only.
   • Attendu : Report-only: User action required sur la stratégie MFA.
2. What If et Audience
   • Créer une named location « Pays autorisés » et une stratégie Block hors de ces pays, en Report-only.
   • Lancer What If pour l'utilisateur de test avec Office 365 puis avec l'App ID d'Exchange Online.
   • Attendu : le groupe Office 365 ne correspond pas dans What If, l'App ID oui ; dans les sign-in logs, l'Audience liste les ressources réelles.
3. Bloquer le device code flow
   • Stratégie Authentication flows › Device code flow › Block sur l'utilisateur de test, en On.
   • Lancer az login --use-device-code avec ce compte.
   • Attendu : connexion refusée ; dans les sign-in logs, l'Authentication protocol vaut Device code et la stratégie est en Failure.
4. Authentication context et protected actions
   • Créer c1 « Phishing-resistant », publié aux apps, et une stratégie qui l'exige (compte d'urgence exclu).
   • Associer c1 aux permissions conditionalAccessPolicies/basic/update dans Protected actions.
   • Modifier une stratégie depuis l'admin center, puis depuis Azure PowerShell.
   • Attendu : step-up dans le portail ; échec avec Azure PowerShell.
5. Stratégie en code
   • Déclarer la stratégie Terraform de la section 12 en enabledForReportingButNotEnforced, la déployer dans le tenant de test, puis la retrouver dans le portail.
   • Nettoyage : terraform destroy, puis vérifier dans Deleted policies (30 jours de soft delete).

Coût : essai P1 / P2 gratuit ; supprimer les stratégies de test et désactiver l'essai à la fin.

14. Les pièges d'examen#

15. Scénarios d'entraînement#

1. Contoso a 180 stratégies, une par application. Les nouvelles applications ne sont couvertes par aucune. Que recommander ?

Regrouper par personas et par exigences communes, avec une base All users · All resources · MFA sans exclusion de ressource ; utiliser le filter for applications (custom security attributes) pour les cas particuliers. Rester sous les 240 stratégies.

2. Une stratégie exige la MFA pour le rôle Helpdesk Administrator limité à l'AU Paris. Les membres ne sont jamais invités. Pourquoi ?

Conditional Access n'applique pas les attributions de rôle scoped à une administrative unit (ni les rôles custom). Cibler un groupe de ces administrateurs.

3. Les développeurs utilisent un service principal depuis GitHub Actions. On veut le bloquer en dehors des IP connues. Licence et configuration ?

Workload ID Premium ; stratégie Workload identities › service principal sélectionné directement, All resources, Network : Any sauf les IP connues, Grant : Block. Les managed identities ne sont pas couvertes.

4. Un utilisateur se plaint d'être bloqué dans Teams alors qu'aucune stratégie ne vise Teams. Démarche ?

Récupérer le Correlation ID, ouvrir la connexion dans les sign-in logs › onglet Conditional Access, regarder l'Audience : une stratégie sur SharePoint ou Exchange s'applique par service dependency. Cibler plutôt le groupe Office 365.

5. La direction veut que la modification d'une stratégie Conditional Access exige une clé FIDO2, même pour un Global Administrator actif en permanence. Solution ?

Créer un authentication context et une stratégie Phishing-resistant MFA qui le cible (compte d'urgence exclu), puis l'associer aux permissions conditionalAccessPolicies/* dans Protected actions. Licence P1.

6. Les commerciaux doivent pouvoir lire les documents SharePoint depuis leur ordinateur personnel, sans pouvoir les télécharger.

Use app enforced restrictions dans une stratégie CA, et SharePoint › Access control › Unmanaged devices › Allow limited, web-only access (ou Set-SPOSite … -ConditionalAccessPolicy AllowLimitedAccess sur les sites concernés). Désactiver les liens « Anyone ».

7. Les administrateurs Azure ne doivent accéder au portail et à la CLI que depuis des postes dédiés marqués SAW. Comment ?

Deux stratégies sur Windows Azure Service Management API : (1) MFA et compliant device ; (2) Block en excluant les appareils filtrés device.extensionAttribute1 -eq "SAW". Les attributs ne sont lus que sur des appareils gérés.

8. Avant d'activer une stratégie « Require compliant device » pour tous, que faire ?

La créer en Report-only, exclure les comptes d'urgence, analyser une semaine les résultats (User action required, Failure) dans Policy impact ou le workbook, tester avec What If, puis activer par vagues.

9. Un utilisateur est retiré d'un groupe exempté d'une stratégie. Deux heures après, il accède encore à Exchange sans MFA. Pourquoi et que faire ?

Les changements de groupe peuvent mettre jusqu'à un jour à être pris en compte par les ressources CAE. Revoke sessions (ou Revoke-MgUserSignInSession) pour forcer une nouvelle évaluation.

10. Le tenant a les security defaults activés et vient d'acheter Microsoft 365 E3. Les stratégies créées restent inactives. Démarche ?

Désactiver les security defaults (Properties › Manage security defaults), puis activer les stratégies de base (MFA pour tous, pour les admins, Block legacy authentication, MFA pour Azure management) ou les Microsoft-managed policies.

16. Pour aller plus loin#

• Resilient access controls : préparer des stratégies de secours désactivées (EM01…) et comprendre les resilience defaults.
• Universal CAE avec Global Secure Access et CAE pour Application Proxy : la CAE s'étend au trafic réseau et aux applications locales publiées (voir 06 et 07).
• Agents : templates AI Agents (bloquer les agent identities à risque élevé, stratégies pour les agents autonomes ou on-behalf-of) et cible All agent resources (preview).
• Coverage tab de Conditional Access : applications sans stratégie sur les 7 derniers jours.

17. Fiche à retenir#

• Licence P1 ; risque P2 ; service principals Workload ID Premium ; 240 stratégies ; 30 jours de soft delete.
• Lecture : Security Reader ; création : Conditional Access Administrator.
• Sans stratégie applicable, le jeton est émis : bloquer explicitement les autres.
• Directory roles : rôles intégrés seulement ; SP directement, pas via un groupe ; managed identities non couvertes.
• Windows Azure Service Management API couvre portail, ARM, Azure CLI et PowerShell, pas Graph PowerShell ni Azure DevOps.
• User action Register or join devices : MFA ou authentication strength seulement, réglage d'appareil à No.
• Named locations : 195, 2 000 plages, IP publique ; MFA trusted IPs déconseillées ; IP du proxy évaluée.
• Authentication flows : device code flow, authentication transfer, protocol tracking (AADSTS530036).
• Sign-in frequency : défaut 90 jours glissants ; Every time avec MFA ; désactiver Remember MFA.
• App enforced restrictions : Exchange et SharePoint, pour l'accès limité depuis l'appareil non géré.
• Filter for devices : opérateur négatif pour viser les non-inscrits ; extensionAttributes si l'appareil est géré.
• Report-only : Success, Failure, User action required, Not applied ; Policy impact ; workbook (P1 + Log Analytics).
• What If : identité, ressource, plateforme, client app obligatoires ; App ID ; pas de service dependencies.
• Sign-in logs : Correlation ID, onglet Conditional Access, Audience, Troubleshooting and support.
• CAE : Disable seulement avec All resources sans condition ; strict location : IP dédiées ; pas pour les guests.
• Authentication context c1 à c99, Publish to apps ; users ou workload identities, pas les deux.
• Protected actions : contexte + stratégie avant, P1, Graph PowerShell oui, Azure PowerShell non.
• Templates : Report-only, n'excluent que le créateur, export JSON ; classic policies mortes depuis le 10/07/2024.
• Microsoft-managed policies : activées 30 jours au plus tôt, on peut les mettre Off, pas les supprimer.

Références#

Toutes lues le 21/10/2026 sur Microsoft Learn et le registre Terraform :

• Study guide for Exam SC-300
• Plan a Conditional Access deployment
• Build a Conditional Access policy
• Conditional Access: Target resources
• Conditional Access: Network assignment
• Conditional Access: Filter for devices
• Conditional Access: Authentication flows
• Block authentication flows with Conditional Access policy
• Conditional Access: Session
• Conditional Access adaptive session lifetime policies
• Token Protection in Microsoft Entra Conditional Access
• Use application enforced restrictions for unmanaged devices
• SharePoint and OneDrive unmanaged device access controls
• Analyze Conditional Access policy impact (report-only)
• Conditional Access insights and reporting
• Troubleshoot Conditional Access policies with the What If tool
• Troubleshoot sign-in problems with Conditional Access
• Sign-in log activity details
• Continuous access evaluation
• Strictly enforce location policies using continuous access evaluation
• Conditional Access for workload identities
• What are protected actions in Microsoft Entra ID?
• Conditional Access policy templates
• Microsoft-managed Conditional Access policies
• Security defaults in Microsoft Entra ID
• New-MgIdentityConditionalAccessPolicy
• Update-MgIdentityConditionalAccessAuthenticationContextClassReference
• azuread_conditional_access_policy (azuread 3.10.0)