# 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 ([**ver sección Entendiendo Active Directory → Elementos jerárquicos de AD**](https://securitylayer.gitbook.io/kerberoscity/entendiendo-active-directory/2-elementos-jerarquicos-de-ad)). 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)**

{% code fullWidth="true" %}

```vim
+----------------------+-------------------------------+-----------------------------------------------+
| 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                   |
+----------------------+-------------------------------+-----------------------------------------------+
```

{% endcode %}

#### 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.&#x20;
* 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:

1. **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 `servicePrincipalName` del objeto de equipo `sql01$`.
2. **Proceso en ejecución**:
   * El servicio MSSQL se ejecuta en `sql01` como 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.
3. **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 `sqlsvc` o `sql01$`).
* 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 `sqlsvc` podrá 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:

1. **Indicador `NotDelegated` (`ADS_UF_NOT_DELEGATED`)**\
   Se configura en el atributo `userAccountControl` de la cuenta y bloquea cualquier tipo de delegación.
2. **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.&#x20;

**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).

<figure><img src="https://3952817437-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fa7XmBBD8fWuk6wM75Um3%2Fuploads%2FkaKvAmmK3KPIOYqib9GG%2Funconstrained.png?alt=media&#x26;token=dd2cd63b-602c-459a-9b73-e118840ce362" alt=""><figcaption></figcaption></figure>

#### 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 `forwardable` y atributos como `msDS-AllowedToDelegateTo` aseguran 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.

<figure><img src="https://3952817437-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fa7XmBBD8fWuk6wM75Um3%2Fuploads%2FnbsnU9gOGro8g00aByeD%2Fconstrained.png?alt=media&#x26;token=b8901de5-862b-44cf-b450-cc151f9d8561" alt=""><figcaption></figcaption></figure>

#### 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-AllowedToActOnBehalfOfOtherIdentity` en un recurso, puede generar tickets en nombre de usuarios privilegiados.
* Requiere estrictos controles de permisos y auditoría para prevenir abusos.

<figure><img src="https://3952817437-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fa7XmBBD8fWuk6wM75Um3%2Fuploads%2FZqYEqelpm4UILqTMDZFp%2FRBCD.png?alt=media&#x26;token=f4a49f8c-3839-49df-af21-c5462acb94a9" alt=""><figcaption></figcaption></figure>

Resumiendo las tres modalidades de delegacion:

{% code fullWidth="true" %}

```
| 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)        |
```

{% endcode %}
