Lacunes de couverture de LAPS : audit et remédiation

Synthèse : que sont les lacunes de couverture de LAPS déployé ?

Les lacunes de couverture de LAPS déployé désignent un environnement Active Directory où la gestion des mots de passe administrateur local existe, mais où sa protection ne couvre pas toutes les machines ou identités importantes. Certains ordinateurs ne reçoivent jamais la stratégie prévue. D’autres utilisent encore un stockage historique en clair, accordent trop largement les droits de récupération ou laissent un mot de passe exposé utilisable jusqu’à la réussite de sa rotation.

Windows Local Administrator Password Solution gère et sauvegarde le mot de passe d’un compte administrateur local. Il vise notamment à réduire les déplacements latéraux reposant sur la réutilisation d’identifiants locaux. La présentation de Windows LAPS par Microsoft décrit la sauvegarde dans Active Directory et la nouvelle implémentation native. Un objet de stratégie, une fonctionnalité installée ou un attribut renseigné constitue un élément à examiner ; chacun répond à une question différente de celle de la protection de tous les appareils visés.

Cet article suppose que LAPS avec sauvegarde dans AD est déjà présent. Notre guide Windows LAPS non déployé explique le cycle de vie manquant des identifiants : mots de passe administrateur local non gérés, statiques ou partagés, et mise en place de leur rotation. Notre article sur l’hygiène des objets ordinateur et le schéma LAPS traite du prérequis plus fondamental d’un schéma non étendu, ainsi que de l’hygiène des ordinateurs et contrôleurs de domaine. Ici, le schéma existe et le déploiement a commencé ; il faut trouver où ce déploiement échoue.

Fonctionnement : quatre façons dont LAPS déployé perd sa protection

1. Une couverture partielle du domaine

Un déploiement peut réussir dans une OU pilote tout en oubliant les serveurs membres, les postes nouvellement provisionnés ou les appareils déplacés vers une autre OU. Deux populations se cachent alors derrière la même affirmation rassurante : « nous utilisons LAPS ». Examinez séparément l’inventaire prévu et l’état réel des postes de travail et des serveurs membres, sans laisser une vaste population de postes masquer un parc de serveurs non géré.

La couverture se distingue également du bon fonctionnement. Un attribut d’expiration peut rester renseigné alors qu’un appareil est hors ligne ou que le traitement de la stratégie échoue. Consignez si un ordinateur présente des indices de Windows LAPS natif, de LAPS historique ou d’aucun des deux, puis vérifiez l’activité récente par rapport à la stratégie de rotation configurée. Explicitez le traitement des objets ordinateur désactivés et des contrôleurs de domaine dans le périmètre ; la gestion des mots de passe DSRM est un cas d’usage distinct propre aux DC.

2. L’attribut historique reste le chemin de récupération

Les générations utilisent des attributs différents. La référence du schéma de Microsoft établit la correspondance entre ms-Mcs-AdmPwdExpirationTime et msLAPS-PasswordExpirationTime, et entre ms-Mcs-AdmPwd et msLAPS-Password. La valeur native msLAPS-Password contient des données de mot de passe en clair au format JSON ; msLAPS-EncryptedPassword contient des données chiffrées. Le seul préfixe msLAPS- ne prouve donc pas le chiffrement.

Windows LAPS peut appliquer une ancienne stratégie grâce au mode d’émulation de Microsoft LAPS historique. L’émulation conserve le stockage AD en clair et ne fournit pas le chiffrement natif des mots de passe. La présence d’un attribut historique doit conduire à examiner la stratégie active et l’état de la migration, sans présumer que l’ancienne extension cliente s’exécute nécessairement. La stratégie Windows LAPS native est prioritaire sur la stratégie historique. L’émulation exige aussi l’absence de l’extension côté client de Microsoft LAPS historique sur l’appareil géré.

3. La récupération des mots de passe est déléguée trop largement

La rotation ne compense pas la récupération du mot de passe actuel par un principal non autorisé. Vérifiez à la fois le droit de récupérer les données stockées et, lorsque le chiffrement est utilisé, le principal autorisé à déchiffrer. Ce sont deux contrôles distincts. Un groupe de support chargé officiellement de la récupération mérite un examen de ses membres ; son nom contenant « LAPS » ne suffit pas à le rendre sûr.

Une délégation large sur une OU peut affecter de nombreux ordinateurs. Les autorisations explicites sur un ordinateur peuvent aussi différer de la référence définie pour l’OU. Examinez ensemble les droits hérités, les exceptions, les membres des groupes et la population autorisée à récupérer les mots de passe. Un droit accordé à un groupe ne correspond pas au nombre de personnes pouvant l’exercer.

4. L’exposition du mot de passe survit à la revue des accès

Une modification d’ACL restreint les futures lectures dans l’annuaire. Elle ne peut pas retirer un mot de passe déjà copié dans un ticket, une transcription, une sortie de script ou la session d’une autre personne. Ce sont des possibilités à examiner lors d’une investigation, et non des preuves qu’une fuite s’est produite dans un environnement donné.

Chaîne d’attaque : des droits de récupération à l’accès local

Une séquence de défaillance plausible commence par la compromission d’une identité disposant de droits de récupération indus. Si ce principal peut obtenir un mot de passe administrateur local utilisable, l’attaquant acquiert un identifiant pour l’ordinateur concerné. La portée de cet accès dépend de l’état du compte, de l’accès réseau et des contrôles d’authentification locaux ; un attribut lisible n’entraîne pas automatiquement la prise de contrôle du domaine.

Un appareil non couvert offre une autre voie : son mot de passe local reste en dehors du cycle de vie LAPS prévu. Un appareil utilisant uniquement la génération historique peut effectuer correctement la rotation tout en exposant des données de récupération en clair à une population de lecteurs trop large. Ces situations peuvent coexister, mais exigent des corrections différentes. Étendre le périmètre d’une stratégie ne supprime pas les lecteurs excessifs, et activer le chiffrement ne fait pas entrer dans le périmètre un appareil exclu.

Pour le triage d’un incident, identifiez l’ordinateur, la génération du mot de passe stocké, la population autorisée à le récupérer et la réussite de la rotation après confinement. Évitez d’exporter de vrais mots de passe uniquement pour démontrer la faiblesse. Les métadonnées, les éléments d’ACL et les journaux des terminaux permettent généralement une première évaluation plus sûre.

Mesurer la couverture et les autorisations de lecture

Rechercher les ordinateurs présentant un indice d’expiration native

Le guide de migration de Microsoft cite un attribut msLAPS-PasswordExpirationTime nouveau ou mis à jour comme moyen de suivre la transition vers Windows LAPS natif. La commande ci-dessous adapte à l’audit les paramètres de filtre LDAP et de propriétés de Get-ADComputer documentés, avec l’attribut documenté. Remplacez l’OU d’exemple par votre périmètre d’audit approuvé. Cette commande est destinée au lecteur ; elle n’a pas été exécutée sur un domaine de production pour cet article.

Get-ADComputer -SearchBase 'OU=Workstations,DC=corp,DC=example' -LDAPFilter '(msLAPS-PasswordExpirationTime=*)' -Properties 'msLAPS-PasswordExpirationTime',OperatingSystem,Enabled

Le résultat est une liste d’ordinateurs présentant un indice d’expiration native, et non un pourcentage ni la preuve du bon fonctionnement de chacun. Comparez-la à l’inventaire attendu des appareils pour identifier les ordinateurs manquants. Une valeur d’expiration historique sur un ordinateur manquant peut révéler un ancien déploiement. Vérifiez l’état désactivé, l’annuaire de sauvegarde prévu et la configuration réelle du terminal avant de conclure à une lacune de couverture. Un appareil sauvegardant dans Entra ne doit pas être jugé sur l’absence d’un attribut de sauvegarde AD.

Pour calculer une couverture défendable, rapprochez le même inventaire de postes et serveurs membres activés et inclus dans le périmètre des indices de déploiement natif ou historique. Précisez quelles générations sont considérées comme couvertes. Séparez la vue de migration vers le natif de celle du déploiement toutes générations confondues. Examinez ensuite la fraîcheur de l’expiration et la réussite de la rotation ; la seule présence d’un attribut ne permet d’établir ni l’une ni l’autre.

Énumérer les principaux de récupération

La référence de Find-LapsADExtendedRights documente la requête sur une OU et l’option -IncludeComputers. Cet exemple substitue une OU d’audit et inclut les autorisations au niveau ordinateur :

Find-LapsADExtendedRights -Identity 'OU=Workstations,DC=corp,DC=example' -IncludeComputers

Comparez les principaux retournés à une liste de récupération approuvée et examinez les appartenances pertinentes ainsi que les autorisations héritées ou explicites. Traitez ce résultat comme une énumération des autorisations, et non comme la preuve d’une lecture de mot de passe effectuée ou une reconstitution exhaustive de l’accès effectif. Conservez les identifiants des objets et des bénéficiaires des droits dans les preuves d’audit, sans stocker les valeurs des mots de passe.

Pour un contrôle de récupération autorisé sur un ordinateur, la référence de Get-LapsADPassword de Microsoft documente le modèle suivant, avec un nom d’ordinateur d’exemple substitué. Il récupère des données d’identification ; ce n’est pas une requête limitée aux métadonnées, et il n’a pas été exécuté sur un domaine de production pour cet article.

Get-LapsADPassword -Identity 'WS-001'

Sans -AsPlainText, les mots de passe retournés sont encapsulés dans SecureString. Examinez Source, DecryptionStatus et AuthorizedDecryptor pour distinguer les résultats du stockage et du déchiffrement. La cmdlet récupère également les mots de passe historiques ms-Mcs-AdmPwd, mais ces résultats ne contiennent pas Account ni PasswordUpdateTime ; une date de mise à jour vide dans ce cas ne prouve pas un échec de rotation.

Détection : lire le journal opérationnel LAPS du client

Microsoft documente ces signaux dans la référence du journal des événements Windows LAPS :

Collectez ces événements dans Microsoft-Windows-LAPS/Operational sur les clients gérés. Le canal correspondant sur un contrôleur de domaine concerne sa propre gestion DSRM, et non l’activité des clients joints au domaine. Un cycle de traitement réussi n’inclut pas nécessairement une rotation si aucune mise à jour de mot de passe n’était due.

Corrélez les événements par appareil et par cycle de traitement. Utilisez la stratégie configurée pour déterminer quand une mise à jour aurait dû se produire. Ces événements opérationnels établissent les résultats du traitement et des mises à jour ; ils n’établissent pas qui a récupéré le mot de passe stocké. L’absence d’événements exige aussi de vérifier le bon fonctionnement de la collecte avant de conclure à une absence d’activité LAPS.

Remédiation : corriger chaque défaillance séparément (Remediation)

1. Réparer le périmètre de la stratégie et les autorisations d’écriture

Attribuez un responsable à chaque ordinateur non couvert. Vérifiez son annuaire de sauvegarde prévu et le ciblage de la stratégie, puis corrigez la cause réelle : emplacement dans une OU, filtrage, priorité des stratégies ou délégation d’écriture. La procédure de déploiement AD de Microsoft documente la commande suivante, avec une OU d’exemple substituée :

Set-LapsADComputerSelfPermission -Identity 'OU=Workstations,DC=corp,DC=example'

Elle accorde des autorisations d’auto-mise à jour des attributs Windows LAPS natifs ; elle ne configure pas de stratégie et ne prouve pas la réussite d’une sauvegarde. Pour les déploiements historiques ou en émulation, utilisez les outils d’ACL historiques décrits dans le guide d’émulation de Microsoft, sans supposer que cette cmdlet native corrige les autorisations historiques. Revérifiez la liste des candidats et les preuves de mise à jour des terminaux après correction.

2. Restreindre la récupération et le déchiffrement

Supprimez les droits indus à leur source réelle, y compris les autorisations héritées, puis déléguez la récupération à la population approuvée. Ajouter un droit restreint ne révoque pas un droit large existant. Répétez la requête sur les droits après la revue des ACL et testez la récupération autorisée sans placer d’identifiants dans les sorties générales de l’audit.

Pour le chiffrement AD natif, la référence des paramètres de stratégie de Microsoft exige un niveau fonctionnel de domaine 2016 ou ultérieur. Examinez ADPasswordEncryptionEnabled et ADPasswordEncryptionPrincipal ; ce dernier identifie le principal autorisé à déchiffrer et doit pouvoir être résolu sur l’appareil. N’assimilez pas les droits de récupération dans l’annuaire à l’autorisation de déchiffrement.

3. Achever la migration depuis la génération historique

Suivez la procédure de migration de Microsoft pour une transition immédiate ou une coexistence temporaire. Pendant la coexistence, les deux implémentations doivent gérer des comptes locaux différents. Vérifiez la stratégie native, les attributs natifs mis à jour et la réussite de l’activité sur les terminaux avant de supprimer le logiciel historique. Examinez également l’accès aux données résiduelles de mots de passe historiques ; un déploiement natif réussi ne prouve pas que tous les anciens chemins de récupération ont été nettoyés.

4. Effectuer la rotation après une exposition crédible

Après avoir contenu l’accès non autorisé, coordonnez la rotation sur le terminal concerné. Microsoft documente Reset-LapsPassword pour les situations exceptionnelles nécessitant un changement immédiat, notamment une compromission de la sécurité d’une machine :

Reset-LapsPassword

Exécutez la commande localement sur l’appareil géré concerné avec les privilèges requis. La cmdlet ne retourne pas d’informations détaillées sur le résultat ; vérifiez les événements produits. Une demande de réinitialisation soumise ne suffit pas à prouver que l’identifiant exposé a cessé de fonctionner. Examinez les identités et terminaux touchés par l’incident en parallèle de la rotation, sans le clôturer uniquement parce que l’ACL de lecture a changé.

Comment EtcSec détecte ces problèmes

Le catalogue accepte ces quatre identifiants. Les descriptions suivantes reflètent les implémentations de Detect() examinées pour cet article, sans prétendre qu’un audit a été exécuté sur votre domaine :

• LAPS_DOMAIN_COVERAGE_LOW évalue la couverture des ordinateurs activés qui ne sont pas des DC, en comptabilisant la présence de LAPS historique ou natif. Il sépare les chiffres des postes et des serveurs et rapporte une métrique au niveau du domaine. Dans le Detect() examiné, une couverture inférieure à 95% produit un constat : sévérité élevée (High) sous 80%, sinon moyenne (Medium) sous 95%. Ce sont les seuils de contrôle d’EtcSec, et non des recommandations de Microsoft. Source : etc-collector public/internal/audit/detectors/ad/advanced/laps/laps-domain-coverage.go, lignes 78–86, commit f51fad0b69c0c7fbda2fcc3c43bd6f6b4da4bee4, examiné le 3 octobre 2026. Le contrôle mesure les indices de déploiement, et non la fraîcheur de la rotation ou la qualité du chiffrement.
• LAPS_LEGACY_ATTRIBUTE identifie les ordinateurs présentant des indices de LAPS historique et aucun indice de Windows LAPS natif. Il n’identifie pas l’implémentation cliente en cours d’exécution et ne démontre pas une lecture non autorisée.
• LAPS_PASSWORD_READABLE examine les ACE d’octroi avec CONTROL_ACCESS ciblant le GUID de schéma ms-Mcs-AdmPwd résolu dans la forêt réelle. Il exclut les bénéficiaires reconnus comme administrateurs intégrés et le SID propre à l’ordinateur. Son périmètre est ce signal d’autorisation historique, et non une évaluation générale des droits de déchiffrement des mots de passe natifs chiffrés.
• LAPS_PASSWORD_LEAKED utilise le même signal d’ACE d’octroi historique CONTROL_ACCESS et signale plus d’un bénéficiaire de lecture distinct sur un ordinateur, après les mêmes exclusions des administrateurs intégrés et du SID propre. Ici, « non-admin » signifie non reconnu par ce filtre ; le détecteur n’établit pas le rôle administratif effectif de chaque bénéficiaire. Il signale une exposition potentielle liée à des autorisations excessives, et non une exfiltration observée, et ne développe pas les groupes en nombre de personnes. Validez séparément l’accès effectif : ce prédicat compte les droits correspondants sans résoudre les ACE de refus face à eux.

Utilisez les constats d’etc-collector pour prioriser les investigations, puis validez séparément la couverture, les droits effectifs, la génération de stratégie et la rotation sur les terminaux. Un constat de déploiement peut être résolu alors qu’un problème d’autorisations persiste. Ne clôturez la revue que lorsque l’inventaire prévu et le chemin de récupération approuvé correspondent tous deux aux preuves.