🛡️ Guía independiente de formación en ciberseguridad · Certificaciones, itinerarios y cursos
Inicio › Cursos › Curso de Defensa y Bastionado de Active Directory
Módulo 3 de 13

Módulo 3: Modelo de administración por niveles (Tiering) y PAW

Módulo 3: Modelo de administración por niveles (Tiering) y PAW

Aviso ético: el contenido de este módulo se ofrece con fines exclusivamente educativos y de formación profesional en ciberseguridad defensiva. Todos los comandos, GPO y consultas deben practicarse únicamente en laboratorios controlados (máquinas virtuales o entornos de pruebas aislados) sobre los que tengas autorización explícita. Aplicar cambios de segregación de privilegios en un Active Directory de producción sin planificación, sin ventana de mantenimiento y sin un plan de rollback puede dejar el dominio inoperativo o, peor, bloquear el acceso de administración de forma irreversible. Sigue siempre el principio de mínimo privilegio, la autorización explícita del propietario del sistema y la normativa aplicable (LOPDGDD/RGPD, ENS, ISO 27001, etc.).

Qué aprenderás

  • Por qué el «modelo de bosque único con todos los admins en Domain Admins» es la causa raíz de la inmensa mayoría de los compromisos totales de Active Directory.
  • El modelo de niveles (Tiering) clásico de Microsoft: Tier 0, Tier 1 y Tier 2, qué contiene cada uno y quién puede administrarlo.
  • Su evolución oficial al Enterprise Access Model (EAM): planos de control, gestión, datos/carga de trabajo, y su extensión a identidad híbrida con Entra ID.
  • Las «reglas de oro» de contención: por qué una credencial de Tier 0 jamás debe autenticarse en un equipo de Tier 1 o Tier 2, y cómo se rompe el movimiento lateral con ellas.
  • Cómo implementar la segregación con GPO reales: Deny log on locally / through Remote Desktop Services / as a batch job / as a service y Restricted Groups.
  • Qué es una PAW (Privileged Access Workstation), por qué existe, y su arquitectura de referencia con jump servers / bastion hosts.
  • Cómo auditar y limpiar la pertenencia a grupos privilegiados (Domain Admins, Enterprise Admins, Schema Admins, Administrators) y qué es AdminSDHolder/SDProp.
  • Un laboratorio guiado para crear los grupos de negación y aplicar una GPO de aislamiento de Tier 0.

1. El problema: ¿por qué un solo credential comprometido tumba todo el dominio?

En los módulos anteriores has visto cómo un atacante que compromete una estación de trabajo normal puede escalar mediante Kerberoasting, abuso de delegación, o extracción de credenciales en memoria con herramientas tipo Mimikatz. Ese salto de «endpoint pwneado» a «control total del dominio» casi nunca ocurre por una vulnerabilidad exótica: ocurre porque un administrador de dominio inició sesión en un equipo que no debía.

El patrón tiene nombre: credential theft + lateral movement + privilege escalation. Un helpdesk resuelve un ticket en el portátil de un usuario con su cuenta de Domain Admins «porque es más rápido»; el token/hash de esa cuenta queda en memoria (LSASS) de ese portátil; el atacante que ya tenía persistencia ahí lo extrae, y en minutos tiene DCSync sobre todo el bosque. No hace falta 0-day: hace falta que la topología de confianza lo permita.

El modelo de niveles no es una mejora cosmética de «buenas prácticas»: es un control de contención estructural. Su objetivo es garantizar que el compromiso de un activo de bajo valor no pueda nunca, por diseño de la topología de autenticación, escalar hasta el control del dominio. Microsoft lo resume así:

«A cornerstone objective of security for identity systems is to build in choke points that provide clean sources / trustworthy sources that can be used to grant privileges and permissions elsewhere in the estate […] The tier model is a security stance where the highest tier controls the entire environment, high value assets are managed at the lowest tier, and no lower tier can control anything at a higher tier.»

— Microsoft, «Enterprise access model» / «Securing privileged access», Microsoft Learn.

2. El modelo de niveles clásico (Tiering)

Microsoft introdujo formalmente este modelo en torno a 2014-2016 dentro de su documentación de «Securing Privileged Access» (SPA/ESAE). Divide todos los activos y todas las cuentas administrativas del entorno en tres niveles de confianza, con una regla de contención estricta entre ellos.

Nivel Qué contiene Quién lo administra Desde dónde se administra
Tier 0
(Control de identidad)		 Controladores de dominio (DC), Active Directory Certificate Services (AD CS) con plantillas peligrosas, Azure/Entra Connect (sync server), servidores DNS integrados en AD, cuentas y grupos que controlan lo anterior: Domain Admins, Enterprise Admins, Schema Admins, Administrators del dominio, cuenta krbtgt, GPO vinculadas a la raíz del dominio/OU de DCs. Únicamente cuentas Tier 0 dedicadas (t0-nombre), número reducido de administradores, MFA obligatoria. Exclusivamente desde PAW de Tier 0. Prohibido RDP/logon interactivo desde equipos de Tier 1 o Tier 2.
Tier 1
(Servidores y aplicaciones)		 Servidores miembro: aplicaciones de negocio, bases de datos, servidores de ficheros, hipervisores, servidores web internos, servicios de nube privada. Administradores de servidor/aplicación con cuentas dedicadas (t1-nombre), normalmente vía grupo Server Admins delegado por OU/servicio. Desde PAW o jump server de Tier 1. No deben usar la misma cuenta con la que administran Tier 0, y NO pueden loguearse en DCs.
Tier 2
(Estaciones de trabajo y usuarios)		 PCs y portátiles de usuario final, impresoras, dispositivos de usuario, cuentas de usuario estándar (correo, ofimática, navegación). Helpdesk / soporte de puesto de trabajo con cuentas dedicadas (t2-nombre). Desde su propio equipo de soporte. Nunca deben usar esa cuenta para loguearse en servidores (Tier 1) ni en DCs (Tier 0).

La regla de contención se resume en una frase que debe memorizarse literalmente: una credencial de un nivel superior jamás debe presentarse (interactivo, RDP, servicio, tarea programada) en un activo de nivel inferior. El flujo de administración es descendente por diseño (Tier 0 puede gestionar Tier 1 y Tier 2 vía GPO/políticas, nunca al revés), pero el logon de credenciales debe ser estrictamente horizontal dentro de cada nivel, jamás cruzado.

2.1. Por qué el orden importa: la dirección del ataque

Fíjate en la asimetría: Tier 0 administra Tier 1 y Tier 2 (empuja GPO de configuración, Windows Update, antivirus), pero eso es gestión centralizada, no logon interactivo con credenciales privilegiadas. El error que rompe el modelo es que un humano con cuenta de Tier 0 inicie sesión interactivamente (RDP, consola, «Ejecutar como», tarea programada) en un equipo de Tier 1 o Tier 2: en ese instante el hash/token queda expuesto en memoria de un activo de menor confianza, y cualquier atacante con persistencia local puede robarlo.

3. La evolución: Enterprise Access Model (EAM)

Desde 2020, Microsoft sustituyó el modelo de tres niveles «plano» por el Enterprise Access Model, que resuelve limitaciones del Tiering clásico: no contemplaba bien el control plane de nube (Azure/Entra) y mezclaba «gestión de la plataforma» con «gestión de cargas de trabajo de negocio». El EAM sigue el mismo principio de contención pero lo reorganiza en planos concéntricos:

Plano Equivalencia con Tiering clásico Qué incluye
Control Plane Tier 0 ampliado AD DS on-prem (DCs, AD CS, krbtgt), Entra ID (Global Administrator, Privileged Role Administrator, Conditional Access), Entra Connect/sync, identidades híbridas, todo lo que define «quién tiene acceso a qué» en toda la organización.
Management Plane Solapa Tier 0/Tier 1 Herramientas de gestión con alcance amplio: consolas de gestión de endpoints (Intune, SCCM/MECM), plataformas de automatización (Ansible Tower, herramientas RMM), sistemas de monitorización con capacidad de ejecución remota.
Data/Workload Plane Tier 1 + Tier 2 Aplicaciones de negocio, servidores de aplicación, bases de datos, estaciones de trabajo de usuario: los activos que generan valor de negocio pero cuyo compromiso individual no debe comprometer el resto.

Mantenemos «Tier 0/1/2» como vocabulario base de este módulo porque sigue siendo el estándar en runbooks, auditorías y herramientas (incluido BloodHound, que etiqueta rutas de ataque hacia Tier 0), señalando que el Control Plane del EAM es su sucesor funcional e incorpora de forma nativa el plano cloud/Entra.

3.1. El añadido crítico del EAM: identidad híbrida

El modelo clásico de 2016 asumía un bosque AD aislado. Hoy, la mayoría de organizaciones sincronizan identidades a Entra ID con Entra Connect (antes Azure AD Connect), lo que crea una superficie que el Tiering clásico no cubría: un servidor Entra Connect on-premises con permisos de sincronización es, de facto, Tier 0/Control Plane, porque quien lo compromete puede manipular atributos sincronizados y, con Password Hash Sync o Pass-Through Authentication mal configurados, escalar entre on-prem y cloud en ambas direcciones. El EAM exige tratar Entra Connect, los roles Global Administrator/Privileged Role Administrator y las políticas de Conditional Access como parte del mismo Control Plane que los controladores de dominio.

4. Implementación técnica: GPO de negación por nivel

La herramienta principal para materializar la contención de logon son los User Rights Assignment de GPO, en concreto los cuatro derechos de «Deny»: Deny log on locally, Deny log on through Remote Desktop Services, Deny log on as a batch job y Deny log on as a service. La estrategia estándar es:

  1. Crear grupos de seguridad globales por nivel: Tier 0 Admins, Tier 1 Admins, Tier 2 Admins (o el prefijo que use tu organización).
  2. Crear GPO de negación vinculadas a las OU correspondientes que nieguen el logon de los grupos de niveles superiores/no correspondientes en los equipos de ese nivel.
  3. Los «Allow log on» (permitir) se gestionan aparte, normalmente restringiendo Allow log on locally/Allow log on through RDS únicamente al grupo del nivel correcto.

Las políticas negativas («Deny») siempre tienen precedencia sobre las positivas («Allow») en la evaluación de Windows, lo cual las hace ideales como control de «cinturón y tirantes»: aunque alguien quede accidentalmente en dos grupos, el Deny gana.

4.1. Ejemplo de GPO de aislamiento de Tier 0 (equipos DC / servidores Tier 0)

En la política vinculada a la OU Domain Controllers (y a cualquier OU de servidores Tier 0 adicionales, como servidores AD CS), en Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > User Rights Assignment, se configuran así los cuatro derechos de negación, incluyendo los grupos Tier 1 Admins y Tier 2 Admins (nunca al revés):

Deny log on locally:
  Tier 1 Admins
  Tier 2 Admins

Deny log on through Remote Desktop Services:
  Tier 1 Admins
  Tier 2 Admins

Deny log on as a batch job:
  Tier 1 Admins
  Tier 2 Admins

Deny log on as a service:
  Tier 1 Admins
  Tier 2 Admins

Nota importante: no se incluye «Tier 0 Admins» en su propia negación (obviamente), y tampoco se debe incluir aquí a Domain Admins si ya has migrado la operativa diaria a cuentas de nivel — pero durante la transición conviene incluir también los grupos legacy (Domain Admins, Enterprise Admins) como excepción explícita SOLO si el proceso de migración aún no ha vaciado esas cuentas de uso operativo; lo ideal a medio plazo es que Domain Admins quede vacío de cuentas de uso diario y solo contenga la cuenta de break-glass (ver §7).

4.2. Ejemplo de GPO simétrica para Tier 1 (servidores miembro)

Deny log on locally:
  Tier 0 Admins
  Tier 2 Admins

Deny log on through Remote Desktop Services:
  Tier 0 Admins
  Tier 2 Admins

Deny log on as a batch job:
  Tier 0 Admins
  Tier 2 Admins

Deny log on as a service:
  Tier 0 Admins
  Tier 2 Admins

Aquí es donde muchas organizaciones se equivocan: piensan que negar solo «de abajo hacia arriba» es suficiente. No lo es. También hay que negar «de arriba hacia abajo» (Tier 0 no debería loguearse rutinariamente en servidores Tier 1 salvo con su cuenta t1 dedicada, no con su cuenta t0), porque de lo contrario el administrador de Tier 0 arrastra su credencial más sensible por todo el parque de servidores, ampliando exactamente la superficie que el modelo pretende reducir.

4.3. Asignar los grupos vía PowerShell/GPMC (referencia de automatización)

Para entornos donde se gestionan las GPO mediante scripting (por ejemplo, despliegue con el módulo GroupPolicy y plantillas ADMX), la asignación de «User Rights Assignment» se realiza habitualmente editando la plantilla de seguridad (GptTmpl.inf) dentro de la GPO, referenciando los grupos por su SID (no por nombre, para evitar problemas de resolución). Un extracto representativo de la sección relevante del GptTmpl.inf:

[Privilege Rights]
SeDenyInteractiveLogonRight = *S-1-5-21-<DOMAIN-ID>-1105,*S-1-5-21-<DOMAIN-ID>-1106
SeDenyRemoteInteractiveLogonRight = *S-1-5-21-<DOMAIN-ID>-1105,*S-1-5-21-<DOMAIN-ID>-1106
SeDenyBatchLogonRight = *S-1-5-21-<DOMAIN-ID>-1105,*S-1-5-21-<DOMAIN-ID>-1106
SeDenyServiceLogonRight = *S-1-5-21-<DOMAIN-ID>-1105,*S-1-5-21-<DOMAIN-ID>-1106

Donde S-1-5-21-<DOMAIN-ID>-1105 y -1106 serían, por ejemplo, los SID de los grupos Tier 1 Admins y Tier 2 Admins en tu dominio. Para obtener el SID de un grupo concreto antes de escribirlo en la plantilla:

Get-ADGroup -Identity "Tier 1 Admins" | Select-Object Name,SID

5. Auditoría de grupos privilegiados

Antes de poder segmentar nada, necesitas saber quién está hoy dentro de los grupos que controlan el dominio. La experiencia de campo es constante: estos grupos casi siempre están «sucios», con cuentas de servicio, ex-empleados, consultores puntuales y hasta cuentas de equipo (no de usuario) que nadie recuerda haber añadido.

5.1. Enumerar los grupos privilegiados críticos

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

# Enterprise Admins (solo existe en el dominio raíz del bosque)
Get-ADGroupMember -Identity "Enterprise Admins" -Recursive |
    Select-Object Name, SamAccountName, objectClass

# Schema Admins (solo existe en el dominio raíz del bosque)
Get-ADGroupMember -Identity "Schema Admins" -Recursive |
    Select-Object Name, SamAccountName, objectClass

# Administrators local del propio DC (grupo de dominio "Administrators")
Get-ADGroupMember -Identity "Administrators" -Recursive |
    Select-Object Name, SamAccountName, objectClass

# Account Operators, Backup Operators, Server Operators, Print Operators
# (grupos "operator" con privilegios elevados frecuentemente olvidados)
"Account Operators","Backup Operators","Server Operators","Print Operators" | ForEach-Object {
    Write-Host "== $_ ==" -ForegroundColor Cyan
    Get-ADGroupMember -Identity $_ -Recursive | Select-Object Name, SamAccountName
}

El parámetro -Recursive es imprescindible: expande grupos anidados dentro de grupos anidados. Es habitual encontrar que Domain Admins «solo tiene 3 miembros directos» pero, al expandir un grupo anidado como «TI-Externos», en realidad hay 40 cuentas con ese privilegio, muchas de terceros.

5.2. Detectar cuentas con último logon antiguo dentro de esos grupos (candidatas a limpieza)

Get-ADGroupMember -Identity "Domain Admins" -Recursive |
    Where-Object { $_.objectClass -eq "user" } |
    Get-ADUser -Properties LastLogonTimestamp, Enabled |
    Select-Object Name, SamAccountName, Enabled,
        @{N="LastLogon";E={[DateTime]::FromFileTime($_.LastLogonTimestamp)}} |
    Sort-Object LastLogon

Cualquier cuenta habilitada (Enabled: True) con LastLogon de más de 90 días dentro de un grupo Tier 0 es, como mínimo, sospechosa de «privilegio zombie» y debe revisarse con el propietario del proceso o deshabilitarse.

6. AdminSDHolder y el proceso SDProp

Un concepto que sorprende a quien llega nuevo a AD: los permisos (ACL) de las cuentas y grupos «protegidos» (miembros directos o indirectos de Domain Admins, Enterprise Admins, Schema Admins, Administrators, Account Operators, Backup Operators, Server Operators, Print Operators, y el propio krbtgt) no se heredan de su OU. Un proceso interno del DC llamado SDProp (Security Descriptor Propagator), que corre cada 60 minutos en el PDC Emulator, sobrescribe la ACL de cualquier objeto «protegido» con la definida en un objeto especial: CN=AdminSDHolder,CN=System,DC=<dominio>,DC=<tld>.

Esto existe por diseño defensivo: evita que alguien con permisos delegados sobre una OU (un técnico junior con «Reset password» sobre una OU de usuarios) escale modificando la ACL de una cuenta que resulta ser miembro de Domain Admins. SDProp reafirma cada hora que esas cuentas solo pueden tocarse con permiso en el propio AdminSDHolder.

El problema práctico: cuando sacas una cuenta de un grupo protegido, el atributo adminCount=1 y la ACL heredada no se revierten automáticamente. La cuenta queda «endurecida» para siempre aunque ya no tenga privilegio real — y es también una técnica de persistencia conocida: un atacante puede escribir una ACE propia en AdminSDHolder para que SDProp le reconceda persistencia sobre todas las cuentas protegidas del dominio cada hora.

6.1. Consultar el objeto AdminSDHolder y su ACL

# Ver el objeto AdminSDHolder y su descriptor de seguridad
$domainDN = (Get-ADDomain).DistinguishedName
Get-ADObject -Identity "CN=AdminSDHolder,CN=System,$domainDN" `
    -Properties ntSecurityDescriptor |
    Select-Object -ExpandProperty ntSecurityDescriptor |
    Select-Object -ExpandProperty Access |
    Format-Table IdentityReference, ActiveDirectoryRights, AccessControlType -AutoSize

# Buscar identidades "anómalas" (no built-in) con permisos sobre AdminSDHolder
$domainDN = (Get-ADDomain).DistinguishedName
$acl = Get-Acl "AD:CN=AdminSDHolder,CN=System,$domainDN"
$acl.Access |
    Where-Object { $_.IdentityReference -notmatch "BUILTIN|NT AUTHORITY|SYSTEM|Domain Admins|Enterprise Admins|SELF" } |
    Format-Table IdentityReference, ActiveDirectoryRights, AccessControlType -AutoSize

Cualquier identidad en el resultado de la segunda consulta que no reconozcas como legítima (cuenta de servicio de backup autorizada, herramienta de gestión de identidades aprobada, etc.) es indicio de una puerta trasera de persistencia sobre AdminSDHolder y debe tratarse como incidente de seguridad, no como limpieza rutinaria.

6.2. Localizar cuentas con adminCount=1 «huérfanas» (ya no son admin pero conservan la ACL protegida)

Get-ADUser -Filter {adminCount -eq 1} -Properties adminCount, MemberOf |
    Select-Object Name, SamAccountName, @{N="GruposActuales";E={$_.MemberOf -join "; "}}

Revisa cada resultado: si la cuenta ya no pertenece a ningún grupo protegido, es una candidata a que un administrador restaure manualmente la herencia de permisos (desmarcando «protect from accidental deletion»/ajustando inheritanceEnabled vía Set-ADObject o herramientas como Fix AdminSDHolder / scripts publicados por la comunidad), documentando el cambio.

7. PAW: Privileged Access Workstations

Aunque tengas la segmentación de grupos y GPO perfecta, sigue existiendo un eslabón débil: el propio equipo desde el que el administrador teclea la contraseña. Si ese equipo tiene correo, navegador y Office, y se usa también para tareas cotidianas, es superficie de phishing o malware con persistencia — y en el instante en que la contraseña de Tier 0 se escribe ahí, toda la segmentación de grupos se vuelve irrelevante.

Una PAW (Privileged Access Workstation) es un equipo dedicado en exclusiva a tareas administrativas de un nivel concreto, con estas características:

  • Sin navegación web general (a lo sumo, lista blanca muy reducida de URL de gestión: portal de Entra, GPMC remoto, etc.).
  • Sin cliente de correo, sin Office con macros, sin mensajería: elimina el vector de phishing/documento malicioso.
  • Hardware dedicado: no es una VM ni un portátil compartido con «otro perfil de Windows». Idealmente hardware físico separado, con imagen mínima (Device Guard/Credential Guard, BitLocker, LAPS para su cuenta local).
  • Aplicaciones mínimas: solo RSAT, PowerShell restringido y cliente RDP hacia el jump server correspondiente.
  • Segregada por nivel: una PAW de Tier 0 no es la misma máquina que una de Tier 1. Un administrador de ambos niveles necesita dos PAW físicamente distintas — nunca «un mismo Windows, dos cuentas».

7.1. Arquitectura de referencia paso a paso

  1. Aprovisionamiento aislado: la PAW se instala desde una imagen dorada gestionada por el propio equipo de Tier 0, nunca desde una imagen genérica de escritorio. El aprovisionamiento ocurre en red segmentada, sin Internet salvo actualizaciones firmadas.
  2. Identidad dedicada: el administrador recibe una cuenta t0-usuario distinta de su cuenta diaria usuario. La cuenta t0 no tiene buzón de correo ni licencia Office 365, para que sea técnicamente imposible usarla para navegar o leer correo.
  3. MFA resistente a phishing: FIDO2/Windows Hello for Business con TPM en cada inicio de sesión sobre la PAW.
  4. Red segmentada: VLAN/subred dedicada de administración, con firewall que solo permite tráfico hacia los DC o el jump server correspondiente, bloqueando Internet general y la VLAN de usuarios.
  5. Salto controlado — jump server / bastion host: desde la PAW no se conecta «directamente y para siempre» a cada DC; se conecta a un jump server (bastion, gateway RDP con grabación de sesión) que centraliza y audita cada sesión. El jump server de Tier 0 solo acepta PAW de Tier 0 y solo permite salida hacia activos de Tier 0.
  6. Aplicación de la GPO de aislamiento: sobre los DC y servidores Tier 0, la GPO de la sección 4.1 garantiza que, aunque alguien use la cuenta t0 desde un equipo que no sea la PAW, el logon se deniegue por política, no solo por buenas costumbres.
  7. Monitorización específica: alertas SIEM cuando una cuenta t0-* se autentica desde una IP/hostname fuera del rango de PAW/jump server registrado — un evento que, por definición, nunca debería ocurrir en operación normal.

7.2. PAW vs. jump server: no son lo mismo

Es un error común confundir ambos conceptos. La PAW es el punto de origen: el equipo físico donde el humano teclea la contraseña. El jump server / bastion es el punto de tránsito: el salto intermedio, auditado, desde el que se alcanza el activo administrado. Saltar al jump server desde el portátil de uso diario sigue exponiendo la credencial en un equipo de confianza baja; usar solo PAW sin jump server centralizado pierde la auditoría/grabación de sesión. Ambas capas son complementarias, no sustitutivas.

8. Cuentas de administración dedicadas: la regla que sostiene todo lo demás

Todo lo anterior —niveles, GPO, PAW— se derrumba si un mismo ser humano usa la misma cuenta para leer correo, navegar y administrar el DC. La regla operativa es:

  • Cada administrador tiene, como mínimo, dos identidades: una cuenta de usuario estándar (sin ningún privilegio elevado, ni siquiera admin local de su equipo) y una o varias cuentas administrativas dedicadas por nivel (t0-nombre, t1-nombre).
  • La cuenta administrativa no tiene buzón y su contraseña se gestiona con política más estricta, preferiblemente con un vault de Privileged Access Management que emite credenciales Just-In-Time.
  • Las cuentas t0 nunca se usan en tareas programadas o servicios de Tier 1/2 (evita que queden expuestas en Credential Manager); para eso se usan Group Managed Service Accounts (gMSA), no cuentas humanas.
  • Idealmente, la pertenencia a Tier 0 Admins se activa Just-In-Time (PAM de AD, o PIM de Entra ID en cloud), no de forma permanente.

9. Laboratorio: crear los grupos de negación y aplicar una GPO de aislamiento de Tier 0

Requisitos: un laboratorio aislado con al menos un Domain Controller Windows Server (2019/2022) y GPMC disponible, más un equipo miembro de prueba que simule un servidor Tier 1. No realices este laboratorio contra un dominio de producción.

Paso 1 — Crear la estructura de OU y los grupos de nivel

# Ejecutar en el DC del laboratorio, con el módulo ActiveDirectory cargado
Import-Module ActiveDirectory

$domainDN = (Get-ADDomain).DistinguishedName

# OU raíz para la administración por niveles
New-ADOrganizationalUnit -Name "Admin" -Path $domainDN -ProtectedFromAccidentalDeletion $true
New-ADOrganizationalUnit -Name "Tier 0" -Path "OU=Admin,$domainDN" -ProtectedFromAccidentalDeletion $true
New-ADOrganizationalUnit -Name "Tier 1" -Path "OU=Admin,$domainDN" -ProtectedFromAccidentalDeletion $true
New-ADOrganizationalUnit -Name "Tier 2" -Path "OU=Admin,$domainDN" -ProtectedFromAccidentalDeletion $true
New-ADOrganizationalUnit -Name "Groups" -Path "OU=Admin,$domainDN" -ProtectedFromAccidentalDeletion $true

# Grupos de nivel (seguridad, ámbito global)
New-ADGroup -Name "Tier 0 Admins" -GroupScope Global -GroupCategory Security `
    -Path "OU=Groups,OU=Admin,$domainDN" -Description "Cuentas con privilegios de control de identidad (Tier 0)"
New-ADGroup -Name "Tier 1 Admins" -GroupScope Global -GroupCategory Security `
    -Path "OU=Groups,OU=Admin,$domainDN" -Description "Cuentas de administracion de servidores/aplicaciones (Tier 1)"
New-ADGroup -Name "Tier 2 Admins" -GroupScope Global -GroupCategory Security `
    -Path "OU=Groups,OU=Admin,$domainDN" -Description "Cuentas de soporte de puesto de trabajo (Tier 2)"

Write-Host "OU y grupos creados correctamente." -ForegroundColor Green

Paso 2 — Crear una cuenta de prueba t0 y añadirla al grupo correspondiente

New-ADUser -Name "t0-labadmin" -SamAccountName "t0-labadmin" `
    -UserPrincipalName "t0-labadmin@$((Get-ADDomain).DNSRoot)" `
    -Path "OU=Tier 0,OU=Admin,$((Get-ADDomain).DistinguishedName)" `
    -AccountPassword (Read-Host -AsSecureString "Introduce contrasena temporal segura") `
    -Enabled $true -ChangePasswordAtLogon $true

Add-ADGroupMember -Identity "Tier 0 Admins" -Members "t0-labadmin"

Paso 3 — Crear la GPO de aislamiento de Tier 0

Import-Module GroupPolicy

New-GPO -Name "T0-Isolation-DenyLogon" -Comment "Niega logon de cuentas Tier1/Tier2 en activos Tier 0"

# Vincular a la OU de Domain Controllers (ajustar el DN si tu OU tiene otro nombre)
$domainDN = (Get-ADDomain).DistinguishedName
New-GPLink -Name "T0-Isolation-DenyLogon" -Target "OU=Domain Controllers,$domainDN" -LinkEnabled Yes

Los cuatro derechos de «Deny log on…» no tienen cmdlet nativo directo en el módulo GroupPolicy de PowerShell (no existe un Set-GPUserRightsAssignment estándar hasta versiones muy recientes de RSAT); en el laboratorio, complétalos manualmente vía consola gráfica:

  1. Abre Group Policy Management Console (GPMC), clic derecho sobre T0-Isolation-DenyLogon → Edit.
  2. Navega a Computer Configuration → Policies → Windows Settings → Security Settings → Local Policies → User Rights Assignment.
  3. Abre «Deny log on locally», marca Define these policy settings, y con Add User or Group añade Tier 1 Admins y Tier 2 Admins.
  4. Repite el mismo procedimiento para «Deny log on through Remote Desktop Services», «Deny log on as a batch job» y «Deny log on as a service», con los mismos dos grupos.
  5. Cierra el editor de GPO.

Paso 4 — Forzar la aplicación y verificar

# En el DC (o en el servidor de prueba dentro de la OU vinculada)
gpupdate /force

# Verificar que la politica se aplico correctamente
gpresult /r /scope computer

# Ver el resultado detallado en HTML para inspeccionar User Rights Assignment
gpresult /h C:Tempgpresult-t0.html /f

Paso 5 — Prueba de contención

Crea una cuenta de prueba t2-labuser, añádela al grupo Tier 2 Admins, e intenta iniciar sesión (RDP o consola) en el propio DC del laboratorio con esa cuenta. El resultado esperado es un rechazo explícito de logon («The local policy of this system does not permit you to logon interactively» o el mensaje equivalente en RDP). Si el logon tiene éxito, revisa: (a) que la GPO esté correctamente vinculada y no bloqueada por herencia (Get-GPInheritance -Target "OU=Domain Controllers,$domainDN"), (b) que hayas ejecutado gpupdate /force en el equipo de destino, y (c) que la cuenta de prueba pertenezca realmente al grupo esperado (Get-ADGroupMember "Tier 2 Admins").

10. Errores comunes

  • Usar la misma cuenta para todo. El error número uno. Un administrador que lee su correo, navega por proveedores, y administra el DC con la misma cuenta DOMINIOjperez convierte cualquier phishing exitoso contra él en un compromiso total del dominio en minutos.
  • Administrar el DC desde el portátil de uso diario. Incluso con una cuenta t0 «correcta», si el RDP hacia el DC se lanza desde el mismo portátil con Outlook y Chrome, la separación de cuentas no protege frente a un keylogger o un secuestro de sesión en ese endpoint.
  • Crear los grupos de Tier pero no aplicar nunca la GPO de negación. La segmentación «solo organizativa» no detiene a nadie; es responsabilidad del auditor comprobar que la GPO está realmente vinculada, sin bloqueo de herencia y sin excepciones injustificadas.
  • Dejar cuentas de servicio o de terceros dentro de Domain Admins «porque siempre ha sido así». Las auditorías de campo encuentran sistemáticamente integraciones (backup, monitorización) que pidieron Domain Admins por comodidad y nunca se sustituyeron por una delegación mínima.
  • No dar servicio a la cuenta de break-glass. Debe existir al menos una cuenta de emergencia con contraseña larga, custodiada físicamente y excluida de MFA por diseño para fallos totales de autenticación — pero su uso debe generar alerta inmediata y no es excusa para relajar el resto del modelo.
  • Confundir jump server con PAW, asumiendo que tener un bastion host ya resuelve el problema aunque los administradores sigan iniciando esas sesiones desde su equipo de escritorio habitual.
  • Olvidar el AdminSDHolder al limpiar grupos. Sacar una cuenta de Domain Admins sin revertir su adminCount y su ACL heredada deja un rastro de privilegio «fantasma» que confunde auditorías futuras y puede ser aprovechado si esa cuenta se reactiva sin revisión.

11. Ejercicio

En tu laboratorio de Active Directory (no en producción):

  1. Enumera con Get-ADGroupMember -Recursive los miembros actuales de Domain Admins, Enterprise Admins y Administrators, y clasifícalos en una tabla propia: cuenta humana / cuenta de servicio / cuenta de equipo / desconocida.
  2. Diseña, en un documento, tu propia convención de nomenclatura de cuentas por nivel (por ejemplo t0-, t1-, t2-) y de grupos (Tier 0 Admins, etc.), adaptada a las siglas de tu organización ficticia.
  3. Crea las OU, grupos y la GPO de negación siguiendo el laboratorio de la sección 9, y documenta con capturas el resultado del intento de logon denegado.
  4. Consulta el objeto AdminSDHolder de tu laboratorio y localiza al menos una cuenta con adminCount=1; investiga si sigue perteneciendo a un grupo protegido o si es candidata a limpieza.
  5. Redacta, en no más de una página, una propuesta de arquitectura de PAW para un entorno ficticio de 5 administradores de Tier 0 y 15 de Tier 1, indicando hardware, red y controles de MFA propuestos.

Preguntas frecuentes

¿El modelo de niveles solo aplica a grandes empresas con cientos de servidores?

No. El principio de contención es independiente del tamaño. Una pyme con un único DC y cinco servidores puede (y debería) tener al menos una cuenta t0 dedicada distinta de la cuenta de correo del responsable de TI, y una GPO básica de «Deny log on» en el DC para cualquier cuenta que no sea esa. La versión completa con PAW físicas dedicadas y jump servers redundantes es donde el coste sí crece con el tamaño, y ahí se aplica de forma proporcional al riesgo y al presupuesto.

¿Windows Hello for Business o Credential Guard sustituyen la necesidad de una PAW?

No, son complementarios. Credential Guard dificulta la extracción de hashes NTLM/tickets Kerberos de LSASS en el propio equipo donde se ejecuta, y Windows Hello for Business elimina la contraseña como factor transmitido en red. Pero ninguno de los dos evita que un administrador abra un documento malicioso en su equipo de uso diario y ese malware capture pulsaciones de teclado, secuestre la sesión activa, o pivote lateralmente antes de que la credencial se use. La PAW ataca la superficie de exposición (qué se puede ejecutar en ese equipo), no solo la protección criptográfica de la credencial una vez capturada.

¿Qué diferencia hay entre el modelo de niveles y simplemente tener un «grupo de administradores» con MFA?

El MFA protege el factor de autenticación; el modelo de niveles protege la topología de exposición. Puedes tener MFA perfecto en tu cuenta de Domain Admins y aun así comprometer el dominio si esa cuenta, ya autenticada con MFA, se usa interactivamente en un equipo de usuario infectado: el atacante no necesita romper el MFA, solo robar el token de sesión o el ticket Kerberos ya emitido desde la memoria de ese equipo. Son controles en capas distintas y ambos son necesarios.

¿Es obligatorio implementar el Enterprise Access Model completo, con sus tres planos, o basta con el Tiering clásico de tres niveles?

Microsoft documenta el EAM como sucesor oficial del Tiering clásico, sobre todo porque incorpora de forma nativa el control plane de Entra ID e identidad híbrida. Para un entorno puramente on-premises, aplicar rigurosamente el Tiering clásico (Tier 0/1/2) sigue dando la contención correcta. Si sincronizas identidades a Entra ID o usas SSO federado, extiende el análisis al Control Plane del EAM, tratando Entra Connect y los roles administrativos de Entra con el mismo rigor que un controlador de dominio.

¿Qué pasa si un DC necesita mantenimiento por parte de un proveedor externo?

El proveedor externo no debe recibir nunca una cuenta de dominio con privilegios de Tier 0 salvo excepción documentada, temporal y supervisada. El patrón correcto: acceso físico/consola fuera de banda (iDRAC/iLO con su propia autenticación, no de dominio) para tareas de hardware, o una cuenta t0 temporal creada solo para la ventana de mantenimiento, deshabilitada justo después, con la sesión supervisada por un administrador interno desde su propia PAW. Nunca se comparte la cuenta t0 habitual de un administrador interno con un tercero.

«Tier 0 assets require the highest level of protection because compromise of these assets would immediately and irrevocably lead to enterprise compromise. […] Administrative accounts for Tier 0 should never be used to log on to systems in Tier 1 or Tier 2, as this would expose the highest privilege credentials to lower trust systems.»

— Microsoft, «Securing privileged access» / «Enterprise access model», Microsoft Learn (learn.microsoft.com/security/privileged-access-workstations, learn.microsoft.com/security/compass/privileged-access-access-model).