Que es la delegacion Kerberos?
La delegacion Kerberos permite que un servicio use la identidad de un usuario para acceder a otro servicio en su nombre. En Active Directory esto no es automaticamente una mala practica: muchas aplicaciones multitier la necesitan. El problema aparece cuando el alcance de esa delegacion es demasiado amplio, cuando nadie revisa que servicios pueden delegar y hacia donde, o cuando se mezcla con cuentas privilegiadas, servidores heredados y permisos mal entendidos.
Microsoft distingue claramente tres modelos que un equipo tecnico debe separar durante una auditoria:
- delegacion no restringida
- delegacion restringida
- resource-based constrained delegation (RBCD)
Tratar los tres como si fueran lo mismo lleva a remediaciones pobres. No todos tienen el mismo riesgo, ni se administran en el mismo objeto, ni delegan el control al mismo administrador.
Como funciona cada modelo
Delegacion no restringida
La delegacion no restringida es la forma mas amplia. El servicio puede reutilizar credenciales delegadas hacia cualquier otro servicio. En la practica, esto convierte al servidor que delega en un punto de alta confianza. Si ese servidor cae, la identidad delegada puede usarse mucho mas alla de la aplicacion original.
Por eso Microsoft lleva años empujando a migrar desde este modelo hacia alternativas mas acotadas. No es un control fino. Es una confianza amplia y dificil de justificar fuera de casos muy concretos y legacy.
Delegacion restringida
La delegacion restringida limita a que servicios backend puede delegar un servicio frontend. Microsoft documenta que este modelo reduce la superficie frente a la delegacion no restringida porque define destinos concretos en lugar de conceder carta blanca.
La lectura correcta para defensa no es solo "esta usando delegacion restringida, entonces esta bien". La pregunta real es:
- a que SPN o servicio backend puede delegar
- si el servicio frontend deberia seguir existiendo con ese rol
- si el owner de la aplicacion sigue siendo el correcto
RBCD
La resource-based constrained delegation cambia algo importante: el control de la delegacion pasa al propietario del recurso backend. Microsoft documenta que el backend puede decidir que servicios frontend pueden actuar en nombre de usuarios sobre ese recurso mediante PrincipalsAllowedToDelegateToAccount.
Esto resuelve varios problemas de administracion cruzada, pero introduce otro: si nadie revisa ese atributo y las ACL que lo protegen, el backend puede terminar aceptando delegacion de principals que no deberian tener ese nivel de confianza.
Microsoft tambien documenta que en RBCD el KDC siempre permite protocol transition como si el bit correspondiente estuviera habilitado, y que la distincion entre identidades afirmadas por servicio y por autoridad de autenticacion se expone con SIDs especificos. Para un lector tecnico, esto significa que RBCD no es un simple switch moderno "mas seguro". Es una forma distinta de modelar y delegar la confianza.
Donde aparece el riesgo real
La delegacion Kerberos se vuelve peligrosa cuando coincide con alguno de estos escenarios:
- servidores con delegacion no restringida fuera de un caso legacy estrictamente controlado
- cuentas de servicio con SPN y privilegios excesivos
- atributos de delegacion revisados una vez y nunca mas
- objetos backend cuyo
PrincipalsAllowedToDelegateToAccountconcede mas confianza de la necesaria - cuentas sensibles que deberian estar fuera de la delegacion por diseño
Microsoft documenta que los miembros de Protected Users no pueden usar delegacion con constrained ni unconstrained delegation. Esto es util para cuentas administrativas humanas de alto riesgo. No arregla por si solo la delegacion de la aplicacion, pero ayuda a separar identidades que nunca deberian viajar por estos flujos.
Auditoria tecnica minima
1. Encontrar delegacion no restringida
Get-ADComputer -Filter {TrustedForDelegation -eq $true} |
Select-Object Name, DistinguishedName
Get-ADUser -LDAPFilter "(userAccountControl:1.2.840.113556.1.4.803:=524288)" |
Select-Object SamAccountName, DistinguishedName
Si este listado devuelve servidores o cuentas que nadie esperaba, ya tienes una deuda tecnica importante.
2. Revisar delegacion restringida
Get-ADComputer -Filter * -Properties msDS-AllowedToDelegateTo |
Where-Object {$_."msDS-AllowedToDelegateTo"} |
Select-Object Name, msDS-AllowedToDelegateTo
Aqui la pregunta no es solo si existe delegacion, sino si los destinos siguen siendo validos y minimos.
3. Revisar RBCD
Get-ADComputer -Filter * -Properties PrincipalsAllowedToDelegateToAccount |
Where-Object {$_.PrincipalsAllowedToDelegateToAccount} |
Select-Object Name, PrincipalsAllowedToDelegateToAccount
RBCD requiere revisar tanto el valor del atributo como quien puede modificarlo. Si las ACL sobre el objeto backend son demasiado amplias, la confianza puede alterarse sin que el equipo lo note.
4. Revisar cuentas sensibles que nunca deberian delegarse
En muchos entornos la delegacion se audita en el servidor, pero no en la identidad usuaria. Conviene revisar explicitamente cuentas de alto valor y confirmar si tienen activado Account is sensitive and cannot be delegated o si estan en grupos como Protected Users cuando el caso de uso lo permite.
Esta validacion es importante porque reduce el riesgo de que una aplicacion con delegacion legitima capture o reutilice identidades que nunca deberian viajar mas alla del primer salto.
5. Mapear el owner tecnico de cada SPN y de cada backend delegado
La auditoria no deberia quedarse en la lista de atributos. Conviene poder responder para cada flujo relevante:
- que aplicacion o servicio usa esa delegacion
- quien es el owner tecnico o funcional
- si el SPN sigue activo y documentado
- si el backend destino sigue siendo el mismo que el diseno original
Buena parte de la delegacion peligrosa no sobrevive por necesidad tecnica, sino por falta de ownership. Cuando nadie sabe por que existe un msDS-AllowedToDelegateTo o un PrincipalsAllowedToDelegateToAccount, el riesgo ya es alto aunque el atributo no haya sido abusado todavia.
Detection
La deteccion util para delegacion Kerberos combina inventario y cambio.
Hay que vigilar:
- modificaciones de atributos de delegacion en AD
- nuevos equipos o cuentas que entren en el conjunto de delegacion no restringida
- cambios en
msDS-AllowedToDelegateTo - cambios en
PrincipalsAllowedToDelegateToAccount - altas de cuentas de servicio con SPN nuevos y permisos excesivos
Un evento como 5136 puede ayudar a ver cambios de objetos de directorio, pero no sustituye una revision periodica del estado real. La mejor postura es mantener una fotografia versionada de:
- objetos con delegacion no restringida
- objetos con delegacion restringida y sus destinos
- objetos backend que aceptan RBCD
- cuentas privilegiadas protegidas con
Account is sensitive and cannot be delegatedo con Protected Users cuando corresponda
Remediacion
1. Eliminar delegacion no restringida salvo justificacion muy fuerte
Get-ADComputer -Filter {TrustedForDelegation -eq $true} |
ForEach-Object { Set-ADComputer -Identity $_ -TrustedForDelegation $false }
No conviene aplicar esto a ciegas en produccion, pero si como principio de hardening: la delegacion no restringida deberia ser excepcional y tener un owner claro.
2. Reducir delegacion restringida a lo minimo posible
Si una aplicacion necesita constrained delegation, el objetivo es que solo pueda delegar a los SPN exactos y aun vigentes. Toda entrada vieja o heredada debe desaparecer.
3. Tratar RBCD como confianza sobre el recurso
En RBCD el backend decide. Por eso la remediation correcta no se limita a listar el atributo. Tambien hay que revisar:
- ACL del objeto backend
- owners reales del servicio
- necesidad funcional del flujo
- existencia de alternativas sin delegation tan amplia
4. Proteger identidades sensibles
Para cuentas administrativas humanas o de alto valor:
- usar Protected Users donde sea viable
- aplicar
Account is sensitive and cannot be delegatedcuando corresponda - evitar que credenciales Tier 0 entren en servicios o saltos que dependan de delegacion
5. Revisar el diseño, no solo el bit
Un entorno con mucha delegacion rara vez tiene un problema de un solo atributo. Suele tener un problema de arquitectura: frontends demasiado confiados, cuentas de servicio con demasiado alcance y poca separacion entre operacion y privilegio.
6. Probar el flujo de la aplicacion despues del cambio
Muchos equipos corrigen la delegacion y solo despues descubren que la aplicacion dependia de un salto concreto o de un SPN olvidado. La validacion correcta debe probar:
- autenticacion del usuario al frontend
- acceso del frontend al backend esperado
- ausencia de destinos de delegacion no documentados
- comportamiento de cuentas sensibles marcadas como no delegables
Sin esta prueba, es habitual que la organizacion reactive una delegacion amplia por urgencia operativa y que el hallazgo reaparezca semanas despues.
Validacion
La validacion correcta debe demostrar que:
- el inventario de delegacion no restringida es minimo y justificado
- los destinos de constrained delegation siguen siendo los correctos
- los recursos con RBCD aceptan solo a los principals esperados
- las cuentas sensibles no pueden ser delegadas accidentalmente
- los cambios no rompieron la aplicacion legitima
Si el equipo solo cambia atributos y no prueba el flujo real de la aplicacion, el riesgo operativo termina devolviendo la mala configuracion poco despues. Tambien conviene registrar que aplicacion, servicio o owner pidio la delegacion y que evidencia funcional justifica mantenerla. Esa trazabilidad reduce muchisimo el numero de excepciones olvidadas en revisiones futuras.
Evidencia minima que merece conservarse
Para mantener este control en el tiempo conviene guardar:
- listado aprobado de equipos o cuentas con delegacion no restringida, si queda alguno
- destinos autorizados de constrained delegation por servicio
- inventario de backends con RBCD y principals autorizados
- resultado de la prueba funcional tras la remediacion
Con esa evidencia, la siguiente revision puede centrarse en la deriva real y no en reconstruir desde cero el mapa de confianza entre servicios.
Fuentes primarias
- Kerberos Constrained Delegation Overview in Windows Server
- Protected Users security group
- Kerberos authentication overview in Windows Server
Como EtcSec detecta esto
EtcSec cubre este tema con varios hallazgos relacionados:
- UNCONSTRAINED_DELEGATION
- CONSTRAINED_DELEGATION
- RBCD_ABUSE
La pregunta util no es solo si existe delegacion. La pregunta util es si la confianza entre servicios sigue limitada al caso de uso real o si ya se convirtio en una ruta lateral disponible para cualquiera que comprometa el servidor equivocado.
