Zero Trust et GPO : le futur de la configuration¶

Zero Trust et GPO : deux logiques différentes¶

Le modèle château-fort des GPO¶

Les GPO ont été conçues dans un modèle périmétrique.

La machine est jointe au domaine — on lui fait confiance. Elle reçoit des politiques au démarrage et à l'ouverture de session. Une fois dans le périmètre, la confiance est implicite.

C'est la logique du château-fort : le pont-levis (l'authentification AD) filtre les entrées. Tout ce qui est à l'intérieur est considéré comme sûr.

Zero Trust remet en question cette logique¶

Le modèle Zero Trust part d'un postulat inverse : ne jamais faire confiance, toujours vérifier.

Peu importe si la machine est sur le réseau interne. Peu importe si elle est jointe au domaine. L'accès à une ressource doit être conditionné à une vérification explicite : qui est l'utilisateur, dans quel état est son poste, depuis quel contexte tente-t-il d'accéder.

Les trois principes fondateurs :

GPO restent pertinentes — mais leur rôle change¶

Les GPO continuent d'avoir un rôle central pour :

• La configuration de l'OS : Credential Guard, BitLocker, ASR, restrictions de démarrage
• Le durcissement AD côté DC : Kerberos policy, NTLM restrictions, audit de sécurité
• Les politiques core AD : ces politiques ne peuvent pas être déployées par MDM

Ce qui manque aux GPO seules : elles ne vérifient pas dynamiquement l'état du poste au moment d'une demande d'accès. Elles configurent, mais ne conditionnent pas.

Contributions des GPO au Zero Trust¶

La carte de correspondance GPO → principe ZT¶

Chaque contrôle GPO peut être mappé sur l'un des trois principes Zero Trust. Le tableau ci-dessous est la colonne vertébrale de ce chapitre.

Les sections suivantes détaillent chaque contrôle avec son chemin GPO, sa valeur de registre et l'event ID à surveiller.

Credential Guard — principe ZT : Assume Breach¶

Ce que Credential Guard protège¶

Credential Guard isole les dérivés de credentials (hachages NTLM, tickets Kerberos) dans un conteneur VBS (Virtualization-Based Security) inaccessible au système d'exploitation principal.

Sans Credential Guard, un attaquant ayant obtenu les droits SYSTEM peut exécuter Mimikatz et extraire les credentials de tous les utilisateurs connectés depuis lsass.exe. C'est le vecteur de mouvement latéral le plus courant dans les compromissions AD.

Avec Credential Guard actif, lsass.exe ne contient plus les dérivés — ils sont dans le conteneur VBS. L'extraction échoue.

Prérequis matériels et OS¶

Chemin GPO — Credential Guard¶

Computer Configuration → Policies → Administrative Templates
  → System → Device Guard
    → Turn On Virtualization Based Security

Paramètres à configurer dans cette GPO :

Vérification post-déploiement¶

# Verify Credential Guard activation status on remote machines
param(
    [string[]]$Computers = @($env:COMPUTERNAME)
)

foreach ($computer in $Computers) {
    $result = Invoke-Command -ComputerName $computer -ScriptBlock {
        $vbs  = Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard
        $cgRunning = $vbs.SecurityServicesRunning -contains 1   # 1 = Credential Guard
        $cgConfig  = $vbs.SecurityServicesConfigured -contains 1

        [PSCustomObject]@{
            Computer             = $env:COMPUTERNAME
            VBSEnabled           = $vbs.VirtualizationBasedSecurityStatus -eq 2  # 2 = Running
            CredGuardConfigured  = $cgConfig
            CredGuardRunning     = $cgRunning
            SecureBootState      = $vbs.RequiredSecurityProperties -contains 1
        }
    } -ErrorAction SilentlyContinue

    $result
}

Computer    VBSEnabled  CredGuardConfigured  CredGuardRunning  SecureBootState
--------    ----------  -------------------  ----------------  ---------------
WKS-001     True        True                 True              True
WKS-002     True        True                 False             True    # config OK mais pas encore actif — reboot requis
WKS-003     False       False                False             False   # matériel non compatible

Event IDs à surveiller¶

WDAC — principe ZT : Assume Breach¶

Application Control comme brique Zero Trust¶

WDAC (Windows Defender Application Control) est le successeur d'AppLocker pour le contrôle d'exécution.

Son principe Zero Trust : ne jamais exécuter ce qui n'est pas explicitement autorisé. C'est l'implémentation technique de "Assume Breach" — même si un attaquant obtient un foothold, il ne peut pas exécuter ses outils si ceux-ci ne sont pas dans la liste blanche.

WDAC opère en mode kernel via le service CI (Code Integrity). Il est plus robuste qu'AppLocker car il ne peut pas être contourné par un processus en espace utilisateur.

Architecture d'une politique WDAC¶

Une politique WDAC définit :

• Les fichiers autorisés : par signature, par chemin, par hash, par attribut de fichier
• Les éditeurs de confiance : Microsoft, éditeurs tiers signés
• Les modes d'opération : Audit (journalise), Enforce (bloque)

La politique est compilée en fichier binaire (.cip) et déployée via GPO ou MDM.

Chemin GPO — déploiement WDAC¶

Computer Configuration → Policies → Administrative Templates
  → System → Device Guard
    → Deploy Windows Defender Application Control

Paramètre : Deploy Windows Defender Application Control → chemin UNC vers le fichier .cip.

\\domain.local\NETLOGON\WDAC\{PolicyId}.cip

Générer et déployer une politique WDAC de base¶

# Generate a WDAC policy based on Microsoft's DefaultWindows baseline (Audit mode first)
# Requires: Windows 10 1903+ or Windows 11 — run on a reference machine

param(
    [string]$PolicyDir      = "C:\WDAC\Policies",
    [string]$SharePath      = "\\domain.local\NETLOGON\WDAC",
    [switch]$EnforceMode    = $false  # Start in Audit mode — set to $true only after audit validation
)

if (-not (Test-Path $PolicyDir)) { New-Item -ItemType Directory -Path $PolicyDir | Out-Null }

$baselineXml  = "C:\Windows\schemas\CodeIntegrity\ExamplePolicies\DefaultWindows_Audit.xml"
$workingXml   = "$PolicyDir\WDAC-Baseline.xml"
$compiledCip  = "$PolicyDir\WDAC-Baseline.cip"

# Copy baseline policy
Copy-Item $baselineXml $workingXml -Force

if ($EnforceMode) {
    # Switch to Enforce mode — use only after audit validation
    Set-RuleOption -FilePath $workingXml -Option 3 -Delete  # Remove Audit Mode option
    Write-Host "Policy set to ENFORCE mode."
} else {
    Set-RuleOption -FilePath $workingXml -Option 3           # Ensure Audit Mode is set
    Write-Host "Policy set to AUDIT mode."
}

# Retrieve Policy ID from XML
$policyId = ([xml](Get-Content $workingXml)).SiPolicy.PolicyID -replace '[{}]'

# Compile policy
ConvertFrom-CIPolicy -XmlFilePath $workingXml -BinaryFilePath $compiledCip

# Deploy to NETLOGON share
if (-not (Test-Path $SharePath)) { New-Item -ItemType Directory -Path $SharePath | Out-Null }
Copy-Item $compiledCip "$SharePath\$policyId.cip" -Force

Write-Host "WDAC policy deployed: $SharePath\$policyId.cip"
Write-Host "Now configure GPO: Computer Config > Administrative Templates > System > Device Guard"
Write-Host "  -> 'Deploy Windows Defender Application Control' = $SharePath\$policyId.cip"

Event IDs à surveiller¶

ASR Rules — principe ZT : Assume Breach¶

ASR comme filet de sécurité comportemental¶

Les règles ASR (Attack Surface Reduction) sont détaillées dans le chapitre 14. Dans un contexte Zero Trust, leur rôle est précis : bloquer les vecteurs d'exploitation les plus courants avant qu'un code malveillant puisse s'exécuter.

ASR opère sur des comportements — une macro Office qui tente de lancer cmd.exe, un script PowerShell obfusqué, une tentative de dump de LSASS. Ces comportements sont des indicateurs de compromission en cours.

Les règles ASR à priorité ZT¶

Dans un projet Zero Trust, certaines règles ASR ont une priorité immédiate :

BitLocker — principe ZT : Verify Explicitly¶

BitLocker et la confiance au niveau du hardware¶

Dans un modèle Zero Trust, la confiance ne peut pas reposer uniquement sur l'identité réseau. Si une machine est volée ou son disque extrait, les données doivent rester inaccessibles.

BitLocker avec TPM implémente le principe "Verify Explicitly" au niveau matériel : le déchiffrement du volume n'est possible que si la chaîne de démarrage est intacte (UEFI, Secure Boot, bootloader, noyau).

Un attaquant qui extrait le disque et le monte sur une autre machine ne peut pas lire les données — le TPM de la machine source est absent.

Le lien BitLocker → Conditional Access¶

BitLocker est également un signal de conformité exploitable par Intune et Conditional Access.

Une politique Conditional Access peut conditionner l'accès à une ressource cloud (Exchange Online, SharePoint) à l'état de chiffrement du poste. Si BitLocker est désactivé, l'accès est bloqué — ou redirigé vers un flux de remédiation.

Ce signal ne remonte que si la machine est co-managée par Intune. La GPO BitLocker chiffre le poste. Intune vérifie l'état et l'expose à Conditional Access.

Event IDs BitLocker à surveiller en contexte ZT¶

LAPS — principe ZT : Use Least Privilege¶

Le mouvement latéral par compte administrateur partagé¶

Dans la majorité des compromissions AD documentées par Microsoft DART, l'un des vecteurs initiaux est le compte administrateur local partagé.

Scénario classique : le compte .\Administrator a le même mot de passe sur 500 postes. L'attaquant compromet un poste, extrait le hash, et peut s'authentifier sur tous les autres avec Pass-the-Hash. Le mouvement latéral est trivial.

LAPS résout ce problème en générant un mot de passe unique par machine, stocké dans AD et accessible uniquement aux opérateurs autorisés.

LAPS v2 — Use Least Privilege natif¶

Windows LAPS (LAPS v2, intégré depuis Windows 11 22H2 et KB5025175) ajoute par rapport à LAPS v1 :

• Chiffrement du mot de passe dans AD (attribut msLAPS-EncryptedPassword)
• Historique des mots de passe (jusqu'à 12 entrées)
• Rotation automatique post-utilisation
• Intégration native avec Intune pour les postes AAD-joined

Les paramètres GPO LAPS v2 sont dans :

Computer Configuration → Policies → Administrative Templates
  → System → LAPS

Vérification de la couverture LAPS sur le parc¶

# Audit LAPS v2 deployment coverage across the domain
# Reports machines without a LAPS password (either not deployed or attribute empty)
param(
    [string]$SearchBase = (Get-ADDomain).DistinguishedName,
    [int]$MaxPasswordAgeDays = 30
)

$cutoff = (Get-Date).AddDays(-$MaxPasswordAgeDays)

$computers = Get-ADComputer -Filter { OperatingSystem -like "*Windows*" } `
    -SearchBase $SearchBase `
    -Properties msLAPS-PasswordExpirationTime, msLAPS-EncryptedPassword, `
                ms-Mcs-AdmPwdExpirationTime, ms-Mcs-AdmPwd

foreach ($computer in $computers) {
    # Detect LAPS version in use
    $hasLAPSv2  = $null -ne $computer.'msLAPS-EncryptedPassword'
    $hasLAPSv1  = $null -ne $computer.'ms-Mcs-AdmPwd' -and $computer.'ms-Mcs-AdmPwd' -ne ''
    $lapsVersion = if ($hasLAPSv2) { "v2" } elseif ($hasLAPSv1) { "v1" } else { "None" }

    # Check expiration
    $expiration  = if ($hasLAPSv2) {
        $computer.'msLAPS-PasswordExpirationTime'
    } elseif ($hasLAPSv1) {
        $computer.'ms-Mcs-AdmPwdExpirationTime'
    } else { $null }

    $isExpired = $expiration -and ([datetime]::FromFileTime($expiration) -lt $cutoff)

    [PSCustomObject]@{
        Computer    = $computer.Name
        LAPSVersion = $lapsVersion
        HasPassword = ($hasLAPSv2 -or $hasLAPSv1)
        Expired     = $isExpired
        ExpiresAt   = if ($expiration) { [datetime]::FromFileTime($expiration) } else { $null }
    }
} | Sort-Object LAPSVersion, Computer

Computer   LAPSVersion  HasPassword  Expired  ExpiresAt
--------   -----------  -----------  -------  ---------
WKS-001    v2           True         False    2026-05-01 07:00:00
WKS-002    v2           True         True     2026-03-01 07:00:00   # rotation en retard
WKS-003    v1           True         False    2026-04-20 08:00:00   # migrer vers v2
WKS-004    None         False        False                          # LAPS non déployé

Verify Explicitly — le maillon manquant des GPO seules¶

Ce que les GPO ne font pas¶

Les GPO configurent le poste. Elles ne vérifient pas l'identité de l'utilisateur au moment d'une demande d'accès.

Une GPO s'applique au démarrage et toutes les 90 minutes. Elle ne sait pas si, entre deux cycles, le poste a été compromis, si l'utilisateur tente d'accéder depuis un réseau non conforme, ou si la session en cours présente des signaux d'anomalie.

"Verify Explicitly" requiert une évaluation dynamique et contextuelle. Les GPO opèrent en batch périodique.

Ce qu'Intune + Conditional Access apportent¶

Intune ajoute la couche manquante :

• Conformité continue : Intune évalue l'état du poste (BitLocker, Defender, OS version, WDAC) et génère un signal de conformité en temps réel
• Conditional Access : Azure AD conditionne l'accès à chaque ressource cloud au signal de conformité Intune
• Hybrid Join : la machine est à la fois dans AD (GPO s'appliquent) et dans AAD (Intune évalue la conformité)

Le flux complet pour un accès à Exchange Online dans une architecture ZT hybride :

Utilisateur → Demande accès Exchange Online
  ↓
Azure AD évalue Conditional Access
  ↓
  Vérifie : identité MFA confirmée ?
  Vérifie : appareil conforme Intune ?
    → BitLocker actif ?
    → Defender actif et à jour ?
    → OS version dans la fenêtre de support ?
    → Aucune app non-conforme ?
  ↓
  Si tout OK → Accès accordé (token)
  Si non-conforme → Blocage ou redirection remédiation

Architecture hybride GPO + Intune¶

La coexistence GPO + Intune (co-management) est documentée dans le chapitre 18 — Azure AD Hybrid Join. L'élément clé : la GPO qui bloque MDM doit être absente.

HKLM\SOFTWARE\Policies\Microsoft\Windows\CurrentVersion\MDM
  DisableMDMEnrollment = 0   (ou clé absente)

Si DisableMDMEnrollment = 1 est présent dans une GPO, le co-management est silencieusement impossible. Intune ne peut pas évaluer la conformité. Conditional Access ne reçoit pas le signal. La boucle ZT est brisée.

# Check whether a GPO is blocking MDM enrollment across the domain
Get-ADComputer -Filter { OperatingSystem -like "*Windows*" } |
    Select-Object -ExpandProperty Name |
    ForEach-Object {
        $val = Invoke-Command -ComputerName $_ -ScriptBlock {
            (Get-ItemProperty "HKLM:\SOFTWARE\Policies\Microsoft\Windows\CurrentVersion\MDM" `
                -Name DisableMDMEnrollment -ErrorAction SilentlyContinue).DisableMDMEnrollment
        } -ErrorAction SilentlyContinue
        [PSCustomObject]@{ Computer = $_; MDMBlocked = ($val -eq 1) }
    } | Where-Object MDMBlocked

:material-table-split: Architecture hybride : matrice de responsabilité¶

Qui gère quoi dans une architecture GPO + Intune + AAD¶

Dans une architecture Zero Trust hybride mature, les trois outils ont des responsabilités distinctes et non redondantes.

Les quatre règles de répartition¶

Règle 1 : Les GPO gèrent tout ce qui touche à l'infrastructure AD core (DC, Kerberos, NTLM, SYSVOL). Intune ne peut pas toucher aux contrôleurs de domaine.

Règle 2 : Intune gère la conformité et la remédiation des postes cloud-attached. Les GPO gèrent la configuration initiale et les politiques qui doivent s'appliquer hors connexion Internet.

Règle 3 : Évitez la redondance GPO + Intune sur le même paramètre. Le "last writer wins" s'applique au registre — une GPO et une policy Intune qui configurent le même paramètre génèrent des conflits silencieux.

Règle 4 : La source de vérité pour l'état de conformité est Intune. La source de vérité pour la configuration AD est la GPO. Ne les inversez pas.

Roadmap de modernisation : GPO → Settings Catalog¶

La trajectoire Microsoft¶

Microsoft ne déprécie pas les GPO pour les environnements Active Directory on-premises. Ce point est clair dans la documentation officielle et dans les communications des équipes produit.

La trajectoire réelle est différente : Microsoft investit dans le Settings Catalog d'Intune comme interface de convergence. Les paramètres ADMX sont progressivement répliqués dans le Settings Catalog pour permettre aux environnements cloud-first de gérer les mêmes politiques via MDM.

Ce que cela signifie en pratique : les GPO restent le meilleur outil pour les machines on-prem AD-joined. Le Settings Catalog devient le meilleur outil pour les machines AAD-joined (Intune-only). Pour les environnements hybrides, les deux coexistent.

Ce que les GPO feront toujours mieux que MDM¶

Roadmap de migration en cinq étapes¶

Group Policy Analytics — export pour la migration¶

# Export all GPOs to XML for import into Intune Group Policy Analytics
# Group Policy Analytics identifies which settings are MDM-supported
param(
    [string]$ExportDir = "C:\GPO-Migration-Export",
    [string]$Domain    = (Get-ADDomain).DNSRoot
)

if (-not (Test-Path $ExportDir)) { New-Item -ItemType Directory -Path $ExportDir | Out-Null }

$gpos = Get-GPO -All -Domain $Domain

$report = foreach ($gpo in $gpos) {
    $xmlFile = "$ExportDir\$($gpo.DisplayName -replace '[\\/:*?"<>|]', '_').xml"
    try {
        # Export GPO settings as XML (importable into Group Policy Analytics)
        Get-GPOReport -Guid $gpo.Id -ReportType Xml -Path $xmlFile
        [PSCustomObject]@{
            GPOName  = $gpo.DisplayName
            Status   = "Exported"
            XmlPath  = $xmlFile
            LastMod  = $gpo.ModificationTime
            Linked   = ($gpo.GpoStatus -ne 'AllSettingsDisabled')
        }
    } catch {
        [PSCustomObject]@{
            GPOName  = $gpo.DisplayName
            Status   = "ERROR: $_"
            XmlPath  = $null
            LastMod  = $gpo.ModificationTime
            Linked   = $null
        }
    }
}

$report | Format-Table -AutoSize
Write-Host ""
Write-Host "Total GPOs exported: $(($report | Where-Object Status -eq 'Exported').Count)"
Write-Host "Upload XML files to: Intune portal > Devices > Group Policy Analytics > Import"

Le Settings Catalog comme interface de convergence¶

Le Settings Catalog d'Intune regroupe aujourd'hui plus de 5 000 paramètres. Microsoft continue d'y ajouter les paramètres ADMX les plus utilisés.

La convergence est réelle, mais partielle. En 2026, le Settings Catalog couvre environ 70% des paramètres GPO courants pour les postes Windows 10/11. Les 30% restants incluent les paramètres DC, les politiques AD core, et les paramètres applicatifs moins courants.

Vision 2026+ et conclusion¶

Un bilan honnête¶

Ce livre a été construit autour d'un postulat opérationnel : les GPO ne disparaissent pas, et les maîtriser est une compétence stratégique durable.

Le paysage de 2026 confirme ce postulat.

La majorité des organisations disposent d'un Active Directory actif. Les migrations Intune-only sont encore minoritaires. Et même dans les environnements cloud-first, les GPO restent nécessaires dès qu'un contrôleur de domaine est présent — ne serait-ce que pour Kerberos policy et la configuration des DC eux-mêmes.

La question n'est pas "GPO ou Intune". La question est "quel outil pour quel périmètre".

Ce que ce livre vous a donné¶

En parcourant ces 25 chapitres, vous avez acquis les outils pour :

• Concevoir une architecture GPO d'entreprise qui résiste à la croissance et aux audits (chapitres 1 à 7)
• Déployer les applications métier critiques — Office, navigateurs, Windows Update, RDS, PKI (chapitres 8 à 16)
• Sécuriser le parc avec BitLocker, LAPS, Credential Guard, ASR, WDAC (chapitres 14, 15, 17)
• Migrer progressivement vers le cloud sans interruption de service (chapitres 18, 19, 20)
• Opérer en autonomie : dépannage de terrain, CI/CD, sécurité des GPO elles-mêmes (chapitres 22, 23, 24)

Ce que Zero Trust change pour votre pratique¶

Zero Trust n'invalide pas ces compétences — il les contextualise.

Les GPO que vous configurez deviennent des briques de conformité dans une évaluation continue. Credential Guard ne vaut que si vous avez une stratégie de détection des tentatives de dump LSASS. BitLocker ne vaut que si l'état de chiffrement remonte à Intune et déclenche le bon Conditional Access. LAPS ne vaut que si la rotation post-utilisation est activée.

La maîtrise technique est le prérequis. L'architecture de vérification continue est ce qui transforme cette maîtrise en posture de sécurité réelle.

Continuer à progresser¶

La sécurité Windows et les GPO évoluent rapidement. Quelques ressources pour rester à niveau :

Un dernier mot sur l'outillage¶

Les GPO resteront l'outil de référence pour la configuration AD on-prem dans toute votre carrière d'administrateur.

Ce qui changera, c'est la surface qu'elles couvrent — progressivement réduite au périmètre AD core tandis que le cloud absorbe la gestion des postes modernes. Ce qui ne changera pas, c'est la rigueur nécessaire pour les concevoir, les documenter et les opérer.

Un parc mal gouverné par GPO accumule de la dette de configuration. Cette dette devient de la surface d'attaque. La différence entre un administrateur compétent et un administrateur expert tient souvent à la discipline qu'il applique à ce qui est invisible — les GPO qui s'appliquent silencieusement, toutes les 90 minutes, sur chaque machine du domaine.

Maîtriser ce mécanisme, c'est maîtriser l'infrastructure.