Permisos y delegaciones mal puestos

Hay dos sabores de delegación y la diferencia lo es todo. La delegación sin restricción marca a un servidor como digno de actuar en nombre de cualquier usuario ante cualquier servicio: cuando un usuario se autentica contra él, el servidor recibe y guarda el ticket que le permite hacerse pasar por ese usuario en cualquier sitio. La restringida limita esa capacidad a una lista de servicios concretos. En la enumeración de Marisma, el servidor que ya administras está marcado con delegación sin restricción —una configuración vieja que nadie revisó—.

Entender qué te regala eso es el paso previo: si consigues que una cuenta valiosa se autentique contra ese servidor, te quedas con su ticket y puedes actuar como ella.

Tener un servidor con delegación sin restricción no basta: hace falta que una cuenta con poder se autentique contra él para capturar su ticket. Esperar a que pase por casualidad es lento; el abuso consiste en provocar esa autenticación. Existen formas legítimas de pedirle a otra máquina —incluido el propio controlador— que se conecte a la tuya, y cuando el controlador se autentica contra tu servidor con delegación sin restricción, su ticket queda en tus manos. Con el ticket de una cuenta de máquina del controlador, actuar sobre el directorio como él deja de ser teoría.

El movimiento correcto no es esperar sentado: es forzar de forma controlada que la cuenta valiosa se autentique contra el servidor que ya controlas.

La delegación restringida suena a segura porque limita a una lista de servicios, pero el detalle está en a qué servicio se delega y con qué margen. Si una cuenta está autorizada a delegar hacia un servicio del controlador, o si el mecanismo permite pedir el ticket «en nombre de» cualquier usuario hacia ese servicio, la restricción no protege de nada: sigue siendo una vía a suplantar a un administrador contra una pieza sensible. El criterio no es «restringida es segura, sin restricción es peligrosa», es leer hacia dónde apunta la delegación y qué permite hacer allí.

Ante una delegación restringida hacia un servicio del controlador, la conclusión sensata es tratarla como peligrosa y comprobar a quién deja suplantar, no darla por inofensiva por llevar la etiqueta «restringida».

Cuando capturas el ticket de una cuenta del controlador, lo que tienes es material de autenticación que puedes presentar tú mismo: es el pase de ticket. Con él actúas ante el directorio con la identidad de esa cuenta sin conocer su contraseña, porque Kerberos valida el ticket, no a quién lo presenta. Ahí la cadena de la ruta llega al dominio: de una cuenta de servicio con clave débil, por un permiso de grupo y una delegación olvidada, hasta actuar como el controlador.

Reconocer que el ticket capturado se reutiliza directamente —no hay que crackear ninguna contraseña más— es entender por qué una delegación mal puesta es una vía tan corta al control del dominio.