Delegación de Kerberos: riesgos y hardening

Aviso ético: todo lo que se explica en este módulo tiene finalidad exclusivamente defensiva y formativa. Los comandos de auditoría (Get-ADComputer, Get-ADUser, Get-ADObject) están pensados para inventariar y remediar delegación peligrosa en dominios de los que eres administrador o en tu propio laboratorio aislado. No utilices estas técnicas contra sistemas de terceros ni sin autorización explícita por escrito. La delegación de Kerberos mal configurada es, en auditorías reales, una de las causas más frecuentes de compromiso total de dominio (Domain Admin) partiendo de un único servidor mal protegido; tu trabajo como defensor es encontrarla antes que el atacante.

Qué aprenderás

Qué es la delegación de Kerberos y por qué existe (el problema del «doble salto» / double hop).
Los tres modelos de delegación en Active Directory: no restringida (unconstrained), restringida (constrained) y restringida basada en recursos (RBCD).
Los atributos de AD que materializan cada tipo de delegación (userAccountControl, msDS-AllowedToDelegateTo, msDS-AllowedToActOnBehalfOfOtherIdentity) y cómo consultarlos.
Por qué la delegación no restringida en un Domain Controller o en cualquier servidor accesible es, en la práctica, equivalente a tener las llaves del reino.
Cómo se abusa conceptualmente de cada tipo (sin operativizar ataques) para poder razonar sobre el riesgo real.
Cómo inventariar TODA la delegación de un dominio con PowerShell/WP-CLI de AD.
Contramedidas concretas: NOT_DELEGATED, Protected Users, eliminación de unconstrained, ACLs sobre atributos de delegación.
Errores habituales que dejan la puerta abierta durante años sin que nadie se dé cuenta.

1. El problema que la delegación intenta resolver: el «doble salto»

Kerberos, por diseño, es un protocolo que autentica a un usuario frente a un servicio concreto mediante un ticket de servicio (TGS) cifrado para ese servicio específico. El problema aparece cuando un servicio necesita, a su vez, actuar en nombre del usuario contra un tercer servicio. Ejemplo clásico: un usuario se autentica contra un servidor IIS/web (salto 1), y esa aplicación web necesita consultar una base de datos SQL Server en otro servidor con la identidad del usuario original (salto 2), no con la identidad de la cuenta de servicio de IIS.

Por defecto, Kerberos no permite este «doble salto»: el ticket de servicio que el usuario presentó a IIS solo sirve para IIS, no puede ser reutilizado por IIS para autenticarse contra SQL Server como si fuera el usuario. La delegación de Kerberos es el mecanismo que Microsoft diseñó para resolver este problema legítimo: permite que un servicio, actuando como intermediario de confianza, se autentique ante un tercer servicio suplantando (impersonando) al usuario original.

El problema de seguridad es que, según cómo se implemente esa delegación, el «servicio intermediario de confianza» puede terminar teniendo la capacidad de suplantar a cualquier usuario del dominio, incluidos los Domain Admins, ante cualquier servicio. Esa es la raíz de todo lo que viene a continuación: delegación mal acotada = escalada de privilegios de dominio.

2. Delegación NO restringida (Unconstrained Delegation)

2.1 Qué es

Es el modelo más antiguo y más peligroso, introducido en Windows 2000/2003. Cuando una cuenta de equipo o de servicio tiene marcado el flag TRUSTED_FOR_DELEGATION en su atributo userAccountControl, ocurre lo siguiente: cuando un usuario se autentica contra ese servidor mediante Kerberos, el KDC (Key Distribution Center, rol que ejerce el Domain Controller) incluye una copia completa del TGT (Ticket Granting Ticket) del usuario dentro del ticket de servicio, y esa copia queda cacheada en memoria (LSASS) del servidor delegado.

Dicho de otro modo: el servidor no solo recibe la prueba de que el usuario se autenticó, sino que recibe el TGT completo del usuario, con el que puede solicitar tickets de servicio para cualquier servicio del dominio, suplantando a ese usuario de forma total e irrestricta. No hay ninguna limitación sobre a qué servicios puede dirigirse esa suplantación.

2.2 Por qué es tan peligrosa

La peligrosidad de unconstrained delegation no depende de que el atacante haga nada sofisticado: depende únicamente de esperar. Si un atacante compromete (obtiene privilegios administrativos locales sobre) un servidor con unconstrained delegation habilitada, puede volcar de la memoria LSASS los TGTs de todos los usuarios que se hayan autenticado contra ese servidor desde el arranque. Si entre esos usuarios se autentica alguna vez un Domain Admin —por ejemplo, porque un administrador se conecta por RDP a ese servidor para tareas de mantenimiento, o porque un servicio de backup con privilegios de dominio recorre ese servidor— el atacante obtiene el TGT de ese DA y, con él, control total del dominio.

Es especialmente crítico en dos escenarios:

Domain Controllers: los propios DCs tienen unconstrained delegation habilitada por defecto en muchos entornos legacy (herencia de comportamientos antiguos), lo que significa que cualquier TGT de cualquier usuario que se autentique contra el DC (que es prácticamente todo el mundo, todo el tiempo) queda expuesto si el DC se ve comprometido. Aunque en ese escenario el dominio ya está perdido de todas formas, es un ejemplo de la magnitud del problema.
Servidores «trampa» con unconstrained: un atacante que ya tiene un punto de apoyo en la red puede identificar qué servidores tienen unconstrained delegation y, si consigue comprometer administrativamente uno de ellos, simplemente provocar o esperar a que un DA se autentique contra él (por ejemplo, forzando la impresión de un documento vía spooler para atraer autenticaciones, un vector históricamente ligado a este tipo de abuso). Este es el motivo por el que auditar y erradicar unconstrained delegation es una de las tareas de mayor retorno en cualquier hardening de AD.

2.3 Cómo se abusa (a nivel conceptual, sin operativizar)

El flujo de abuso, a alto nivel, es: (1) el atacante identifica cuentas de equipo/servicio con TRUSTED_FOR_DELEGATION; (2) compromete administrativamente uno de esos servidores; (3) monitoriza o fuerza la caché de tickets Kerberos en memoria a la espera de que se autentique una cuenta privilegiada; (4) extrae el TGT cacheado de esa cuenta privilegiada; (5) reutiliza ese TGT para solicitar tickets de servicio contra cualquier recurso del dominio, actuando como esa cuenta. No se detalla aquí instrumentación ofensiva: lo relevante para el defensor es entender que el compromiso de un único servidor con esta configuración puede escalar a compromiso total de dominio sin explotar ninguna vulnerabilidad adicional, solo abusando de una característica de diseño mal acotada.

2.4 Cómo se endurece

La contramedida es, conceptualmente, simple: no debería existir unconstrained delegation en un dominio moderno, salvo excepciones extremadamente justificadas y compensadas con controles adicionales (aislamiento de red estricto, Tier Model, PAW). Los pasos concretos:

Inventariar todas las cuentas de equipo y de usuario con TrustedForDelegation -eq $true.
Para cada una, evaluar si la delegación es realmente necesaria; si no lo es, desactivarla.
Si es necesaria, migrar a delegación restringida (constrained) o RBCD, que acotan a qué servicios concretos se puede delegar.
Proteger a las cuentas privilegiadas (Domain Admins, Enterprise Admins, cuentas de servicio Tier 0) marcándolas explícitamente como no delegables (ver sección 5), de forma que aunque exista unconstrained delegation en algún servidor, el TGT de esas cuentas nunca quede expuesto a copia.
Aplicar el Tier Model: las cuentas Tier 0 nunca deben autenticarse interactivamente contra servidores Tier 1/2, que es donde suele vivir la unconstrained delegation heredada.

3. Delegación RESTRINGIDA (Constrained Delegation)

3.1 Qué es

Introducida en Windows Server 2003, resuelve el problema más evidente de unconstrained delegation: en lugar de recibir el TGT completo del usuario (delegación irrestricta a cualquier servicio), el servidor delegado solo puede solicitar tickets de servicio para una lista explícita y acotada de SPNs (Service Principal Names) de destino. Esa lista se almacena en el atributo msDS-AllowedToDelegateTo de la cuenta que delega.

El mecanismo Kerberos que hace esto posible es la extensión S4U (Service-for-User), con dos subprotocolos:

S4U2Self: permite a un servicio obtener un ticket de servicio para sí mismo en nombre de un usuario, sin que ese usuario haya presentado credenciales Kerberos directamente contra ese servicio (por ejemplo, si el usuario se autenticó por NTLM o por formulario web). Esto es lo que se llama protocol transition.
S4U2Proxy: permite a ese servicio, ya en posesión de un ticket «en nombre de» el usuario, solicitar al KDC un ticket de servicio contra otro servicio de la lista permitida en msDS-AllowedToDelegateTo, suplantando al usuario ante ese tercer servicio.

3.2 El peligro específico: «protocol transition»

El flag TRUSTED_TO_AUTH_FOR_DELEGATION en userAccountControl habilita S4U2Self sin requerir que el usuario se haya autenticado por Kerberos previamente contra el servicio delegante. Esto es funcionalmente muy potente (permite escenarios legítimos como aplicaciones web con autenticación por formulario que luego delegan a un backend Kerberos), pero introduce un riesgo grave: si un atacante controla o compromete una cuenta con TRUSTED_TO_AUTH_FOR_DELEGATION y con msDS-AllowedToDelegateTo apuntando a un SPN sensible, puede solicitar un ticket S4U2Self en nombre de cualquier usuario del dominio que elija arbitrariamente —sin necesidad de que ese usuario se haya autenticado nunca contra el servicio— y encadenarlo con S4U2Proxy contra el SPN permitido.

El riesgo se agrava exponencialmente si el SPN de destino en msDS-AllowedToDelegateTo es algo como ldap/nombreDC.dominio.local, porque el servicio LDAP de un Domain Controller permite, con un ticket de servicio LDAP suplantando a un DA, realizar operaciones equivalentes a DCSync (replicación de hashes de todo el dominio) o cualquier operación administrativa vía LDAP. Es decir: constrained delegation mal acotada hacia LDAP de un DC es, en la práctica, tan grave como unconstrained delegation.

Otro matiz importante: constrained delegation con S4U2Proxy, en su forma clásica, restringe el servicio destino pero no siempre restringe qué usuario puede ser suplantado (salvo que además se apliquen restricciones adicionales de «sensitive» en el propio usuario objetivo). Esto significa que, si la lista de msDS-AllowedToDelegateTo incluye un SPN sensible, da igual cuánto se restrinja el destino: el atacante puede elegir suplantar a un DA igualmente.

3.3 Cómo se endurece

Auditar todas las cuentas con msDS-AllowedToDelegateTo poblado y revisar exhaustivamente a qué SPNs apuntan.
Prestar especial atención (alerta crítica) a cualquier entrada que apunte a servicios ldap/, cifs/, host/ o krbtgt/ de un Domain Controller: casi nunca está justificado y debe eliminarse salvo justificación documentada y aprobada.
Revisar qué cuentas tienen TRUSTED_TO_AUTH_FOR_DELEGATION (protocol transition) y confirmar que es estrictamente necesario; si el servicio siempre recibe autenticación Kerberos directa del usuario, no necesita protocol transition y el flag debe retirarse.
Acotar la lista de SPNs permitidos al mínimo imprescindible (principio de mínimo privilegio aplicado a delegación).
Proteger con ACL la escritura del atributo msDS-AllowedToDelegateTo: si un atacante con privilegios de escritura sobre el objeto puede añadir un SPN a esta lista, puede crear su propia ruta de delegación abusiva sin que TRUSTED_FOR_DELEGATION esté marcado como tal por un administrador (ver sección 4.3 sobre GenericWrite/GenericAll).

4. Delegación RESTRINGIDA BASADA EN RECURSOS (RBCD)

4.1 Qué es

Introducida en Windows Server 2012, invierte el modelo de confianza respecto a constrained delegation clásica. En lugar de que el servidor origen (el que delega) declare a qué servicios puede delegar (msDS-AllowedToDelegateTo), es el objeto de recurso destino (el servidor/servicio que recibirá la conexión delegada) el que declara, mediante el atributo msDS-AllowedToActOnBehalfOfOtherIdentity, qué cuentas tienen permiso para actuar en su nombre (Resource-Based Constrained Delegation).

Este cambio de modelo tenía como objetivo dar más control al propietario del recurso destino y no requerir privilegios de Domain Admin para configurar delegación entre dos objetos si el administrador del recurso destino tiene permisos de escritura sobre su propio objeto (por ejemplo, para escenarios entre dominios/forests, o delegación gestionada por equipos de aplicación sin escalar a AD Admins). El atributo se almacena como un descriptor de seguridad (security descriptor, formato SDDL) que lista qué principals están autorizados.

4.2 Por qué es peligrosa: el vector de abuso principal

El riesgo de RBCD no nace tanto del mecanismo Kerberos en sí (que de hecho es más seguro por diseño que unconstrained, al estar acotado al recurso destino) sino de quién tiene permisos de escritura sobre el atributo msDS-AllowedToActOnBehalfOfOtherIdentity de los objetos de equipo del dominio. Este es el vector de abuso más citado en la literatura de ADSecurity: si un atacante controla (o compromete) cualquier cuenta que tenga privilegios de escritura sobre un objeto de equipo (por ejemplo, por delegación de permisos de «Join domain» o por ACLs heredadas mal configuradas, o simplemente porque por defecto los usuarios autenticados pueden unir hasta 10 equipos al dominio —ms-DS-MachineAccountQuota—, y sobre los equipos que ellos mismos crean tienen control total), ese atacante puede:

Crear (o usar) una cuenta de equipo bajo su control.
Escribir en msDS-AllowedToActOnBehalfOfOtherIdentity del objeto de equipo víctima, autorizando a su propia cuenta de equipo controlada a delegar hacia esa víctima.
Usar S4U2Self + S4U2Proxy desde su cuenta de equipo controlada para obtener tickets de servicio contra la víctima, suplantando a cualquier usuario del dominio (incluido un DA, si el usuario objetivo no está protegido) ante los servicios de esa máquina víctima.

Esto convierte RBCD en un vector de escalada de privilegios extremadamente común en pruebas de intrusión modernas, porque no depende de que un administrador haya configurado mal la delegación explícitamente: depende de permisos de escritura sobre objetos AD que a menudo están mal auditados (ACLs heredadas, delegaciones históricas de «unir equipos al dominio», grupos con GenericWrite/GenericAll/WriteDacl sobre OUs completas).

4.3 Cómo se endurece

Auditar qué principals tienen permisos de escritura (GenericWrite, GenericAll, WriteProperty sobre el atributo específico, WriteDacl, WriteOwner) sobre objetos de equipo, especialmente los que alojan servicios sensibles.
Reducir ms-DS-MachineAccountQuota a 0 en el dominio si no hay necesidad operativa de que usuarios estándar unan equipos libremente (reduce drásticamente la superficie de «cuentas de equipo bajo control de un atacante» que sirven de origen para RBCD).
Revisar y limpiar ACLs heredadas anómalas sobre OUs de equipos y servidores (delegaciones históricas del departamento de IT que ya no deberían existir).
Auditar periódicamente qué objetos tienen msDS-AllowedToActOnBehalfOfOtherIdentity poblado y validar que cada entrada es legítima y documentada.
Aplicar Protected Users / NOT_DELEGATED a cuentas privilegiadas: como se detalla en la sección 5, esto neutraliza el impacto de RBCD (y de los otros dos modelos) sobre las cuentas más críticas, con independencia de qué ACLs existan.

5. Tabla comparativa: tipo de delegación vs atributo AD vs riesgo vs contramedida

Tipo de delegación	Atributo(s) AD clave	Riesgo principal	Contramedida principal
No restringida (Unconstrained)	`userAccountControl` con flag `TRUSTED_FOR_DELEGATION` (0x80000)	El servidor recibe y cachea el TGT completo del usuario; compromiso del servidor = suplantación total de cualquiera que se autentique contra él, sin límite de servicio destino.	Eliminar el flag salvo justificación extrema; migrar a constrained/RBCD; nunca en servidores accesibles a Tier > 0; proteger cuentas privilegiadas con NOT_DELEGATED.
Restringida (Constrained)	`msDS-AllowedToDelegateTo` (lista de SPNs) + opcionalmente `TRUSTED_TO_AUTH_FOR_DELEGATION` (0x1000000, protocol transition)	Con protocol transition, permite S4U2Self en nombre de cualquier usuario elegido arbitrariamente; si el SPN destino es LDAP de un DC u otro servicio sensible, equivale a compromiso de dominio.	Auditar y minimizar la lista de SPNs; retirar protocol transition si no es imprescindible; nunca permitir SPNs de DC; proteger escritura del atributo con ACL.
Restringida basada en recursos (RBCD)	`msDS-AllowedToActOnBehalfOfOtherIdentity` (security descriptor en el objeto destino)	Cualquier principal con permiso de escritura sobre este atributo del objeto destino (o sobre el objeto completo vía GenericWrite/GenericAll) puede autoconcederse delegación desde una cuenta de equipo bajo su control.	Auditar ACLs de escritura sobre objetos de equipo; `ms-DS-MachineAccountQuota = 0`; revisar delegaciones de permisos heredadas; proteger cuentas privilegiadas con NOT_DELEGATED.

6. Comandos de auditoría (PowerShell / módulo ActiveDirectory)

A continuación, los comandos base para inventariar delegación en un dominio. Todos son de solo lectura salvo los marcados explícitamente como remediación.

6.1 Encontrar unconstrained delegation (equipos y usuarios)

# Equipos con delegación NO restringida (TrustedForDelegation = $true)
Get-ADComputer -Filter {TrustedForDelegation -eq $true} -Properties TrustedForDelegation, servicePrincipalName, OperatingSystem, PrimaryGroupID |
    Select-Object Name, DistinguishedName, OperatingSystem, TrustedForDelegation

# Usuarios (cuentas de servicio) con delegación NO restringida
Get-ADUser -Filter {TrustedForDelegation -eq $true} -Properties TrustedForDelegation, ServicePrincipalName |
    Select-Object Name, DistinguishedName, ServicePrincipalName, TrustedForDelegation

# Alternativa vía userAccountControl (bitmask 0x80000 = 524288 = TRUSTED_FOR_DELEGATION)
Get-ADObject -LDAPFilter "(userAccountControl:1.2.840.113556.1.4.803:=524288)" -Properties userAccountControl, distinguishedName, objectClass |
    Select-Object Name, objectClass, distinguishedName

6.2 Encontrar constrained delegation y protocol transition

# Cualquier objeto (equipo o usuario) con msDS-AllowedToDelegateTo poblado
Get-ADObject -LDAPFilter "(msDS-AllowedToDelegateTo=*)" -Properties msDS-AllowedToDelegateTo, userAccountControl, objectClass |
    Select-Object Name, objectClass, @{N='AllowedToDelegateTo';E={$_.'msDS-AllowedToDelegateTo'}}

# Detectar específicamente TRUSTED_TO_AUTH_FOR_DELEGATION (0x1000000 = 16777216, protocol transition)
Get-ADObject -LDAPFilter "(userAccountControl:1.2.840.113556.1.4.803:=16777216)" -Properties userAccountControl, msDS-AllowedToDelegateTo |
    Select-Object Name, distinguishedName, @{N='AllowedToDelegateTo';E={$_.'msDS-AllowedToDelegateTo'}}

# ALERTA CRÍTICA: cruzar el resultado anterior contra SPNs de Domain Controllers.
# Cualquier coincidencia con ldap/, cifs/, host/ o krbtgt/ de un DC exige remediación inmediata.
$dcs = (Get-ADDomainController -Filter *).HostName
Get-ADObject -LDAPFilter "(msDS-AllowedToDelegateTo=*)" -Properties msDS-AllowedToDelegateTo |
    ForEach-Object {
        foreach ($spn in $_.'msDS-AllowedToDelegateTo') {
            if ($dcs | Where-Object { $spn -like "*$_*" }) {
                [PSCustomObject]@{ Cuenta = $_.Name; SPNPeligroso = $spn }
            }
        }
    }

6.3 Encontrar RBCD (delegación basada en recursos)

# Objetos (normalmente equipos) con msDS-AllowedToActOnBehalfOfOtherIdentity configurado
Get-ADComputer -Filter * -Properties msDS-AllowedToActOnBehalfOfOtherIdentity |
    Where-Object { $_.'msDS-AllowedToActOnBehalfOfOtherIdentity' -ne $null } |
    ForEach-Object {
        $sd = New-Object Security.AccessControl.RawSecurityDescriptor `
            -ArgumentList $_.'msDS-AllowedToActOnBehalfOfOtherIdentity', 0
        [PSCustomObject]@{
            Objeto = $_.Name
            PrincipalsAutorizados = ($sd.DiscretionaryAcl | ForEach-Object {
                (New-Object Security.Principal.SecurityIdentifier $_.SecurityIdentifier).Translate([Security.Principal.NTAccount])
            }) -join '; '
        }
    }

# Comprobar ms-DS-MachineAccountQuota a nivel de dominio (idealmente 0)
Get-ADObject -Identity (Get-ADDomain).DistinguishedName -Properties ms-DS-MachineAccountQuota |
    Select-Object ms-DS-MachineAccountQuota

6.4 Auditar ACLs de escritura sobre objetos de equipo (origen de abuso RBCD)

# Ejemplo: comprobar quién tiene GenericWrite/GenericAll/WriteProperty sobre un equipo concreto
$equipo = Get-ADComputer -Identity "SRV-APP01"
(Get-Acl "AD:$($equipo.DistinguishedName)").Access |
    Where-Object {
        $_.ActiveDirectoryRights -match "GenericWrite|GenericAll|WriteProperty|WriteDacl|WriteOwner"
    } |
    Select-Object IdentityReference, ActiveDirectoryRights, AccessControlType

6.5 Remediación: marcar cuentas sensibles como no delegables (NOT_DELEGATED)

# Marca el flag "Account is sensitive and cannot be delegated" (userAccountControl += NOT_DELEGATED, 0x100000)
# Esto impide que el TGT/ticket de esta cuenta sea reutilizado por CUALQUIER tipo de delegación,
# con independencia de la configuración del servidor delegante. Es la contramedida más robusta
# a nivel de cuenta individual.
Set-ADAccountControl -Identity "DA-Alejandro" -AccountNotDelegated $true

# Aplicarlo en bloque a todo el grupo Domain Admins
Get-ADGroupMember -Identity "Domain Admins" -Recursive |
    Where-Object { $_.objectClass -eq 'user' } |
    ForEach-Object { Set-ADAccountControl -Identity $_.SamAccountName -AccountNotDelegated $true }

# Añadir la cuenta al grupo Protected Users (protección adicional: además de NOT_DELEGATED,
# fuerza Kerberos-only sin NTLM, deshabilita cacheo de credenciales y reduce TTL del TGT a 4h)
Add-ADGroupMember -Identity "Protected Users" -Members "DA-Alejandro"

# Eliminar unconstrained delegation de un equipo concreto tras confirmar que no es necesaria
Set-ADComputer -Identity "SRV-LEGACY01" -TrustedForDelegation $false

# Eliminar una entrada de constrained delegation SPN concreta (dejando el resto)
Set-ADObject -Identity "CN=SRV-APP01,OU=Servers,DC=lab,DC=local" `
    -Remove @{ 'msDS-AllowedToDelegateTo' = 'cifs/dc01.lab.local' }

7. Laboratorio guiado

Objetivo: en tu dominio de laboratorio aislado (no producción), realizar un inventario completo de toda la delegación existente y aplicar la contramedida de «no delegable» sobre las cuentas de Domain Admins.

Levanta o utiliza un laboratorio de AD aislado (por ejemplo, un DC + 2 servidores miembro en una red virtual sin salida a producción). Confirma que tienes una sesión con el módulo ActiveDirectory de RSAT cargado (Import-Module ActiveDirectory).
Ejecuta los tres bloques de la sección 6.1 y 6.2 y guarda el resultado en un CSV: identifica cuántos objetos tienen TrustedForDelegation y cuántos tienen msDS-AllowedToDelegateTo poblado. En un laboratorio recién creado probablemente el resultado esté vacío: crea deliberadamente un caso de prueba (por ejemplo, habilita TrustedForDelegation en una cuenta de equipo de prueba con Set-ADComputer -Identity "SRV-TEST" -TrustedForDelegation $true) para verificar que tu script de auditoría lo detecta correctamente.
Ejecuta el bloque de la sección 6.3 para RBCD. Crea un caso de prueba: desde una cuenta de equipo de prueba, escribe en msDS-AllowedToActOnBehalfOfOtherIdentity de otra cuenta de equipo de prueba (puedes usar Set-ADComputer -Identity "SRV-VICTIMA" -PrincipalsAllowedToDelegateToAccount "SRV-ORIGEN$") y verifica que tu script de auditoría detecta correctamente el principal autorizado.
Comprueba el valor de ms-DS-MachineAccountQuota con el comando de la sección 6.3. Si es distinto de 0, documenta el riesgo (cualquier usuario autenticado puede crear hasta N cuentas de equipo y usarlas como origen de un ataque RBCD).
Identifica todos los miembros (recursivos) del grupo Domain Admins de tu laboratorio con Get-ADGroupMember -Identity "Domain Admins" -Recursive.
Aplica Set-ADAccountControl -AccountNotDelegated $true a cada uno de esos miembros (usa el bucle de la sección 6.5).
Verifica el resultado consultando el atributo userAccountControl de cada cuenta y confirmando que el flag NOT_DELEGATED (0x100000) está presente: Get-ADUser -Identity "DA-Alejandro" -Properties userAccountControl | Select userAccountControl.
Añade además esas cuentas al grupo Protected Users y documenta en un informe breve (una tabla) qué cuentas quedaron protegidas, qué delegación peligrosa se encontró (real o de prueba) y qué acción de remediación se aplicó a cada hallazgo.
Limpieza: revierte los cambios de prueba que hayas introducido deliberadamente (paso 2 y 3) si vas a reutilizar el laboratorio para otros módulos, dejando constancia en tu informe de qué revertiste.

8. Errores comunes

Dejar unconstrained delegation «heredada» en servidores legacy sin volver a evaluarla nunca. Es extremadamente frecuente encontrar servidores migrados de Windows Server 2003/2008 que arrastran TrustedForDelegation = $true por inercia, sin que nadie recuerde por qué se configuró así ni si sigue siendo necesario.
No proteger las cuentas privilegiadas de delegación, asumiendo que «como no tienen delegación configurada en su propia cuenta, están a salvo». Esto es un error conceptual grave: el riesgo no depende de la configuración de la cuenta del DA, sino de la configuración del servidor contra el que ese DA se autentica. Si el DA se conecta alguna vez a un servidor con unconstrained delegation, su TGT queda expuesto, sin que su propia cuenta tenga «nada configurado».
Confundir constrained delegation con «seguro por definición». Constrained delegation con protocol transition (TRUSTED_TO_AUTH_FOR_DELEGATION) apuntando a un SPN sensible es, en la práctica, casi tan peligrosa como unconstrained si el atacante puede elegir libremente a qué usuario suplantar.
Ignorar RBCD por no ser «delegación configurada por un admin». Al depender de permisos de escritura sobre objetos, RBCD puede ser abusada sin que ningún administrador haya tocado conscientemente ninguna casilla de delegación; el hallazgo requiere auditar ACLs, no solo flags de delegación.
ms-DS-MachineAccountQuota por defecto (10) sin revisar. Es uno de los valores más olvidados de un dominio: permite a cualquier usuario autenticado crear hasta 10 cuentas de equipo, que son precisamente el «origen» habitual en ataques RBCD.
No auditar periódicamente: la delegación cambia con el tiempo (nuevas aplicaciones, nuevos servicios, migraciones). Un inventario hecho una vez y nunca repetido pierde validez rápidamente.
Aplicar NOT_DELEGATED solo a la cuenta «Administrator» y olvidar el resto de miembros de Domain Admins, Enterprise Admins y cuentas de servicio Tier 0 (gMSA/cuentas de servicio con privilegios equivalentes).

9. Ejercicio

En tu entorno de laboratorio (o, si no dispones de uno, describe el procedimiento paso a paso de forma documentada):

Genera un informe completo de delegación del dominio: todas las cuentas con unconstrained, todas con constrained (indicando si tienen protocol transition), y todas con RBCD configurada, incluyendo para cada una el principal afectado y el SPN o principal de destino.
Para cada hallazgo, clasifica el riesgo en Crítico / Alto / Medio / Bajo según estos criterios: Crítico = unconstrained en servidor accesible a Tier 0/1, o constrained/RBCD apuntando a SPN de DC; Alto = unconstrained en cualquier otro servidor, o protocol transition sin justificación documentada; Medio = constrained bien acotada pero sin revisión de ACL de escritura sobre el atributo; Bajo = RBCD documentada y con ACL de escritura auditada y restringida.
Propón y aplica la remediación para cada hallazgo Crítico y Alto, y documenta por qué los Medio/Bajo se consideran aceptables (o proponlos también para remediación si tu criterio de riesgo lo justifica).
Añade NOT_DELEGATED + Protected Users a todas las cuentas Tier 0 de tu laboratorio y verifica el resultado con los comandos de auditoría.

Preguntas frecuentes

¿Basta con quitar TrustedForDelegation de los Domain Controllers para estar a salvo?

No es suficiente por sí solo, aunque es un paso necesario. Los DCs suelen tener unconstrained delegation por razones de compatibilidad legacy y debe revisarse, pero el riesgo real está distribuido por todo el dominio: cualquier servidor miembro con TrustedForDelegation = $true es un punto de exposición si alguna cuenta privilegiada se autentica contra él alguna vez. La defensa robusta combina: eliminar delegación innecesaria en todos los servidores, proteger explícitamente las cuentas privilegiadas con NOT_DELEGATED/Protected Users, y aplicar el Tier Model para que esas cuentas nunca toquen servidores de tiers inferiores.

¿Por qué no desactivar directamente toda la delegación de Kerberos en el dominio?

Porque hay escenarios legítimos y ampliamente usados (aplicaciones multi-capa con backend SQL, servicios de archivos, proxies de autenticación) que dependen de constrained delegation o RBCD bien configuradas para funcionar correctamente sin duplicar credenciales ni recurrir a alternativas peores (como almacenar contraseñas de servicio en texto claro en la aplicación). El objetivo no es «cero delegación», sino «cero delegación no restringida» y «delegación restringida acotada al mínimo imprescindible, auditada y con las cuentas privilegiadas explícitamente excluidas».

¿NOT_DELEGATED afecta al funcionamiento normal de la cuenta?

Impide que esa cuenta sea suplantada mediante cualquier tipo de delegación Kerberos (unconstrained, constrained o RBCD) por parte de un tercer servicio. No afecta a la autenticación normal de esa cuenta contra los servicios a los que accede directamente. Es una restricción unidireccional pensada exactamente para cuentas privilegiadas que no deberían formar parte nunca de una cadena de delegación de terceros.

¿Es RBCD «más segura» que constrained delegation clásica solo por ser más moderna?

No necesariamente; son modelos de confianza distintos, no una jerarquía de seguridad. RBCD traslada el control al objeto destino, lo cual puede ser positivo (delegar la gestión sin requerir privilegios de Domain Admin) pero también negativo, porque abre la puerta a que cualquiera con permisos de escritura sobre un objeto de equipo cree su propia ruta de delegación sin que un administrador de dominio lo haya decidido conscientemente. La seguridad real depende de cómo estén auditadas las ACLs de escritura sobre esos objetos, no del modelo en sí.

¿Cómo priorizo si encuentro varios tipos de delegación peligrosa a la vez en una auditoría real?

Como regla general: primero neutraliza el impacto sobre cuentas privilegiadas (NOT_DELEGATED + Protected Users sobre Domain Admins/Enterprise Admins/Tier 0), porque es la medida de mayor retorno y menor esfuerzo, y corta el impacto de los tres modelos simultáneamente. Después, elimina toda unconstrained delegation que no esté justificada, empezando por servidores con mayor exposición (accesibles desde redes de usuario, con RDP abierto, etc.). Por último, revisa y acota constrained delegation (SPNs hacia DCs) y audita las ACLs de escritura que habilitan RBCD no autorizada.

«Unconstrained Delegation should be avoided whenever possible given the risk it poses to Active Directory… If a computer with Unconstrained Delegation is compromised, all cached Kerberos TGTs (Ticket Granting Tickets) on that computer can be extracted… This means an attacker could potentially get the Domain Admin’s Kerberos TGT and use it to compromise the domain.»

— Sean Metcalf, ADSecurity.org, «Kerberos & KRBTGT: Active Directory’s Domain Kerberos Service Account» / serie sobre Kerberos Delegation (adsecurity.org)

Módulo 8: Delegación de Kerberos — riesgos y endurecimiento