SecurityLayer

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

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

Last updated