Intune et Conditional Access : exiger la conformité sans bloquer l’organisation

Position recommandée

Une configuration policy applique un état, une compliance policy l’évalue et Conditional Access utilise le résultat dans une décision de connexion. Mélanger ces rôles rend les incidents difficiles à corriger.

Je commence en report-only avec comptes d’urgence exclus, populations pilotes et actions de non-conformité laissant un délai adapté au risque. Les nouveaux appareils et scénarios de récupération sont testés.

Le sign-in log Entra est la preuve de la décision CA; Intune explique ensuite le setting non conforme. Un utilisateur n’est pas débloqué tant que le nouveau signal et un nouveau token n’ont pas convergé.

Une configuration policy applique un état, une compliance policy l’évalue et Conditional Access utilise le résultat dans une décision de connexion. Mélanger ces rôles rend les incidents difficiles à corriger.

Besoin, cas d’usage et périmètre de la recommandation

La conformité n’applique généralement pas toute la configuration de sécurité. Je déploie d’abord BitLocker, firewall ou Defender, puis je contrôle leur résultat dans une policy distincte.

Intune transmet l’état à Entra. Conditional Access réévalue lors d’une authentification selon utilisateur, application, device, emplacement, risque et contrôles exigés.

Les actions for noncompliance définissent immédiatement ou après délai notification et conséquence. Le délai tient compte du temps réel de correction et du risque, jamais d’une valeur générique.

Critères de décision et options possibles

Pour Conformité et Conditional Access, je commence par trois résultats concrets: Inventorier policies CA et compliance, Déployer CA en report-only et Tester nouveaux devices et appareils non conformes. Ils doivent être observables avant de comparer les méthodes disponibles.

L’architecture cible suit Configure → Evaluate → Signal → Enforce. Chaque composant a un propriétaire clair, un état vérifiable et une méthode de retour arrière; cette répartition évite qu’une seconde politique masque le résultat de la première.

Le pilote contrôle notamment Inventorier policies CA et compliance, Déployer CA en report-only et Tester nouveaux devices et appareils non conformes. La généralisation ne commence qu’après une période stable et après vérification des exceptions propres aux populations visées.

La recommandation devient mesurable lorsqu’elle relie le besoin à une cible vérifiable. Les résultats attendus sont Inventorier policies CA et compliance, Déployer CA en report-only et Tester nouveaux devices et appareils non conformes. Les responsabilités se répartissent ainsi: Configure: Policies établissent l’état. Evaluate: Intune calcule la conformité. Signal: Entra reçoit compliant/device risk. Enforce: CA accorde, challenge ou bloque. Cette répartition permet d’attribuer chaque écart au bon propriétaire et d’éviter qu’un second profil, une ancienne autorité ou une exception silencieuse ne produise un résultat apparemment correct mais impossible à exploiter dans la durée.

Les écarts « Utilisateur conforme bloqué », « Tous les nouveaux devices bloqués », « Not evaluated » et « Risk inconnu » servent de tests de décision. Pour chacun, la preuve indiquée dans la matrice doit permettre de choisir entre correction, exception temporaire et retour arrière. Le pilote surveille également les points suivants: ne jamais exclure largement pour masquer les incidents, tester toutes les applications critiques, les comptes d’urgence sont contrôlés et le signal peut avoir une latence. La valeur cible, le mode de distribution, les contrôles et la sortie de secours sont ainsi évalués ensemble.

Architecture cible et répartition des responsabilités

La conformité n’applique généralement pas toute la configuration de sécurité. Je déploie d’abord BitLocker, firewall ou Defender, puis je contrôle leur résultat dans une policy distincte.

Intune transmet l’état à Entra. Conditional Access réévalue lors d’une authentification selon utilisateur, application, device, emplacement, risque et contrôles exigés.

Les actions for noncompliance définissent immédiatement ou après délai notification et conséquence. Le délai tient compte du temps réel de correction et du risque, jamais d’une valeur générique.

Prérequis, gouvernance et préparation

La préparation de Conformité et Conditional Access couvre Entra ID P1/P2 selon capacités, policies de configuration stables, compliance par plateforme, comptes d’urgence, sign-in logs accessibles. Le propriétaire de chaque composant et la population pilote sont définis avant la création de la configuration.

L’état initial est mesuré avec Inventorier policies CA et compliance. Déployer CA en report-only. Tester nouveaux devices et appareils non conformes. Vérifier comptes d’urgence et exclusions. Il servira de point de comparaison pendant le pilote et lors d’un éventuel retour arrière.

• Entra ID P1/P2 selon capacités
• policies de configuration stables
• compliance par plateforme
• comptes d’urgence
• sign-in logs accessibles
• communication et support prêts

Fonctionnement détaillé et frontières de responsabilité

La conformité n’applique généralement pas toute la configuration de sécurité. Je déploie d’abord BitLocker, firewall ou Defender, puis je contrôle leur résultat dans une policy distincte.

Intune transmet l’état à Entra. Conditional Access réévalue lors d’une authentification selon utilisateur, application, device, emplacement, risque et contrôles exigés.

Les actions for noncompliance définissent immédiatement ou après délai notification et conséquence. Le délai tient compte du temps réel de correction et du risque, jamais d’une valeur générique.

• Entra ID P1/P2 selon capacités
• policies de configuration stables
• compliance par plateforme
• comptes d’urgence

Mise en œuvre, exploitation et cas limites

Une policy CA All users/All cloud apps sans comptes d’urgence et sans validation peut verrouiller l’administration. Je conserve des emergency access accounts surveillés et teste l’accès depuis un chemin indépendant.

Defender device risk enrichit le signal, mais dépend de l’onboarding et de la remontée. Un appareil sans donnée ne doit pas être silencieusement considéré sain.

L’expérience utilisateur comprend message, Portail d’entreprise, self-remediation et support. Le runbook part du sign-in log, identifie la policy CA, puis le setting Intune exact.

• Mesurer utilisateurs affectés
• Valider délai de grâce et notifications
• Suivre signal Intune puis sign-in Entra

Méthode de validation à l’échelle du parc

Pour conformité et conditional access, je constitue un échantillon qui couvre au minimum deux modèles matériels, plusieurs profils utilisateur, un site réseau contraint et les exceptions métier connues. Un résultat homogène sur des machines de laboratoire identiques ne démontre pas la robustesse de la configuration.

Les mesures portent sur Inventorier policies CA et compliance. Déployer CA en report-only. Tester nouveaux devices et appareils non conformes. Vérifier comptes d’urgence et exclusions. Elles sont définies avant le pilote de Conformité et Conditional Access afin que les seuils ne soient pas déplacés après l’observation.

Les cas « Utilisateur conforme bloqué », « Tous les nouveaux devices bloqués », « Not evaluated », « Risk inconnu » servent de scénarios négatifs. Ils vérifient que l’échec reste visible, localisable et associé à une correction précise.

La généralisation de Conformité et Conditional Access tient compte de ne jamais exclure largement pour masquer les incidents, tester toutes les applications critiques, les comptes d’urgence sont contrôlés, le signal peut avoir une latence. Chaque vague se ferme après lecture de ces points et validation du retour à l’état connu.

Configuration recommandée et déploiement par étapes

La méthode retenue pour Conformité et Conditional Access se déploie par les étapes « Mesurer l’état initial », « Configurer le pilote », « Observer les indicateurs », « Décider la vague suivante ». Chaque passage produit un résultat vérifiable avant l’ouverture du suivant.

Paramètres, commandes et automatisation

Les commandes et valeurs de cette section servent à vérifier Inventorier policies CA et compliance. Déployer CA en report-only. Tester nouveaux devices et appareils non conformes. Vérifier comptes d’urgence et exclusions. Chaque exemple précise l’état attendu et les éléments à comparer dans le service.

Le contexte d’exécution, les permissions et les effets sur Configure, Evaluate, Signal, Enforce doivent rester explicites lorsque la configuration est automatisée.

# Collecte de diagnostic
$ErrorActionPreference = 'Stop'
try {
 dsregcmd.exe /status
 Get-BitLockerVolume -MountPoint C: | Select-Object VolumeStatus,ProtectionStatus,EncryptionMethod
 Get-MpComputerStatus | Select-Object AntivirusEnabled,RealTimeProtectionEnabled,AntivirusSignatureLastUpdated
}
catch { Write-Error "Collecte conformité impossible : $($_.Exception.Message)"; exit 1 }

Validation, indicateurs et critères GO / NO-GO

La décision repose sur Inventorier policies CA et compliance, Déployer CA en report-only, Tester nouveaux devices et appareils non conformes et Vérifier comptes d’urgence et exclusions. Ces indicateurs couvrent le résultat technique, l’état du service et l’effet réel sur la population pilote.

• Inventorier policies CA et compliance.
• Déployer CA en report-only.
• Tester nouveaux devices et appareils non conformes.
• Vérifier comptes d’urgence et exclusions.
• Mesurer utilisateurs affectés
• Valider délai de grâce et notifications
• Suivre signal Intune puis sign-in Entra

Exploitation, journaux et contrôle continu

La chronologie de Conformité et Conditional Access relie Configure, Evaluate, Signal, Enforce. Les heures et identifiants communs indiquent si les informations décrivent la même tentative.

Les états sont lus à partir de Inventorier policies CA et compliance. Déployer CA en report-only. Tester nouveaux devices et appareils non conformes. Vérifier comptes d’urgence et exclusions. Cette séquence sépare une absence de configuration d’un traitement en attente ou d’un échec confirmé.

Les causes « Token ou DeviceId ancien », « Enforcement trop tôt », « Policy non applicable ou check-in », « MDE non onboardé/remontée » restent des hypothèses jusqu’à ce que la preuve indiquée dans la matrice les confirme.

• Inventorier policies CA et compliance.
• Déployer CA en report-only.
• Tester nouveaux devices et appareils non conformes.
• Vérifier comptes d’urgence et exclusions.
• Mesurer utilisateurs affectés
• Valider délai de grâce et notifications
• Suivre signal Intune puis sign-in Entra

Exceptions, erreurs connues et traitement

Les exceptions à prévoir pour Conformité et Conditional Access apparaissent notamment sous la forme Utilisateur conforme bloqué, Tous les nouveaux devices bloqués, Not evaluated, Risk inconnu. La preuve associée indique s’il faut corriger la configuration ou conserver une exception documentée.

Coût de maintien des exceptions

Une exception à Conformité et Conditional Access crée une charge récurrente: elle doit être identifiée, surveillée et réévaluée jusqu’à sa suppression. Sans propriétaire ni date de revue, cette charge finit par devenir une configuration parallèle difficile à tester.

Rollback, gestion du changement et points de vigilance

Le rollback de Conformité et Conditional Access restaure explicitement l’affectation, la valeur ou l’autorité précédente. Les actions et points de vigilance ci-dessous précisent ce qui doit être contrôlé après ce retour.