Delegación en Active Directory: detectar y corregir riesgos

La delegación de Kerberos permite a un servicio de front-end actuar en nombre de un usuario ante un servicio de back-end; el caso clásico es una aplicación web que consulta un SQL Server como el usuario que ha iniciado sesión y no como ella misma. Es una funcionalidad legítima y a veces necesaria, pero cada una de sus tres implementaciones crea una relación de confianza que, si se sitúa en el servidor o la cuenta equivocados, ofrece a un atacante que compromete esa única máquina una vía para suplantar a otros usuarios, a menudo incluidos los administradores.

Esta guía explica en qué se diferencian los tres tipos de delegación, cómo inventariar todas las relaciones de delegación de su dominio y cómo proteger las cuentas que nunca deberían poder delegarse.

Los tres tipos de delegación

Delegación sin restricciones

Cuando un usuario se autentica mediante Kerberos ante un servidor de confianza para la delegación sin restricciones, el cliente envía una copia reenviada del TGT del usuario junto con el ticket de servicio, y el servidor la almacena en memoria. Ese servidor puede entonces reutilizar el TGT para solicitar tickets para cualquier servicio, como ese usuario, indefinidamente (hasta que caduque el TGT). Si un Domain Admin se autentica alguna vez ante esa máquina, aunque solo sea para navegar por un recurso compartido, su TGT queda en memoria a disposición de quien quiera tomarlo.

De forma predeterminada, todos los controladores de dominio son de confianza para la delegación sin restricciones (es necesario para su funcionamiento normal). La regla crítica: ningún servidor que no sea un controlador de dominio debe tener este indicador. Era un valor predeterminado heredado habitual en servidores de impresión, servidores IIS antiguos y servidores de aplicaciones mal configurados, y sigue siendo uno de los puntos de apoyo más valiosos que puede encontrar un atacante.

Delegación restringida

Introducida en Windows Server 2003, la delegación restringida limita al front-end a suplantar usuarios solo ante una lista explícita de SPN de back-end, configurada mediante msDS-AllowedToDelegateTo en la cuenta del front-end. También admite la «transición de protocolo» (TRUSTED_TO_AUTH_FOR_DELEGATION), que permite al front-end obtener un ticket en nombre de un usuario incluso sin un salto Kerberos previo; resulta útil para aplicaciones web que autentican a los usuarios mediante formularios u otros medios pero que aun así necesitan delegar en un back-end. Es más segura que la delegación sin restricciones, pero sigue siendo arriesgada: quien controle la cuenta del front-end puede suplantar a cualquier usuario (incluidos los administradores) ante todos los servicios de esa lista de permitidos.

Delegación restringida basada en recursos (RBCD)

Introducida en Windows Server 2012, RBCD invierte el lugar donde se configura la confianza: en lugar de que el front-end declare dónde puede delegar, es el recurso de back-end el que declara qué cuentas de front-end pueden actuar en su nombre, mediante msDS-AllowedToActOnBehalfOfOtherIdentity. Es más flexible (funciona a través de los límites de dominio/bosque y no requiere derechos de Domain Admin para configurarse, solo acceso de escritura al objeto de equipo de destino), pero esa flexibilidad es también el riesgo: cualquiera con GenericWrite/WriteProperty sobre un objeto de equipo puede concederse derechos RBCD para suplantar a usuarios ante él, incluso mediante los privilegios de creación de cuentas de equipo que muchos usuarios tienen de forma predeterminada (ms-DS-MachineAccountQuota).

Encontrar la delegación en su dominio

Haga un inventario completo antes de decidir qué corregir. Debe ser una auditoría periódica, no un ejercicio puntual.

# Delegación sin restricciones: equipos y usuarios (debe estar vacío salvo los DC)
Get-ADComputer -Filter 'TrustedForDelegation -eq $true' -Properties TrustedForDelegation, servicePrincipalName |
    Select-Object Name, DistinguishedName

Get-ADUser -Filter 'TrustedForDelegation -eq $true' -Properties TrustedForDelegation |
    Select-Object Name, DistinguishedName

# Delegación restringida: cuentas con msDS-AllowedToDelegateTo con valor
Get-ADComputer -Filter * -Properties msDS-AllowedToDelegateTo, TrustedToAuthForDelegation |
    Where-Object { $_."msDS-AllowedToDelegateTo" } |
    Select-Object Name, msDS-AllowedToDelegateTo, TrustedToAuthForDelegation

Get-ADUser -Filter * -Properties msDS-AllowedToDelegateTo, TrustedToAuthForDelegation |
    Where-Object { $_."msDS-AllowedToDelegateTo" } |
    Select-Object Name, msDS-AllowedToDelegateTo, TrustedToAuthForDelegation

# Delegación restringida basada en recursos: PrincipalsAllowedToDelegateToAccount es la vista
# decodificada por el módulo ActiveDirectory del descriptor msDS-AllowedToActOnBehalfOfOtherIdentity
Get-ADComputer -LDAPFilter '(msDS-AllowedToActOnBehalfOfOtherIdentity=*)' `
    -Properties PrincipalsAllowedToDelegateToAccount |
    Select-Object @{n='Computer';e={$_.Name}},
        @{n='DelegatedFrom';e={$_.PrincipalsAllowedToDelegateToAccount -join '; '}}

Trate cada coincidencia de delegación sin restricciones fuera de la OU Domain Controllers como un hallazgo crítico que requiere corrección inmediata. Para las coincidencias de delegación restringida y RBCD, verifique cada una frente a un registro de cambio: la delegación debe estar documentada, ser deliberada y revisarse, no ser un vestigio de una prueba de concepto olvidada.

Eliminar la delegación no deseada

# Eliminar la delegación sin restricciones de una cuenta de equipo que no es DC
Set-ADComputer -Identity "APP01" -TrustedForDelegation $false

# Eliminar las entradas de delegación restringida
Set-ADComputer -Identity "APP02" -Clear msDS-AllowedToDelegateTo

# Borrar la RBCD de un recurso
Set-ADComputer -Identity "SQL01" -Clear msDS-AllowedToActOnBehalfOfOtherIdentity

Proteger las cuentas privilegiadas: «sensible y no se puede delegar»

Independientemente de la delegación que exista en el resto del dominio, las cuentas privilegiadas deben quedar excluidas explícitamente de cualquier delegación mediante el indicador NOT_DELEGATED (bit de userAccountControl, que aparece como "Account is sensitive and cannot be delegated" en ADUC). Esto impide que cualquier servicio, incluso una delegación restringida configurada legítimamente, obtenga un ticket para suplantar a esa cuenta.

# Aplicar a una sola cuenta privilegiada
Set-ADAccountControl -Identity "adm-t0-famette" -AccountNotDelegated $true

# Aplicar a todos los miembros de Domain Admins y Enterprise Admins
"Domain Admins", "Enterprise Admins" | ForEach-Object {
    Get-ADGroupMember -Identity $_ -Recursive |
        Where-Object { $_.objectClass -eq 'user' } |
        ForEach-Object { Set-ADAccountControl -Identity $_.SamAccountName -AccountNotDelegated $true }
}

Verificar

Get-ADUser -Identity "adm-t0-famette" -Properties userAccountControl |
    Select-Object Name, @{n='NotDelegated';e={
        [bool]($_.userAccountControl -band 0x100000)
    }}

La pertenencia a Protected Users (tratada en Tier 0 y acceso privilegiado) ofrece una protección aún más sólida y complementaria: bloquea directamente NTLM y la delegación sin restricciones/restringida para la cuenta, sin necesidad de configurar por separado el indicador NOT_DELEGATED, y además endurece los requisitos de vigencia y cifrado de los tickets Kerberos.

Por qué la delegación sin restricciones en un servidor que no es DC es crítica

Merece repetirse por separado porque es la configuración incorrecta de delegación de mayor valor: un servidor comprometido de confianza para la delegación sin restricciones se convierte en una trampa de credenciales que recolecta el TGT de cada administrador en cuanto lo toca, sin necesidad de explotar el equipo del propio administrador. Junto con la formación de los equipos de infraestructura sobre la delegación sin restricciones, debe ser un punto permanente de toda revisión de seguridad de AD, comprobado cada vez que se aprovisiona un nuevo servidor, no solo durante las auditorías periódicas.

Qué rompe

• Las aplicaciones web que usan la delegación Kerberos para consultar bases de datos de back-end como el usuario que ha iniciado sesión (habitual en SharePoint, SSRS y aplicaciones de intranet a medida) dependen de la delegación restringida: eliminar una entrada de msDS-AllowedToDelegateTo sin sustituirla por la entrada acotada correcta rompe la funcionalidad de «ejecutar como usuario» y obliga a la aplicación a recurrir al contexto de una cuenta de servicio o a fallar directamente.
• Los servidores vinculados de SQL Server configurados para la autenticación delegada (en lugar de credenciales almacenadas) dejan de funcionar si se borran las entradas de delegación de la cuenta de servicio de SQL; audítelas y reconfigúrelas como delegación restringida con SPN explícitos en lugar de eliminarlas por completo.
• Los servidores de impresión y los proxies de aplicaciones antiguos a los que históricamente se concedió la delegación sin restricciones como solución general a menudo dependían de ella de forma silenciosa; eliminar el indicador puede manifestarse como errores intermitentes de «acceso denegado» en escenarios de doble salto (por ejemplo, un usuario que navega por un recurso compartido a través de un servidor de impresión que después necesita autenticarse más allá). Pruébelo en una ventana de mantenimiento y esté preparado para reconfigurarlo como delegación restringida correctamente acotada.
• La RBCD usada para accesos legítimos a recursos entre dominios (por ejemplo, un escenario de migración o una aplicación multibosque) se romperá si se borra sin haber vuelto a aprovisionar antes la relación mediante un control de cambios documentado.

Lecturas relacionadas: Hardening de Kerberos para las técnicas de falsificación de tickets con las que suele encadenarse el abuso de la delegación, y Tier 0 y acceso privilegiado para la separación de cuentas por niveles que mantiene las cuentas de servicio delegables lejos de las credenciales Tier 0. Consulte también DCSync para saber qué hace un atacante después de obtener un TGT de Domain Admin mediante el abuso de la delegación.