Quota de comptes machine Active Directory (ms-DS-MachineAccountQuota) : le paramètre par défaut qui permet à tout utilisateur d'ajouter un ordinateur

Quota de comptes machine Active Directory (ms-DS-MachineAccountQuota) : les bases

Le quota de comptes machine Active Directory — l'attribut ms-DS-MachineAccountQuota, stocké sur l'objet domaine lui-même — vaut 10 par défaut sur chaque domaine. Cela signifie que tout utilisateur de domaine authentifié, sans le moindre droit d'administration délégué, peut joindre jusqu'à dix nouveaux comptes ordinateur au domaine dès l'installation. Ceci est vrai depuis l'introduction de cet attribut avec Windows 2000 Server, et c'est encore la valeur par défaut sur les domaines créés aujourd'hui, sauf si un administrateur l'a explicitement durcie.

Un ingénieur Microsoft a documenté ce défaut sans détour sur le blog TechNet de l'entreprise dès 2005 : « La plupart d'entre vous connaissent la limite de 10 fois où des utilisateurs authentifiés peuvent joindre des machines à un domaine », décrivant ms-DS-MachineAccountQuota comme la propriété de l'objet domaine qui contrôle ce comportement, modifiable via ADSI Edit. La référence actuelle de Microsoft sur les stratégies de sécurité pour le droit utilisateur associé Ajouter des postes de travail au domaine (SeMachineAccountPrivilege) confirme le même chiffre côté privilège : « Un utilisateur disposant de ce droit peut ajouter jusqu'à 10 postes de travail au domaine », et sur les contrôleurs de domaine, ce droit est accordé par défaut au groupe Utilisateurs authentifiés.

Pourquoi la valeur par défaut ne raconte pas toute l'histoire

Il existe une seconde voie, indépendante du quota, à connaître avant de « corriger » ce paramètre : la documentation Microsoft elle-même précise que « les utilisateurs peuvent aussi joindre un ordinateur à un domaine s'ils disposent de la permission Create Computer Objects sur une unité d'organisation (OU) ou sur le conteneur Computers », et que les utilisateurs disposant de cette permission déléguée « peuvent ajouter un nombre illimité d'appareils au domaine, qu'ils disposent ou non du droit utilisateur Ajouter des postes de travail au domaine ». Remettre le quota à zéro ne change rien pour un compte qui détient déjà les droits délégués Create Computer objects sur une OU — les deux mécanismes doivent être revus ensemble, ce qui explique pourquoi ce paramètre revient sans cesse dans les revues des erreurs de configuration de sécurité Active Directory les plus courantes, des années après sa première documentation.

Pourquoi un compte ordinateur en libre-service constitue un point d'ancrage

Un compte ordinateur n'est pas un objet anodin. C'est un principal de sécurité à part entière, doté de son propre SID et d'un mot de passe choisi par le créateur (ou généré par un outil) — atterrissant par défaut dans le conteneur CN=Computers, dont le créateur est propriétaire plutôt que les administrateurs du domaine. Il ne porte, en soi, aucun privilège particulier. Ce qu'il fournit, en revanche, c'est une identité jointe au domaine et entièrement contrôlée par l'attaquant — le prérequis manquant pour plusieurs techniques d'abus de délégation déjà couvertes ailleurs dans ce catalogue, notamment l'abus de délégation contrainte basée sur les ressources (RBCD) et la surface d'attaque plus large des objets ordinateur.

Créer ce compte ne nécessite rien de plus qu'un utilisateur de domaine standard et un quota supérieur à zéro. Les outils publics en font une opération d'une seule ligne, toutes documentées dans des références communautaires telles que la page MachineAccountQuota de The Hacker Recipes :

# Impacket — création de compte ordinateur via SAMR
addcomputer.py -computer-name 'PWN01$' -computer-pass 'P@ssw0rd123!' \
  -dc-host dc01.corp.local corp.local/lowpriv:'Password1'

# Powermad — meme resultat via LDAP depuis un hote Windows joint au domaine
New-MachineAccount -MachineAccount PWN01 -Password (ConvertTo-SecureString 'P@ssw0rd123!' -AsPlainText -Force)

bloodyAD et Certipy account create exposent la même primitive via LDAP, pour les opérateurs qui préfèrent un outil unique multiplateforme. Aucun de ces outils ne nécessite de droits élevés — seulement le ms-DS-MachineAccountQuota par défaut de 10.

La chaîne d'attaque : d'un compte ordinateur gratuit à l'abus de délégation

Étape 1 — Confirmer que le quota est exploitable

Une requête LDAP rapide, anonyme ou authentifiée, sur l'objet domaine révèle la valeur en vigueur :

ldapsearch -x -H ldap://dc01.corp.local -D 'corp\lowpriv' -w 'Password1' \
  -b 'DC=corp,DC=local' -s base '(objectClass=domain)' ms-DS-MachineAccountQuota

Si la valeur retournée est supérieure à zéro, et que le compte exécutant la requête ne fait l'objet d'aucune autre restriction, la création de comptes ordinateur en libre-service est disponible.

Étape 2 — Créer un compte ordinateur contrôlé par l'attaquant

À l'aide de l'un des outils présentés ci-dessus, l'attaquant consomme une unité de son propre quota pour créer un compte machine. Cette seule action produit un SID machine avec un mot de passe connu — une identité qui n'existait pas un instant plus tôt et que les administrateurs du domaine n'ont ni provisionnée, ni examinée, ni approuvée.

Étape 3 — Enchaîner vers l'abus de délégation

Le compte ordinateur nouvellement créé n'est pas, en soi, privilégié — mais il devient l'identité contrôlée à travers laquelle transitent les chaînes RBCD et de relais NTLM. Dans les scénarios de relais, des techniques de coercition (par exemple, l'authentification forcée de type PetitPotam) sont utilisées pour relayer l'authentification NTLM d'une victime vers LDAP/LDAPS sur un contrôleur de domaine ; ntlmrelayx.py d'Impacket peut alors utiliser son option --delegate-access pour créer un compte ordinateur au cours de cette session relayée et, dans la foulée, configurer msDS-AllowedToActOnBehalfOfOtherIdentity sur la cible relayée, afin que le nouveau compte ordinateur puisse usurper l'identité d'utilisateurs arbitraires vis-à-vis de celle-ci via S4U2Self/S4U2Proxy — transformant une authentification relayée unique en accès RBCD permanent. Le fonctionnement complet du RBCD lui-même, ainsi que l'éventail plus large des façons dont les attributs et les ACL d'un objet ordinateur sont détournés, sont couverts dans les deux articles liés ci-dessus ; le quota de comptes machine est le paramètre qui fournit à l'attaquant l'objet ordinateur dont ces chaînes ont besoin en premier lieu.

Détection

# Valeur actuelle du quota
Get-ADObject (Get-ADDomain).DistinguishedName -Properties ms-DS-MachineAccountQuota

# Objets ordinateur crees via la voie de libre-service par quota (mS-DS-CreatorSID renseigne)
Get-ADComputer -Filter * -Properties ms-DS-CreatorSID |
    Where-Object { $_.'ms-DS-CreatorSID' } |
    Select-Object Name, DistinguishedName, ms-DS-CreatorSID

Établir une référence pour le provisioning légitime

Les outils de provisioning légitimes s'exécutent généralement sous des comptes de service dédiés, joignant les machines dans une OU connue selon un calendrier prévisible. Tout événement 4741 où SubjectUserName est un compte utilisateur final standard, ou où l'objet ordinateur résultant atterrit en dehors de cette OU, mérite d'être examiné, quel qu'en soit le volume.

Remediation

1. Désactiver le quota en le mettant à zéro à l'échelle du domaine. C'est le changement au plus fort effet de levier :

   Set-ADDomain -Identity corp.local -Replace @{'ms-DS-MachineAccountQuota'='0'}
   

   Vérifiez avec la requête Get-ADObject de la section Détection.

2. Restreindre et réattribuer le droit « Ajouter des postes de travail au domaine ». Selon les recommandations de sécurité propres à Microsoft, retirez-le du groupe Utilisateurs authentifiés dans la stratégie de domaine par défaut des contrôleurs de domaine, et n'accordez SeMachineAccountPrivilege qu'à un groupe de provisioning dédié. Le quota seul ne referme pas cette porte — le droit utilisateur est le second verrou, et les recommandations Microsoft elles-mêmes signalent le fait de le laisser sur Utilisateurs authentifiés comme une « vulnérabilité modérée ».

3. Limiter et déléguer Create Computer objects de façon restreinte. Accordez cette permission uniquement sur une OU dédiée aux ordinateurs, uniquement au compte ou au groupe qui provisionne réellement les machines (compte de service d'imagerie, SCCM, Intune Hybrid Join) — jamais à Utilisateurs authentifiés ou Utilisateurs du domaine. Cette permission déléguée contourne entièrement le quota : le périmètre compte plus que le chiffre.

4. Surveiller et générer une alerte sur l'ID d'événement 4741 combiné à un mS-DS-CreatorSID renseigné, en particulier pour les objets ordinateur atterrissant en dehors de votre OU de provisioning attendue.

5. Auditer et revérifier après chaque migration ou nouveau déploiement de domaine. ms-DS-MachineAccountQuota est défini par objet domaine ; un domaine nouvellement promu ou migré réintroduit la valeur par défaut de 10, sauf si elle est explicitement durcie à nouveau.

Vérifier la correction

Après avoir mis le quota à zéro et réattribué le droit utilisateur, confirmez que le changement tient réellement en tentant une jointure au domaine depuis un compte de test standard, non délégué — elle doit échouer avec une erreur d'accès refusé. Relancez la requête Get-ADObject de la section Détection pour confirmer la valeur stockée, car le délai de propagation des GPO peut sinon donner l'impression qu'un changement est appliqué avant qu'il n'ait atteint chaque contrôleur de domaine.

🚨 Danger : les administrateurs du domaine, ainsi que tout compte disposant séparément de la délégation Create Computer objects, ne sont jamais limités par le quota. Mettre le quota à 0 est nécessaire, mais pas suffisant — associez ce changement aux modifications de droit utilisateur et de délégation ci-dessus.

Ce paramètre est exactement le type de vérification à attribut unique qui a sa place dans un audit de sécurité Active Directory récurrent plutôt que dans une correction ponctuelle, puisqu'il revient silencieusement à sa valeur par défaut sur tout domaine nouvellement créé ou migré.

Comment EtcSec détecte cela

L'audit Active Directory d'EtcSec signale un ms-DS-MachineAccountQuota laissé au-dessus de zéro comme Quota de comptes machine élevé au-dessus de la valeur par défaut, et suit séparément les conditions d'exploitation comme Abus du quota de comptes machine, en corrélant la valeur de quota en vigueur avec les résultats de délégation et d'objets ordinateur tels que RBCD sur objet ordinateur et Abus de RBCD, afin que la chaîne allant de « n'importe quel utilisateur peut ajouter un ordinateur » à « n'importe quel utilisateur peut usurper un principal privilégié sur un hôte cible » soit mise en évidence comme un seul chemin d'attaque plutôt que comme quatre résultats distincts.