Kerberos Delegations
La delegación Kerberos permite que un servicio se autentique ante otro servicio en nombre del usuario original. Existen tres tipos, cada uno con distinto nivel de riesgo: unconstrained, constrained y resource-based constrained.
Links: S4U2Proxy - Microsoft | S4U2Self - Microsoft | Active Directory Extensions - Microsoft
Concepto general
Un usuario se autentica contra un servicio (ej: web server). Ese servicio necesita acceder a otro recurso (ej: base de datos) con los mismos permisos del usuario, no con permisos propios. La delegación permite que el servicio "se haga pasar" por el usuario ante el segundo recurso.
Unconstrained Delegation
El servicio puede impersonar al usuario ante cualquier otro servicio del dominio. Es la opción más permisiva y peligrosa.
Configuración
En la pestaña Delegation de la cuenta: Trust this computer for delegation to any service (Kerberos only).
Solo un admin o cuenta con el privilegio SeEnableDelegationPrivilege puede habilitarlo. Una cuenta de servicio no puede auto-configurarse esta opción.
Cómo funciona internamente
Activa el flag TRUSTED_FOR_DELEGATION en el UAC de la cuenta. Cuando un usuario solicita un TGS para ese servicio, el DC incluye una copia del TGT del usuario dentro del TGS ticket. El servicio puede extraer ese TGT y usarlo para solicitar TGS tickets a cualquier otro servicio, actuando como el usuario.
Constrained Delegation
El servicio solo puede impersonar al usuario ante una lista definida de servicios.
Configuración
En la pestaña Delegation: Trust this computer for delegation to specified services only. La lista de servicios permitidos se guarda en el atributo msDS-AllowedToDelegateTo de la cuenta de servicio.
Cómo funciona internamente
No se envía una copia completa del TGT. En su lugar, el servicio hace una petición TGS especial que incluye:
- additional tickets — Copia del TGS ticket que el usuario envió al servicio
- cname-in-addl-tkt — Flag que indica al DC usar la información del ticket adjunto (el usuario) en lugar de la del servidor
El DC verifica que el servicio tenga permiso de delegar al recurso solicitado y que el TGS sea forwardable (a menos que la cuenta tenga Account is sensitive and cannot be delegated).
Resource-Based Constrained Delegation (RBCD)
Invierte la responsabilidad: en lugar de que el servicio defina a qué recursos puede delegar, es el recurso destino quien define qué cuentas tienen permiso de delegar hacia él.
Configuración
El recurso mantiene una lista de confianza en su atributo msDS-AllowedToActOnBehalfOfOtherIdentity. A diferencia de los otros dos tipos, cualquier cuenta de servicio puede modificar su propia lista sin necesitar privilegios especiales de admin.
El atributo msDS-AllowedToActOnBehalfOfOtherIdentity
Este es el atributo central de RBCD y la principal diferencia respecto a los otros dos tipos de delegación. En unconstrained y constrained delegation, la configuración vive en el servicio que origina la delegación (TRUSTED_FOR_DELEGATION o msDS-AllowedToDelegateTo). En RBCD, en cambio, la configuración vive en el objeto que recibe la delegación, es decir, en el recurso final.
Técnicamente es un Security Descriptor (una estructura tipo DACL) que define qué cuentas (principals) están autorizadas a actuar en nombre de otra identidad ante ese recurso. Cuando se agrega una cuenta a este atributo, se le está diciendo al recurso destino: "confío en que esta cuenta puede pedir tickets en nombre de cualquier usuario para acceder a mí".
Esto es relevante desde el punto de vista ofensivo porque, a diferencia de SeEnableDelegationPrivilege (necesario para configurar unconstrained o constrained delegation), modificar msDS-AllowedToActOnBehalfOfOtherIdentity solo requiere tener permisos de escritura (GenericWrite, GenericAll, o ser dueño del objeto) sobre la cuenta de la computadora destino, algo mucho más común de encontrar en un dominio real. Esto convierte a RBCD en un vector de escalada de privilegios muy explotado cuando un atacante controla una cuenta de máquina o tiene privilegios de escritura sobre un objeto computer.
Agregar una cuenta a la lista de confianza
Import-Module ActiveDirectory
Set-ADComputer <RECURSO_DESTINO> -PrincipalsAllowedToDelegateToAccount (Get-ADComputer <SERVICIO_ORIGEN>)Cómo funciona internamente
Igual que constrained delegation (TGS con additional tickets), pero el DC verifica la lista de confianza en el recurso destino en lugar de en el servicio origen.
S4U2Proxy (Service for User to Proxy)
Es la extensión que implementa la petición TGS descrita en constrained delegation y RBCD. El servicio solicita un TGS para el recurso final incluyendo una copia del TGS ticket del usuario.
S4U2Self (Service for User to Self)
Resuelve el caso donde el usuario se autenticó contra el servicio sin Kerberos (por ejemplo, vía NTLM), por lo que el servicio no tiene un TGS ticket del usuario para usar en S4U2Proxy.
Permite que el servicio solicite un TGS forwardable hacia sí mismo en nombre de un usuario arbitrario, simulando que el usuario se autenticó vía Kerberos. Una vez obtenido ese TGS, lo usa en la petición S4U2Proxy.
Esto se llama protocol transition.
Habilitación de S4U2Self
Se controla en la configuración de constrained delegation:
Use Kerberos only— Deshabilita S4U2Self, no permite protocol transitionUse any authentication protocol— Habilita S4U2Self, permite crear un TGS para cualquier usuario arbitrario
Importante:
Use any authentication protocoles peligroso porque permite generar tickets para usuarios arbitrarios sin que estos se hayan autenticado realmente, lo cual es la base de varios ataques de abuso de delegación.
Resumen comparativo
- Unconstrained — Impersona a cualquier servicio. Riesgo: máximo. Copia completa del TGT.
- Constrained — Impersona solo a servicios en
msDS-AllowedToDelegateTo. Riesgo: medio-alto si tieneUse any authentication protocol. - RBCD — El recurso destino controla quién puede delegar via
msDS-AllowedToActOnBehalfOfOtherIdentity. Riesgo: cualquier cuenta de servicio puede auto-configurarse como confiable.