ms-DS-MachineAccountQuota a 0 y delegación de uniones

De forma predeterminada, todo usuario autenticado de un dominio de Active Directory puede crear hasta diez cuentas de equipo. El límite se almacena en el atributo ms-DS-MachineAccountQuota de la raíz del dominio, y el permiso procede del derecho de usuario "Add workstations to domain", que la Default Domain Controllers Policy concede a Authenticated Users. Era una comodidad de la época en que los usuarios unían sus propios PC. Hoy, sobre todo, regala a los atacantes una entidad de seguridad de dominio gratuita con una contraseña conocida y un SPN controlable, que es justo lo que necesitan el abuso de RBCD, las cadenas de relay hacia LDAP y varios ataques a plantillas de AD CS.

Es uno de los cambios de hardening más sencillos de AD: un atributo y un derecho de usuario. El trabajo está en encontrar quién depende silenciosamente del valor predeterminado y darle en su lugar una delegación adecuada y acotada.

Por qué importa una cuenta de equipo gratuita

Una cuenta de usuario por sí sola es un punto de apoyo débil para varios ataques contra AD. Muchos de ellos necesitan una entidad de seguridad que tenga un nombre de entidad de seguridad de servicio (SPN), una contraseña que el atacante conozca y el derecho a solicitar tickets Kerberos como servicio. Las cuentas de equipo tienen las tres cosas, y la cuota permite a cualquier usuario autenticado crear una desde cualquier equipo unido al dominio, o incluso no unido, con acceso de red a un DC, usando nada más que llamadas LDAP o SAMR estándar. Los kits ofensivos como Impacket y Powermad incluyen un comando de una sola línea para ello.

Lo que permite esa cuenta depende del resto de su configuración, y por eso la cuota aparece en tantas cadenas de ataque:

• Delegación restringida basada en recursos. Si el atacante puede escribir msDS-AllowedToActOnBehalfOfOtherIdentity en un destino, directamente o mediante un NTLM relay hacia LDAP, lo apunta a su nueva cuenta de equipo y suplanta a usuarios ante el destino.
• Plantillas de AD CS en las que puede inscribirse Domain Computers. La nueva cuenta es automáticamente miembro de Domain Computers, así que puede inscribirse en la plantilla Machine predeterminada y en cualquier plantilla personalizada con los mismos permisos. Combinado con otras configuraciones incorrectas de plantillas, eso se convierte en una vía para autenticarse como otra persona.
• Errores de implementación de Kerberos. Los problemas de suplantación de sAMAccountName de 2021 (CVE-2021-42278 y CVE-2021-42287) requerían una cuenta de equipo que el atacante pudiera renombrar. Los parches corrigieron esos errores concretos, pero es probable que el siguiente tenga el mismo requisito previo.
• Persistencia. Una cuenta de equipo creada durante una intrusión rara vez se detecta, rara vez caduca y mantiene una contraseña válida durante todo el tiempo que el atacante quiera.

Ninguno de estos ataques necesita la cuota si el atacante ya tiene derechos de creación a nivel de OU, y por eso la auditoría siguiente examina también quién los tiene.

Medir: la cuota actual y quién la ha usado

Lea el valor actual y compruebe quién tiene el derecho de usuario en los controladores de dominio.

Import-Module ActiveDirectory

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

Para el derecho de usuario, abra la GPO vinculada a la OU Domain Controllers (normalmente la Default Domain Controllers Policy) y consulte:

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

El valor predeterminado es Authenticated Users. En un DC puede confirmar la configuración efectiva con gpresult /h o exportando la directiva de seguridad local con secedit /export /cfg, donde el derecho aparece como SeMachineAccountPrivilege.

Después, busque los objetos de equipo creados a través de la cuota. Cuando un usuario sin privilegios crea una cuenta de equipo usando SeMachineAccountPrivilege, el DC graba el SID del creador en mS-DS-CreatorSID. Las cuentas creadas por administradores o mediante delegación sobre una OU no lo tienen.

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

Preste atención a los equipos sin valor de sistema operativo y sin inicios de sesión: ese patrón suele indicar una cuenta creada por un script o una herramienta, no por una unión real. Las entradas recientes creadas por usuarios estándar son o bien un proceso del service desk que nadie documentó, o bien algo que hay que pasar al equipo de respuesta a incidentes.

Auditar: quién une equipos legítimamente

Examine el evento 4741 (se ha creado una cuenta de equipo) en los DC durante unas semanas. Los campos Subject muestran qué cuenta creó cada objeto de equipo. Agrupe por creador para ver qué personas y cuentas de servicio unen equipos y con qué frecuencia.

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

Ejecútelo en todos los DC o, mejor aún, en su recopilador central (consulte auditoría y detección en AD). Los creadores legítimos típicos son: la cuenta de servicio de despliegue que usan las secuencias de tareas de SCCM/MDT, el Intune Connector for Active Directory usado para las uniones híbridas de Autopilot, algunos administradores de servidores y técnicos del service desk. Todo lo que quede fuera de esos grupos va a la lista de conversaciones pendientes.

Aplicar: establecer la cuota en 0 y delegar correctamente

Crear primero los derechos de unión delegados

Cree un grupo, por ejemplo GG-Workstation-Join, y concédale derechos de unión solo sobre la OU de destino. El conjunto mínimo sobre la OU es:

• Create Computer objects y Delete Computer objects sobre la OU (este objeto y los descendientes).
• Sobre los objetos de equipo descendientes: Reset password, Read and write Account Restrictions, Validated write to DNS host name y Validated write to service principal name.

Puede concederlo con el Asistente para delegación de control (tarea personalizada, "Only the following objects in the folder: Computer objects") o mediante un script con el proveedor 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'   # clase 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

Limite esto a las OU de preparación de estaciones de trabajo y servidores, nunca a la OU Domain Controllers ni a ninguna OU que contenga activos Tier 0. Incluya en él las cuentas de servicio de despliegue, la cuenta del conector de Intune y el grupo de unión del service desk, y asigne a cada uno su propio grupo si apuntan a OU diferentes.

Para los equipos que deba unir una persona concreta sin derechos más amplios, cree previamente el objeto de equipo y use "The following user or group can join this computer to a domain" en Active Directory Users and Computers, o use la unión al dominio sin conexión con djoin.exe /provision ejecutado por un administrador.

Establecer la cuota en 0

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

Cambiar el atributo requiere acceso de escritura a la raíz del dominio, normalmente Domain Admins. Surte efecto en cuanto se replica; no hay nada que reiniciar.

Quitar Authenticated Users del derecho de usuario

Con la cuota en 0, el derecho de usuario es inofensivo para los usuarios estándar, pero eliminarlo es defensa en profundidad y hace explícita la intención. En la GPO de Domain Controllers, configure Add workstations to domain solo con su grupo de unión, o déjelo vacío si todas las uniones se hacen mediante delegación sobre OU (los permisos de OU no dependen de este derecho).

Limpiar lo que creó la cuota

Recorra el CSV del paso de medición. Para cada dispositivo legítimo, muévalo a la OU correcta, confirme que el propietario es Domain Admins o su grupo de aprovisionamiento y elimine las ACE explícitas concedidas al creador original: el usuario que creó el objeto conserva derechos de escritura sobre él (incluido el conjunto de propiedades Account Restrictions) mucho después de que el dispositivo cambie de manos. Deshabilite las cuentas sin dispositivo correspondiente, espere un ciclo y después elimínelas.

Tenga en cuenta el hardening de la unión al dominio introducido con las actualizaciones de octubre de 2022 (KB5020276): reutilizar una cuenta de equipo existente durante la unión queda bloqueado salvo que la cuenta que realiza la unión la haya creado, sea una cuenta privilegiada o esté permitida por la directiva "Domain controller: Allow computer account re-use during domain join". Corregir la propiedad durante la limpieza evita sorpresas cuando se reinstalen los dispositivos.

Verificar

# La cuota es 0
(Get-ADObject (Get-ADDomain).DistinguishedName -Properties 'ms-DS-MachineAccountQuota').'ms-DS-MachineAccountQuota'

# Ningún equipo nuevo creado mediante la cuota desde el cambio
$changeDate = Get-Date '2026-01-15'   # fecha en que se estableció la cuota en 0
Get-ADComputer -LDAPFilter '(mS-DS-CreatorSID=*)' -Properties whenCreated |
    Where-Object { $_.whenCreated -gt $changeDate } |
    Select-Object Name, whenCreated

Pruebe una unión con una cuenta de usuario estándar: debe fallar con un error que indica que el usuario ha superado el número máximo de cuentas de equipo. Pruebe una unión con un miembro del grupo delegado en la OU de preparación: debe funcionar. Mantenga las alertas sobre el evento 4741 cuando el creador no sea una cuenta de aprovisionamiento conocida. La mayoría de las herramientas de evaluación señalan una cuota distinta de cero, así que su próxima evaluación con PingCastle debería dar por resuelta esa regla.

Qué rompe

• Los usuarios que unen sus propios equipos con su cuenta de dominio habitual, incluidos los desarrolladores que crean VM de laboratorio unidas al AD de producción. Ahora necesitan el grupo delegado o un objeto creado previamente.
• Los procesos de despliegue que usaban una cuenta de usuario normal sin delegación sobre la OU, a menudo una antigua credencial JoinDomain de MDT en CustomSettings.ini o una cuenta de unión de red de una secuencia de tareas. Fallan en el paso de unión hasta que la cuenta se añade al grupo delegado.
• Las herramientas de terceros que crean objetos de equipo para hosts Linux (realmd/SSSD, Samba), dispositivos NAS o brokers de VDI cuando están configuradas con una cuenta estándar. Asigne a cada una una cuenta de servicio dedicada con delegación sobre su propia OU.
• Autopilot híbrido, si la cuenta de equipo o la cuenta de servicio del conector de Intune no estaba delegada sobre la OU de destino; la documentación ya lo exige, pero los tenants en los que «simplemente funcionaba» a menudo dependían de la cuota.
• La reinstalación reutilizando nombres existentes puede toparse con el hardening de la unión de 2022 si no se normalizó la propiedad.

Lecturas relacionadas: el tema Delegación y la guía principal sobre delegación en Active Directory, la entrada del glosario sobre la cuota de cuentas de equipo y auditoría de plantillas de AD CS, donde las plantillas de equipo en las que puede inscribirse Domain Computers convierten cualquier equipo creado por un atacante en un certificado.