4 - Kerberos delegation
Para comprender adecuadamente los mecanismos de delegación en Kerberos —especialmente la Delegación Restringida Basada en Recursos (RBCD)— es esencial entender cómo se relacionan los siguientes conceptos clave: usuarios, computadoras y servicios. La delegación no ocurre en el vacío; se basa en la interacción entre estos elementos en el contexto de Active Directory (AD).
Usuarios y Computadoras
En Active Directory, un usuario es una entidad representada por una cuenta. Esta cuenta puede ser utilizada por una persona física o un proceso automatizado. Existen dos tipos relevantes:
Cuentas de usuario estándar: utilizadas por personas para realizar tareas cotidianas o por scripts para funciones específicas (por ejemplo, backups).
Cuentas de equipo: utilizadas por las computadoras del dominio. En AD, los nombres de estas cuentas terminan en el carácter
$. Desde la perspectiva de Active Directory, las computadoras son tratadas como una subclase de usuario, lo cual es fundamental para entender los privilegios y capacidades en los escenarios de delegación.
Veamos el siguiente ejemplo de formatos comunes de cuentas en Active Directory, tanto para usuarios como para equipos y cuentas especiales (administrator y krbtgt)
+----------------------+-------------------------------+-----------------------------------------------+
| Tipo de cuenta | Formato | Ejemplo |
+----------------------+-------------------------------+-----------------------------------------------+
| Usuario | sAMAccountName | johndoe |
| | UPN (User Principal Name) | johndoe@DOMAIN.LOCAL |
| | DN (Distinguished Name) | CN=John Doe,OU=Users,DC=DOMAIN,DC=LOCAL |
| | SID | S-1-5-21-XXXXXXXXX-...-1103 |
+----------------------+-------------------------------+-----------------------------------------------+
| Equipo (máquina) | sAMAccountName | pc-01$ |
| | Nombre DNS (FQDN) | pc-01.DOMAIN.LOCAL |
| | DN | CN=PC-01,OU=Computers,DC=DOMAIN,DC=LOCAL |
| | SID | S-1-5-21-XXXXXXXXX-...-1105 |
+----------------------+-------------------------------+-----------------------------------------------+
| Cuenta especial | sAMAccountName | Administrator |
| (Administrador) | UPN | Administrator@DOMAIN.LOCAL |
| | DN | CN=Administrator,CN=Users,DC=DOMAIN,DC=LOCAL |
| | SID | S-1-5-21-XXXXXXXXX-...-500 |
+----------------------+-------------------------------+-----------------------------------------------+
| Cuenta especial | sAMAccountName | krbtgt |
| (Kerberos TGT) | UPN | krbtgt@DOMAIN.LOCAL |
| | DN | CN=krbtgt,CN=Users,DC=DOMAIN,DC=LOCAL |
| | SID | S-1-5-21-XXXXXXXXX-...-502 |
+----------------------+-------------------------------+-----------------------------------------------+
| Servicio Web | sAMAccountName | websvc |
| | UPN | websvc@DOMAIN.LOCAL |
| | SPN | HTTP/web01.DOMAIN.LOCAL |
| | DN |CN=websvc,OU=ServiceAccounts,DC=DOMAIN,DC=LOCAL|
| | SID | S-1-5-21-XXXXXXXXX-...-1110 |
+----------------------+-------------------------------+-----------------------------------------------+
| Servicio SQL | sAMAccountName | sqlsvc |
| | UPN | sqlsvc@DOMAIN.LOCAL |
| | SPN | MSSQLSvc/sql01.DOMAIN.LOCAL |
| | DN |CN=sqlsvc,OU=ServiceAccounts,DC=DOMAIN,DC=LOCAL|
| | SID | S-1-5-21-XXXXXXXXX-...-1111 |
+----------------------+-------------------------------+-----------------------------------------------+Servicios
Un servicio en el contexto de Kerberos se caracteriza por:
Estar identificado por un SPN (Service Principal Name) en Active Directory. Este SPN asocia un nombre de servicio con su cuenta de ejecución y equipo host.
Ser ejecutado como un proceso dentro de un equipo, aunque no necesita estar activo para que un cliente obtenga un TGS para él.
Ejecutarse bajo el contexto de seguridad de una cuenta de usuario, que suele ser la cuenta de equipo del host, aunque puede ser una cuenta de usuario estándar.
Poder ser accedido por cualquier usuario del dominio, sin restricción previa de autorización en la emisión del TGS.
Ejemplo: Servicio MSSQL ejecutado en un servidor del dominio
Contexto:
El servidor de base de datos se llama
sql01.domain.local.El servicio SQL Server se ejecuta con la cuenta de equipo:
sql01$@DOMAIN.LOCAL.El SPN registrado en Active Directory es:
MSSQLSvc/sql01.domain.local:1433
Detalles técnicos aplicados:
SPN (Service Principal Name):
Este SPN (
MSSQLSvc/sql01.domain.local:1433) es único y permite al KDC identificar el servicio para emitir TGS adecuados.Se encuentra en el atributo
servicePrincipalNamedel objeto de equiposql01$.
Proceso en ejecución:
El servicio MSSQL se ejecuta en
sql01como un proceso de sistema (sqlservr.exe), pero incluso si el proceso está detenido, cualquier cliente aún puede solicitar un TGS para ese SPN, porque Kerberos no comprueba la disponibilidad del servicio al emitir el ticket.
Contexto de ejecución:
El servicio se ejecuta bajo el contexto de seguridad de la cuenta de equipo (
sql01$), por lo que todos los privilegios y permisos de esa cuenta aplican a las operaciones realizadas por el servicio.Alternativamente, un administrador puede configurar el servicio para que se ejecute bajo una cuenta de usuario dedicada (por ejemplo,
sqlsvc@DOMAIN.LOCAL), y entonces los privilegios serán los de esa cuenta.
Dado que un servicio hereda los privilegios de su cuenta propietaria, cualquier SPN registrado en una cuenta con capacidad de delegación puede heredar esa capacidad. Los SPNs se almacenan en el atributo servicePrincipalName de la cuenta correspondiente. Para modificar ese atributo se requiere el permiso Validated-SPN, que en cuentas de usuario estándar sólo está disponible para administradores o roles delegados.
Servicios y Delegación
1. Los servicios usan cuentas de usuario o de equipo
En Active Directory, un servicio (como un servidor web, una base de datos, etc.) no tiene identidad propia.
Cuando un servicio se ejecuta, lo hace "como" una cuenta del dominio: puede ser una cuenta de usuario o una cuenta de equipo (como
sqlsvcosql01$).Esa cuenta es la que representa al servicio ante el sistema.
2. La delegación depende de la cuenta, no del proceso
La delegación Kerberos es una capacidad que permite que un servicio actúe en nombre de un usuario para autenticarse en otro servicio, es como si el servicio "A" tuviese la capacidad de impersonar al usuario "X" que quiere comunicarse con otros servicios del dominio "B" y "C".
Para que un proceso pueda hacer delegación, la cuenta con la que se está ejecutando debe tener permisos de delegación en AD.
3. El KDC solo ve a la cuenta, no al proceso
Cuando un servicio pide un ticket al KDC (Key Distribution Center), el KDC no distingue qué proceso lo pide.
Solo ve: “esta cuenta de dominio está haciendo una solicitud”.
Entonces, todos los procesos que corren bajo esa misma cuenta tienen los mismos derechos de delegación.
Ejemplo práctico
Supongamos que el servicio SQLServer se ejecuta con la cuenta sqlsvc@domain.local.
Si en Active Directory se le permite delegar credenciales a esa cuenta (
sqlsvc):Cualquier proceso que se ejecute como
sqlsvcpodrá delegar.No importa si el proceso es
sqlservr.exe, un script, o un malware: el KDC no lo sabe.
Por eso, una cuenta que tiene delegación habilitada puede ser peligrosa si es comprometida, porque se puede abusar esa capacidad desde cualquier proceso
Entonces en términos de delegación, como los servicios se ejecutan con la identidad de una cuenta de usuario (o equipo), sólo podrán delegar si dicha cuenta tiene permisos para hacerlo. En la práctica, cuando un proceso interactúa con el KDC, el KDC identifica únicamente al usuario propietario del proceso, no al proceso en sí. Es decir, cualquier proceso que se ejecute bajo esa cuenta tendrá los mismos privilegios de delegación
Mecanismos de restricción
Active Directory permite evitar que ciertas cuentas sean objeto de delegación, a través de dos mecanismos:
Indicador
NotDelegated(ADS_UF_NOT_DELEGATED) Se configura en el atributouserAccountControlde la cuenta y bloquea cualquier tipo de delegación.Grupo "Protected Users" (desde Windows Server 2012 R2) Las cuentas miembros de este grupo tienen múltiples restricciones:
No pueden usar autenticación NTLM.
No pueden usar cifrados débiles como DES o RC4 para pre autenticación Kerberos.
No pueden ser objeto de delegación (de ningún tipo).
No pueden renovar TGTs más allá de las 4 horas de vida inicial.
Estas medidas deben considerarse antes de aplicar técnicas o configuraciones de delegación, ya que bloquean completamente su funcionamiento
Tipos de delegación en Kerberos
Existen tres tipos principales de delegación Kerberos, cada uno con características y controles diferentes, a continuación se los describirá brevemente:
1. Delegación sin restricciones (Unconstrained Delegation)
Descripción: Este es el modelo más antiguo y menos seguro de delegación. Cuando una cuenta de equipo tiene configurada una delegación sin restricciones, cualquier servicio que se ejecute en ese sistema puede impersonar a cualquier usuario que se autentique en él, y acceder en su nombre a cualquier otro servicio del dominio.
Funcionamiento: Cuando un usuario "A" se autentica en un servidor "B" con delegación sin restricciones (ver imagen paso 3), el KDC (Key Distribution Center) le entrega su TGT (Ticket Granting Ticket) al servidor. Esto permite que el servidor "B" use ese TGT para solicitar nuevos tickets TGS hacia cualquier otro servicio "X" en nombre del usuario "A" (ver imagen paso 4 y 5).
Desventajas:
Representa un riesgo crítico de seguridad.
Si un atacante compromete un sistema con este tipo de delegación, podrá suplantar cualquier usuario para acceder a cualquier servicio, incluyendo controladores de dominio (DCs).
2. Delegación restringida (Constrained Delegation)
Descripción: Introducida en Windows Server 2003, esta variante mejora el control al limitar los servicios a los que una cuenta puede delegar. Es decir, el servicio puede actuar en nombre de un usuario solo para determinados servicios específicos, definidos explícitamente por un administrador.
Funcionamiento: Se utilizan dos extensiones del protocolo Kerberos:
S4U2Self (Service for User to Self): permite a un servicio obtener un TGS reenviable para sí mismo en nombre de un usuario, sin necesidad de conocer la contraseña ni tener el TGT original del usuario. El KDC verifica la identidad del usuario a partir del PAC contenido en el ticket inicial.
S4U2Proxy (Service for User to Proxy): permite a ese mismo servicio usar ese TGS reenviable para solicitar un nuevo TGS hacia un servicio específico, autorizado mediante el atributo
msDS-AllowedToDelegateTo.
Ventajas:
Más control y seguridad respecto a la delegación sin restricciones. Los flags como
forwardabley atributos comomsDS-AllowedToDelegateToaseguran que esta delegación sea controlada.Los servicios destino están claramente especificados.
Desventajas:
La configuración debe hacerse desde la cuenta de servicio que realizará la delegación.
Requiere privilegios administrativos en el dominio para configurar correctamente.
3. Delegación restringida basada en recursos (Resource-Based Constrained Delegation – RBCD)
Descripción: RBCD fue introducida en Windows Server 2012 para ofrecer un modelo más seguro y descentralizado. A diferencia de la delegación restringida tradicional, la configuración se define en el recurso destino (por ejemplo, el servidor al que se quiere acceder), en lugar del servicio que solicita la delegación. RBCD es una forma moderna de delegación que invierte el control: en lugar de definir en el servidor origen (servicio A) hacia dónde puede delegar, se configura en el servidor destino (servicio B) quiénes tienen permitido actuar en nombre de otros usuarios.
Funcionamiento:
El atributo clave aquí es msDS-AllowedToActOnBehalfOfOtherIdentity, que se establece en el objeto de equipo del recurso (por ejemplo, un controlador de dominio o servidor de archivos). Este atributo contiene un descriptor de seguridad (SD) que define qué equipos o usuarios tienen permiso para delegar hacia él. El flujo también utiliza S4U2Self y S4U2Proxy
Ventajas:
Descentraliza la configuración, lo cual es útil en entornos con múltiples administradores de servicios.
Permite que los administradores del recurso tengan el control de quién puede delegar hacia su servicio.
Desventajas:
Si un atacante consigue modificar el atributo
msDS-AllowedToActOnBehalfOfOtherIdentityen un recurso, puede generar tickets en nombre de usuarios privilegiados.Requiere estrictos controles de permisos y auditoría para prevenir abusos.
Resumiendo las tres modalidades de delegacion:
| Tipo de delegación | ¿Quién controla **a quién se puede delegar**? | ¿Quién ejecuta la delegación en sí? |
| ------------------------------ | ------------------------------------------------------------------------------------------| ----------------------------------- |
| **Unconstrained Delegation** | El **servicio delegado** (`Servicio A`) | El servicio A (porque tiene el TGT) |
| **Constrained Delegation** | El **KDC**, basado en lo que está definido en el servicio delegado (`Servicio A`) | El KDC (verifica y emite TGS) |
| **Resource-Based Constrained** | El **servicio destino** (`Servicio B`), porque **decide quién puede actuar en su nombre** | El KDC (como en Constrained) |Last updated