¿Se sigue recomendando el modelo por niveles ahora que Microsoft habla del modelo de acceso empresarial?

Sí. El modelo de acceso empresarial extiende el modelo por niveles a los planos de control de la nube y del SaaS, pero la regla central no cambia: las credenciales de un plano más privilegiado nunca deben exponerse en un sistema de menor confianza. Para Active Directory local, la separación Tier 0 / 1 / 2 sigue siendo la forma práctica de aplicarlo.

¿Puedo añadir cuentas de servicio a Protected Users?

No. Protected Users desactiva NTLM, la delegación y los tickets Kerberos de larga duración para sus miembros. Las cuentas de servicio y las cuentas de equipo dejarán de funcionar. Para los servicios, usa cuentas de servicio administradas de grupo (gMSA).

¿Cuál es la mejora más rápida si todavía no puedo implantar el modelo por niveles completo?

Saca de Domain Admins las cuentas de uso diario, crea cuentas de administración separadas, añádelas a Protected Users y deniégales el inicio de sesión en los puestos de trabajo mediante GPO. Solo con eso se corta la vía de robo de credenciales más habitual.

Modelo por niveles y Protected Users en Active Directory

La mayoría de los compromisos de Active Directory siguen el mismo camino. Un atacante llega a un puesto de trabajo, encuentra en memoria una credencial privilegiada porque un administrador inició sesión allí y la reutiliza hasta alcanzar un controlador de dominio. Credential Guard, el EDR y LAPS lo dificultan, pero la causa raíz es de arquitectura: se expusieron credenciales muy privilegiadas en una máquina que un usuario corriente puede comprometer.

El modelo por niveles elimina esa exposición. Su regla es breve: una cuenta solo puede iniciar sesión en sistemas de su propio nivel. Un Domain Admin nunca escribe su contraseña en un puesto de trabajo, un administrador de servidores nunca inicia sesión en el portátil de un usuario y las cuentas de soporte técnico nunca tocan los servidores. Esta guía convierte esa regla en directivas de grupo, pertenencias a grupos y comprobaciones.

Los tres niveles

Nivel	Qué contiene	Quién lo administra
Tier 0	Controladores de dominio, el propio AD DS, AD CS (PKI), AD FS, servidores de Microsoft Entra Connect / Cloud Sync, la plataforma de virtualización o de copia de seguridad que aloja los DC y cualquier sistema que tenga control sobre ellos	Un puñado de cuentas de administración de Tier 0, usadas solo desde estaciones de administración de Tier 0
Tier 1	Servidores miembro y aplicaciones: servidores de archivos, SQL, web y de aplicaciones	Cuentas de administración de servidores, desde jump hosts o estaciones de administración de Tier 1
Tier 2	Puestos de trabajo, portátiles, dispositivos de usuario, impresoras	Cuentas de soporte técnico / administración de puestos

Lo más difícil es ser honesto con el Tier 0. Todo lo que puede controlar un activo de Tier 0 es Tier 0: el clúster de hipervisores que ejecuta DC virtuales, el servidor de copias que puede restaurar NTDS.dit, la herramienta de distribución de software con un agente en los DC, el agente de supervisión que se ejecuta como SYSTEM en los DC. Si el servidor de sitio de SCCM distribuye software a los controladores de dominio, SCCM es Tier 0.

Microsoft describe ahora un modelo de acceso empresarial más amplio, con planos de control, de administración, de datos/cargas de trabajo, de acceso de usuarios y de acceso de aplicaciones, que extiende la misma idea a Entra ID y a las cargas de trabajo en la nube. En AD local, los tres niveles son la forma de implementarlo.

Paso 1: separar las cuentas

Cada administrador recibe una cuenta por nivel en el que trabaja, además de su cuenta de usuario normal:

jdoe: correo, navegación, Office. Sin derechos de administración en ningún sitio.
adm-t2-jdoe: administrador local en los puestos de trabajo (idealmente mediante LAPS y no por pertenencia a grupo).
adm-t1-jdoe: administrador en los servidores miembro.
adm-t0-jdoe: Domain Admins o derechos de Tier 0 delegados. Solo unas pocas personas.

Crea una estructura de OU que refleje los niveles (Admin\Tier0, Admin\Tier1, Admin\Tier2, cada una con Accounts, Groups, Devices) para que las GPO y la delegación puedan dirigirse a cada nivel de forma limpia.

Después reduce los grupos privilegiados. Comprueba quién está realmente en ellos, incluidas las pertenencias anidadas:

PowerShell

foreach ($g in "Domain Admins","Enterprise Admins","Schema Admins","Administrators",
               "Account Operators","Server Operators","Backup Operators","Print Operators") {
  Get-ADGroupMember -Identity $g -Recursive |
    Select-Object @{n="Group";e={$g}}, SamAccountName, objectClass
}

Account Operators, Server Operators, Backup Operators y Print Operators tienen caminos hacia el compromiso de un controlador de dominio. Deben estar vacíos. Schema Admins y Enterprise Admins deben estar vacíos salvo durante cambios planificados.

Paso 2: imponer las restricciones de inicio de sesión con GPO

El modelo por niveles solo funciona si se impone, no si solo se documenta. Usa User Rights Assignment en Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies, aplicado por OU de nivel:

GPO vinculada a	Deny log on locally	Deny log on through Remote Desktop Services	Deny access to this computer from the network	Deny log on as a batch job / as a service
Puestos de trabajo (Tier 2)	Grupos de administración de Tier 0 y Tier 1	Grupos de administración de Tier 0 y Tier 1	Grupos de administración de Tier 0 y Tier 1	Grupos de administración de Tier 0 y Tier 1
Servidores miembro (Tier 1)	Grupos de administración de Tier 0	Grupos de administración de Tier 0	Grupos de administración de Tier 0	Grupos de administración de Tier 0
Controladores de dominio (Tier 0)	Grupos de administración de Tier 1 y Tier 2	Grupos de administración de Tier 1 y Tier 2	(normalmente no se deniega: los DC deben aceptar inicios de sesión de red de todos)	Grupos de administración de Tier 1 y Tier 2

Los derechos de denegación prevalecen sobre los de concesión, así que esto se mantiene aunque alguien añada adm-t0-jdoe al grupo Administrators local de un puesto de trabajo. Incluye los grupos integrados Domain Admins y Enterprise Admins en las listas de denegación de Tier 0 de los puestos de trabajo y los servidores miembro.

Una observación sobre el inicio de sesión de red: denegar el acceso desde la red a las cuentas de Tier 0 en los servidores bloquea la administración remota por SMB, WinRM y similares con esas cuentas, que es justamente el objetivo. Prueba primero con una OU piloto, porque algunas herramientas de administración heredadas dependen de que un Domain Admin inicie sesión en todas partes.

Paso 3: poner a las personas de Tier 0 en Protected Users

Protected Users es un grupo de seguridad global integrado (Windows Server 2012 R2 y posteriores) que aplica a sus miembros protecciones no configurables. En dispositivos con Windows 10 / Windows 11 o Windows Server 2012 R2 o posterior, y con el nivel funcional de dominio en Windows Server 2012 R2 o superior para las protecciones del controlador de dominio:

Se rechaza la autenticación NTLM, así que no hay hash NTLM que robar ni retransmitir.
Kerberos no usará DES ni RC4 para la preautenticación.
La cuenta no se puede delegar (ni con delegación restringida ni sin restricciones).
La duración del TGT se limita a cuatro horas en lugar de diez.
Las credenciales no se almacenan en caché: ni verificador de inicio de sesión en caché, ni texto en claro de CredSSP o WDigest, ni claves de largo plazo en memoria.

Añade todas las cuentas de administración humanas de Tier 0 y Tier 1. No añadas cuentas de servicio, cuentas de equipo ni tu cuenta de emergencia (break-glass), que debe funcionar cuando Kerberos no funciona. Prueba antes: todo lo que autentique estas cuentas con NTLM, por ejemplo un appliance de administración que se conecta por dirección IP, dejará de funcionar, lo que suele ser un hallazgo en sí mismo.

Para las cuentas que no puedan entrar en Protected Users, marca al menos Account is sensitive and cannot be delegated en el objeto de la cuenta.

PowerShell

Add-ADGroupMember -Identity "Protected Users" -Members adm-t0-jdoe, adm-t1-jdoe
Get-ADUser -Filter {AdminCount -eq 1} -Properties AccountNotDelegated |
  Select-Object SamAccountName, AccountNotDelegated

Paso 4: administrar desde el lugar adecuado

Las restricciones de inicio de sesión indican adónde no puede ir una cuenta de administración; también necesitas un lugar seguro al que sí pueda ir. Una estación de trabajo de acceso privilegiado (PAW) es un dispositivo endurecido que solo se usa para administrar: sin correo, sin navegación, con control de aplicaciones estricto, Credential Guard activado y administrado desde su propio nivel. Para el Tier 0 es innegociable. Para el Tier 1, los servidores de salto endurecidos son un término medio habitual.

Cuando tengas que conectarte por RDP desde un dispositivo de menor confianza, usa Remote Credential Guard (mstsc /remoteGuard) o el modo Restricted Admin (mstsc /restrictedAdmin) para que no se envíen credenciales reutilizables al host remoto. En general se prefiere Remote Credential Guard, porque mantiene las solicitudes Kerberos en el lado del cliente y aun así te permite acceder a los recursos de red con tu propia identidad.

Paso 5: directivas y silos de autenticación (opcional)

Para una imposición más fuerte que la de los derechos de usuario, las directivas y silos de autenticación de Active Directory (nivel funcional de dominio 2012 R2 o superior) restringen dónde pueden obtener tickets Kerberos las cuentas de Tier 0, y es el propio controlador de dominio quien lo comprueba. Por ejemplo, los miembros de un silo "Tier0" solo reciben un TGT cuando inician sesión desde equipos de ese silo. Requiere el blindaje de Kerberos (FAST) y pruebas cuidadosas, pero cierra huecos que los derechos de denegación por GPO no pueden cerrar, como una cuenta de Tier 0 usada desde un dispositivo no administrado.

Verificarlo

¿Dónde han iniciado sesión las cuentas de Tier 0? En los controladores de dominio, los eventos 4768 (TGT solicitado) y 4769 (ticket de servicio solicitado) muestran la dirección del cliente; en los sistemas miembro, el 4624 con tipo de inicio de sesión 2 (interactivo), 10 (interactivo remoto) o 3 (red) muestra dónde se usaron las cuentas. Genera un informe de las cuentas de Tier 0 que se autentican desde cualquier equipo que no sea un DC o una PAW; debería estar vacío.
¿Es efectivo Protected Users? En un DC, el registro Applications and Services Logs > Microsoft > Windows > Authentication anota los errores de los miembros de Protected Users (los registros ProtectedUserFailures-DomainController y ProtectedUserSuccesses-DomainController en los DC, y ProtectedUser-Client en los clientes, están deshabilitados de forma predeterminada; habilítalos primero). Los intentos NTLM de los miembros aparecen como errores.
¿Hay caminos ocultos? Herramientas como BloodHound (Community Edition) o PingCastle cartografían rutas de ataque a través de ACL, anidamiento de grupos y delegación. Ejecútalas con regularidad: un modelo por niveles sobre el papel suele tener fugas por una ACL antigua en una OU o una GPO editable por un grupo de Tier 1.

Lista de comprobación

Lista de activos de Tier 0 por escrito, incluidos hipervisores, copias de seguridad, PKI y servidores de sincronización
Cuentas de administración separadas por nivel, sin derechos de administración en las cuentas de uso diario
Grupos Operators vacíos; Schema/Enterprise Admins vacíos de forma predeterminada
GPO de denegación de inicio de sesión en puestos de trabajo, servidores miembro y DC
Cuentas privilegiadas humanas en Protected Users; el resto marcadas como "sensibles y no delegables"
PAW para el Tier 0; Remote Credential Guard para RDP
Informe mensual de inicios de sesión de Tier 0 fuera del Tier 0
Revisión periódica de rutas de ataque (BloodHound CE / PingCastle)

El modelo por niveles es más trabajo organizativo que técnico, y por eso se suele saltar. Combínalo con contraseñas de administrador local únicas y Credential Guard, y un solo portátil víctima de phishing dejará de ser un camino hacia tus controladores de dominio.