Tras promover un Windows Server 2022 a controlador de dominio (DC), puede suceder que cuentas administrativas de dominio no puedan iniciar sesión por consola ni por RDP. La causa habitual es un “tattooing” de derechos de usuario heredados. A continuación explico cómo diagnosticarlo, corregirlo con GPO o secedit y prevenirlo.

Resumen del caso real

Un servidor Windows Server 2022 se promovió como cuarto DC en un dominio con nivel funcional 2016. La replicación de Active Directory era correcta y los demás DC (2019) no presentaban incidentes. Sin embargo:

• No era posible iniciar sesión por consola ni a través de Remote Desktop Services (RDP) con cuentas administrativas de dominio.
• En RSOP (Resultant Set of Policy) no aparecían definiciones para Allow log on locally ni para Allow log on through Remote Desktop Services, por lo que parecían aplicarse los valores predeterminados.
• El registro de seguridad carecía de eventos de inicio de sesión (por ejemplo, 4624/4625) que sí existían en un DC sano.
• PowerShell Remoting (WinRM) y MMC (consolas remotas) sí permitían conectar y administrar el equipo.

Explicación técnica del problema

Los derechos de usuario definidos en Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > User Rights Assignment se almacenan en la base de seguridad local del equipo (la base de datos de seguridad, gestionada por secedit). Cuando un equipo miembro recibe una GPO que modifica estos derechos, los valores pueden persistir incluso si esa GPO deja de aplicarse posteriormente. Este fenómeno se conoce coloquialmente como “tattooing” en configuraciones de seguridad.

Tras la promoción a DC, el servidor pasa a la OU Domain Controllers y deja de estar sometido a GPO de servidores miembro. Si alguna de esas GPO anteriores contenía derechos de Denegar (por ejemplo, Deny log on locally y/o Deny log on through Remote Desktop Services) y quedó “tatuada”, el DC puede seguir bloqueando interactivamente el acceso, aunque RSOP no muestre ninguna GPO vigente que esté aplicando dicho bloqueo. En otras palabras: RSOP no ve los valores persistentes de la base de seguridad si no provienen de una GPO activa, pero el subsistema de seguridad sí los hace cumplir.

Como consecuencia, las entradas “Deny” heredadas ganan prioridad sobre cualquier “Allow” implícito o predeterminado, impidiendo el logon local y el logon remoto por RDS a grupos que deberían poder conectarse (p. ej., Domain Admins o Administrators del dominio).

Por qué MMC y PowerShell Remoting sí funcionan

La conexión por MMC remota o por PowerShell Remoting no es un logon interactivo (tipo 2) ni un logon interactivo remoto (tipo 10/RDP). Normalmente se ejecuta como logon de red (tipo 3) a través de RPC/WinRM, lo cual se ampara en derechos diferentes: Access this computer from the network (SeNetworkLogonRight) y pertenencia a los grupos administrativos adecuados. Por eso, aunque los derechos Interactive y Remote Interactive estén indebidamente denegados, la administración remota por estos canales puede seguir operativa y permite remediar el problema sin acceso físico.

Mapa de derechos implicados

Nombre en directiva	Constante interna	Descripción y notas
Allow log on locally	SeInteractiveLogonRight	Permite el inicio de sesión interactivo en consola o sesión local.
Deny log on locally	SeDenyInteractiveLogonRight	Deniega siempre el logon local a los sujetos listados. Tiene prioridad sobre “Allow”.
Allow log on through Remote Desktop Services	SeRemoteInteractiveLogonRight	Habilita el logon remoto tipo RDP (Logon Type 10).
Deny log on through Remote Desktop Services	SeDenyRemoteInteractiveLogonRight	Bloquea el logon por RDP. Predomina sobre el “Allow”.

Diagnóstico paso a paso

1. Comprobar el conjunto resultante de directivas Genere un informe con gpresult o revise RSOP. Si no aparecen las directivas de User Rights Assignment para los derechos anteriores, sospeche de valores persistentes en la base local: gpresult /h C:\Temp\gp.html
2. Exportar la base de seguridad con secedit secedit /export /cfg C:\Temp\secpol.inf Abra C:\Temp\secpol.inf y busque claves como:
   • SeDenyInteractiveLogonRight
   • SeDenyRemoteInteractiveLogonRight
   • SeInteractiveLogonRight
   • SeRemoteInteractiveLogonRight
   Si las claves SeDeny... contienen SIDs o grupos inesperados (p. ej., Administrators, Domain Admins o grupos amplios), ha encontrado el origen del bloqueo.
3. Comparar con la plantilla base de DC La plantilla predeterminada para DC está en %windir%\inf\defltdc.inf. Le servirá para contrastar qué debería estar definido por defecto en un controlador de dominio recién promovido.
4. Validar pertenencia de grupos whoami /groups Confirme que la cuenta afectada pertenece a Domain Admins o al grupo que su política considere como administradores de DC. Si aun así el acceso falla, es un fuerte indicio de una entrada “Deny” tatuada.
5. Revisar el Visor de eventos Busque eventos 4625 (fallos de inicio de sesión). Algunos bloqueos por “Deny” pueden no generar el evento típico si el rechazo se produce de forma temprana; en otros casos lo verá con subestado como c000015b (Usuario no autorizado para este tipo de inicio de sesión). La ausencia de 4624/4625, comparada con un DC sano, apunta a un bloqueo antes de completar la fase de autenticación interactiva.

Solución eficaz con GPO correctiva

La forma más limpia y sostenible de resolverlo es forzar, mediante una GPO sólo para la OU Domain Controllers, los valores correctos de User Rights Assignment y, en particular, sobrescribir cualquier “Deny” que quedó tatuado.

1. Abra Group Policy Management.
2. Cree una nueva GPO (por ejemplo, “Baseline DC – User Rights Assignment”).
3. Vincúlela a la OU Domain Controllers con la precedencia apropiada.
4. Edite la GPO: Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > User Rights Assignment.
5. Defina explícitamente:
   • Allow log on locally: incluya Administrators (y, si su política lo requiere, Backup Operators, Account Operators, etc.).
   • Allow log on through Remote Desktop Services: incluya Administrators (recomendado no otorgar RDP a usuarios estándar en DC).
   • Deny log on locally y Deny log on through Remote Desktop Services: asegúrese de que no contienen Administrators ni Domain Admins. Mantenga únicamente grupos que deban estar denegados, como Guests, si su política lo contempla.
6. Actualice directivas y verifique: gpupdate /force En muchos casos no es necesario reiniciar, pero si el derecho afectado es logon interactivo es recomendable hacerlo para acelerar la aplicación.

Al aplicarse, la GPO reescribe los valores persistentes en la base de seguridad (secedit.sdb) y restablece el acceso.

Alternativas de remediación con secedit

Si prefiere una intervención inmediata sin esperar el refresco de GPO, puede normalizar directamente con secedit utilizando la plantilla de DC.

Exportar, auditar y limpiar

secedit /export /cfg C:\Temp\secpol.inf

Revise en el archivo las claves SeDeny... y también SeInteractiveLogonRight/SeRemoteInteractiveLogonRight. Documente lo hallado y, a continuación, restablezca el conjunto de derechos al perfil base de DC:

secedit /configure /db C:\Temp\secedit.sdb ^
  /cfg %windir%\inf\defltdc.inf ^
  /areas USER_RIGHTS

El modificador /areas USER_RIGHTS limita la operación sólo a asignaciones de derechos de usuario. Tras aplicarlo, ejecute gpupdate /force y valide el inicio de sesión.

Importante: aunque esta vía resuelve con rapidez, es aconsejable consolidar la corrección en una GPO para evitar regresiones y garantizar consistencia entre DC.

Configuración recomendada para DC

Como pauta general, minimice la superficie de acceso directo a los DC y documente explícitamente quién puede iniciar sesión. A modo de guía rápida:

Directiva	Recomendado	Comentarios
Allow log on locally (SeInteractiveLogonRight)	Administrators	Agregue operadores específicos sólo si su modelo de operaciones lo exige.
Allow log on through Remote Desktop Services (SeRemoteInteractiveLogonRight)	Administrators	Evite conceder RDP a usuarios estándar en DC; prefiera saltos desde servidores de administración.
Deny log on locally (SeDenyInteractiveLogonRight)	Vacío o grupos estrictamente prohibidos (p. ej., Guests)	No incluya Administrators ni Domain Admins.
Deny log on through Remote Desktop Services (SeDenyRemoteInteractiveLogonRight)	Vacío o grupos estrictamente prohibidos	No bloquee accidentalmente a grupos administrativos.

Procedimiento detallado para crear la GPO de normalización

1. En Group Policy Management, haga clic derecho en Group Policy Objects y cree la GPO “Baseline DC – User Rights Assignment”.
2. Con la GPO creada, seleccione la OU Domain Controllers y elija Link an existing GPO para vincularla.
3. Edite la GPO y navegue a Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > User Rights Assignment.
4. Para cada derecho, marque Define these policy settings y asigne explícitamente los grupos recomendados (por ejemplo, “Administrators”).
5. Guarde cambios. Opcionalmente, habilite Enforced si necesitara que prevalezca sobre otras GPO vinculadas a la misma OU (use esta opción con prudencia).
6. Refresque directivas y valide capacidad de inicio de sesión desde consola y RDP.

Verificaciones posteriores a la corrección

• Refresco de directivas: gpupdate /force. Si no se resuelve de inmediato, reinicie para acelerar la adopción de los derechos interactivos.
• Exportación de control: repita secedit /export y confirme que SeDenyInteractiveLogonRight y SeDenyRemoteInteractiveLogonRight quedan en blanco o conforme al estándar.
• Visor de eventos: verifique eventos 4624 (éxito) y 4625 (fallo) con los Logon Type esperados (2 para local, 10 para RDP). Compruebe que los fallos previos desaparecen.
• Grupo efectivo: whoami /groups desde la sesión de prueba para confirmar membresías.

Checklist de prevención antes y después de promover

• Mueva los servidores candidatos a DC a una OU de staging con Block Inheritance para quitar GPO de servidores miembro (especialmente las que definen Deny en User Rights Assignment).
• Valide qué GPO aplican antes de lanzar el asistente de promoción. Documente cualquier directiva de seguridad.
• Tras la promoción, confirme que únicamente aplican Default Domain Controllers Policy y las GPO específicas para DC que su organización haya definido.
• Mantenga una GPO estándar y explícita para DC que fije los User Rights Assignment críticos y evite valores “pegados” de GPO anteriores.
• Automatice una tarea de verificación post‑promoción que ejecute: secedit /export /cfg C:\Temp\secpol-postpromo.inf findstr /R /C:"^SeDeny.*=" C:\Temp\secpol-postpromo.inf Si el comando devuelve líneas con SIDs/grupos inesperados, remédielo de inmediato con la GPO o con secedit /configure.

Preguntas frecuentes y matices prácticos

¿Por qué RSOP no muestra los “Deny” si están activos?
Porque RSOP refleja lo que declaran las GPO vigentes. Si un valor quedó persistente en la base de seguridad y actualmente ninguna GPO lo define, RSOP no lo verá; el motor de seguridad, sin embargo, sí lo aplica.

¿Por qué faltan eventos 4624/4625?
Dependiendo del punto de rechazo, el evento puede no generarse o aparecer con subestados distintos. El bloqueo por derecho “Deny” puede abortar el proceso antes de registrar un logon interactivo típico.

¿Puedo “arreglarlo” añadiendo más Allow?
No si existe un Deny contradictorio: en esta materia, Deny prevalece sobre Allow. Debe eliminar o vaciar la entrada de Deny para el grupo/usuario afectado.

¿Es seguro usar secedit /configure con defltdc.inf?
Sí, siempre que limite el área a USER_RIGHTS y conozca su línea base. Aun así, consolide la solución con una GPO para asegurar consistencia y trazabilidad.

¿Y si no tengo acceso por RDP ni consola, pero sí por PowerShell Remoting?
Aproveche WinRM para aplicar la GPO o ejecutar secedit remotamente. Ejemplo:

Enter-PSSession -ComputerName DC2022 -Credential (Get-Credential)
secedit /configure /db C:\Temp\secedit.sdb /cfg $env:windir\inf\defltdc.inf /areas USER_RIGHTS
gpupdate /force

Guía de comprobación rápida

1. Imposible iniciar sesión local/RDP en el DC recién promovido.
2. RSOP no muestra User Rights Assignment relevantes: sospecha de valores persistentes.
3. secedit /export: revisar SeDenyInteractiveLogonRight y SeDenyRemoteInteractiveLogonRight.
4. Solución preferente: GPO en OU Domain Controllers que defina Allow correctos y limpie Deny.
5. Alternativa rápida: secedit /configure con defltdc.inf sobre USER_RIGHTS.
6. Validar con eventos 4624/4625, whoami /groups y nueva exportación de secpol.inf.

Conclusión y resumen en una frase

El incidente lo provocaban entradas “Deny” persistentes (tattooing) heredadas de una GPO aplicada cuando el servidor era miembro; al promoverlo a DC, esos valores permanecieron en la base de seguridad local y bloquearon el logon. Al sobrescribir esas asignaciones con una GPO para DC —o restaurarlas con secedit a la plantilla defltdc.inf— se restableció el acceso y quedó normalizada la configuración.

Referencias operativas útiles

• Ruta de edición: Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > User Rights Assignment.
• Plantilla base de DC: %windir%\inf\defltdc.inf.
• Exportación auditoría: secedit /export /cfg C:\Temp\secpol.inf.
• Normalización puntual: secedit /configure /db C:\Temp\secedit.sdb /cfg %windir%\inf\defltdc.inf /areas USER_RIGHTS.
• Verificación de grupos: whoami /groups.
• Refresco: gpupdate /force.

Ejemplo de secpol.inf con valores problemáticos

En un caso real, la exportación contenía líneas similares a estas (nombres ilustrativos):

SeDenyInteractiveLogonRight = DOMAIN\Administrators, DOMAIN\Domain Admins
SeDenyRemoteInteractiveLogonRight = DOMAIN\Domain Admins
; ...
SeInteractiveLogonRight = *S-1-5-32-544
SeRemoteInteractiveLogonRight = *S-1-5-32-544

La presencia de Administrators y/o Domain Admins en los SeDeny... era el motivo del bloqueo. Tras aplicar la GPO correctiva o secedit /configure, las líneas SeDeny... quedaron vacías o con grupos permitidos por política, y los Allow se mantuvieron en su estado correcto.

Buenas prácticas de seguridad y operación

• Minimice el número de DC accesibles por RDP. Considere usar jump servers con MFA y registrar las sesiones.
• Use grupos dedicados para administración de DC y evite usar cuentas de usuario estándar para acceso a controladores de dominio.
• Incluya pruebas automatizadas que verifiquen periódicamente que los derechos críticos no contienen entradas indebidas.
• Documente y revise las GPO que asignan derechos de usuario. Etiquete y versione los cambios significativos.
• Considere controles de acceso condicional (redes administrativas, PAM/JIT) para reducir la exposición de logon interactivo a DC.

Plantilla rápida para GPO “post‑promoción” de DC

Úsela como base y ajústela a su entorno:

• Allow log on locally: Administrators.
• Allow log on through Remote Desktop Services: Administrators.
• Deny log on locally: vacío o Guests (según su política).
• Deny log on through Remote Desktop Services: vacío o grupos explícitamente prohibidos.
• Otros derechos a revisar (no siempre relacionados con el síntoma, pero relevantes): Access this computer from the network (SeNetworkLogonRight) y su par de Deny, Shut down the system, Debug programs, etc.

Comandos de utilidad reunidos

:: Informe de GPO
gpresult /h C:\Temp\gp.html

\:: Exportar configuración de seguridad efectiva
secedit /export /cfg C:\Temp\secpol.inf

\:: Normalizar derechos de usuario a la plantilla de DC
secedit /configure /db C:\Temp\secedit.sdb /cfg %windir%\inf\defltdc.inf /areas USER\_RIGHTS

\:: Forzar refresco de directivas
gpupdate /force

\:: Validación de membresías
whoami /groups

Cierre

Cuando un servidor miembro con GPO restrictivas pasa a DC, es fácil olvidar que algunos derechos de usuario pueden quedar arraigados. Detectar y limpiar esas entradas “Deny” persistentes —y fijar una línea base clara mediante una GPO exclusiva para la OU de controladores de dominio— evita bloqueos de acceso en el peor momento, mejora la higiene de seguridad y reduce el tiempo de recuperación ante incidencias similares.

Resumen en una frase: el bloqueo lo causaban entradas “Deny” persistentes heredadas de una GPO de servidores miembro; sobrescribir esas asignaciones con una GPO para DC (o restablecerlas con secedit) resolvió el problema.