Directivas y silos de autenticación para cuentas Tier 0

Las GPO de denegación de inicio de sesión son la columna vertebral del modelo de niveles, pero las aplica cada equipo de destino. Si una GPO no se aplica, si un servidor está en la OU equivocada o si un atacante controla un equipo y simplemente ignora su directiva local, el dominio sigue aceptando una contraseña o un hash Tier 0. Las directivas y silos de autenticación trasladan esa decisión al KDC: una cuenta Tier 0 solo puede obtener un TGT desde un dispositivo aprobado, piense lo que piense el propio dispositivo.

Esta guía explica cómo se evalúan realmente los silos de autenticación, los requisitos previos (incluido el blindaje de Kerberos), cómo construir un silo Tier 0, cómo desplegarlo en modo auditoría y cómo verificarlo. La visión general breve está en Tier 0 y acceso privilegiado. Esta es la implementación.

Cómo funcionan las directivas y los silos

En la partición de configuración, dentro de CN=AuthN Policy Configuration,CN=Services, residen dos tipos de objeto:

• Directiva de autenticación (msDS-AuthNPolicy): por tipo de objeto (usuario, equipo, servicio), define una vigencia del TGT y dos condiciones escritas en SDDL: allowed to authenticate from (qué dispositivos pueden solicitar el TGT de la cuenta) y allowed to authenticate to (qué cuentas pueden solicitar tickets de servicio para este servicio).
• Silo de directivas de autenticación (msDS-AuthNPolicySilo): agrupa cuentas y asigna una directiva por tipo de objeto. La pertenencia es bidireccional: el silo enumera los miembros permitidos en msDS-AuthNPolicySiloMembers y cada cuenta apunta a su silo en msDS-AssignedAuthNPolicySilo. Se necesitan ambos.

Cuando un miembro del silo se autentica, el KDC añade una notificación (claim) de silo al TGT. Una condición de la directiva puede entonces decir «el dispositivo que solicita este TGT debe ser miembro del silo Tier0». Como la identidad del dispositivo procede del propio TGT del equipo usado para el blindaje FAST, la funcionalidad depende de que el blindaje y las notificaciones se admitan de extremo a extremo.

Cada directiva y cada silo tienen un indicador enforce. Sin él, el KDC evalúa las reglas y registra lo que habría fallado, pero permite la solicitud. Ese modo auditoría es la clave de un despliegue seguro.

Requisitos previos

• Nivel funcional de dominio Windows Server 2012 R2 o superior, y todos los DC con Windows Server 2012 R2 o posterior.
• Compatibilidad del KDC con notificaciones y blindaje en todos los DC: Computer Configuration > Policies > Administrative Templates > System > KDC > KDC support for claims, compound authentication and Kerberos armoring en Enabled con Supported. No salte a Always provide claims ni a Fail unarmored authentication requests para este proyecto.
• Compatibilidad del cliente en todos los dispositivos del silo: Computer Configuration > Policies > Administrative Templates > System > Kerberos > Kerberos client support for claims, compound authentication and Kerberos armoring en Enabled. Windows 8 / Server 2012 y posteriores lo admiten.
• Se recomienda encarecidamente la pertenencia a Protected Users para las mismas cuentas Tier 0. Fuerza AES, bloquea NTLM y la delegación y establece un TGT predeterminado de 240 minutos, lo que complementa al silo. Consulte Protected Users.
• Un inventario completo de cuentas y dispositivos Tier 0, incluidas las PAW y los servidores de salto Tier 0.

# Comprobar el nivel funcional y los sistemas operativos de los DC
(Get-ADDomain).DomainMode
Get-ADDomainController -Filter * | Select-Object HostName, OperatingSystem

Decisiones de diseño

Resuelva tres cuestiones antes de crear nada.

Alcance del silo. Empiece con un silo para los administradores humanos Tier 0 y los dispositivos que utilizan. Resista la tentación de añadir cuentas de servicio, cuentas de sincronización de Entra Connect o cuentas de copia de seguridad en la primera iteración. Sus patrones de autenticación son más difíciles de prever, y un fallo ahí supone una interrupción del servicio y no un administrador contrariado. Un segundo silo para las cuentas de servicio Tier 0 puede llegar cuando el primero lleve unos meses estable.

Vigencia del TGT. Un TGT más corto limita cuánto tiempo puede reutilizarse un ticket robado. Cuatro horas (240 minutos) coincide con el valor predeterminado de Protected Users y se ajusta a una sesión de trabajo de administración. Acortarla más produce sobre todo solicitudes de reautenticación sin una ganancia significativa; alargarla deshace parte del beneficio. Si una cuenta está a la vez en Protected Users y en una directiva, se aplica la vigencia de la directiva.

Qué dirección restringir. Allowed to authenticate from en la directiva de usuario es el control del modelo de niveles: mantiene las credenciales Tier 0 fuera de los dispositivos de niveles inferiores. Allowed to authenticate to en una directiva de equipo o de servicio es lo contrario: restringe qué cuentas pueden obtener tickets de servicio para los servidores Tier 0. Ese segundo control es muy útil para sistemas Tier 0 dedicados, como una bóveda PAM o el host de administración de una CA sin conexión, pero en los DC bloquearía a todos los usuarios del dominio, así que no lo aplique allí.

Construir el silo Tier 0 en modo auditoría

El patrón: un silo, una directiva de usuario que restringe desde dónde pueden autenticarse los usuarios Tier 0 y una directiva de equipo para los propios dispositivos Tier 0 (normalmente solo la vigencia, sin condiciones restrictivas).

$siloName = 'Tier0-Silo'

# Condición: el dispositivo que solicita el TGT debe ser miembro del silo Tier0
$fromSilo = "O:SYG:SYD:(XA;OICI;CR;;;WD;(@USER.ad://ext/AuthenticationSilo == `"$siloName`"))"

# Directiva de usuario: TGT de 4 horas, solo desde dispositivos del silo. Todavía sin -Enforce: modo auditoría.
New-ADAuthenticationPolicy -Name 'Tier0-Users' `
    -Description 'Tier 0 admins: TGT only from Tier 0 devices' `
    -UserTGTLifetimeMins 240 `
    -UserAllowedToAuthenticateFrom $fromSilo `
    -ProtectedFromAccidentalDeletion $true

# Directiva de equipo para PAW y servidores Tier 0: sin condiciones, vigencia predeterminada
New-ADAuthenticationPolicy -Name 'Tier0-Computers' `
    -Description 'Tier 0 devices' -ProtectedFromAccidentalDeletion $true

# Silo en modo auditoría
New-ADAuthenticationPolicySilo -Name $siloName `
    -UserAuthenticationPolicy 'Tier0-Users' `
    -ComputerAuthenticationPolicy 'Tier0-Computers' `
    -ServiceAuthenticationPolicy 'Tier0-Computers' `
    -ProtectedFromAccidentalDeletion $true

El @USER de una condición allowed to authenticate from se refiere a la cuenta del dispositivo que blinda la solicitud, no al administrador. Es intencionado, y es el punto que más confusión genera al leer estas directivas.

Asignar miembros

Añada los usuarios Tier 0, las PAW, los servidores de salto Tier 0 y, si los administradores inician sesión en la consola de los DC, los propios DC. Cada miembro necesita ambos pasos:

$members = @(
    Get-ADGroupMember 'Tier0-Accounts' | ForEach-Object { Get-ADUser $_ }
    Get-ADGroupMember 'Tier0-Devices'  | ForEach-Object { Get-ADComputer $_ }
)

foreach ($m in $members) {
    # Permitir la cuenta en el silo (msDS-AuthNPolicySiloMembers)
    Grant-ADAuthenticationPolicySiloAccess -Identity $siloName -Account $m
    # Apuntar la cuenta al silo (msDS-AssignedAuthNPolicySilo)
    Set-ADAccountAuthenticationPolicySilo -Identity $m -AuthenticationPolicySilo $siloName
}

No añada cuentas de servicio, gMSA ni cuentas de emergencia (break-glass) a este silo durante la primera fase. Las cuentas de emergencia deben quedar fuera del silo, muy supervisadas y con su contraseña en una caja fuerte física.

Recopilar datos de auditoría

Las decisiones del silo se registran en los DC en registros operativos dedicados que están deshabilitados de forma predeterminada:

# Ejecutar en todos los DC
wevtutil sl "Microsoft-Windows-Authentication/AuthenticationPolicyFailures-DomainController" /e:true
wevtutil sl "Microsoft-Windows-Authentication/ProtectedUserFailures-DomainController" /e:true

En AuthenticationPolicyFailures-DomainController, los eventos del modo auditoría son el 305 (la directiva habría rechazado un TGT) y el 306 (se habría rechazado un ticket de servicio). Sus equivalentes en modo de aplicación son el 105 y el 106, y el 101 registra una autenticación NTLM bloqueada por una directiva. Deje el modo auditoría activo durante al menos un ciclo completo de administración, incluidas las tareas de cierre de mes, las noches de parcheo y las rotaciones de guardia.

Get-ADDomainController -Filter * | ForEach-Object {
    Get-WinEvent -ComputerName $_.HostName -FilterHashtable @{
        LogName = 'Microsoft-Windows-Authentication/AuthenticationPolicyFailures-DomainController'
        Id      = 305, 306
    } -ErrorAction SilentlyContinue
} | Select-Object MachineName, TimeCreated, Id, Message

Cada coincidencia es o bien un administrador que se autentica desde un dispositivo no Tier 0 (un problema de proceso que corregir), o bien un dispositivo Tier 0 que falta en el silo (un problema de pertenencia que corregir).

Aplicar

Cuando el registro de auditoría esté en calma, aplique primero la directiva y después el silo:

Set-ADAuthenticationPolicy -Identity 'Tier0-Users' -Enforce $true
Set-ADAuthenticationPolicySilo -Identity 'Tier0-Silo' -Enforce $true

Aplíquelo un martes por la mañana con un administrador frente a la consola de un DC, no un viernes por la tarde. Si algo sale mal, -Enforce $false en el silo surte efecto en cuanto se replica.

Una directiva con condiciones allowed to authenticate from también bloquea los inicios de sesión de red NTLM de sus usuarios, salvo que los permita explícitamente con el parámetro UserAllowedNTLMNetworkAuthentication de la directiva. Déjelo desactivado para el Tier 0.

Supervisar el propio silo

Una vez aplicado, el silo es un control Tier 0, y su manipulación es una señal de ataque. Con Audit Directory Service Changes habilitado en los DC, los cambios en msDS-AssignedAuthNPolicySilo en las cuentas y en los objetos de directiva y silo de la partición de configuración generan el evento 5136. Genere una alerta ante cualquier cambio de este tipo fuera de una ventana de cambios, y ante cualquier evento 105 o 106 en modo de aplicación para una cuenta Tier 0, que significa o bien un error, o bien alguien que intenta usar una credencial Tier 0 desde el lugar equivocado.

Verificar

# Configuración del silo y estado de aplicación
Get-ADAuthenticationPolicySilo -Identity 'Tier0-Silo' -Properties * |
    Select-Object Name, Enforce, UserAuthenticationPolicy, ComputerAuthenticationPolicy, msDS-AuthNPolicySiloMembers

# Todas las cuentas Tier 0 están asignadas al silo
Get-ADGroupMember 'Tier0-Accounts' | Get-ADUser -Properties msDS-AssignedAuthNPolicySilo |
    Where-Object { -not $_.'msDS-AssignedAuthNPolicySilo' } | Select-Object SamAccountName
# No debe devolver nada

Después, pruebe el funcionamiento. Desde una PAW, inicie sesión con una cuenta Tier 0 y ejecute klist: la hora de expiración del TGT debe reflejar la vigencia de 240 minutos. Desde una estación de trabajo estándar, intente un runas /user: con la misma cuenta: debe fallar, y el DC debe registrar el evento 105 junto con un error 4768 con el código de resultado 0xC (KDC_ERR_POLICY). Guarde ambas pruebas como evidencia para las auditorías.

Qué rompe

• Administradores en dispositivos no Tier 0: cualquier inicio de sesión Tier 0 desde un portátil, un servidor Tier 1 o una estación de trabajo del service desk falla. Ese es el objetivo, pero saca a la luz todos los hábitos no documentados desde el primer día.
• Las tareas programadas y los servicios que se ejecutan como miembros del silo fallan si se ejecutan en un dispositivo fuera del silo. Mígrelos a gMSA fuera del Tier 0 o incorpore deliberadamente el host al Tier 0.
• Los clientes no Windows y heredados sin compatibilidad con el blindaje (Linux antiguos, herramientas de macOS, dispositivos de red que usan las credenciales de AD de un administrador) no pueden autenticarse como miembros del silo.
• Administración entre bosques: las notificaciones de dispositivo no atraviesan las confianzas de forma predeterminada, así que no se puede restringir a los administradores Tier 0 de un bosque a dispositivos de otro bosque sin un trabajo adicional de transformación de notificaciones.
• Recuperación de DC: en una recuperación de bosque en la que se reconstruyen los DC, el silo sigue aplicándose. Mantenga una cuenta de emergencia documentada fuera del silo, como se explica en el plan de recuperación del bosque.

Lecturas relacionadas: Kerberos y autenticación para la capa de blindaje y cifrado que hay bajo los silos, estaciones de trabajo de acceso privilegiado para los dispositivos que se incluyen en el silo, y la visión general del área Tier 0.