Tier 0 y acceso privilegiado: blindar los Domain Admins

La mayoría de los compromisos de Active Directory no empiezan con un zero-day contra un controlador de dominio: empiezan con una cuenta con demasiados privilegios iniciando sesión en un equipo mal protegido. Un administrador de TI se conecta por RDP a una estación de trabajo del service desk con sus credenciales de Domain Admin para arreglar un problema de impresora, una herramienta de robo de credenciales recolecta el token y el atacante llega directamente a NTDS.dit. El modelo de niveles existe para que ese recorrido sea imposible por diseño, no por un memorando de políticas.

Esta guía cubre el modelo de acceso empresarial, cómo separar física y lógicamente el Tier 0, y el trabajo concreto de GPO, grupos y PowerShell necesario para hacerlo cumplir.

El modelo de niveles: Tier 0, 1 y 2

El clásico modelo de tres niveles de Microsoft (hoy integrado en el Enterprise Access Model, más amplio) separa la administración según el radio de impacto:

La regla que hace funcionar el modelo es direccional: una cuenta de administración de Tier N solo puede iniciar sesión en activos de Tier N. Una credencial de Tier 0 nunca debe tocar un equipo de Tier 1 o Tier 2, y un administrador de Tier 1 nunca debe usar sus credenciales en una estación de trabajo de Tier 2. Basta con violar esta regla una vez (iniciar sesión en un PC del service desk con una cuenta de Domain Admin) para que el límite entre niveles desaparezca, porque el robo de credenciales en ese equipo proporciona ahora acceso de Tier 0.

Qué pertenece al Tier 0

Sea estricto aquí: la expansión descontrolada del alcance del Tier 0 es el fallo más habitual. El Tier 0 incluye:

• Los controladores de dominio (todos, incluidos los RODC a efectos administrativos)
• Las CA raíz y emisoras de AD Certificate Services (una CA comprometida puede falsificar certificados de autenticación para cualquier usuario)
• Los servidores AD FS y sus certificados de firma de tokens
• Los servidores Microsoft Entra Connect / Entra Connect Sync
• Los sistemas de copia de seguridad y de imágenes capaces de restaurar o leer datos de AD
• Las propias Privileged Access Workstations y cualquier host de salto/bastión usado para llegar al Tier 0
• Los grupos de seguridad: Domain Admins, Enterprise Admins, Schema Admins, Administrators (en los DC), Account Operators, Backup Operators, Print Operators, Server Operators

Si no está seguro de si algo pertenece al Tier 0, pregúntese: «si este sistema se ve comprometido, ¿puede el atacante comprometer el dominio?». Si la respuesta es sí, es Tier 0, sin más, por muy incómodo que resulte operativamente.

Cuentas de administración separadas

Cada administrador humano que toque el Tier 0 necesita una cuenta dedicada que no se use para nada más: ni correo, ni navegación, ni Teams. Una convención de nombres práctica:

florian.amette          -> standard user account (Tier 2, email, day-to-day)
adm-t0-famette          -> Tier 0 admin account (DCs, PKI, Entra Connect)
adm-t1-famette          -> Tier 1 admin account (member servers, apps)

No reutilice una única cuenta «admin» entre niveles, y no otorgue a la cuenta de usuario estándar ninguna pertenencia implícita a grupos privilegiados. Hágalo cumplir con grupos protegidos por AdminSDHolder y auditorías periódicas de pertenencia, no con confianza.

GPO de denegación de inicio de sesión para hacer cumplir el límite

La pertenencia a grupos por sí sola no impide que un administrador inicie sesión en el nivel equivocado: necesita denegaciones explícitas de derechos de inicio de sesión. Cree GPO dedicadas y vincúlelas por nivel:

GPO: "Tier 0 – Deny Logon From Lower Tiers" (vinculada a la OU Domain Controllers y a cualquier OU de servidores Tier 0)

Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > User Rights Assignment

Replique esto con una GPO "Tier 1 – Deny Logon From Tier 0 and Tier 2" en las OU de servidores miembro y una GPO "Tier 2 – Deny Logon From Tier 0 and Tier 1" en las OU de estaciones de trabajo. Esto es lo que realmente impide que una credencial de Domain Admin sea utilizable si se obtiene mediante phishing en una estación de trabajo: incluso con credenciales válidas, el derecho de denegación bloquea el inicio de sesión.

Grupo Protected Users

Añadir las cuentas de Tier 0 a Protected Users (disponible desde Windows Server 2012 R2, aplicado por DC y clientes 2012 R2 o posteriores) endurece la propia credencial:

• Bloquea por completo la autenticación NTLM para la cuenta
• Bloquea DES y RC4 en la preautenticación Kerberos, forzando AES
• Desactiva el almacenamiento en caché de credenciales (sin inicio de sesión en caché, sin CredSSP, sin WDigest)
• Impide la renovación de tickets Kerberos más allá de 4 horas, forzando una nueva autenticación

Add-ADGroupMember -Identity "Protected Users" -Members "adm-t0-famette"

Pruébelo primero en un grupo piloto; consulte «Qué rompe» más abajo. Combínelo con el endurecimiento del cifrado descrito en Hardening de Kerberos para obtener el efecto completo.

Privileged Access Workstations (PAW)

Una GPO de denegación de inicio de sesión impide el inicio de sesión en el nivel equivocado, pero el administrador sigue necesitando algún sitio desde el que administrar el Tier 0. Esa es la PAW: un dispositivo endurecido y de propósito único que:

• No ejecuta navegador, cliente de correo ni suite de Office (o un navegador muy restringido limitado al portal de administración interno)
• Está unido a una OU dedicada de Tier 0 con sus propias GPO restrictivas
• No concede al usuario que inicia sesión más derechos de administrador local de los necesarios
• Es el único dispositivo autorizado para iniciar sesión con credenciales de Tier 0 (aplicado mediante las GPO de denegación anteriores en sentido inverso: las cuentas de Tier 0 se deniegan en todas partes excepto en la OU de las PAW)
• Utiliza BitLocker, Credential Guard y parches al día como base

PAW mínima viable: una VM o Cloud PC bloqueado y reservado exclusivamente para tareas de Tier 0, al que se accede por RDP desde una estación de trabajo estándar, pero sin iniciar nunca sesión directamente con credenciales de Tier 0 en la propia estación de trabajo.

Directivas de autenticación y silos

Los dominios Windows Server 2012 R2 o posteriores admiten Authentication Policies y Authentication Policy Silos, que aplican los límites entre niveles en el KDC de Kerberos en lugar de depender solo de los derechos de inicio de sesión de las GPO: una capa de defensa en profundidad que sobrevive incluso si una GPO no llega a aplicarse.

# Crear un silo que restrinja a los administradores de Tier 0 al acceso a PAW y DC
New-ADAuthenticationPolicySilo -Name "Tier0-Silo" `
    -UserAuthenticationPolicy "Tier0-UserAuthPolicy" `
    -ComputerAuthenticationPolicy "Tier0-ComputerAuthPolicy" `
    -Enforce

# La pertenencia es bidireccional: permitir la cuenta en el silo y después asignar el silo a la cuenta
Grant-ADAuthenticationPolicySiloAccess -Identity "Tier0-Silo" -Account "adm-t0-famette"
Set-ADAccountAuthenticationPolicySilo -Identity "adm-t0-famette" -AuthenticationPolicySilo "Tier0-Silo"

Las directivas de autenticación también pueden limitar la vigencia del TGT de Kerberos para los miembros del silo, reduciendo la ventana de la que dispone un atacante si roba un ticket.

Limpiar Domain Admins y Enterprise Admins

Audite la pertenencia con regularidad: estos grupos acumulan entradas obsoletas durante años.

# Listar los miembros actuales de Domain Admins y Enterprise Admins
Get-ADGroupMember -Identity "Domain Admins" -Recursive |
    Select-Object Name, SamAccountName, objectClass

Get-ADGroupMember -Identity "Enterprise Admins" -Recursive |
    Select-Object Name, SamAccountName, objectClass

# Buscar cuentas que no han iniciado sesión en 90 días o más pero siguen siendo privilegiadas
$cutoff = (Get-Date).AddDays(-90)
Get-ADGroupMember -Identity "Domain Admins" |
    Get-ADUser -Properties LastLogonDate |
    Where-Object { $_.LastLogonDate -lt $cutoff -or -not $_.LastLogonDate }

Estado objetivo: Enterprise Admins debe estar vacío salvo durante cambios programados a nivel de bosque (actualizaciones de esquema, incorporación de nuevos dominios), y vaciarse de nuevo después. Domain Admins solo debe contener el pequeño conjunto de cuentas nominativas de administradores de Tier 0: ni cuentas de servicio, ni cuentas «por si acaso», ni cuentas de proveedores.

# Verificar una asignación de derechos de usuario concreta (p. ej., deny log on locally) aplicada por GPO
Get-ADGroup "Tier 1 Admins" | Select-Object -ExpandProperty SID
# Contrastar con los derechos de usuario efectivos en el host de destino (incluye las GPO de dominio):
secedit /export /cfg "$env:TEMP\rights.inf" /areas USER_RIGHTS
Select-String -Path "$env:TEMP\rights.inf" -Pattern "SeDenyInteractiveLogonRight"

Qué rompe

• Las tareas programadas y los servicios que se ejecutan con cuentas de Domain Admin en servidores miembro o estaciones de trabajo fallarán de inmediato en cuanto se apliquen los derechos de denegación de inicio de sesión como trabajo por lotes/servicio. Inventaríe todas las tareas programadas y servicios con Get-ScheduledTask / Get-CimInstance Win32_Service filtrando por nombres de cuentas privilegiadas antes del despliegue, y mígrelos después a Group Managed Service Accounts (gMSA) limitadas al Tier 1.
• Los flujos de trabajo delegados del service desk que dependen de una cuenta «admin» compartida tanto para restablecer contraseñas como para diagnosticar servidores dejan de funcionar entre niveles: debe delegar los derechos de restablecimiento de contraseñas mediante delegación por OU en lugar de cuentas que crucen niveles.
• La pertenencia a Protected Users rompe las aplicaciones heredadas dependientes de NTLM, el inicio de sesión en caché en equipos que no son DC y la renovación de tickets Kerberos más allá de 4 horas: haga un piloto antes de un despliegue amplio.
• El acceso al Tier 0 exclusivamente desde PAW ralentiza la respuesta ante emergencias salvo que prevea al menos una vía de emergencia (break-glass) (un procedimiento documentado, supervisado y físicamente protegido) para la recuperación de los DC cuando la propia PAW no esté disponible.

Lecturas relacionadas: Hardening de Kerberos para la capa de autenticación que hay bajo estas cuentas, y Delegación para los riesgos de la delegación restringida que pueden eludir los límites entre niveles. Consulte también las entradas del glosario sobre Protected Users y DCSync.