Constrained Delegation

Ejemplo práctico

Dado los siguientes elementos el modelo Constrained Delegation funcionaria de la siguiente manera

Elemento          : Nombre                         : Tipo
------------------:------------------------------- :-------------------------------
Usuario           : johndoe@DOMAIN.LOCAL           : Cuenta de usuario
Servidor frontend : mail01.domain.local            : Cuenta de equipo/servicio (MAIL01$)
Servicio delegado : HTTP/mail01.domain.local       : SPN registrado en MAIL01$
Servidor destino  : sql01.domain.local             : Cuenta de servicio (MSSQLSvc/sql01.domain.local)
Servicio destino  : MSSQLSvc/sql01.domain.local    : SPN del servicio destino

Nota: Aunque se trate de un "Mail Server", si la aplicación expone un frontend web (como Outlook Web Access, Exchange Admin Center, etc.), entonces el SPN usado para ese acceso web es HTTP/...

Escenario: johndoe accede al servicio web de correo en mail01, y este servidor actúa en su nombre para acceder a sql01, pero solo porque se le ha permitido específicamente en AD.

1. `AS_REQ` / `AS_REP` – `johndoe` obtiene su TGT

Cliente solicita TGT del KDC (igual que en todos los flujos Kerberos).
El KDC entrega el TGT de johndoe
Al igual que en Unconstrained Delegation se deben respetar las siguientes flags
- Not_Delegate = false para el usuario johndoe
- Protected_Users = false para el usuario johndoe

2. `TGS_REQ` / `TGS_REP` – `johndoe` solicita acceso a `HTTP/mail01.domain.local`

johndoe pide al KDC un TGS para el SPN del mail server.
Este TGS no contiene el TGT reenviable, porque estamos usando Constrained Delegation.
En vez de enviar el TGT, se usará un mecanismo especial más seguro que explicamos abajo.
johndoe se conecta a mail01 y le entrega el TGS
Del lado del servicio se deben encontrar las siguientes condiciones:
- Trusted_for_Delegation = true
- msDS-AllowedToDelegateTo = MSSQLSvc/sql01.domain.local Esto es la lista blanca donde aparecen todos los servicios (SPN) a los que el mail server puede delegar

3. Delegación: `mail01` actúa como `johndoe` hacia `sql01`

MAIL01$ quiere acceder al servicio MSSQLSvc/sql01.domain.local como si fuera johndoe.
Para eso, usa el Service-for-User-to-Self (S4U2self) y Service-for-User-to-Proxy (S4U2proxy):

a. S4U2self: MAIL01$ pide un ticket para sí mismo en nombre de johndoe

KDC verifica que johndoe se autenticó previamente al SPN HTTP/mail01.
Si todo está bien, el KDC le entrega un TGS especial a MAIL01$ en nombre de johndoe.
- Este ticket sólo es válido hacia mail01, y no sirve para delegar todavía.
- El ticket S4U2Self es válido solo hacia el servicio mismo (ej: HTTP/mail01)
- No puede ser reenviado a otros servicios y no puede ser usado para conexión directa entre servicios
- Solo puede usarse como base para S4U2Proxy

b. S4U2proxy: MAIL01$ usa ese ticket para obtener un TGS para sql01

MAIL01$ presenta el S4U2self al KDC y dice:
"Quiero un TGS para MSSQLSvc/sql01.domain.local, actuando como johndoe"
El KDC consulta el atributo msDS-AllowedToDelegateTo de MAIL01$
- Si incluye MSSQLSvc/sql01.domain.local, se permite la delegación

Entonces, ¿qué guarda `MAIL01$`?

En Constrained Delegation, MAIL01$ no guarda nada persistente ni sensible del usuario.
Solo realiza un proceso de suplantación temporal en cada sesión, mediante el KDC.
Es el KDC quien firma y respalda esa suplantación controlada.

4. Acceso final: `mail01` accede a `sql01` como `johndoe`

mail01 se conecta al servicio SQL usando el TGS2.
sql01 verifica el ticket y permite el acceso como si fuera johndoe.

Resumen de configuraciones que debemos tener en cuenta cuando hablamos de Constrained Delegation

+----------------------+----------------------------------------------+------------------------------------------------------------+
| Elemento             | Configuración                                | Descripción                                                |
+----------------------+----------------------------------------------+------------------------------------------------------------+
| Usuario              | NOT_DELEGATED = FALSE                        | Permite que su TGS sea reenviable                          |
|                      | Miembro de Protected Users = FALSE           | Usuarios protegidos no permiten delegación                 |
|                      | TGS con flag "forwardable" = TRUE            | Necesario para que el servicio pueda usarlo en S4U2Proxy   |
+----------------------+----------------------------------------------+------------------------------------------------------------+
| Servicio que delega  | SPN registrado correctamente                 | Ej: HTTP/web01.domain.local                                |
| (ej. Web Server)     | Delegación habilitada:                       | Seleccionar: "Trust this user for delegation to specified  |
|                      | → "Use Kerberos only"                        | services only" en modo seguro                            |
|                      | Atributo msDS-AllowedToDelegateTo            | Contiene los SPN de servicios destino autorizados          |
+----------------------+----------------------------------------------+------------------------------------------------------------+
| Servicio destino     | SPN registrado correctamente                 | Ej: MSSQLSvc/sql01.domain.local                            |
| (ej. SQL Server)     |                                              | No requiere más configuración explícita                    |
+----------------------+----------------------------------------------+------------------------------------------------------------+
| KDC (Controlador de  | Verifica PAC del usuario                     | Se extrae del TGS recibido en S4U2Self                     |
| Dominio)             | Verifica flag forwardable en TGS             | Si no está, se rechaza S4U2Proxy                           |
|                      | Verifica msDS-AllowedToDelegateTo            | Autoriza o deniega la delegación a SPN destino             |
+----------------------+----------------------------------------------+------------------------------------------------------------+

Resumen técnico de cada mensaje Kerberos que vimos en esta sección

+----------------+---------------------+-------------------------------------------------------------+
| Mensaje        | Dirección           | Propósito / Ejemplo                                         |
+----------------+---------------------+-------------------------------------------------------------+
| KRB_AS_REQ     | Cliente → KDC       | johndoe solicita un TGT para autenticarse en el dominio.    |
+----------------+---------------------+-------------------------------------------------------------+
| KRB_AS_REP     | KDC → Cliente       | El KDC entrega el TGT cifrado con la clave krbtgt.          |
+----------------+---------------------+-------------------------------------------------------------+
| KRB_TGS_REQ    | Cliente → KDC       | johndoe solicita un TGS para HTTP/mail01.domain.local.      |
+----------------+---------------------+-------------------------------------------------------------+
| KRB_TGS_REP    | KDC → Cliente       | Entrega un TGS cifrado con la clave de MAIL01$.             |
+----------------+---------------------+-------------------------------------------------------------+
| KRB_AP_REQ     | Cliente → Servicio  | johndoe accede al servicio de MAIL01$ presentando su TGS.   |
+----------------+---------------------+-------------------------------------------------------------+
| KRB_AP_REP     | Servicio → Cliente  | (Opcional) Confirmación mutua desde el servicio.            |
+----------------+---------------------+-------------------------------------------------------------+
| KRB_TGS_REQ    | Servicio → KDC      | MAIL01$ solicita, con S4U2Self, un TGS para sí mismo en     |
|                |                     | nombre de johndoe.                                          |
+----------------+---------------------+-------------------------------------------------------------+
| KRB_TGS_REP    | KDC → Servicio      | El KDC entrega un TGS para MAIL01$ en nombre de johndoe.    |
+----------------+---------------------+-------------------------------------------------------------+
| KRB_TGS_REQ    | Servicio → KDC      | MAIL01$ solicita, con S4U2Proxy, un TGS para MSSQLSvc.      |
+----------------+---------------------+-------------------------------------------------------------+
| KRB_TGS_REP    | KDC → Servicio      | El KDC entrega un TGS que permite actuar como johndoe       |
|                |                     | ante MSSQLServer.                                           |
+----------------+---------------------+-------------------------------------------------------------+
| KRB_AP_REQ     | Servicio → SQL      | MAIL01$ accede a MSSQL como si fuera johndoe, usando el TGS.|
+----------------+---------------------+-------------------------------------------------------------+

Last updated 6 days ago

1. AS_REQ / AS_REP – johndoe obtiene su TGT

2. TGS_REQ / TGS_REP – johndoe solicita acceso a HTTP/mail01.domain.local

3. Delegación: mail01 actúa como johndoe hacia sql01

Entonces, ¿qué guarda MAIL01$?

4. Acceso final: mail01 accede a sql01 como johndoe