BitLocker ne s’active pas silencieusement avec Intune : diagnostic complet

Résumé

Le silent encryption exige un appareil et une policy compatibles. Je contrôle version Windows, jointure Entra, TPM, UEFI, Secure Boot, WinRE, droits utilisateur et absence de demande d’authentification incompatible.

Je n’applique BitLocker que par une autorité de configuration pour une population. Endpoint Security, Settings Catalog, baseline, GPO et MECM peuvent viser les mêmes CSP ou paramètres FVE et créer un conflit difficile à lire.

Le succès comprend trois preuves : volume chiffré avec protecteurs attendus, clé de récupération sauvegardée dans Entra ID et état Intune cohérent. La rotation ou la consultation de clé relève ensuite d’un processus audité.

Le silent encryption exige un appareil et une policy compatibles. Je contrôle version Windows, jointure Entra, TPM, UEFI, Secure Boot, WinRE, droits utilisateur et absence de demande d’authentification incompatible.

Contexte, objectif et périmètre

BitLocker peut être déjà actif par l’OEM, démarrer automatiquement ou être piloté par Intune. L’état observé dépend donc de l’historique du poste autant que du nouveau profil.

Une erreur 65000 ou un profil en erreur ne possède pas une cause universelle. Je corrèle le setting exact, la build Windows et les événements avant de reprendre un contournement terrain.

Je traite « BitLocker silencieux avec Intune » comme une chaîne de preuves et non comme une succession de boutons à cliquer. Une action n’est considérée comme réussie que lorsque le résultat est visible au niveau attendu : configuration du service, état reçu par le poste, traitement local, puis remontée cohérente dans les outils d’administration. Cette séparation évite de confondre une affectation valide avec une exécution terminée.

Je conserve systématiquement les heures en UTC et en heure locale, l’identité de l’appareil, le contexte utilisateur ou système, la version de Windows et la version des composants concernés. Sans ces repères, deux événements semblables peuvent appartenir à des cycles différents. Les exemples de journaux sont anonymisés et les identifiants techniques doivent l’être avant tout partage.

Ma méthode part du symptôme observable, formule plusieurs hypothèses concurrentes, puis cherche la preuve capable d’en éliminer une. Je ne commence pas par vider un cache, supprimer une clé ou réinstaller un agent : ces actions modifient précisément l’état qui permettrait de comprendre l’incident. La collecte initiale reste donc en lecture seule.

Une correction n’est proposée qu’après localisation de la phase en échec. Je distingue toujours le contournement temporaire, la correction causale et la correction structurelle. Le retour arrière est préparé avant la modification, puis le résultat est contrôlé sur un pilote représentatif avant toute généralisation.

• Objectif : qualifier les prérequis silent
• Objectif : détecter les conflits de policy
• Objectif : prouver chiffrement et escrow
• Périmètre : volumes OS Windows 10/11 supportés
• Périmètre : BitLocker Endpoint Security/Intune
• Périmètre : Entra joined et hybrid joined selon prérequis

Architecture et fonctionnement général

Le profil Intune est traduit en paramètres CSP puis appliqué par le client MDM. Les valeurs peuvent être projetées dans les stratégies FVE, mais le registre seul ne prouve pas la réussite du chiffrement.

Windows évalue matériel, firmware et configuration de récupération. Sur un appareil non compatible avec le scénario silencieux, l’utilisateur peut recevoir une interaction ou le chiffrement peut rester inactif.

La clé de récupération doit être sauvegardée dans Entra. Je vérifie l’identifiant du protecteur local et l’objet device correspondant avant de déclarer l’escrow réussi.

Prérequis techniques et préparation

Avant toute mise en œuvre, je fige le périmètre de test et je capture l’état initial. Cette photographie comprend les versions, les affectations, les autorités de gestion, les dépendances et les exceptions connues. Elle sert autant à interpréter le résultat qu’à construire le retour arrière.

Je vérifie les prérequis sur un appareil réellement représentatif. Une console qui autorise la création d’un profil ne prouve ni l’éligibilité du poste, ni la disponibilité effective de la fonctionnalité dans le tenant. Les prérequis réseau, licence, identité et système doivent tous être confirmés.

• Windows supporté
• Entra join ou hybrid join supporté
• TPM opérationnel
• UEFI natif et Secure Boot
• WinRE disponible
• une seule autorité BitLocker
• droits de lecture recovery key contrôlés

Procédure de mise en œuvre

La procédure suivante est volontairement découpée en points de contrôle. Je ne poursuis pas lorsqu’un résultat attendu manque : continuer masquerait la première divergence et produirait des symptômes secondaires plus difficiles à interpréter.

Les noms de groupes, profils, applications et fichiers sont des exemples. Je les remplace par les conventions de l’organisation, je documente la population ciblée et je conserve une preuve avant/après pour chaque changement.

Les prérequis qui bloquent silencieusement

TPM présent ne signifie pas TPM prêt. Je vérifie son état, les erreurs firmware et les événements. Un Secure Boot désactivé ou un démarrage Legacy modifie aussi le scénario supporté.

WinRE doit être disponible pour certains parcours de récupération. reagentc /info confirme son état ; une partition de récupération cassée doit être réparée avant la généralisation.

Les paramètres d’authentification au démarrage peuvent rendre impossible l’absence d’interaction. Je vérifie que la policy choisie correspond au modèle silent attendu et au type d’utilisateur.

Chiffrement, protecteur et escrow

Get-BitLockerVolume et manage-bde montrent le chiffrement réel. Je vérifie pourcentage, méthode, ProtectionStatus et KeyProtector.

La présence d’un protecteur RecoveryPassword local ne prouve pas sa sauvegarde cloud. Je recherche la clé sur le bon objet Entra et je contrôle les droits d’accès.

Une rotation produit une nouvelle valeur ; son processus doit être audité. Je ne copie jamais une clé de récupération dans un ticket ou un article.

Scripts, commandes et exemples de lecture

Les commandes présentées servent à observer ou illustrer le fonctionnement. Les scripts de diagnostic restent de niveau 1, avec arrêt sur erreur et gestion globale de l’exception. Ils ne modifient pas le poste. Une remédiation serait au minimum de niveau 2, avec mode de simulation, journalisation adaptée au test et comportement de rollback explicitement validé.

Je lis toujours la sortie avec le contexte d’exécution. Une commande lancée dans la session de l’utilisateur ne voit pas nécessairement les mêmes certificats, chemins, variables, applications ou ruches de registre qu’un processus exécuté par l’Intune Management Extension sous SYSTEM.

# Exemple pédagogique non testé — niveau 1
$ErrorActionPreference = 'Stop'
try {
  $volume = Get-BitLockerVolume -MountPoint 'C:'
  $tpm = Get-Tpm
  $secureBoot = Confirm-SecureBootUEFI
  [pscustomobject]@{ VolumeStatus=$volume.VolumeStatus; Protection=$volume.ProtectionStatus; Encryption=$volume.EncryptionMethod; TpmReady=$tpm.TpmReady; SecureBoot=$secureBoot }
}
catch { Write-Error "Collecte BitLocker impossible : $($_.Exception.Message)"; exit 1 }

Validation et critères de contrôle

Je valide d’abord le résultat technique sur le poste, puis sa remontée dans le service. Le portail peut conserver un état ancien pendant un certain temps ; inversement, un état vert dans la console ne dispense pas de contrôler l’artefact local réellement attendu.

Le critère GO exige un résultat reproductible, une absence de régression sur les fonctions voisines, une documentation à jour et un retour arrière démontré. Le critère NO-GO s’applique dès qu’une dépendance n’est pas maîtrisée, qu’une partie du parc réagit différemment ou que l’état final ne peut pas être prouvé.

• prérequis silent validés
• une seule autorité
• volume chiffré
• protecteurs attendus
• clé sauvegardée
• reporting Intune cohérent

Journaux, diagnostic et constitution des preuves

Le journal DeviceManagement-Enterprise-Diagnostics-Provider/Admin relie la policy MDM et le CSP. Microsoft-Windows-BitLocker/BitLocker Management et BitLocker-API/Management détaillent le moteur de chiffrement. System apporte les erreurs TPM.

Je capture les événements dans la fenêtre de synchronisation et de démarrage du chiffrement. Une erreur historique sur un ancien profil ne doit pas être confondue avec la policy active.

• manage-bde -status
• Get-BitLockerVolume
• Get-Tpm et Secure Boot
• reagentc /info
• DM-EDP/Admin
• BitLocker Management et BitLocker-API/Management
• clé présente dans Entra

Dépannage : symptômes, preuves et corrections

Je pars de la colonne Symptôme, mais je ne choisis jamais une correction sur ce seul indice. La colonne Preuve indique l’élément qui doit confirmer la cause. Si cette preuve manque, l’hypothèse reste ouverte et l’action proposée ne doit pas être appliquée comme une recette automatique.

Après correction, je reproduis le scénario initial et je compare les mêmes points de mesure. Un changement de symptôme n’est pas toujours une résolution : il peut simplement indiquer que le traitement progresse jusqu’à une nouvelle phase. La chronologie complète reste donc la référence.

Retour arrière et points de vigilance

Le retour arrière ne consiste pas seulement à retirer une affectation. Je restaure l’autorité précédente, la configuration ou la version attendue, puis je vérifie que le poste a effectivement reçu et appliqué ce nouvel état. Les caches et délais de remontée sont documentés au lieu d’être interprétés comme une absence de rollback.

Je conserve les preuves du pilote, le motif de la décision et les écarts rencontrés. Si le service cloud ou une interface évolue, je réévalue les étapes avant une nouvelle vague. Aucun succès obtenu uniquement sur le poste de développement ne constitue une validation de production.

• Rollback : retirer affectation pilote
• Rollback : restaurer ancienne policy
• Rollback : déchiffrer uniquement si risque et procédure le justifient
• Vigilance : ne jamais exposer une recovery key
• Vigilance : ne pas généraliser l’erreur 65000
• Vigilance : tester récupération avant production