Active Directory: solo el creador del objeto puede unir el equipo (KB5020276) — causa y solución con GPO

¿Te falla unir un equipo a Active Directory cuando el objeto ya fue precreado? Desde los endurecimientos de Netjoin, por defecto solo la cuenta que creó ese objeto (o ciertos administradores) puede reutilizarlo. Aquí tienes la causa, cómo diagnosticarlo y la solución soportada con GPO.

Índice

Contexto y síntoma

En muchos entornos de TI, un equipo de imaging o un servicio de despliegue precrea la cuenta de equipo en AD y otra persona (o script) realiza el domain join después. Lo que antes funcionaba ahora puede fallar con mensajes como:

NERR_AccountReuseBlockedByPolicy (0xAAC)
Access is denied al reutilizar una cuenta de equipo existente

En el cliente, el fichero C:\Windows\Debug\netsetup.log y el evento 4101 (origen NetJoin) suelen registrar el bloqueo. En los controladores de dominio (DC), aparecen eventos 16995–16998 (origen Directory-Services-SAM) indicando que la reutilización fue denegada por directiva.

Qué cambió en Windows

Microsoft reforzó el proceso de unión al dominio y, especialmente, la reutilización de cuentas de equipo preexistentes. A partir de los endurecimientos introducidos en 2022 y ampliados/afinados en 2023 y 2024, ya no basta con tener permisos delegados “genéricos” sobre la OU u objeto: por defecto, solo puede reutilizar esa cuenta:

La cuenta que creó el objeto de equipo (su SID coincide con el msDS-CreatorSID del objeto)
Miembros de grupos administrativos de alto nivel (por ejemplo, Domain Admins, Enterprise Admins o Account Operators)

Además, Microsoft retiró la vía no soportada de permitir la reutilización mediante el valor de registro NetJoinLegacyAccountReuse. La vía oficial hoy es una directiva de seguridad publicada vía GPO que define una allowlist de cuentas o grupos autorizados para reutilizar cuentas de equipo durante el join.

Idea clave: si precreas cuentas y otra persona/servicio las une, debes habilitar explícitamente quiénes pueden reutilizarlas con la nueva GPO “Domain controller: Allow computer account re-use during domain join”.

Cómo solucionarlo (método recomendado)

Aplicar la GPO de “allowlist” en los Controladores de Dominio

Comprueba requisitos de actualización
Asegúrate de que todos los DCs y equipos miembro ejecutan como mínimo las actualizaciones acumulativas de septiembre de 2023 (o posteriores). Esto garantiza que la nueva directiva sea reconocida.
Crea/edita una GPO vinculada a la OU “Domain Controllers”
Abre gpmc.msc → crea una GPO (por ejemplo, “DC – Allow Machine Account Reuse”) y edítala.
Ruta de la directiva
Equipo > Configuración de Windows > Configuración de seguridad > Directivas locales > Opciones de seguridad > Domain controller: Allow computer account re-use during domain join
Habilita la directiva y define la allowlist
Activa “Definir esta configuración de directiva” y agrega usuarios o grupos que estén autorizados para reutilizar cuentas de equipo (por ejemplo, la cuenta de servicio que precrea objetos o un grupo “Join-Account-Reuse-Allowed” gestionado por TI). Buenas prácticas:
- Evita agregar “Authenticated Users”, “Domain Users” o grupos masivos.
- Usa grupos en lugar de usuarios individuales para facilitar auditoría y rotación.
- Documenta por qué cada principal está en la allowlist y revísalo trimestralmente.
Forzar actualización de directivas y replicación
En cada DC, ejecuta: gpupdate /force Espera la replicación de AD. Si utilizas múltiples sitios, comprueba la convergencia antes de probar.
Probar y validar
Repite el join con una cuenta presente en la allowlist. Si sigue fallando, revisa:
- C:\Windows\Debug\netsetup.log en el cliente
- Eventos 16995–16998 en los DCs (canal Directory-Services-SAM)

Opciones operativas cuando el join está bloqueado

Hacer el join con la misma cuenta que creó el objeto (se salta la necesidad de estar en la allowlist).
Eliminar el objeto de equipo “obsoleto” y unir de nuevo (el join creará una cuenta limpia con el creador actual).
Renombrar el equipo y unir con un nombre que no exista aún en AD.

Alternativa	Ventajas	Riesgos/Consideraciones
Join con la cuenta creadora	Rápido, sin cambios de GPO	Dependencia de una credencial concreta; poca escalabilidad
Eliminar objeto y unir de cero	Estado limpio; elimina residuos de atributos	Requiere permiso para borrar; impacto si había ACLs personalizadas en el objeto
Renombrar y unir con nombre nuevo	Evita conflictos por duplicados	Puede romper referencias a nombre antiguo (GPOs por filtro, scripts, inventario)

Delegación correcta para cuentas precreadas

Si vas a mantener el flujo “precrear y que otro una”, además de la GPO de allowlist, verifica que la delegación de permisos sobre la OU u objeto de equipo incluye como mínimo:

Reset Password
Read and write Account Restrictions
Validated write to DNS host name
Validated write to service principal name (SPN)

En Active Directory Users and Computers (ADUC), usa el Asistente de Delegación en la OU donde se crean los equipos. Para revisarlo vía PowerShell:

# Ver permisos efectivos (ejemplo utilizando dsacls)
dsacls "OU=Equipos,DC=contoso,DC=com"

Ver atributos clave del equipo precreado

Get-ADComputer PC-123 -Properties msDS-CreatorSID,servicePrincipalName,dNSHostName |
Select Name, @{N="CreatorSID";E={$\_.("msDS-CreatorSID")}}, dNSHostName, servicePrincipalName

Cuando no precreas cuentas

Si permites que los usuarios unan equipos sin precreación, revisa:

SeMachineAccountPrivilege (Add workstations to domain) en la directiva de seguridad: define quién puede crear cuentas de equipo.
ms-DS-MachineAccountQuota: por defecto, cada usuario puede unir hasta 10 equipos.

# Consultar la cuota por dominio
Get-ADDomain | Select-Object -ExpandProperty 'ms-DS-MachineAccountQuota'

Cambiar la cuota (ejemplo: 0 = solo cuentas autorizadas)

Set-ADDomain -Identity "contoso.com" -Replace @{'ms-DS-MachineAccountQuota'=0}

Si estableces la cuota en 0, únicamente quienes tengan SeMachineAccountPrivilege u otra delegación explícita podrán crear cuentas de equipo.

Diagnóstico rápido

En el equipo cliente

Abre C:\Windows\Debug\netsetup.log y busca NERR_AccountReuseBlockedByPolicy o referencias a reuse blocked.
Visor de eventos → System → origen NetJoin → Evento 4101.

En los controladores de dominio

Visor de eventos → Applications and Services Logs → Microsoft → Windows → Directory-Services-SAM → canal Operational.
Busca eventos 16995–16998, que detallan el SID del creador, quién intentó la operación y si coincide con la allowlist.

Checklist operativo (guía de campo)

Identifica si el objeto de equipo ya existe en AD y quién lo creó (msDS-CreatorSID).
Confirma que DCs y clientes tienen las actualizaciones de seguridad de septiembre de 2023 o superiores.
Aplica/valida la GPO “Domain controller: Allow computer account re-use during domain join”.
Asegúrate de incluir en la allowlist a la cuenta de servicio o grupo que realiza el join.
Evita en la allowlist a “Authenticated Users” o grupos masivos.
Comprueba delegaciones en la OU: Reset Password, Account Restrictions, validated writes a DNS y SPN.
Fuerza gpupdate /force en DCs y espera replicación.
Reintenta el join y revisa netsetup.log + eventos 4101 y 16995–16998 si falla.
Como plan B, elimina el objeto obsoleto o realiza el join con el creador.
Documenta y audita la allowlist (revisión trimestral).

Preguntas frecuentes

¿Qué grupos pueden reutilizar cuentas sin estar en la allowlist?

Normalmente, Domain Admins, Enterprise Admins y Account Operators pueden hacerlo. No obstante, por higiene de seguridad se recomienda operar con cuentas de servicio dedicadas y una allowlist explícita, en lugar de usar cuentas con privilegios amplios.

¿La GPO requiere reiniciar los controladores de dominio?

No suele requerir reinicio; basta con actualizar directivas (gpupdate /force) y esperar la replicación. Aun así, si persiste el comportamiento anterior, valida que la GPO está aplicada en los DCs (usa gpresult /h) y que tienen las actualizaciones mínimas.

¿Puedo seguir usando la clave de registro `NetJoinLegacyAccountReuse`?

No. Ese mecanismo fue retirado y ya no es la vía soportada. La única forma recomendada es la GPO con allowlist.

¿Cómo gestiono grandes equipos de despliegue?

Crea un grupo de AD (por ejemplo, Join-Account-Reuse-Allowed), agrega ahí las cuentas de técnicos/servicios y añade el grupo a la allowlist de la GPO. Así reduces el mantenimiento y facilitas auditoría.

¿Esto afecta a Azure AD Join o a Entra ID?

No. Este endurecimiento afecta al join clásico de Active Directory (dominios on‑premises). No interfiere con escenarios de registro en la nube salvo que haya hybrid join y procesos que toquen AD local.

¿Qué pasa si mis DCs son muy antiguos?

La directiva requiere que los DCs tengan las actualizaciones de línea base (septiembre de 2023 o posteriores). Si hay DCs sin esas actualizaciones, pueden ignorar o no entender la directiva, y el comportamiento será inconsistente. Actualiza primero.

¿Cómo verifico que la allowlist se está aplicando?

En el Visor de eventos de los DCs, los eventos 16995–16998 muestran si el intento de reutilización fue permitido o bloqueado, y qué cuenta se evaluó contra la allowlist. También puedes usar gpresult en un DC para confirmar que la GPO está en vigor.

Mapeo de errores a causas y acciones

Mensaje / Código	Causa probable	Acción recomendada
`NERR_AccountReuseBlockedByPolicy (0xAAC)`	Reutilización bloqueada por la directiva endurecida	Agregar la cuenta/grupo a la allowlist en la GPO o usar la cuenta creadora
Access is denied	Faltan permisos delegados (Reset Password, validated writes)	Corregir delegación en la OU/objeto según prácticas recomendadas
La cuenta de equipo ya existe	Nombre en uso o objeto obsoleto	Eliminar el objeto y unir de cero o renombrar el equipo

Playbook para el Service Desk

Pedir el nombre del equipo y la cuenta de AD usada para el join.
Comprobar si el objeto existe en la OU prevista y si su msDS-CreatorSID coincide con el usuario que está intentando unir.
Si no coincide, validar si la cuenta pertenece a la allowlist. Si no, tramitar inclusión temporal o ejecutar el join con una cuenta autorizada.
Si urge, eliminar el objeto y reintentar el join (coordinando con el equipo propietario de la OU).
Registrar la incidencia e incluir evidencias de netsetup.log y eventos de DC.

Automatizaciones y ejemplos de scripts

Comprobar estado del canal seguro del equipo

# Desde el equipo: verifica relación de confianza (no soluciona el bloqueo de reutilización, pero ayuda a aislar problemas)
Test-ComputerSecureChannel -Verbose

Unión al dominio por línea de comandos

# PowerShell (requiere reinicio):
Add-Computer -DomainName "contoso.com" -Credential (Get-Credential) -Restart

netdom (CMD):

netdom join %COMPUTERNAME% /domain\:contoso.com /UserD\:CONTOSO\cuenta\de\join /PasswordD:\*

Eliminar un objeto de equipo obsoleto de forma segura

# Ejecutar con privilegios adecuados
Remove-ADComputer -Identity "PC-123" -Confirm:$false

Revisar atributos útiles del equipo en AD

Get-ADComputer "PC-123" -Properties whenCreated,msDS-CreatorSID,dNSHostName,servicePrincipalName,description |
  Select Name, whenCreated, @{N="CreatorSID";E={$_.("msDS-CreatorSID")}}, dNSHostName

Seguridad y cumplimiento

Mínimo privilegio: limita la allowlist a cuentas de servicio o grupos de técnicos realmente necesarios.
Auditoría: registra cambios en la GPO y en la membresía del grupo utilizado en la allowlist.
Segregación de funciones: separa quién precrea objetos y quién puede reutilizarlos, pero controla y audita la intersección mediante la allowlist.
Revisión periódica: adopta un ciclo (mensual/trimestral) para revisar la allowlist y los reportes de eventos 16995–16998.

Errores habituales y cómo evitarlos

Confiar en el registro NetJoinLegacyAccountReuse: obsoleto. No perdura y no es soportado.
Agregar “Authenticated Users” a la allowlist: riesgo innecesario. Amplía la superficie de ataque.
Olvidar la base de actualizaciones en DCs/clients: provoca que la GPO no surta efecto o haya comportamientos inconsistentes.
Delegaciones incompletas en la OU: terminan en Access is denied incluso si la allowlist está bien.

Ejemplo de procedimiento paso a paso

Reúne datos: nombre del equipo, OU destino, quién precreó y quién hará el join.
Verifica msDS-CreatorSID del objeto y confirma si el operador está en la allowlist.
Si no lo está, solicita su inclusión (temporal o permanente) en el grupo de allowlist y actualiza GPO en los DCs.
Ejecuta el join desde el equipo con la cuenta autorizada; valida netsetup.log.
Si el join falla, elimina el objeto y reintenta o realiza el join con nombre alternativo.
Documenta la intervención y los eventos relevantes en los DCs.

Resumen ejecutivo

Sí, es por las actualizaciones de endurecimiento (cambios de Netjoin). La reutilización de cuentas de equipo ahora está restringida por defecto.
Implementa la GPO “Domain controller: Allow computer account re-use during domain join” con una allowlist controlada.
Si no quieres tocar GPO: une con la cuenta creadora o borra y recrea el objeto antes del join.
Verifica delegaciones (Reset Password, Account Restrictions, validated writes a DNS/SPN) para evitar Access is denied.
Para uniones sin precreación, controla SeMachineAccountPrivilege y la cuota ms-DS-MachineAccountQuota.

Glosario rápido

Allowlist: lista explícita de cuentas/grupos que el DC acepta para reutilizar cuentas de equipo existentes durante el join.
msDS-CreatorSID: atributo con el SID de la cuenta que creó el objeto de equipo.
netsetup.log: log de cliente con detalles del proceso de unión al dominio.
Eventos 16995–16998: eventos de DC que describen decisiones de permitir/bloquear la reutilización.
SeMachineAccountPrivilege: derecho de crear cuentas de equipo en el dominio.

Con estos pasos, recuperarás el flujo “una persona precrea y otra une” de forma consistente, segura y alineada con el endurecimiento actual de Windows y Active Directory.