BitLocker via GPO¶

La CSE BitLocker : pas de CSE dédiée¶

Une idée reçue courante¶

Contrairement à ce que l'on pourrait attendre, BitLocker n'a pas de CSE (Client-Side Extension) dédiée. Il n'existe pas de DLL spécifique chargée d'interpréter des paramètres BitLocker dans SYSVOL.

BitLocker est piloté exclusivement via des valeurs de registre sous-politiques, traitées par la CSE Registry standard ({35378EAC-683F-11D2-A89A-00C04FBBCFA2}). La GPMC génère un registry.pol ordinaire — BitLocker réagit ensuite aux valeurs présentes sous sa clé de registre dédiée.

La clé FVE¶

Tous les paramètres BitLocker gérés par GPO aboutissent sous :

HKLM\SOFTWARE\Policies\Microsoft\FVE\

Le service BitLocker Drive Encryption Service (BDESVC) lit cette branche au démarrage et à chaque changement de politique pour déterminer ses contraintes opérationnelles.

Valeurs de registre FVE clés¶

Paramètres GPO BitLocker¶

Chemin GPMC¶

L'ensemble des paramètres BitLocker se trouve à :

Computer Configuration
  └── Policies
        └── Administrative Templates
              └── Windows Components
                    └── BitLocker Drive Encryption

Trois sous-nœuds distincts existent pour le volume OS, les volumes de données fixes, et les volumes amovibles.

:material-encryption: Méthode de chiffrement¶

Le paramètre "Choose drive encryption method and cipher strength" contrôle l'algorithme appliqué au moment du chiffrement initial.

Protection au démarrage¶

Le paramètre "Require additional authentication at startup" contrôle ce que BitLocker vérifie avant de déverrouiller le volume OS.

TPM seul — le déverrouillage est transparent, aucune interaction utilisateur. C'est le mode par défaut recommandé pour les flottes de postes standards. La protection repose sur l'intégrité de la chaîne de démarrage mesurée par le TPM.

TPM + PIN — l'utilisateur saisit un PIN numérique (4 à 20 chiffres) ou un PIN renforcé alphanumérique. Résistant aux attaques physiques par extraction de clé. Recommandé pour les populations à risque élevé (dirigeants, équipes sécurité, accès à des données classifiées).

TPM + Clé USB — la clé de démarrage est stockée sur une clé USB qui doit être présente à chaque démarrage. Rare en entreprise car contraignant, utilisé dans des contextes très spécifiques (postes fixes dans des locaux sécurisés).

Sans TPM — BitLocker déverrouille via un mot de passe ou une clé USB uniquement. Nécessite d'activer EnableBDEWithNoTPM = 1. Acceptable uniquement sur des machines sans TPM 2.0 en environnement contrôlé.

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\FVE]
"UseAdvancedStartup"=dword:00000001
"UseTPM"=dword:00000000
"UseTPMPIN"=dword:00000002
"UseTPMKey"=dword:00000000
"UseTPMKeyPIN"=dword:00000000

Options de récupération¶

Le paramètre "Choose how BitLocker-protected operating system drives can be recovered" définit ce qui est disponible si la chaîne de démarrage normale échoue.

La récupération peut se faire via :

• Mot de passe de récupération (48 chiffres) — stocké dans AD DS, imprimable, sauvegardable manuellement.
• Agent de récupération de données (DRA) — un certificat de déchiffrement d'entreprise, nécessite une PKI interne.

Pour une entreprise sans PKI dédiée, le mot de passe de récupération avec backup AD DS est la seule option viable.

Backup des clés de récupération dans AD DS¶

L'attribut msFVE-RecoveryInformation¶

Quand BitLocker sauvegarde une clé de récupération dans AD DS, il crée un objet enfant sur l'objet ordinateur concerné. Cet objet enfant est de classe msFVE-RecoveryInformation.

Chaque objet msFVE-RecoveryInformation contient :

Un ordinateur peut avoir plusieurs objets msFVE-RecoveryInformation si le volume a été re-chiffré ou si plusieurs clés ont été générées.

Vérifier la présence d'un backup avant déploiement¶

Avant d'activer BitLocker sur un grand nombre de machines, il est indispensable de s'assurer que la configuration AD DS est correcte. Ce script vérifie, pour une OU donnée, quels ordinateurs ont une clé de récupération sauvegardée.

# Verify BitLocker recovery key backup in AD DS for a given OU
# Returns a report of computers with and without keys stored
#Requires -Module ActiveDirectory

param (
    [Parameter(Mandatory)]
    [string]$SearchBase,

    [string]$OutputCsvPath = "$env:TEMP\bitlocker-backup-audit.csv"
)

$computers = Get-ADComputer -Filter { Enabled -eq $true } `
    -SearchBase $SearchBase `
    -Properties distinguishedName, operatingSystem

$results = foreach ($computer in $computers) {
    $recoveryObjects = Get-ADObject `
        -Filter { objectClass -eq 'msFVE-RecoveryInformation' } `
        -SearchBase $computer.DistinguishedName `
        -Properties msFVE-RecoveryGuid, whenCreated `
        -ErrorAction SilentlyContinue

    [PSCustomObject]@{
        ComputerName     = $computer.Name
        OperatingSystem  = $computer.OperatingSystem
        HasRecoveryKey   = [bool]$recoveryObjects
        KeyCount         = ($recoveryObjects | Measure-Object).Count
        LatestBackup     = ($recoveryObjects | Sort-Object whenCreated -Descending | Select-Object -First 1).whenCreated
        DN               = $computer.DistinguishedName
    }
}

$results | Export-Csv -Path $OutputCsvPath -NoTypeInformation -Encoding UTF8

$withKey    = ($results | Where-Object { $_.HasRecoveryKey }).Count
$withoutKey = ($results | Where-Object { -not $_.HasRecoveryKey }).Count

Write-Host "Computers with recovery key   : $withKey"
Write-Host "Computers without recovery key: $withoutKey"
Write-Host "Report exported to: $OutputCsvPath"

Computers with recovery key   : 142
Computers without recovery key: 8
Report exported to: C:\Users\Admin\AppData\Local\Temp\bitlocker-backup-audit.csv

Récupérer une clé depuis AD DS¶

La récupération se fait via l'interface GPMC (onglet BitLocker Recovery sur l'objet ordinateur dans ADUC) ou via PowerShell.

# Retrieve BitLocker recovery password from AD DS for a specific computer
# Requires 'Read msFVE-RecoveryPassword' permission on the computer object
param (
    [Parameter(Mandatory)]
    [string]$ComputerName
)

$computer = Get-ADComputer -Identity $ComputerName -Properties distinguishedName

$recoveryObjects = Get-ADObject `
    -Filter { objectClass -eq 'msFVE-RecoveryInformation' } `
    -SearchBase $computer.DistinguishedName `
    -Properties msFVE-RecoveryPassword, msFVE-RecoveryGuid, whenCreated |
    Sort-Object whenCreated -Descending

foreach ($obj in $recoveryObjects) {
    [PSCustomObject]@{
        RecoveryGuid     = $obj.'msFVE-RecoveryGuid'
        RecoveryPassword = $obj.'msFVE-RecoveryPassword'
        BackupDate       = $obj.whenCreated
    }
}

Le paramètre de blocage critique¶

Le paramètre GPO "Do not enable BitLocker until recovery information is stored to AD DS for (OS|fixed|removable) drives" est le garde-fou fondamental.

Lorsqu'il est activé (RequireActiveDirectoryBackup = 1 et OSRequireActiveDirectoryBackup = 1), BitLocker refuse de commencer le chiffrement si la communication avec AD DS échoue au moment de la sauvegarde de la clé.

Cela signifie qu'une machine hors domaine au moment du chiffrement ne sera pas chiffrée — ce qui est le comportement correct. Un disque non chiffré est récupérable. Un disque chiffré sans clé sauvegardée est perdu.

BitLocker Network Unlock¶

Le problème datacenter¶

En environnement datacenter ou salle serveur, le mode TPM+PIN crée un problème opérationnel majeur : chaque redémarrage non planifié (mise à jour, crash, maintenance) requiert une intervention physique pour saisir le PIN. Sur un parc de centaines de serveurs, c'est inacceptable.

BitLocker Network Unlock résout ce problème. Un serveur sur le réseau interne peut être déverrouillé automatiquement au démarrage, sans PIN, à condition qu'il soit sur le réseau d'entreprise au moment du boot. Si le réseau n'est pas accessible (démarrage hors site, démarrage sur un réseau inconnu), le mode de repli (PIN ou récupération) s'applique.

Infrastructure requise¶

Network Unlock nécessite :

Déploiement du certificat¶

Le certificat de Network Unlock est un certificat x509 avec une utilisation étendue de clé spécifique. Il est déployé via GPO dans :

Computer Configuration
  └── Policies
        └── Windows Settings
              └── Security Settings
                    └── Public Key Policies
                          └── BitLocker Drive Encryption Network Unlock Certificate

La clé privée reste sur le serveur WDS. Les clients reçoivent uniquement la clé publique via GPO pour chiffrer leur requête de déverrouillage au boot.

Flux de déverrouillage Network Unlock¶

sequenceDiagram
    participant C as Client (PXE/UEFI)
    participant DHCP as Serveur DHCP
    participant WDS as Serveur WDS
    participant TPM as TPM Client

    C->>DHCP: DHCPDISCOVER (UEFI PXE mode)
    DHCP-->>C: DHCPOFFER + option 245 (Network Unlock endpoint)
    C->>WDS: Envoi paquet chiffré avec clé publique Network Unlock
    Note over C,WDS: Paquet contient : challenge TPM chiffré avec cert public WDS
    WDS->>WDS: Déchiffrement avec clé privée Network Unlock
    WDS-->>C: Réponse chiffrée avec clé publique client
    C->>TPM: Déchiffrement via TPM (validation PCR)
    TPM-->>C: Clé de volume déverrouillée
    Note over C: Volume OS déverrouillé — démarrage normal

Pré-provisioning BitLocker en OSD¶

Le problème du chiffrement post-OSD¶

En déploiement classique MDT ou MECM/SCCM, BitLocker est activé après l'installation de l'OS. Si le disque n'a pas été pré-provisionné, le chiffrement intégral du disque prend plusieurs heures sur des disques de grande capacité — bloquant la séquence de tâches ou nécessitant de laisser la machine disponible pendant le chiffrement.

Le pré-provisioning pendant WinPE¶

La solution est d'activer BitLocker pendant la phase WinPE, avant même que l'OS ne soit installé. À ce stade, le volume OS est vide — le chiffrement est quasi-instantané.

REM Step 1: Enable BitLocker pre-provisioning on the OS volume (WinPE phase)
REM The drive letter may vary — use the letter assigned to the OS partition
manage-bde -on %OSDisk% -used -skiphardwaretest

REM Step 2: Protect with TPM (key protector added before OS install)
manage-bde -protectors -add %OSDisk% -tpm

Interaction avec les GPO post-déploiement¶

Après l'installation de l'OS et la jonction au domaine, les GPO BitLocker s'appliquent pour la première fois. Plusieurs cas à anticiper :

Cas 1 — GPO compatible avec le pré-provisioning. Le volume est déjà chiffré avec TPM. Si la GPO impose TPM seul, aucune action requise — BitLocker est déjà dans l'état attendu.

Cas 2 — GPO impose TPM+PIN, pré-provisioning TPM seul. BitLocker détecte un écart entre la politique et l'état actuel. Sur Windows 10/11, le système ne dégrade pas la protection existante. L'administrateur doit ajouter le protecteur PIN manuellement ou via script post-déploiement.

Cas 3 — GPO impose le backup AD DS, backup non encore effectué. La GPO déclenche automatiquement le backup de la clé TPM au prochain refresh. Vérifier via PowerShell après jonction domaine.

# Verify BitLocker state and trigger AD DS backup if key not yet stored
# Run as part of post-OSD configuration script

$volume = Get-BitLockerVolume -MountPoint $env:SystemDrive

Write-Host "Protection status : $($volume.ProtectionStatus)"
Write-Host "Encryption method : $($volume.EncryptionMethod)"
Write-Host "Key protectors    : $($volume.KeyProtector.KeyProtectorType -join ', ')"

# Force AD DS backup of the numerical password protector
$numericProtector = $volume.KeyProtector | Where-Object { $_.KeyProtectorType -eq 'RecoveryPassword' }

if ($numericProtector) {
    Backup-BitLockerKeyProtector `
        -MountPoint $env:SystemDrive `
        -KeyProtectorId $numericProtector.KeyProtectorId
    Write-Host "Recovery key backed up to AD DS successfully."
} else {
    Write-Warning "No RecoveryPassword protector found — verify GPO configuration."
}

Protection status : On
Encryption method : XtsAes256
Key protectors    : Tpm, RecoveryPassword
Recovery key backed up to AD DS successfully.

Séquence de démarrage avec BitLocker¶

Arbre de décision au démarrage¶

flowchart TD
    A([Démarrage machine]) --> B{UEFI / Secure Boot\nactivé ?}
    B -- Non --> C[⚠️ Mesures PCR invalides\nDémarrage en mode récupération]
    B -- Oui --> D{TPM présent\net activé ?}
    D -- Non --> E{Clé USB présente ?}
    E -- Non --> F[Saisie mot de passe BitLocker\nou mode récupération]
    E -- Oui --> G[Déverrouillage via clé USB]
    D -- Oui --> H{Mesures PCR\nvalides ?}
    H -- Non --> I[⚠️ Chaîne de démarrage modifiée\nMise à jour BIOS / OS ?]
    I --> J[Saisie du mot de passe\nde récupération 48 chiffres]
    H -- Oui --> K{Mode de protection\nchoisi ?}
    K -- TPM seul --> L([Déverrouillage automatique\nTransparent pour l'utilisateur])
    K -- TPM + PIN --> M{PIN correct ?}
    M -- Non --> N[3 tentatives max\npuis mode récupération]
    M -- Oui --> L
    K -- Network Unlock --> O{Sur le réseau\nd'entreprise ?}
    O -- Oui --> P{Réponse WDS\nobtenue ?}
    P -- Oui --> L
    P -- Non --> M
    O -- Non --> M

    style C fill:#ff6b6b,color:#fff
    style I fill:#ff6b6b,color:#fff
    style N fill:#ffa94d,color:#fff
    style J fill:#ffa94d,color:#fff
    style L fill:#51cf66,color:#fff

Décodage des états de démarrage¶

Mesures PCR invalides — le TPM a détecté un changement dans la chaîne de démarrage. Causes légitimes : mise à jour firmware UEFI, activation/désactivation Secure Boot, changement de bootloader. Dans ce cas, la récupération via mot de passe 48 chiffres est normale. Après récupération, le TPM se resynchronise.

3 tentatives PIN puis récupération — comportement par défaut configurable via GPO (OSLockoutDurationMinutes). En environnement haute sécurité, réduire à 1 tentative.

Network Unlock — repli sur PIN — si le serveur WDS est indisponible ou que le réseau est inaccessible, la machine bascule silencieusement sur le protecteur PIN (s'il existe) ou sur la récupération. Documenter ce comportement pour les équipes d'astreinte.

Pièges de production¶

Piège 1 — Backup non configuré + panne disque¶

C'est le scénario catastrophe. Si RequireActiveDirectoryBackup n'est pas activé et qu'un poste est chiffré sans que la clé ait été sauvegardée, une panne disque nécessitant un remplacement partiel du matériel (carte mère avec nouveau TPM) rend les données définitivement inaccessibles.

Ce scénario arrive plus souvent qu'on ne le croit, typiquement lors d'un déploiement rapide où le paramètre de backup a été oublié.

Piège 2 — Migration AES-CBC vers XTS-AES¶

De nombreux parcs déployés avant Windows 10 1511 utilisent encore AES-CBC-128. La GPO peut être mise à jour pour imposer XTS-AES-256 — mais le changement ne s'applique pas aux volumes déjà chiffrés.

# Audit encryption method across managed computers via CIM
# Requires WinRM enabled on targets

param (
    [Parameter(Mandatory)]
    [string[]]$ComputerNames
)

$results = foreach ($computer in $ComputerNames) {
    try {
        $volumes = Get-CimInstance -ClassName Win32_EncryptableVolume `
            -Namespace root\cimv2\Security\MicrosoftVolumeEncryption `
            -ComputerName $computer `
            -ErrorAction Stop

        foreach ($vol in $volumes) {
            [PSCustomObject]@{
                Computer         = $computer
                DriveLetter      = $vol.DriveLetter
                EncryptionMethod = $vol.EncryptionMethod
                ProtectionStatus = $vol.ProtectionStatus
            }
        }
    } catch {
        [PSCustomObject]@{
            Computer         = $computer
            DriveLetter      = 'N/A'
            EncryptionMethod = "ERROR: $($_.Exception.Message)"
            ProtectionStatus = -1
        }
    }
}

$results | Group-Object EncryptionMethod | ForEach-Object {
    Write-Host "$($_.Name): $($_.Count) volume(s)"
}

$results | Export-Csv "$env:TEMP\encryption-method-audit.csv" -NoTypeInformation -Encoding UTF8

AES_128: 47 volume(s)
XTS_AES_256: 203 volume(s)
XTS_AES_128: 12 volume(s)

La migration des 47 volumes AES_128 nécessite une opération manuelle ou scriptée (manage-bde -upgrade ou déchiffrement + re-chiffrement).

Piège 3 — Volumes amovibles et compatibilité¶

Un volume amovible chiffré avec XTS-AES ne peut pas être lu sur Windows 7 ou 8.1 — même avec BitLocker To Go Reader. Ces versions ne comprennent pas le format XTS.

Si votre organisation utilise encore des postes Windows 7 (en fin de vie mais parfois présents dans des environnements industriels), conserver impérativement AES-CBC pour les volumes amovibles.

Piège 4 — Mise à jour firmware et PCR¶

Une mise à jour firmware UEFI modifie les mesures PCR. Si BitLocker utilise les PCR 0 (firmware) dans son profil de validation — ce qui est le cas par défaut — chaque mise à jour firmware déclenche une entrée en mode récupération au redémarrage suivant.

Deux approches pour gérer ce cas :

Option A — Suspendre BitLocker avant mise à jour firmware (recommandé)

# Suspend BitLocker protection for one reboot cycle before firmware update
# BitLocker automatically resumes after the next boot
Suspend-BitLocker -MountPoint $env:SystemDrive -RebootCount 1
Write-Host "BitLocker suspended for 1 reboot cycle. Apply firmware update and reboot."

Option B — Exclure PCR 0 du profil de validation (à utiliser avec précaution)

Cette option réduit la surface de protection — elle est acceptable uniquement dans des environnements avec Secure Boot robuste et gestion rigoureuse des mises à jour firmware.

Piège 5 — Suppression de l'objet ordinateur AD¶

Quand un objet ordinateur est supprimé d'AD DS (par nettoyage de comptes inactifs, par exemple), tous les objets msFVE-RecoveryInformation enfants sont supprimés avec lui. Si la machine est ensuite réintégrée au domaine avec un nouvel objet ordinateur, l'ancienne clé de récupération n'est plus dans AD DS.

Toujours vérifier que la machine est re-chiffrée ou que la clé est re-sauvegardée après réintégration.

Références croisées¶

• Chapitre 13 — Stratégies de sécurité — Contexte général des mécanismes de sécurité GPO, scecli.dll, et audit avancé. BitLocker s'inscrit dans une stratégie de sécurité endpoint plus large.
• Gpo pour les Admins — Chapitre 17 : BitLocker et LAPS — Déploiement enterprise de BitLocker avec LAPS, intégration Intune/Entra ID, et gestion du cycle de vie des clés dans un environnement hybride.