ms-DS-MachineAccountQuota à 0 et délégation des jonctions

Par défaut, chaque utilisateur authentifié d'un domaine Active Directory peut créer jusqu'à dix comptes d'ordinateurs. La limite est stockée dans l'attribut ms-DS-MachineAccountQuota de la tête du domaine, et l'autorisation provient du droit utilisateur « Add workstations to domain » (ajouter des stations de travail au domaine), que la Default Domain Controllers Policy accorde à Authenticated Users. C'était une commodité à l'époque où les utilisateurs joignaient eux-mêmes leur PC. Aujourd'hui, cela offre surtout aux attaquants un principal du domaine gratuit, avec un mot de passe connu et un SPN contrôlable — exactement ce dont ont besoin les abus de RBCD, les chaînes de relais vers LDAP et plusieurs attaques sur les modèles AD CS.

C'est l'une des mesures de durcissement les plus simples d'AD : un attribut et un droit utilisateur. Le travail consiste à trouver qui dépend silencieusement de la valeur par défaut et à lui accorder à la place une délégation propre et délimitée.

Pourquoi un compte d'ordinateur gratuit compte

Un compte utilisateur seul constitue un point d'appui faible pour plusieurs attaques AD. Beaucoup nécessitent un principal doté d'un Service Principal Name, d'un mot de passe connu de l'attaquant et du droit de demander des tickets Kerberos en tant que service. Les comptes d'ordinateurs réunissent ces trois conditions, et le quota permet à tout utilisateur authentifié d'en créer un depuis n'importe quelle machine, jointe au domaine ou non, disposant d'un accès réseau à un DC, avec de simples appels LDAP ou SAMR standard. Les boîtes à outils offensives comme Impacket et Powermad proposent une commande d'une ligne pour cela.

Ce que ce compte permet dépend du reste de votre configuration, ce qui explique que le quota apparaisse dans tant de chaînes d'attaque :

• La délégation contrainte basée sur les ressources. Si l'attaquant peut écrire msDS-AllowedToActOnBehalfOfOtherIdentity sur une cible, directement ou via un relais NTLM vers LDAP, il la fait pointer vers son nouveau compte d'ordinateur et usurpe l'identité d'utilisateurs auprès de la cible.
• Les modèles AD CS ouverts à l'inscription par Domain Computers. Le nouveau compte est automatiquement membre de Domain Computers ; il peut donc s'inscrire au modèle Machine par défaut et à tout modèle personnalisé doté des mêmes autorisations. Combiné à d'autres erreurs de configuration de modèles, cela devient un chemin vers l'authentification sous une autre identité.
• Les bogues d'implémentation de Kerberos. Les failles d'usurpation de sAMAccountName de 2021 (CVE-2021-42278 et CVE-2021-42287) nécessitaient un compte d'ordinateur que l'attaquant pouvait renommer. Les correctifs ont réglé ces bogues précis, mais le prochain aura probablement le même prérequis.
• La persistance. Un compte d'ordinateur créé pendant une intrusion est rarement remarqué, expire rarement et conserve un mot de passe valide aussi longtemps que l'attaquant le souhaite.

Aucune de ces attaques n'a besoin du quota si l'attaquant dispose déjà de droits de création au niveau d'une UO ; c'est pourquoi l'audit ci-dessous examine aussi qui les détient.

Mesurer : le quota actuel et qui l'a utilisé

Lisez la valeur actuelle et vérifiez qui détient le droit utilisateur sur les contrôleurs de domaine.

Import-Module ActiveDirectory

$domainDN = (Get-ADDomain).DistinguishedName
Get-ADObject -Identity $domainDN -Properties 'ms-DS-MachineAccountQuota' |
    Select-Object DistinguishedName, 'ms-DS-MachineAccountQuota'

Pour le droit utilisateur, ouvrez la GPO liée à l'UO Domain Controllers (normalement la Default Domain Controllers Policy) et examinez :

Computer Configuration > Policies > Windows Settings > Security Settings >
  Local Policies > User Rights Assignment > Add workstations to domain

La valeur par défaut est Authenticated Users. Sur un DC, vous pouvez confirmer le paramètre effectif avec gpresult /h ou en exportant la stratégie de sécurité locale avec secedit /export /cfg, où le droit apparaît sous le nom SeMachineAccountPrivilege.

Trouvez ensuite les objets ordinateurs créés via le quota. Lorsqu'un utilisateur non privilégié crée un compte d'ordinateur à l'aide de SeMachineAccountPrivilege, le DC inscrit le SID du créateur dans mS-DS-CreatorSID. Les comptes créés par des administrateurs ou via une délégation sur une UO ne le portent pas.

Get-ADComputer -LDAPFilter '(mS-DS-CreatorSID=*)' `
    -Properties mS-DS-CreatorSID, whenCreated, operatingSystem, lastLogonTimestamp, enabled |
    ForEach-Object {
        $sid = $_.'mS-DS-CreatorSID'
        $creator = try { (New-Object Security.Principal.SecurityIdentifier($sid, 0)).Translate(
                        [Security.Principal.NTAccount]).Value } catch { "$sid (unresolved)" }
        [PSCustomObject]@{
            Computer   = $_.Name
            Creator    = $creator
            Created    = $_.whenCreated
            OS         = $_.operatingSystem
            Enabled    = $_.Enabled
            LastLogon  = if ($_.lastLogonTimestamp) { [datetime]::FromFileTime($_.lastLogonTimestamp) }
            DN         = $_.DistinguishedName
        }
    } | Sort-Object Created -Descending | Export-Csv .\quota-created-computers.csv -NoTypeInformation

Soyez attentif aux ordinateurs sans valeur de système d'exploitation et sans ouverture de session : ce schéma signale souvent un compte créé par un script ou un outil, et non par une véritable jonction. Les entrées récentes créées par des utilisateurs standard relèvent soit d'un processus du support que personne n'a documenté, soit d'un élément à transmettre à la réponse à incident.

Auditer : qui joint légitimement des machines

Examinez l'événement 4741 (un compte d'ordinateur a été créé) sur les DC pendant quelques semaines. Les champs Subject indiquent quel compte a créé chaque objet ordinateur. Regroupez par créateur pour voir quelles personnes et quels comptes de service joignent des machines, et à quelle fréquence.

Get-WinEvent -FilterHashtable @{ LogName = 'Security'; Id = 4741 } -MaxEvents 5000 |
    ForEach-Object {
        $x = [xml]$_.ToXml()
        $d = @{}; $x.Event.EventData.Data | ForEach-Object { $d[$_.Name] = $_.'#text' }
        [PSCustomObject]@{ Creator = "$($d.SubjectDomainName)\$($d.SubjectUserName)"; Computer = $d.TargetUserName }
    } | Group-Object Creator | Sort-Object Count -Descending | Select-Object Count, Name

Exécutez cette requête sur chaque DC ou, mieux, sur votre collecteur central (voir audit et détection AD). Les créateurs légitimes typiques sont : le compte de service de déploiement utilisé par les séquences de tâches SCCM/MDT, l'Intune Connector for Active Directory utilisé pour les jonctions Autopilot hybrides, quelques administrateurs de serveurs et des techniciens du support. Tout ce qui sort de ces groupes rejoint la liste des personnes à rencontrer.

Imposer : quota à 0 et délégation propre

Créer d'abord les droits de jonction délégués

Créez un groupe, par exemple GG-Workstation-Join, et accordez-lui des droits de jonction sur l'UO cible uniquement. L'ensemble minimal sur l'UO est :

• Create Computer objects et Delete Computer objects sur l'UO (cet objet et ses descendants).
• Sur les objets ordinateurs descendants : Reset password, Read and write Account Restrictions, Validated write to DNS host name et Validated write to service principal name.

Vous pouvez l'accorder avec l'Assistant Délégation de contrôle (tâche personnalisée, « Only the following objects in the folder: Computer objects »), ou par script avec le fournisseur ActiveDirectory :

$ou      = 'OU=Workstations,DC=corp,DC=example,DC=com'
$group   = Get-ADGroup 'GG-Workstation-Join'
$sid     = [Security.Principal.SecurityIdentifier]$group.SID
$computer = [guid]'bf967a86-0de6-11d0-a285-00aa003049e2'   # classe computer
$resetPw  = [guid]'00299570-246d-11d0-a768-00aa006e0529'   # Reset Password
$acctRes  = [guid]'4c164200-20c0-11d0-a768-00aa006e0529'   # Account Restrictions
$dnsHost  = [guid]'72e39547-7b18-11d1-adef-00c04fd8d5cd'   # Validated write to DNS host name
$spn      = [guid]'f3a64788-5306-11d1-a9c5-0000f8036d4d'   # Validated write to SPN

$R = [System.DirectoryServices.ActiveDirectoryRights]
$A = [System.Security.AccessControl.AccessControlType]::Allow
$I = [System.DirectoryServices.ActiveDirectorySecurityInheritance]

$acl = Get-Acl "AD:\$ou"
$acl.AddAccessRule((New-Object DirectoryServices.ActiveDirectoryAccessRule($sid, ($R::CreateChild -bor $R::DeleteChild), $A, $computer, $I::All)))
$acl.AddAccessRule((New-Object DirectoryServices.ActiveDirectoryAccessRule($sid, $R::ExtendedRight, $A, $resetPw, $I::Descendents, $computer)))
$acl.AddAccessRule((New-Object DirectoryServices.ActiveDirectoryAccessRule($sid, ($R::ReadProperty -bor $R::WriteProperty), $A, $acctRes, $I::Descendents, $computer)))
$acl.AddAccessRule((New-Object DirectoryServices.ActiveDirectoryAccessRule($sid, $R::Self, $A, $dnsHost, $I::Descendents, $computer)))
$acl.AddAccessRule((New-Object DirectoryServices.ActiveDirectoryAccessRule($sid, $R::Self, $A, $spn, $I::Descendents, $computer)))
Set-Acl -Path "AD:\$ou" -AclObject $acl

Limitez cette délégation aux UO de préparation des postes de travail et des serveurs, jamais à l'UO Domain Controllers ni à une UO contenant des actifs Tier 0. Placez-y les comptes de service de déploiement, le compte du connecteur Intune et le groupe de jonction du support, et donnez à chacun son propre groupe s'ils ciblent des UO différentes.

Pour les machines qui doivent être jointes par une personne précise sans droits plus larges, pré-créez l'objet ordinateur et utilisez « The following user or group can join this computer to a domain » dans Utilisateurs et ordinateurs Active Directory, ou recourez à la jonction hors ligne avec djoin.exe /provision exécuté par un administrateur.

Régler le quota sur 0

Set-ADDomain -Identity (Get-ADDomain) -Replace @{ 'ms-DS-MachineAccountQuota' = 0 }

La modification de l'attribut nécessite un accès en écriture à la tête du domaine, normalement réservé aux Domain Admins. Elle prend effet dès sa réplication ; aucun redémarrage n'est nécessaire.

Retirer Authenticated Users du droit utilisateur

Avec un quota à 0, le droit utilisateur est inoffensif pour les utilisateurs standard, mais le retirer relève de la défense en profondeur et rend l'intention explicite. Dans la GPO des Domain Controllers, réservez Add workstations to domain à votre groupe de jonction, ou laissez-le vide si toutes les jonctions passent par la délégation sur les UO (les autorisations sur les UO ne dépendent pas de ce droit).

Nettoyer ce que le quota a créé

Traitez le fichier CSV issu de l'étape de mesure. Pour chaque appareil légitime, déplacez-le dans la bonne UO, confirmez que le propriétaire est Domain Admins ou votre groupe de provisionnement, et supprimez les ACE explicites accordées au créateur d'origine : l'utilisateur qui a créé l'objet conserve des droits d'écriture sur celui-ci (y compris sur le jeu de propriétés Account Restrictions) longtemps après que l'appareil a changé de mains. Désactivez les comptes sans appareil correspondant, attendez un cycle, puis supprimez-les.

Tenez compte du durcissement de la jonction au domaine introduit par les mises à jour d'octobre 2022 (KB5020276) : la réutilisation d'un compte d'ordinateur existant lors d'une jonction est désormais bloquée, sauf si le compte qui effectue la jonction l'a créé, est un compte privilégié ou est autorisé par la stratégie « Domain controller: Allow computer account re-use during domain join ». Corriger la propriété lors du nettoyage évite les mauvaises surprises lors de la réinstallation des appareils.

Vérifier

# Le quota vaut 0
(Get-ADObject (Get-ADDomain).DistinguishedName -Properties 'ms-DS-MachineAccountQuota').'ms-DS-MachineAccountQuota'

# Aucun nouvel ordinateur créé via le quota depuis le changement
$changeDate = Get-Date '2026-01-15'   # date à laquelle le quota a été réglé sur 0
Get-ADComputer -LDAPFilter '(mS-DS-CreatorSID=*)' -Properties whenCreated |
    Where-Object { $_.whenCreated -gt $changeDate } |
    Select-Object Name, whenCreated

Testez une jonction avec un compte utilisateur standard : elle doit échouer avec une erreur indiquant que l'utilisateur a dépassé le nombre maximal de comptes d'ordinateurs. Testez une jonction dans l'UO de préparation avec un membre du groupe délégué : elle doit réussir. Continuez à déclencher des alertes sur les 4741 dont le créateur n'est pas un compte de provisionnement connu. La plupart des outils d'évaluation signalent un quota non nul ; votre prochaine évaluation PingCastle devrait donc lever cette règle.

Ce que cela casse

• Les utilisateurs qui joignent eux-mêmes leurs machines avec leur compte de domaine habituel, y compris les développeurs qui construisent des VM de laboratoire jointes à l'AD de production. Ils ont désormais besoin du groupe délégué ou d'un objet pré-créé.
• Les processus de déploiement qui utilisaient un simple compte utilisateur sans délégation sur l'UO, souvent un ancien identifiant MDT JoinDomain dans CustomSettings.ini ou un compte de jonction réseau de séquence de tâches. Ils échouent à l'étape de jonction jusqu'à ce que le compte soit ajouté au groupe délégué.
• Les outils tiers qui créent des objets ordinateurs pour des hôtes Linux (realmd/SSSD, Samba), des NAS ou des brokers VDI lorsqu'ils sont configurés avec un compte standard. Donnez à chacun un compte de service dédié, délégué sur sa propre UO.
• Autopilot hybride si le compte d'ordinateur ou le compte de service du connecteur Intune n'a pas été délégué sur l'UO cible ; la documentation l'exige déjà, mais les tenants où « ça marchait tout seul » s'appuyaient souvent sur le quota.
• La réinstallation avec réutilisation des noms existants peut se heurter au durcissement de la jonction de 2022 si la propriété n'a pas été normalisée.

Pour aller plus loin : la thématique Délégation et le guide de référence sur la délégation dans Active Directory, l'entrée du glossaire machine account quota, et l'audit des modèles AD CS, où les modèles machine ouverts à l'inscription par Domain Computers transforment tout ordinateur créé par un attaquant en certificat.