Points clés à retenir (TL;DR)
Synthèse exécutive- Un script central ne peut pas dechiffrer un mot de passe LAPS sauvegarde dans Entra ID : le chiffrement DPAPI-NG est lie au peripherique.
- Oubliez la synchronisation du secret en clair vers Active Directory ; privilegiez une console interne unifiee qui lit la source d'autorite via Microsoft Graph.
- La permission Graph
DeviceLocalCredential.Read.Alldonne acces a tous les secrets LAPS Azure : traitez-la comme un acces hautement privilegie. - Choisissez une seule source d'autorite (Entra OU AD) pour LAPS afin d'eviter deux comptes admin locaux concurrents.
- Toute operation de ce type est un changement au sens ITIL : fenetre de maintenance, validation et plan de retour obligatoires.
Contexte
Dans une PME en cours de modernisation, le parc est souvent hybride : certains postes sont joints a Active Directory (AD) classique, d’autres sont geres via Microsoft Intune et joints a Entra ID. Deux technologies cohabitent alors pour proteger le compte administrateur local et les cles de recuperation BitLocker : le LAPS hérité (attribut ms-Mcs-AdmPwd dans AD) et le Windows LAPS moderne (attribut msLAPS-Password dans AD, ou sauvegarde chiffree dans Entra ID).
La tentation est forte : faire en sorte que les secrets stockes dans Entra se retrouvent aussi dans AD, pour que l’equipe support lise un seul endroit. C’est un reflexe de continuite operationnelle legitime. Mais la mecanique de chiffrement de Windows LAPS rend cette synchronisation « secret en clair » techniquement impossible depuis un serveur central, et toute solution de contournement crée un risque de securite qu’il faut comprendre avant d’agir.
Comment ca fonctionne
Voici le scenario typique (conditionnel, illustratif) que rencontre une equipe TI qui veut unifier la lecture des secrets.
Etape 1 — Sauvegarde du secret
Un poste gere par Intune applique une politique Windows LAPS avec BackupDirectory = Azure AD only. A chaque rotation (par exemple tous les 30 jours), le mot de passe de l’administrateur local est chiffre cote peripherique via DPAPI-NG, puis pousse vers Entra ID dans l’objet deviceLocalCredentials.
Etape 2 — Tentative de lecture centralisee
Un serveur applicatif execute une tache planifiee qui interroge Graph pour enumerer les secrets :
GET https://graph.microsoft.com/v1.0/directory/deviceLocalCredentials
?$select=id,deviceName,lastBackupDateTime,credentials&$top=100La reponse contient bien les entrees, mais le champ du mot de passe est chiffre. Le script recupere des metadonnees (nom du peripherique, horodatage de sauvegarde), pas le secret exploitable.
Etape 3 — Le mur du dechiffrement
Pour obtenir le mot de passe en clair, il faut soit etre sur le peripherique lui-meme, soit utiliser Get-LapsAADPassword dans un contexte utilisateur interactif disposant du droit de lecture. Une tache planifiee en mode application (app-only, certificat) ne peut pas effectuer ce dechiffrement. Le script central est donc structurellement incapable d’ecrire le secret en clair dans l’attribut AD msLAPS-Password.
Lien avec la securite offensive
Comprendre ce mecanisme compte aussi pour la defense. Un attaquant qui compromet un compte disposant de DeviceLocalCredential.Read.All peut moissonner les secrets LAPS a l’echelle du parc (Credential Access — T1555, Credentials from Password Stores). De meme, la lecture non autorisee des attributs LAPS dans AD releve de T1003 (OS Credential Dumping) lorsque les permissions LDAP sont trop larges. Multiplier les copies du secret (Entra + AD) multiplie la surface d’exposition.
Signaux
Ce qui rend ce type de mauvaise architecture dangereux :
- Permission Graph trop large accordee a une application de service, avec consentement administrateur, sans restriction d’acces au compte applicatif.
- Deux comptes administrateur locaux gerés en parallele (LAPS hérité via GPO + Windows LAPS moderne via Intune) : risque de conflit et de mot de passe obsolete valide.
- Certificat ou secret client stocke en clair dans un script ou une variable d’environnement sur le serveur de synchronisation.
- Delegation AD donnant le droit d’ecriture sur les attributs LAPS a un compte de service qui est, de fait, equivalent administrateur de domaine.
Detection
Logique de correlation a mettre en place :
- Entra ID — journaux d’audit : surveillez les lectures de
deviceLocalCredentialset l’ajout de la permissionDeviceLocalCredential.Read.Alla toute application. Alertez sur tout consentement administrateur nouveau. - Active Directory — audit LDAP : activez l’audit d’acces aux objets et surveillez les lectures/ecritures sur
ms-Mcs-AdmPwdetmsLAPS-Password(evenements 4662). Une lecture massive par un seul compte est anormale. - Volume anormal : correlez un pic de requetes Graph
deviceLocalCredentialsavec une connexion applicative depuis une IP ou un contexte inhabituel (Discovery — T1087, Account Discovery). - Rotation forcee : une rotation inattendue des secrets LAPS peut signaler qu’un attaquant veut effacer ses traces ou garantir sa persistance.
Mitigation
La bonne reponse n’est pas de synchroniser le secret, mais de centraliser la lecture via une console interne qui s’authentifie a la source d’autorite. Comparatif des approches :
| Approche | Principe | Evaluation |
|---|---|---|
| Console interne unifiee | Un service back-end lit Entra via Graph et, en repli, AD ; les techniciens n’accedent ni a Entra ni a AD directement | Recommandee : acces controle, auditable, extensible (BitLocker, infos poste) |
| Basculer vers AD uniquement | Politique Intune BackupDirectory = Active Directory only ; lecture directe de msLAPS-Password |
Simple, mais perd la visibilite portail Intune |
| Double politique (Entra + AD) | Deux comptes admin locaux geres en parallele | Fragile : risque de conflit, a eviter |
Mise en oeuvre d’une console de lecture securisee
Prerequis :
- Une inscription d’application dediee dans Entra, distincte de vos autres integrations.
- Authentification par certificat (pas de secret client en clair) ; stockage dans un coffre de secrets (ex. Azure Key Vault).
- Permission Graph
DeviceLocalCredential.Read.All(permission d’application), avec consentement administrateur. - Acces reseau du back-end restreint, journalisation activee, acces technicien derriere authentification forte (MFA).
Lecture d’un secret cote back-end (contexte application, PowerShell) :
Connect-MgGraph -ClientId "<app-id>" -TenantId "<tenant-id>" `
-CertificateThumbprint "<thumbprint-depuis-coffre>" -NoWelcome
# Lire le secret LAPS d'un poste cible depuis Entra
Get-LapsAADPassword -DeviceIds "poste-exemple" -IncludePasswords -AsPlainTextEtape de validation :
- Confirmez que la console retourne bien un mot de passe pour un poste de test recent, et compare l’horodatage a
lastBackupDateTimedans Entra. - Verifiez dans les journaux d’audit Entra que l’acces a bien ete trace au nom de l’application de service, pas d’un compte nominatif.
- Testez un poste absent de la source : la console doit renvoyer une erreur claire, pas une fuite d’information.
Plan de retour :
- Si la console pose probleme, les technicien habilites conservent l’acces de secours : lecture directe dans le portail Intune (Entra) ou via
Get-LapsAADPassworden session administrateur. - Pour revenir en arriere sur une permission : dans l’inscription d’application, supprimez
DeviceLocalCredential.Read.Allet revoquez le consentement ; l’acces aux secrets est immediatement coupe. - Documentez le changement au CAB, planifiez-le en fenetre de maintenance et rattachez-le au processus de gestion des changements ITIL.
A retenir
La synchronisation « secret en clair » de LAPS d’Entra ID vers Active Directory est une impasse technique : le chiffrement DPAPI-NG l’empeche par conception. La bonne reponse consiste a choisir une source d’autorite claire et a centraliser la lecture derriere une console interne auditable, en traitant la permission Graph correspondante comme un acces hautement privilegie. Chaque etape doit passer par la gestion des changements, avec validation et plan de retour.
Vous gerez un parc hybride et souhaitez securiser vos secrets LAPS et cles BitLocker sans ouvrir de brèche ? Nos analystes peuvent vous aider a definir l’architecture, durcir les permissions et mettre en place la detection adaptee a votre PME.
