Directivas de autenticación y silos Active Directory, Tier 0: qué son realmente
La protección mediante directivas de autenticación y silos de Active Directory Tier 0 es una única función de Windows Server 2012 R2 que la mayoría de los entornos todavía no ha activado, incluso una década después de su lanzamiento. Un silo de directiva de autenticación es un contenedor de AD (objectClass msDS-AuthNPolicySilos) que agrupa las cuentas de usuario, equipo y servicio que se quieren proteger juntas. Una directiva de autenticación (objectClass msDS-AuthNPolicies) es el conjunto de reglas aplicado a ese contenedor: cuánto puede vivir un ticket Kerberos (TGT, ticket-granting ticket), desde qué dispositivos se permite iniciar sesión a una cuenta, y qué principales pueden autenticarse ante un servicio que se ejecuta bajo esa cuenta.
La idea es sencilla: tus cuentas de Domain Admins solo deberían autenticarse desde un puñado de estaciones de administración privilegiadas (PAW) y controladores de dominio. Las directivas de autenticación y los silos son el mecanismo que convierte esa suposición en algo que el KDC realmente hace cumplir, en lugar de una regla que solo vive en un documento de onboarding.
Las cuentas solo pueden pertenecer a un silo. Una vez asignada, el controlador de dominio adjunta una notificación de silo de directiva de autenticación al ticket Kerberos de la cuenta al iniciar sesión, notificación que los recursos compatibles pueden usar para sus propios controles de acceso, además de lo que la directiva del silo ya restringe.
El propio ejemplo de Microsoft es una buena ilustración de la intención: crear un silo "Administradores de bosque" que contenga las cuentas de Enterprise Admins, Schema Admins y Domain Admins, y luego adjuntar una directiva para que el inicio de sesión mediante contraseña o tarjeta inteligente desde cualquier cosa que no sea un controlador de dominio o una consola de administración designada falle sin más. Al silo no le importa cómo se obtuvo la credencial —mediante phishing, repetición, o tecleada correctamente por el administrador real— solo le importa si el dispositivo de origen está en la lista permitida.
Un mismo silo puede contener las tres clases de cuentas de Active Directory —usuario, equipo y cuenta de servicio administrada— pero la directiva se comporta de forma distinta según la clase. Las cuentas de servicio y equipo nunca deberían unirse al grupo Protected Users: el motivo que da Microsoft es que toda autenticación entrante falla para esos tipos de cuenta, y la pertenencia no les aporta ninguna protección local de todos modos porque la contraseña o el certificado siempre están presentes en el host. Microsoft también recomienda no configurar una vigencia de TGT para cuentas de equipo. La distinción por tipo de cuenta importa tanto como la pertenencia al silo en sí.
Cómo funciona: vigencia del TGT, notificaciones y el requisito de blindaje
Las directivas de autenticación actúan en dos puntos del intercambio Kerberos: el intercambio AS (inicio de sesión inicial, emisión del TGT) y el intercambio TGS (solicitudes de ticket de servicio). Se pueden restringir tres cosas:
- Vigencia del TGT — fijada a un valor más corto y no renovable que el predeterminado del dominio (4 horas es lo que obtienen automáticamente los miembros del grupo Protected Users). Una cuenta Tier 0 con un TGT no renovable de 1 hora deja una ventana mucho más pequeña a un atacante que roba un ticket.
AllowedToAuthenticateFrom— el conjunto de dispositivos desde los que un usuario puede iniciar sesión. Se aplica en el intercambio AS.AllowedToAuthenticateTo— el conjunto de principales autorizados a autenticarse ante un servicio que se ejecuta bajo esta cuenta. Se aplica en el intercambio TGS.
Las restricciones de dispositivo son donde se atascan la mayoría de los despliegues. Comprobar AllowedToAuthenticateFrom requiere blindaje Kerberos (FAST): el KDC necesita el propio TGT del dispositivo solicitante para validar su identidad antes de poder decidir si ese dispositivo está en la lista permitida. Las dos directivas de grupo que activan el blindaje llegan como No configurada en un dominio predeterminado —lo hemos cubierto por separado— así que en un dominio sin modificar, la restricción de inicio de sesión simplemente no funciona en silencio, aunque la restricción de vigencia del TGT sí siga funcionando. Es un requisito previo aquí, no un endurecimiento opcional adicional.
Todo silo de directiva de autenticación empieza en modo solo auditoría — el equivalente en PowerShell de -WhatIf. El modo auditoría registra lo que fallaría sin bloquear nada, que es la forma prevista de rodar una directiva antes de que un administrador se bloquee a sí mismo fuera de su propio dominio.
Por qué este control sigue sin usarse en la mayoría de las arquitecturas Tier 0
Tres puntos de fricción explican por qué las directivas de autenticación y los silos rara vez salen de la fase piloto, incluso en entornos que por lo demás se toman en serio la administración por tiers.
Un nivel funcional de dominio que nadie revisita
Las vigencias de TGT personalizadas necesitan el nivel funcional de dominio Windows Server 2012 R2 en el dominio de cuenta. Restringir el inicio de sesión de usuario necesita ese mismo DFL en el dominio de cuenta con compatibilidad de control de acceso dinámico, además de dispositivos cliente que a su vez admitan control de acceso dinámico. Restringir la emisión de tickets de servicio es un requisito del dominio de recurso, que debe estar en DFL 2012 R2 por derecho propio, así que una arquitectura Tier 0 entre dominios tiene dos niveles funcionales que comprobar, no uno. Muchos dominios elevaron su DFL hace años por un motivo no relacionado —una migración de confianza de bosque, una extensión de esquema para otro proyecto— y nunca volvieron a preguntarse qué más desbloqueaba ese nivel funcional. Los silos de directiva de autenticación quedan en esa lista sin usar porque nada empuja a un administrador a buscarlos.
Sin excepciones ni forma de saltárselo
Una vez que una cuenta cae bajo las restricciones de autenticación, no hay forma de sortearlas: un Domain Admin bloqueado por un silo aplicado queda bloqueado, punto (aparte del RID 500). Microsoft formula su versión más contundente de esta advertencia sobre el grupo Protected Users en lugar de sobre los silos, pero el modo de fallo es el mismo: las restricciones de autenticación no tienen solución alternativa, los Enterprise Admins y Domain Admins están sujetos a ellas como cualquier otro, y añadir a todos los miembros de esos grupos de golpe puede bloquearlos a todos, incluidas las cuentas que normalmente resolverían el problema. La guía propia de Microsoft para directivas de autenticación y silos es procedimental más que tranquilizadora: mantener los clientes y los controladores de dominio conectados a la red, rotar las contraseñas de las cuentas protegidas después, y deshabilitar el inicio de sesión en caché donde sea posible. Ese perfil de riesgo basta para que la mayoría de los equipos se detengan en un piloto de una o dos cuentas de prueba y nunca avancen más.
La dependencia del blindaje
Obtener valor real de las restricciones de dispositivo requiere que el blindaje Kerberos ya esté funcionando, y el propio blindaje es un cambio de GPO independiente en controladores de dominio y clientes que la mayoría de los equipos no ha hecho —ver el requisito anterior. Pilotar directivas de autenticación sin blindaje antes equivale a pilotar una función que, en silencio, hace solo la mitad de lo que se supone que debe hacer.
Nada de esto es motivo para saltárselo. Un TGT acortado y no renovable en cuentas Tier 0 reduce directamente la ventana para un ticket robado: el caso de pass-the-ticket, donde un atacante extrae un TGT legítimo de la memoria y lo repite mientras sigue siendo válido.
Hay que ser precisos sobre lo que no cubre. Una directiva de autenticación da forma al ticket que el KDC emite: el controlador de dominio devuelve un TGT no renovable con la vigencia configurada al responder a una solicitud AS, y comprueba la restricción de inicio de sesión contra la solicitud AS blindada. Un Golden Ticket se forja fuera de línea con la clave krbtgt y nunca pasa por un intercambio AS, así que lleva la vigencia y la identidad que el atacante haya elegido: la vigencia del TGT del silo y su restricción de inicio de sesión no tienen ningún poder sobre él. Lo que sí puede morder a un ticket forjado es la comprobación del lado TGS: un servicio cuya cuenta lleva una condición AllowedToAuthenticateTo se evalúa cuando se solicita el ticket de servicio, no cuando se emitió el TGT. Incluso eso tiene un límite: sigue siendo una comprobación del lado del KDC, y un Silver Ticket se forja contra la propia clave del servicio y se presenta directamente al host sin que el controlador de dominio sea consultado nunca, así que ninguna directiva de autenticación lo ve jamás.
Configurar un silo de directiva de autenticación
La guía completa está en la guía de Microsoft para configurar cuentas protegidas; en resumen:
1. Activar el blindaje Kerberos
Mediante directiva de grupo, en controladores de dominio y clientes:
Configuración del equipo > Plantillas administrativas > Sistema > KDC
"Compatibilidad del cliente del Centro de distribución de claves (KDC) con notificaciones,
autenticación compuesta y blindaje Kerberos" → Habilitada, "Proporcionar notificaciones siempre"
Configuración del equipo > Plantillas administrativas > Sistema > Kerberos (clientes)
"Compatibilidad del cliente Kerberos con notificaciones, autenticación compuesta
y blindaje Kerberos" → Habilitada
Confirma con un inicio de sesión de prueba desde un cliente unido al dominio antes de tocar ninguna directiva: los fallos de blindaje son silenciosos si no, y no querrás depurar dos funciones nuevas a la vez.
2. Crear la directiva de autenticación
Establecer una vigencia de TGT en minutos:
New-ADAuthenticationPolicy -Name "Tier0-AdminPolicy" `
-UserTGTLifetimeMins 60 `
-Description "Cuentas admin Tier 0 - TGT no renovable de 1h"
3. Crear el silo — no aplicado por defecto
New-ADAuthenticationPolicySilo -Name "Tier0-Silo"
Todo silo nuevo empieza en modo auditoría. Añade -Enforce solo cuando el periodo de auditoría esté limpio: es el equivalente integrado de -WhatIf, y está ahí precisamente para que un error tipográfico en una condición de control de acceso no bloquee la cuenta que habría podido arreglarlo.
4. Conceder acceso y asignar cuentas
Grant-ADAuthenticationPolicySiloAccess -Identity "Tier0-Silo" -Account "da-jsmith"
Get-ADUser -Filter 'Name -like "da-*"' |
Set-ADAccountAuthenticationPolicySilo -AuthenticationPolicySilo "Tier0-Silo" `
-AuthenticationPolicy "Tier0-AdminPolicy"
Una cuenta debe recibir acceso al silo y tener asignado el par silo/directiva a la vez: conceder solo el acceso no inscribe la cuenta.
5. Rodar y luego aplicar
Set-ADAuthenticationPolicySilo -Identity "Tier0-Silo" -Enforce $true
Set-ADAuthenticationPolicy -Identity "Tier0-AdminPolicy" -Enforce $true
El silo y la directiva llevan cada uno su propio indicador Enforce: cambiar solo uno deja el otro en modo auditoría, lo que es una fuente habitual de confusión del tipo "por qué esto no bloqueó nada" durante el despliegue.
Detección
Los eventos viven en un registro operativo deshabilitado por defecto: habilitarlo es el paso cero para que todo esto sea visible:
Visor de eventos > Registros de aplicaciones y servicios > Microsoft > Windows >
Authentication > AuthenticationPolicyFailures-DomainController → Habilitar registro
| Indicador | Event ID | Registro | Descripción |
|---|---|---|---|
| Inicio de sesión NTLM rechazado | 101 | AuthenticationPolicyFailures-DomainController | La autenticación NTLM falló porque la directiva de autenticación de la cuenta exige comprobaciones que NTLM no puede satisfacer |
| TGT Kerberos denegado (aplicado) | 105 | AuthenticationPolicyFailures-DomainController | Se rechazó una solicitud de TGT porque el dispositivo solicitante no cumplió la restricción de inicio de sesión del silo |
| TGT Kerberos se habría denegado (auditoría) | 305 | AuthenticationPolicyFailures-DomainController | Equivalente en modo auditoría de 105: la señal a vigilar durante el rodaje antes de aplicar |
| Ticket de servicio Kerberos denegado (aplicado) | 106 | AuthenticationPolicyFailures-DomainController | Se rechazó una solicitud TGS: el usuario, el dispositivo, o ambos, no cumplían la condición allowed-to-authenticate-to de la cuenta de servicio |
| Ticket de servicio Kerberos se habría denegado (auditoría) | 306 | AuthenticationPolicyFailures-DomainController | Equivalente en modo auditoría de 106 |
Un pico de 105/106 después de que un silo pase de auditoría a aplicado es o bien un bloqueo legítimo que hay que corregir (un PAW que aún no está en la lista permitida), o bien un intento real de usar una credencial Tier 0 desde donde no debería: ambos casos merecen una alerta.
Remediación (Remediation)
- Inventaría las cuentas Tier 0 y el conjunto exacto de hosts desde los que deberían poder autenticarse alguna vez (PAW, controladores de dominio: nada más).
- Activa el blindaje Kerberos mediante GPO en los controladores de dominio y los clientes elegibles para Tier 0; confirma con un inicio de sesión de prueba antes de tocar ninguna directiva.
- Crea la directiva de autenticación y el silo en modo auditoría; déjalos sin aplicar durante al menos un ciclo operativo completo.
- Habilita el registro
AuthenticationPolicyFailures-DomainControllery revisa los eventos 305/306 en busca de falsos positivos: PAW que faltan, jump hosts olvidados. - Aplica el silo y la directiva. Rota inmediatamente la contraseña de cada cuenta inscrita.
- Combina esto con la pertenencia al grupo Protected Users para las cuentas que no necesiten delegación Kerberos: Protected Users además bloquea NTLM, la preautenticación DES/RC4, y tanto la delegación restringida como la no restringida sin excepción. Nunca añadas cuentas de servicio o de equipo a Protected Users: toda autenticación entrante falla para esos tipos de cuenta.
Cómo detecta esto EtcSec
La auditoría de Active Directory de EtcSec señala la ausencia de este control desde varios ángulos en lugar de con una única comprobación: NOT_IN_PROTECTED_USERS detecta cuentas privilegiadas fuera del grupo Protected Users, WEAK_KERBEROS_POLICY marca un dominio cuya vigencia máxima de ticket sigue por encima de 10 horas o cuya ventana de renovación supera los 7 días, FGPP_NOT_CONFIGURED marca un dominio sin ninguna directiva de contraseñas específica configurada, y los controles alineados con ANSSI ANSSI_R40_NO_PSO_TIER0 y ANSSI_R82_R83_ADMIN_ARCHITECTURE señalan específicamente los grupos de administración Tier 0 que no están cubiertos por una directiva específica dedicada ni por ningún control de restricción de inicio de sesión.
Explore las páginas de identidad que apoyan este tema