Cet article fait partie de la série Migrer un millier de postes vers Windows 11 et Intune.
Des postes provisionnés, mais toujours en clair
Des postes neufs provisionnés par Windows Autopilot, en jonction hybride. Une stratégie BitLocker Intune exige le chiffrement complet du disque en XTS-AES 256, avec sauvegarde de la clé de récupération dans Entra ID. Pas de dépendance à l’Active Directory : la clé doit partir dans le cloud, et nulle part ailleurs.
Sur la plupart des postes, tout se passe bien. Sur certains, rien ne se passe. Du tout.
Le poste sort du provisionnement, l’utilisateur ouvre sa session, les applications s’installent. Des jours plus tard, le disque n’est toujours pas chiffré.
(Get-BitLockerVolume -MountPoint $env:SystemDrive).VolumeStatus
# FullyDecrypted
Dans Intune, le poste remonte non conforme sur le chiffrement. La stratégie BitLocker est pourtant bien attribuée, bien reçue, et d’autres postes du même lot sont chiffrés sans problème.
La stratégie, le matériel, puis le moment
La stratégie elle-même. Même stratégie, même groupe, même modèle de poste : sur les voisins, ça fonctionne. Cela rendait un problème général d’attribution moins probable, sans suffire à exclure un conflit local de stratégies.
Le matériel. TPM présent, prêt, démarrage sécurisé actif. Et surtout, en lançant l’assistant BitLocker du panneau de configuration à la main, le chiffrement démarrait et la clé partait dans Entra ID sans erreur. Le poste était donc parfaitement capable de chiffrer.
Le moment. C’est là que la piste s’est ouverte. Les journaux BitLocker montraient une tentative de chiffrement très tôt, juste après la jonction, suivie d’un échec de sauvegarde de la clé de récupération. Puis plus rien.
La fenêtre de jonction hybride
Dans le scénario hybride de ce projet, la jonction au domaine local précédait la fin de l’enregistrement dans Entra ID. La synchronisation Entra Connect et l’enregistrement côté poste devaient encore se terminer. Pendant cette fenêtre, qui peut durer de quelques minutes à bien plus longtemps, le poste répond encore « non » à cette question :
dsregcmd /status | Select-String 'AzureAdJoined'
# AzureAdJoined : NO
La stratégie BitLocker arrive pendant cette fenêtre. Les journaux des postes concernés montraient une tentative précoce et un échec de sauvegarde de la clé dans Entra ID. Avec l’exigence de sauvegarde avant chiffrement retenue ici, le chiffrement n’aboutissait pas. La chronologie observée orientait vers cette fenêtre d’enregistrement.
Jusque-là, c’est un comportement prudent. Le problème, dans notre déploiement, était l’absence de reprise observée après cet échec. Le poste finit par être reconnu par Entra ID, la session utilisateur s’ouvre normalement, mais aucune nouvelle tentative concluante n’a été observée pendant les jours de suivi. Le disque restait en clair. Ce constat concerne les postes et la configuration étudiés ; il ne signifie pas que BitLocker ne réessaie jamais dans toutes les configurations Windows.
Ce qui n’a pas résolu le blocage
Attendre. Sur nos postes, plusieurs jours d’attente n’ont pas déclenché de reprise concluante.
Réattribuer la stratégie. Retirer puis remettre l’attribution ne relance pas la tentative de façon fiable, et ce n’est pas une méthode tenable sur plusieurs centaines de postes.
Désactiver l’exigence de sauvegarde. Chiffrer sans clé sauvegardée, c’est remplacer un problème de conformité par un risque de perte de données. Hors de question.
La remédiation retenue
Nous avons retenu une paire de scripts de remédiation Intune, exécutée régulièrement pour reprendre les postes restés non chiffrés.
La détection signale un poste quand trois conditions sont réunies : le disque système est entièrement en clair, le poste est bien joint à Entra ID (sinon il est trop tôt pour agir), et aucun chiffrement n’est déjà en cours.
$status = (Get-BitLockerVolume -MountPoint $env:SystemDrive).VolumeStatus
if ($status -in 'EncryptionInProgress','FullyEncrypted') { exit 0 }
Cet extrait illustre uniquement l’exclusion de deux états : ce n’est pas le script de détection complet. Les autres états, notamment un chiffrement suspendu ou un déchiffrement en cours, demandent un traitement distinct. Un volume entièrement chiffré ne prouve pas non plus, à lui seul, la présence de sa clé dans Entra ID.
Ce dernier point compte. Une première version de la détection ne regardait que l’état « chiffré » : un poste en cours de chiffrement était vu comme en échec, et la remédiation tentait de relancer un chiffrement déjà en route. Il a fallu deux versions pour arriver à une détection fiable.
La remédiation relance le chiffrement avec les mêmes paramètres que la stratégie (XTS-AES 256, protecteur TPM, mot de passe de récupération), puis sauvegarde explicitement la clé dans Entra ID. L’un des appels utilisés est celui-ci :
BackupToAAD-BitLockerKeyProtector -MountPoint $env:SystemDrive -KeyProtectorId $id
Ici, $id désigne l’identifiant d’un protecteur de type RecoveryPassword déjà présent sur le volume. La commande sauvegarde ce protecteur dans Entra ID ; elle ne crée pas le protecteur et ne chiffre pas le disque. Son rôle est décrit dans la référence Microsoft. Les extraits de cet article ne constituent pas une remédiation complète à déployer telle quelle.
La réussite de la sauvegarde doit être contrôlée avant de considérer le poste comme traité. L’exigence de sauvegarde de la stratégie doit être conservée.
Une fois la remédiation passée sur les postes de ce projet, le chiffrement démarre, la clé apparaît sur l’objet appareil dans Entra ID, et la conformité est revenue au vert après remontée des nouveaux états dans Intune. Ce délai dépend des cycles de synchronisation et d’évaluation.
Le délai et les conditions à respecter
L’utilisation des remédiations Intune exige une licence éligible ; la présence d’Intune seule ne suffit pas à le déduire. Elle ajoute aussi un délai : le poste n’est chiffré qu’au passage suivant du script, pas à la sortie du provisionnement. Pendant ce laps de temps, le disque est en clair. Dans ce projet, ce délai était encadré pendant la préparation des postes dans les locaux. Un portable ne doit pas être considéré comme prêt à remettre simplement parce que la remédiation est attribuée : il faut vérifier le chiffrement et la sauvegarde de la clé.
Ce que je testerais avant de généraliser
Tester la chaîne complète sur un poste réel, en jonction hybride, avant le déploiement. Un poste joint directement à Entra ID ne reproduit pas cette même séquence de jonction hybride ; il ne suffit donc pas pour valider ce scénario. Il peut toutefois rencontrer d’autres causes d’échec de chiffrement.
Prévoir la remédiation dès le départ. Il faut vérifier le comportement de chaque stratégie dépendant de l’identité du poste, sans généraliser le résultat BitLocker à Windows LAPS ou aux applications. Ici, c’est la reprise du chiffrement qui a nécessité une intervention.
Repérer les postes concernés
Dans le centre d’administration Intune, le rapport de chiffrement permet de rechercher les appareils non chiffrés. Cherchez les postes Windows gérés depuis plus de quelques jours, joints à Entra ID, et toujours non chiffrés.
Sur un poste, l’état du disque et l’état de jonction fournissent un premier tri :
manage-bde -status $env:SystemDrive
Un disque en clair sur un poste joint depuis longtemps justifie une investigation. Cela ne prouve pas cette cause : il faut corréler les journaux BitLocker-API, l’état de jonction, les prérequis et les stratégies effectivement appliquées. La documentation de dépannage Microsoft détaille aussi les conflits de stratégies, le TPM, WinRE et l’UEFI.
AuditMS mesure le taux de chiffrement de votre parc Intune et signale les postes non chiffrés, en lecture seule. Lancer un audit sur auditms.fr