Conditional Access Entra ID : Nouveautes Mars 2026

Tour d'horizon des nouvelles fonctionnalites Conditional Access dans Entra ID deployees en mars 2026. Les équipes de sécurité et les professionnels du domaine y trouveront des recommandations applicables immediatement. Face a la sophistication croissante des attaques ciblant les environnements Active Directory et Entra ID, les administrateurs système et les équipes de sécurité doivent constamment renforcer leurs defenses. Cet article présente les techniques, outils et méthodologies nécessaires pour auditer, securiser et surveiller efficacement ces infrastructures critiques dans un contexte de menaces en perpetuelle evolution. Active Directory reste la cible privilégiée des attaquants en environnement Windows. Comprendre conditional access entra mars 2026 est indispensable pour les équipes offensives comme défensives.

Contexte et Enjeux

La sécurité d'Active Directory reste un enjeu majeur pour les entreprises en 2025-2026. Avec la multiplication des attaques abouties, les équipes IT doivent constamment adapter leurs defenses. Les environnements hybrides combinant AD on-premise et Entra ID (anciennement Azure AD) ajoutent une complexite supplementaire.

Pour comprendre les fondamentaux, consultez notre article sur Rbcd Attaque Defense. Les techniques d'attaque evoluent rapidement, comme détaillé dans Gpo Abuse Attaque Defense.

Votre Active Directory résisterait-il à une attaque Kerberoasting ?

447
PAGES

Guide Gratuit : Sécuriser Active Directory (447 pages)

Attaques, Tiering Model, durcissement, monitoring — par Ayi NEDJIMI

Télécharger le PDF →

Analyse Technique Detaillee

L'approche technique repose sur plusieurs vecteurs d'attaque complementaires. Les pentesters et red teamers utilisent ces techniques pour identifier les failles dans les configurations AD. La comprehension de la chaine d'attaque complete est essentielle pour mettre en place des defenses efficaces.

⚡

Retour terrain

Dans mes missions de hardening Active Directory, le point le plus sous-estimé est la gestion du groupe 'Opérateurs de compte' et des délégations personnalisées créées au fil des années. Pour un groupe logistique de 1 500 utilisateurs, j'ai trouvé 312 ACL personnalisées dont 89 accordaient des permissions d'écriture sur des attributs sensibles (adminCount, memberOf sur groupes privilégiés) à des comptes d'utilisateurs standards. La dette technique en sécurité AD est souvent invisible jusqu'au premier audit sérieux.

Les outils comme BloodHound, Impacket et Rubeus permettent d'automatiser la détection des chemins d'attaque. Selon les recommandations de CERT-FR, la surveillance des événements critiques (Event ID 4769, 4662, 4724) est indispensable. Notre guide Pass The Hash Attaque Defense détaillé les procedures d'audit.

La complexite des environnements modernes nécessite une approche en couches. Le modele de tiering recommande par Microsoft et l'ANSSI reste la référence pour segmenter les acces privilegies.

Notre avis d'expert

Le modèle Zero Trust remet fondamentalement en question l'architecture traditionnelle d'Active Directory. Pourtant, la majorité des entreprises restent dépendantes d'AD pour leur gestion d'identités. La transition vers une architecture hybride sécurisée nécessite une planification minutieuse et un modèle de Tiering rigoureux.

Stratégies de Defense et Remediation

La remediation doit etre progressive et priorisee. Commencez par les quick wins : desactiver NTLM ou possible, activer le Protected Users group, configurer le tiering. Ensuite, abordez les chantiers de fond comme la migration vers le passwordless et le renforcement du Conditional Access.

• Étape 1 : Audit complet avec les scripts recommandes — voir Forest Trust Abuse Attaque Defense
• Étape 2 : Remediation des configurations critiques
• Étape 3 : Mise en place du monitoring continu
• Étape 4 : Tests de penetration reguliers

Plusieurs outils gratuits facilitent l'audit et le durcissement d'Active Directory. PingCastle, Purple Knight et ADRecon fournissent des rapports detailles. Les références de OWASP completent ces outils avec des bonnes pratiques validees. Pour approfondir, consultez Pass The Ticket Attaque Defense.

Cas concret

L'attaque SolarWinds (2020) a utilisé la technique Golden SAML pour forger des tokens d'authentification, permettant un accès persistant aux environnements Microsoft 365 et Azure AD sans déclencher d'alertes. Cette technique a démontré que la compromission d'un serveur AD FS pouvait anéantir la confiance dans toute l'infrastructure d'identité.

Questions frequentes

Comment securiser un environnement Active Directory ?

La sécurisation d'Active Directory repose sur plusieurs piliers : l'implementation du modele de tiering, la restriction des privileges administratifs, la surveillance des événements critiques, le déploiement du Protected Users group, la desactivation des protocoles obsoletes comme NTLM et la mise en place d'audits reguliers.

Qu'est-ce que le modele de tiering Active Directory ?

Le modele de tiering est une architecture de sécurité recommandee par Microsoft et l'ANSSI qui segmente les acces privilegies en trois niveaux : Tier 0 pour les controleurs de domaine, Tier 1 pour les serveurs membres et Tier 2 pour les postes de travail, empechant ainsi la propagation laterale des attaquants.

Pourquoi les attaques Active Directory sont-elles si frequentes ?

Les attaques Active Directory sont frequentes car AD reste le système d'authentification central de la majorite des entreprises. Les configurations par defaut sont souvent permissives, les privileges excessifs repandus et les techniques d'exploitation bien documentees, ce qui en fait une cible privilegiee pour les attaquants.

La mise en pratique de ces concepts nécessite une approche methodique et structuree. Les équipes techniques doivent d'abord evaluer leur niveau de maturite actuel sur le sujet, identifier les lacunes prioritaires et definir un plan d'action realiste. L'implementation progressive, avec des jalons mesurables, garantit une adoption durable et efficace des pratiques recommandees.

Les organisations qui reussissent le mieux dans ce domaine adoptent une culture d'amelioration continue. Cela implique des revues regulieres des processus, une veille technologique active et une formation permanente des équipes. Les indicateurs de performance doivent etre definis des le depart pour mesurer objectivement les progres realises et ajuster la stratégie si necessaire.

L'integration de ces pratiques dans les processus existants de l'organisation est un facteur cle de succes. Plutot que de creer des workflows paralleles, il est recommande d'enrichir les procedures actuelles avec les controles et les verifications necessaires. Cette approche reduit la resistance au changement et facilite l'adoption par les équipes operationnelles.

Recommandations de durcissement

La sécurisation d'un environnement Active Directory passe par une approche méthodique. Le modèle de tiering proposé par Microsoft — avec une séparation stricte des comptes administrateurs Tier 0, Tier 1 et Tier 2 — reste la fondation de toute architecture sécurisée. Pourtant, dans la majorité des audits, on constate que ce modèle n'est que partiellement appliqué.

LAPS (Local Administrator Password Solution) est un autre pilier souvent négligé. Sans LAPS, un seul mot de passe administrateur local compromis peut ouvrir la voie à un mouvement latéral massif. La documentation Microsoft détaille la mise en œuvre, mais l'implémentation sur un parc hétérogène prend du temps et de la planification.

Points de contrôle prioritaires

Les chemins d'attaque les plus courants dans un AD passent par : les délégations Kerberos non contraintes, les comptes de service avec des SPN et des mots de passe faibles (cible du Kerberoasting), les GPO mal configurées qui exposent des credentials, et les ACL permissives sur des objets sensibles comme AdminSDHolder.

BloodHound permet de cartographier ces chemins en quelques minutes. Si vous ne l'avez jamais lancé sur votre environnement de production, la découverte risque d'être instructive. La réalité est souvent plus complexe que ce que les schémas théoriques laissent supposer.

Consultez les recommandations de l'ANSSI et le référentiel MITRE ATT&CK TA0004 (Privilege Escalation) pour structurer votre approche défensive.

Contexte et enjeux actuels

Impact opérationnel

Pour approfondir ce sujet, consultez notre outil open-source bloodhound-custom-queries qui facilite l'analyse avancée des chemins d'attaque Active Directory.

Les sujets techniques en cybersécurité exigent une approche rigoureuse, fondée sur l'expérimentation et la validation en conditions réelles. Les environnements de laboratoire — qu'ils soient construits avec Proxmox, VMware Workstation ou des services cloud éphémères — sont indispensables pour tester les techniques, les outils et les contre-mesures avant tout déploiement en production.

L'un des écueils les plus fréquents dans la mise en œuvre de solutions techniques de sécurité est le gap entre la documentation officielle et la réalité du terrain. Les guides de déploiement supposent souvent un environnement propre et standardisé, là où la plupart des organisations gèrent un patrimoine applicatif hétérogène, avec des dépendances croisées et des configurations héritées.

Approche méthodique recommandée

Pour chaque implémentation technique, la méthodologie suivante a fait ses preuves : audit de l'existant, définition des prérequis, déploiement en environnement de test, validation fonctionnelle et sécurité, déploiement progressif en production avec rollback plan, puis monitoring post-déploiement. Chaque étape doit être documentée.

Les référentiels MITRE ATT&CK et MITRE D3FEND fournissent un cadre structuré pour aligner les mesures techniques sur les menaces réelles. D3FEND, en particulier, cartographie les contre-mesures défensives face aux techniques d'attaque, ce qui facilite la priorisation des investissements en sécurité.

La documentation interne — runbooks, playbooks, procédures d'exploitation — est le maillon souvent manquant. Sans elle, la connaissance reste dans la tête des experts, et chaque départ ou absence crée un risque opérationnel. Avez-vous documenté vos procédures critiques de manière à ce qu'un nouveau membre de l'équipe puisse les exécuter de manière autonome ?

Sources et références : MITRE ATT&CK Privilege Escalation · ADSecurity.org

Conclusion

La sécurisation d'Active Directory est un processus continu qui nécessite une vigilance constante. Les nouvelles menaces de 2026 renforcent la nécessite d'adopter une approche proactive, combinant audit regulier, monitoring en temps reel et formation des équipes.

Article suivant recommandé

BloodHound 5 : Nouveaux Chemins d'Attaque Detectes →

BloodHound 5 introduit de nouveaux collecteurs et chemins d'attaque pour auditer Active Directory et Entra ID.

Kerberoasting : Technique d'attaque ciblant les Service Principal Names (SPN) dans Active Directory pour extraire et craquer hors ligne les tickets de service Kerberos.

Les techniques d'attaque Active Directory décrites nécessitent une autorisation écrite préalable. Testez uniquement sur des environnements de lab ou dans le cadre d'un audit mandaté.

Utilisez BloodHound Community Edition pour cartographier les chemins d'attaque Active Directory avant un audit. La visualisation graphique révèle des vecteurs invisibles à l'analyse manuelle.

Votre Active Directory est-il compromis ?

Audit AD complet, détection de chemins d'attaque, durcissement Tier Model — intervention sous 48h.

Audit AD — Devis gratuit [email protected]

Nouvelles Politiques Conditional Access Mars 2026

Microsoft a déployé en mars 2026 plusieurs nouvelles capacités Conditional Access qui changent fondamentalement l'approche de la protection des identités dans Entra ID. Ces fonctionnalités adressent les lacunes identifiées dans les campagnes APT récentes, notamment le vol de tokens et le contournement MFA.

Token Protection : Lier les Tokens aux Appareils

# Token Protection (Preview depuis 2023, GA mars 2026)
# Lie cryptographiquement le token à l'appareil qui a effectué l'authentification
# Un token volé depuis l'appareil A ne peut pas être utilisé depuis l'appareil B

# Créer une politique Token Protection
Connect-MgGraph -Scopes "Policy.ReadWrite.ConditionalAccess"

$body = @{
    displayName = "Token Protection - Exchange et SharePoint"
    state = "enabled"
    conditions = @{
        users = @{
            includeUsers = @("All")
            excludeUsers = @("BREAK-GLASS-ACCOUNT-OBJECTID")
        }
        applications = @{
            includeApplications = @(
                "00000002-0000-0ff1-ce00-000000000000",  # Exchange Online
                "00000003-0000-0ff1-ce00-000000000000"   # SharePoint Online
            )
        }
        clientAppTypes = @("mobileAppsAndDesktopClients")
        # Note: Token Protection ne s'applique qu'aux clients non-browser
    }
    sessionControls = @{
        signInFrequency = @{
            isEnabled = $true
            type = "hours"
            value = 1
        }
        tokenProtection = @{
            isEnabled = $true
        }
    }
}
# Appel via Microsoft Graph
$response = Invoke-MgGraphRequest -Method POST   -Uri "https://graph.microsoft.com/v1.0/identity/conditionalAccess/policies"   -Body $body -ContentType "application/json"

Authentication Strength : Remplacer "Require MFA" par des Exigences Précises

# Authentication Strength (GA 2024, nouvelles méthodes 2026)
# Permet de spécifier EXACTEMENT quelles méthodes MFA sont acceptées
# Exemples : FIDO2 only, Temporary Access Pass, Certificate-based auth

# Créer une Authentication Strength personnalisée
$authStrengthBody = @{
    displayName = "Phishing-Resistant MFA"
    description = "Exige FIDO2 ou CBA - résistant au phishing"
    allowedCombinations = @(
        "fido2",                           # Clé FIDO2 (YubiKey, etc.)
        "x509CertificateMultiFactor",      # Smart card / CBA
        "windowsHelloForBusiness"          # Windows Hello Enterprise
    )
    # Exclut explicitement les méthodes faibles :
    # - SMS OTP (SIM swapping)
    # - TOTP apps (susceptibles au phishing AiTM)
    # - Voice calls
}

$authStrength = Invoke-MgGraphRequest -Method POST   -Uri "https://graph.microsoft.com/v1.0/identity/conditionalAccess/authenticationStrength/policies"   -Body $authStrengthBody

# Utiliser cette Authentication Strength dans une CA Policy
$caPolicy = @{
    displayName = "Admins - Phishing-Resistant MFA Required"
    state = "enabled"
    conditions = @{
        users = @{
            includeRoles = @(
                "62e90394-69f5-4237-9190-012177145e10",  # Global Admin
                "194ae4cb-b126-40b2-bd5b-6091b380977d"   # Security Admin
            )
        }
        applications = @{ includeApplications = @("All") }
    }
    grantControls = @{
        operator = "OR"
        authenticationStrength = @{
            id = $authStrength.id
        }
    }
}

Insider Risk Integration et Adaptive Protection

# Adaptive Protection (Microsoft Purview + Entra ID CA)
# Intègre le risk score Insider Risk Management dans Conditional Access
# Un utilisateur avec un score de risque élevé → MFA forcée ou blocage

# Configurer Adaptive Protection
# 1. Activer Microsoft Purview Insider Risk Management
# 2. Activer Adaptive Protection dans Purview : Settings → Adaptive Protection
# 3. Dans Entra ID CA, utiliser la condition "Insider Risk"

$adaptivePolicy = @{
    displayName = "Insider Risk - High Risk Block"
    conditions = @{
        users = @{ includeUsers = @("All") }
        applications = @{ includeApplications = @("All") }
        insiderRiskLevels = @("elevatedRisk", "highRisk")
        # elevatedRisk = risque modéré, highRisk = risque critique
    }
    grantControls = @{
        operator = "OR"
        builtInControls = @("block")
    }
}

# Pour les risques "moderateRisk", une session restrictive est préférable au blocage
$moderateRiskPolicy = @{
    displayName = "Insider Risk - Moderate Risk - Restricted Session"
    conditions = @{
        users = @{ includeUsers = @("All") }
        applications = @{ includeApplications = @("All") }
        insiderRiskLevels = @("moderateRisk")
    }
    sessionControls = @{
        applicationEnforcedRestrictions = @{ isEnabled = $true }
        cloudAppSecurity = @{
            isEnabled = $true
            cloudAppSecurityType = "mcasConfigured"  # MCAS/Defender for Cloud Apps
        }
    }
}

Template 20 Politiques CA pour une Organisation Sécurisée

Contournements Connus et Mitigations

# Contournement 1 : AiTM (Adversary-in-the-Middle) Phishing
# Outil : Evilginx, Modlishka, Muraena
# Capture le session cookie même avec MFA activé

# Mitigation :
# - Authentication Strength avec FIDO2/CBA UNIQUEMENT (AiTM-résistant)
# - Token Protection : lie le token à l'appareil → cookie volé inutilisable
# - Continuous Access Evaluation (CAE) : révocation quasi-temps réel du token

# Activer CAE
$caePolicy = @{
    displayName = "CAE - Strict Enforcement"
    conditions = @{
        applications = @{
            includeApplications = @("All")
        }
        users = @{ includeUsers = @("All") }
    }
    sessionControls = @{
        continuousAccessEvaluation = @{
            mode = "strictLocation"  # "disabled" | "strictLocation" | "strictEnforcement"
        }
    }
}

# Contournement 2 : Pass-the-Cookie depuis browser profil sync
# Chrome/Edge sync les cookies entre appareils → si compte Google/Microsoft compromis
# Mitigation : Disable Chrome Sync via GPO + Defender for Cloud Apps session policies

# Contournement 3 : Primary Refresh Token (PRT) theft
# Obtenir le PRT = accéder à tous les services SSO sans MFA
# Outil: AADInternals Get-AADIntUserPRTToken (depuis SYSTEM sur le poste)
# Mitigation :
# - Windows Credential Guard (virtualisation-based security)
# - Hybrid Azure AD Join + Defender for Endpoint tamper protection

# Dépannage CA : Sign-in Logs
# Azure Portal > Entra ID > Sign-in logs > Filter
# "Conditional Access" column : Success/Failure/Not Applied

# KQL pour analyser les échecs CA
SigninLogs
| where ConditionalAccessStatus == "failure"
| extend CADetails = parse_json(ConditionalAccessPolicies)
| mv-expand CADetails
| where CADetails.result == "failure"
| project TimeGenerated, UserPrincipalName, AppDisplayName,
  PolicyName = CADetails.displayName, FailureReason = CADetails.conditions
| order by TimeGenerated desc
| limit 100

La maturité d'une politique Conditional Access se mesure à sa capacité à résister aux techniques d'attaque modernes tout en maintenant une expérience utilisateur fluide pour les accès légitimes. L'ordre de priorité recommandé pour 2026 est : (1) blocage legacy auth immédiat, (2) MFA pour les admins avec Authentication Strength phishing-resistant, (3) Token Protection pour Exchange/SharePoint, (4) blocage device code flow, (5) Risk-based policies. Ces cinq politiques couvrent plus de 80 % des vecteurs d'attaque sur les identités cloud documentés dans les incidents 2024-2026.