Conditional Access : passer de Report-only à Enforced sans bloquer l’entreprise

Report-only est un banc d’essai, pas une protection

Une politique Conditional Access en mode Report-only est évaluée pendant les connexions, mais ses contrôles d’octroi et de session ne sont pas appliqués. Elle révèle quels utilisateurs, applications, appareils et emplacements seraient touchés sans encore bloquer l’accès. Sa valeur dépend donc de la qualité de l’analyse et d’une date de sortie claire.

Passer directement de l’observation à une portée Tous les utilisateurs, Toutes les ressources peut verrouiller l’administration, interrompre un client ancien ou révéler une dépendance invisible entre services. La méthode sûre combine comptes d’urgence, inventaire, journaux, What If, essais réels et anneaux de déploiement.

• Microsoft — Analyser l’impact de Conditional Access ↗
• Guide connexe — Comptes d’urgence Entra ID →

1. Fixer les prérequis avant de changer l’état

Une exclusion d’urgence ne doit pas devenir une échappatoire quotidienne. Ces comptes doivent utiliser une authentification résistante à l’hameçonnage, rester inutilisés en temps normal et déclencher une alerte à chaque activité.

• Confirmer les licences : Conditional Access exige Microsoft Entra ID P1; les politiques fondées sur le risque utilisateur ou de connexion exigent P2.
• Maintenir au moins deux comptes d’urgence infonuagiques, exclus de toutes les politiques Conditional Access, surveillés et testés.
• S’assurer que les utilisateurs pilotes ont enregistré les méthodes requises et que les appareils attendus peuvent atteindre l’état conforme.
• Conserver un administrateur capable d’annuler le changement depuis un poste sécurisé, sans utiliser son compte quotidien.
• Définir propriétaire, justification, fenêtre, critères de réussite, seuil d’arrêt et procédure de retour arrière.

• Microsoft — Planifier Conditional Access ↗
• Microsoft — Gérer les comptes d’accès d’urgence ↗

2. Inventorier et sauvegarder les politiques

Avant le changement, exportez toutes les politiques et consignez leurs groupes, rôles, ressources, exclusions, conditions, contrôles et état. Recherchez les chevauchements : plusieurs politiques peuvent s’appliquer à une connexion et leurs exigences se cumulent. Une exclusion dans une politique n’annule pas les exigences d’une autre.

Utilisez une convention comme CA01-AllApps-AllUsers-RequireMFA et tenez un registre externe avec propriétaire, billet de changement et date de révision. L’objet Conditional Access ne possède pas de champ propriétaire destiné à cette gouvernance.

Connect-MgGraph -Scopes 'Policy.Read.All','Directory.Read.All'
$stamp = Get-Date -Format 'yyyyMMdd-HHmmss'
$folder = Join-Path $env:TEMP "CA-export-$stamp"
New-Item -ItemType Directory -Path $folder | Out-Null

$policies = Get-MgIdentityConditionalAccessPolicy -All
$policies | Select-Object Id,DisplayName,State,CreatedDateTime,ModifiedDateTime |
  Export-Csv (Join-Path $folder 'policies.csv') -NoTypeInformation -Encoding utf8
$policies | ConvertTo-Json -Depth 30 |
  Set-Content (Join-Path $folder 'policies.json') -Encoding utf8

$policies | Group-Object State | Select-Object Name,Count

• Microsoft Graph — Ressource conditionalAccessPolicy ↗
• Guide — Microsoft Graph PowerShell →

3. Lire correctement les résultats Report-only

Le mode Report-only ne déclenche pas une invite MFA ni l’acceptation des conditions d’utilisation. User action required signifie donc que l’utilisateur devra agir une fois la politique active, pas qu’il sera nécessairement bloqué. À l’inverse, une exigence d’appareil conforme peut afficher une invite de certificat répétée sur macOS, iOS ou Android même en Report-only; Microsoft recommande d’exclure ces plateformes pendant ce test si cette invite pose problème.

Dans Entra, ouvrez Monitoring & health > Sign-in logs, sélectionnez une connexion, puis les onglets Conditional Access et Report-only. Examinez l’application cliente, la ressource réellement demandée, le type de client, l’appareil, l’emplacement, la méthode d’authentification et l’identifiant de corrélation.

• Microsoft — Dépanner les connexions Conditional Access ↗

4. Mesurer les tendances, pas seulement quelques événements

Le classeur Conditional Access Insights and reporting compare les politiques actives et Report-only par utilisateur, application et période. Il nécessite Entra ID P1, un espace Log Analytics et l’acheminement des journaux de connexion. Utilisez-le pour repérer un service oublié ou une population surreprésentée, puis retournez aux événements individuels pour comprendre la cause.

La requête suivante déplie les résultats de chaque politique. Remplacez le nom par celui de votre politique et analysez les catégories plutôt qu’un seuil universel. Les données n’existent qu’à partir du moment où les journaux sont acheminés à l’espace.

let PolicyName = "CA01-AllApps-AllUsers-RequireMFA";
SigninLogs
| where TimeGenerated > ago(14d)
| mv-expand Policy = ConditionalAccessPolicies
| extend PolicyNameObserved = tostring(Policy.displayName),
         PolicyResult = tostring(Policy.result)
| where PolicyNameObserved == PolicyName
| summarize SignIns=count(), Users=dcount(UserPrincipalName)
    by PolicyResult, AppDisplayName, ClientAppUsed
| order by SignIns desc

• Microsoft — Classeur Insights and reporting ↗

5. Compléter avec What If et des scénarios réels

What If simule les politiques applicables à une identité, une ressource, une plateforme, une adresse IP et d’autres signaux. Testez au minimum un employé, un administrateur, un invité, chaque plateforme, un site distant, un réseau non fiable et les principales applications. L’outil explique la portée; il ne remplace pas une connexion réelle dans un environnement correctement configuré.

Teams peut demander des jetons pour Exchange, SharePoint et d’autres ressources. Une politique visant une dépendance peut interrompre une fonction même si l’utilisateur pense accéder seulement à Teams. Les journaux d’audience et un essai de bout en bout sont indispensables.

• Microsoft — Outil What If ↗

6. Traiter les dépendances avant l’application

Les identités de charge de travail utilisent leurs propres politiques Conditional Access et leur propre modèle de licence. Ne supposez pas qu’une politique utilisateur protège les principaux de service. Inventoriez séparément comptes de service, connecteurs, tâches, appareils partagés et flux de code d’appareil.

• Microsoft — Conditional Access pour les identités de charge de travail ↗
• Guide — Postes d’administration sécurisés →

7. Utiliser des exclusions temporaires et traçables

Une exclusion large transforme rapidement une politique efficace en contrôle théorique. Préférez un groupe statique temporaire par problème, avec propriétaire, justification, date d’expiration et alerte sur les changements d’appartenance. Corrigez ensuite la cause et retirez l’exception.

Les emplacements nommés sont un signal, pas une preuve d’identité. Exclure tout le réseau du bureau d’une exigence MFA permet à un appareil compromis sur ce réseau de profiter de la même confiance. Utilisez cette exception seulement si le risque résiduel est accepté et documenté.

8. Déployer par anneaux avec des critères de sortie

Microsoft recommande au moins une semaine en Report-only pour chaque politique, mais la fenêtre doit couvrir votre cycle réel : employés en congé, tâches mensuelles, voyages et applications rarement utilisées. Changez une politique ou un petit ensemble cohérent à la fois; autrement, la cause d’un blocage devient difficile à isoler.

Conditional Access ne réalise pas un véritable test A/B de deux variantes actives. Ciblez des groupes pilotes ordonnés et conservez une copie Report-only de la modification proposée lorsque vous devez la comparer à une politique déjà active.

9. Procédure d’activation contrôlée

L’état Graph de Report-only est enabledForReportingButNotEnforced; l’état appliqué est enabled. L’exemple suivant est volontairement en lecture seule afin d’éviter une activation accidentelle. Le changement doit rester une opération approuvée, idéalement protégée par Protected Actions et exécutée avec le rôle Conditional Access Administrator plutôt qu’Administrateur général.

• Geler la configuration analysée et joindre l’export JSON au changement.
• Revalider l’exclusion et la connexion des deux comptes d’urgence.
• Confirmer les critères de sortie du pilote et les coordonnées du soutien.
• Passer la politique ciblée de Report-only à On pendant une fenêtre surveillée.
• Exécuter immédiatement les scénarios positifs et négatifs du plan de test.
• Surveiller échecs, appels, applications et populations touchées pendant la vague.
• Élargir seulement lorsque les preuves correspondent aux attentes.

$policyName = 'CA01-AllApps-AllUsers-RequireMFA'
$policy = Get-MgIdentityConditionalAccessPolicy -All |
  Where-Object DisplayName -eq $policyName

if (-not $policy) { throw "Policy not found: $policyName" }
if (@($policy).Count -ne 1) { throw "Policy name is not unique" }

$policy | Select-Object Id,DisplayName,State,CreatedDateTime,ModifiedDateTime
if ($policy.State -ne 'enabledForReportingButNotEnforced') {
  throw "Expected report-only state; no change should proceed"
}

10. Préparer un retour arrière précis

Si une vague provoque un blocage critique, utilisez un compte d’urgence depuis le poste prévu et remettez uniquement la politique fautive en Report-only ou Disabled. Une exclusion temporaire d’un groupe fiable peut dépanner un cas circonscrit, mais elle doit être retirée rapidement. Ne désactivez pas tout Conditional Access pour réparer une application.

Conservez l’heure, l’identifiant de corrélation, l’utilisateur, l’application, la ressource et le code d’erreur. Les erreurs AADSTS53000 à 53004 orientent notamment vers conformité, jonction, application approuvée, blocage CA ou risque. Après stabilisation, corrigez la dépendance, rejouez le pilote et documentez la décision.

• Microsoft — Retour arrière Conditional Access ↗

Checklist de décision avant Enforced

Le but n’est pas d’obtenir zéro événement Report-only, mais de comprendre chaque catégorie significative. Une bonne politique est exigeante pour l’attaquant, prévisible pour l’utilisateur légitime et réversible pour l’équipe TI.

• Deux comptes d’urgence fonctionnels, exclus, surveillés et testés.
• Export JSON et inventaire des chevauchements conservés.
• Période Report-only représentative terminée.
• Success, Failure, User action required et Not applied expliqués.
• What If et essais réels complétés pour les scénarios critiques.
• Dépendances, invités, appareils et automatisations validés.
• Exclusions minimales avec propriétaire et échéance.
• Pilote appliqué sans incident critique et soutien prêt.
• Retour arrière testé et personne responsable disponible.
• Surveillance après activation et révision périodique planifiées.

• Service — Audit de sécurité Microsoft 365 et Entra ID →
• Guide — Vol de jetons Microsoft 365 et AiTM →