Hygiène des Objets Ordinateur Contrôleur de Domaine Active Directory Schéma LAPS : Six Lacunes Qu'un Audit Réel Retrouve Toujours

Hygiène des Objets Ordinateur Contrôleur de Domaine Active Directory Schéma LAPS : Ce Que Couvre Cet Audit

Hygiène des objets ordinateur contrôleur de domaine Active Directory schéma LAPS : ce sont les vérifications qu'un audit réel fait remonter en premier, et aucune n'est individuellement spectaculaire : un schéma AD jamais étendu pour LAPS, des contrôleurs de domaine situés hors de leur OU, et des objets ordinateur que personne n'a regardés depuis des années. Ensemble, ils se situent sous les chemins d'attaque les plus médiatisés — Kerberoasting, DCSync, escalade ADCS — et déterminent en silence si ces attaques sont même nécessaires. Un domaine où chaque objet ordinateur est à jour, où chaque contrôleur de domaine est correctement placé, et où les mots de passe administrateur locaux sont gérés de façon centralisée est un domaine où un attaquant doit travailler pour obtenir un point d'appui. Un domaine où rien de tout cela n'est vrai distribue des raccourcis.

Cet article couvre six lacunes qu'un audit réel mené contre un environnement AD réel fait systématiquement remonter ensemble, et dont aucune n'apparaît dans une liste type « top 10 des mauvaises configurations » car aucune n'est une vulnérabilité isolée et spectaculaire :

1. L'extension de schéma Active Directory pour LAPS n'a jamais été appliquée — pas « LAPS est déployé mais pas partout », les attributs de schéma eux-mêmes n'existent pas.
2. Des contrôleurs de domaine dont l'objet ordinateur se trouve hors de l'OU Domain Controllers.
3. Des objets contrôleur de domaine qui ont cessé de répliquer et n'ont jamais été nettoyés.
4. Des objets ordinateur obsolètes, inactifs, sans propriétaire pour les surveiller.
5. Des ordinateurs sans BitLocker, y compris des contrôleurs de domaine hébergeant NTDS.dit.
6. Des comptes ordinateur dont le mot de passe machine a cessé de tourner.

Chacune de ces lacunes est, individuellement, peu spectaculaire. Ensemble, elles décrivent un environnement où le cycle de vie des objets n'est le travail de personne — et c'est exactement la condition sur laquelle comptent les attaquants lorsque les contrôles les plus visibles sont déjà verrouillés.

Pourquoi un Schéma LAPS Non Étendu Est la Lacune la Plus Profonde

Local Administrator Password Solution existe en deux générations, et la distinction compte ici. Le LAPS Microsoft historique stockait le mot de passe géré dans l'attribut ms-Mcs-AdmPwd, ajouté au schéma en exécutant Update-AdmPwdADSchema en tant que membre de Schema Admins — voir la référence d'attribut officielle de Microsoft dans MS-ADA2. Depuis la mise à jour cumulative d'avril 2023, Windows LAPS est livré comme composant natif de l'OS et utilise un jeu d'attributs distinct et chiffré (msLAPS-Password, msLAPS-EncryptedPassword, msLAPS-PasswordExpirationTime) — voir la référence technique Windows LAPS. Chaque génération nécessite sa propre extension de schéma, effectuée une seule fois (Update-LapsADSchema pour les nouveaux attributs), à l'échelle du domaine, par un membre de Schema Admins.

Cette étape est facile à sauter car l'omettre ne produit aucune erreur. Les GPO peuvent être liées, le CSE LAPS peut être déployé sur chaque poste, et rien ne se passera — il n'existe aucun attribut où écrire le mot de passe. C'est une lacune différente, et plus fondamentale, que « LAPS est configuré mais certains ordinateurs ne sont pas dans le périmètre », qui est la lacune Windows LAPS Non Déployé que nous avons couverte séparément. Ici, le schéma lui-même n'a jamais été touché, ce qui signifie que tous les mots de passe administrateur local du domaine sont non gérés — le plus souvent identiques sur toute une image de déploiement, selon l'analyse de déploiement LAPS d'ADSecurity.org. Un seul identifiant admin local basé sur une image, une fois craqué ou extrait d'un poste de faible valeur, débloque un mouvement latéral vers toutes les machines construites à partir de cette image.

DC Hors de Leur OU et Métadonnées Jamais Nettoyées

DC_NOT_IN_DC_OU paraît cosmétique jusqu'à ce qu'on vérifie ce que Microsoft associe réellement à l'OU Domain Controllers par défaut : la stratégie Default Domain Controllers Policy, qui définit les attributions de droits utilisateur spécifiques aux DC, la politique d'audit et les options de sécurité — la même chaîne d'héritage de GPO que nous détaillons dans Mauvaises Configurations GPO : Comment la Stratégie de Groupe Devient un Vecteur d'Attaque. Déplacer l'objet ordinateur d'un contrôleur de domaine vers une autre OU — même une sous-OU créée par souci de rangement organisationnel — casse cette chaîne d'héritage, et Microsoft documente cela depuis des années comme une configuration non supportée, pas une simple préférence de style ; voir l'article de Computerworld sur cette erreur et le guide de sécurité des contrôleurs de domaine de Semperis. Un DC qui a silencieusement perdu sa politique d'audit de base est un DC qui génère des journaux de sécurité incomplets — ce qui constitue exactement le type d'angle mort dont dépend une technique d'enregistrement de DC pirate comme DCShadow ; nous couvrons cet abus spécifique dans Attaque DCShadow : Enregistrement d'un Contrôleur de Domaine Pirate.

DC_INACTIVE est le problème jumeau : un objet ordinateur de DC qui a cessé de répliquer et n'a jamais été formellement décommissionné. Les recommandations de Microsoft indiquent explicitement qu'un DC retiré suite à une panne matérielle ou une rétrogradation forcée échouée laisse des métadonnées d'annuaire et DNS orphelines — objets ordinateur et NTDS Settings, connexions de réplication, enregistrements SRV/CNAME — qui doivent être supprimées délibérément via un nettoyage de métadonnées, et non laissées en place ; voir Nettoyer les métadonnées de serveur d'un contrôleur de domaine Active Directory. Laissée en l'état, cette identité de DC obsolète produit des résultats de localisation de DC incohérents et offre à un attaquant un objet plausible et rarement audité à usurper ou réutiliser. Le placement des objets et la santé de la réplication constituent le volet « hygiène » de la sécurité des DC ; le volet réseau/service — force de chiffrement LDAPS, Print Spooler exposé, dérive d'horloge au-delà de la tolérance Kerberos — est une checklist distincte que nous avons publiée dans Audit DC : TLS Faible LDAPS, Spouleur d'Impression, Synchronisation Horaire.

Ordinateurs Obsolètes, BitLocker Absent, et Mots de Passe Machine Jamais Renouvelés

COMPUTER_STALE_INACTIVE est l'équivalent, pour un objet ordinateur, d'un compte utilisateur obsolète : une machine qui ne s'est pas authentifiée depuis des mois mais reste un principal Kerberos pleinement valide, avec un SID, des appartenances à des groupes, et — si quelqu'un lui a un jour accordé des droits de délégation ou d'écriture sur quelque chose de sensible — une surface d'attaque que personne ne surveille. Ce même angle mort touche aussi les comptes utilisateur obsolètes, un problème couvert séparément dans Comptes Obsolètes et Sur-Privilégiés dans AD. Les risques distincts et plus profonds qui reposent sur un objet ordinateur une fois qu'un attaquant le contrôle (délégation sans contrainte, abus RBCD, droits permettant DCSync) sont couverts séparément dans Surface d'Attaque des Objets Ordinateur Active Directory ; cette lacune-ci concerne le simple fait que ces objets existent, sans être jamais revus.

COMPUTER_NO_BITLOCKER compte le plus sur les machines qui hébergent les données les plus sensibles au repos. Pour un contrôleur de domaine en particulier, c'est NTDS.dit — la base contenant le hash de mot de passe de chaque compte. Les recommandations officielles de Microsoft pour le durcissement des contrôleurs de domaine préconisent BitLocker adossé à un TPM sur tous les volumes des DC, précisément parce que cela protège l'annuaire même si un disque physique est retiré du serveur (voir la référence Securing Domain Controllers Against Attack). Lorsque BitLocker est activé avec un séquestre de clé basé sur AD, le mot de passe de récupération se dépose comme objet enfant msFVE-RecoveryInformation sous l'objet ordinateur — voir Storing BitLocker Recovery Keys in Active Directory — son absence est donc directement interrogeable, et non quelque chose qu'il faut croire sur parole via un tableur.

COMPUTER_PASSWORD_OLD suit un signal plus subtil. Par défaut, le paramètre « Membre du domaine : durée de vie maximale du mot de passe de compte d'ordinateur » est de 30 jours — chaque ordinateur joint au domaine est censé renouveler son propre mot de passe machine selon cette cadence, un paramètre documenté dans la référence de politique de sécurité de Microsoft et détaillé par le tutoriel d'ADSecurity.org sur le mot de passe de compte machine. Un compte machine dont le mot de passe est bien plus ancien que 30 jours et qui continue de s'authentifier activement signale généralement un canal sécurisé cassé, pas un système durci — et un mot de passe machine statique donne à un attaquant qui compromet le compte beaucoup plus de temps pour le forcer par force brute ou le rejouer avant que la rotation n'impose une réinitialisation.

Détection

# 1. Confirmer que l'extension de schéma LAPS existe (l'une ou l'autre génération)
Get-ADObject -SearchBase (Get-ADRootDSE).schemaNamingContext `
    -Filter {name -eq "ms-Mcs-AdmPwd" -or name -eq "msLAPS-Password"}

# 2. Contrôleurs de domaine dont l'objet ordinateur se trouve hors de l'OU DC par défaut
Get-ADDomainController -Filter * | ForEach-Object {
    $dn = (Get-ADComputer $_.Name).DistinguishedName
    if ($dn -notmatch "OU=Domain Controllers") { "$($_.Name) -> $dn" }
}

# 3. Objets ordinateur obsolètes — aucune authentification depuis 90+ jours
Get-ADComputer -Filter * -Properties lastLogonTimestamp |
    Where-Object { [DateTime]::FromFileTime($_.lastLogonTimestamp) -lt (Get-Date).AddDays(-90) } |
    Select-Object Name, @{N='LastLogon';E={[DateTime]::FromFileTime($_.lastLogonTimestamp)}}

# 4. Ordinateurs sans information de récupération BitLocker séquestrée dans AD
Get-ADComputer -Filter * | ForEach-Object {
    $recovery = Get-ADObject -Filter {objectClass -eq "msFVE-RecoveryInformation"} -SearchBase $_.DistinguishedName
    if (-not $recovery) { $_.Name }
}

# 5. Mot de passe de compte machine plus ancien que la politique de 30 jours
Get-ADComputer -Filter * -Properties PasswordLastSet |
    Where-Object { $_.PasswordLastSet -lt (Get-Date).AddDays(-30) } |
    Select-Object Name, PasswordLastSet

Remédiation

1. Étendre le Schéma LAPS, Une Fois, à l'Échelle du Domaine

Exécutez Update-LapsADSchema (Windows LAPS) — ou Update-AdmPwdADSchema si l'organisation reste délibérément sur LAPS historique — en tant que membre de Schema Admins, puis déléguez le droit d'écriture SELF sur les nouveaux attributs avec Set-LapsADComputerSelfPermission avant de déployer la GPO.

2. Replacer les Objets DC Mal Positionnés dans Domain Controllers

Utilisez Move-ADObject ou ADUC pour déplacer l'objet ordinateur, puis confirmez que la Default Domain Controllers Policy se réapplique avec gpresult /r sur le DC concerné.

3. Résoudre ou Retirer Délibérément les DC Inactifs

Si repadmin /showrepl montre un véritable échec de réplication, corrigez-le. Si le DC a réellement disparu, effectuez un nettoyage de métadonnées en bonne et due forme plutôt que de laisser en place l'objet orphelin et les enregistrements DNS associés.

4. Désactiver, Puis Supprimer, les Ordinateurs Obsolètes Selon un Calendrier Fixe

Par exemple, désactiver après 90 jours d'inactivité et supprimer après 180 jours — la même discipline déjà appliquée aux comptes utilisateur obsolètes.

5. Activer BitLocker Avec TPM et Séquestre de Clé AD

Priorisez d'abord les contrôleurs de domaine, via le paramètre de GPO « Stocker les informations de récupération BitLocker dans Active Directory Domain Services », afin que msFVE-RecoveryInformation se peuple et devienne auditable.

6. Laisser la Politique de 30 Jours pour le Mot de Passe Machine Telle Quelle

Enquêtez, plutôt que d'ignorer, toute machine active dont le PasswordLastSet a dérivé bien au-delà de cette limite — le plus souvent, Test-ComputerSecureChannel -Repair corrige un canal sécurisé cassé qui bloque silencieusement la rotation.

Comment EtcSec Détecte Cela

L'audit Active Directory d'EtcSec vérifie directement ces six conditions sur le domaine : COMPUTER_NO_LAPS pour une extension de schéma manquante, DC_NOT_IN_DC_OU et DC_INACTIVE pour le placement et la santé de réplication des contrôleurs de domaine, COMPUTER_STALE_INACTIVE pour les machines dormantes jamais revues, COMPUTER_NO_BITLOCKER pour le chiffrement disque non séquestré, et COMPUTER_PASSWORD_OLD pour la rotation de mot de passe machine à l'arrêt.