Riesgos de la delegación de Kerberos

He pasado horas y horas tratando de aprender y comprender la autenticación de Windows, Kerberos, SPN y la delegación restringida en IIS 7.5. Una cosa que no entiendo es por qué es "arriesgado" dejar habilitada la delegación (es decir, no deshabilitar la delegación para cuentas confidenciales) para administradores, directores generales, etc. ¿Puede alguien explicarme esto en términos simples? Encuadre su respuesta con respecto a un entorno de intranet.

Mi razonamiento es que no debería ser una preocupación, porque la delegación simplemente permite que un servidor web front-end, por ejemplo, actúe en nombre de la persona autenticada de Windows cuando se comunica con otros servidores. Si la persona tiene acceso, tiene acceso, no entiendo por qué esto debería ser una preocupación.

Por favor perdona mi ignorancia. Principalmente soy un desarrollador, pero mi empresa funciona muy esbelta en estos días y también me veo obligado a usar el sombrero de administrador del servidor ... desafortunadamente, todavía no encaja muy bien, jajaja.

Dos ejemplos:

1. La delegación restringida permite la suplantación sin tener las credenciales del usuario o el token de autenticación. Para ver un ejemplo, vea esta respuesta .

2. En un escenario de delegación sin restricciones más típico de carne y papas, ya sea la autenticación integrada de Windows o la autenticación de formularios, tener acceso de delegación al token de autenticación de un usuario es muy poderoso. Eso literalmente significa que el token se puede usar para suplantar a ese usuario para acceder a cualquier recurso de red. Cualquier persona involucrada en ese proceso, como un desarrollador, podría usarlo de una manera nefasta para obtener acceso no autorizado.

En ambos ejemplos, si la casilla está marcada para "la cuenta es confidencial y no se puede delegar", estos no son problemas de seguridad. También es posible diseñar un sistema / característica donde estas capacidades existen, pero están estrictamente controladas.

Esa casilla debe estar marcada para cuentas administrativas, como los miembros del grupo Administradores de empresa, porque (con suerte) esas cuentas rara vez necesitan usar aplicaciones que requieren suplantación. También es una buena idea para los altos ejecutivos que tienen acceso a información confidencial, como un CIO, COO, jefe de Finanzas / Tesorería, etc.

En resumen, Microsoft proporcionó esa casilla de verificación y la advertencia que la acompaña por una muy buena razón, y no debe descartarse ni tomarse a la ligera a menos que se pueda demostrar que un escenario particular no tiene una exposición de riesgo indeseable, o algún control compensatorio. Esto generalmente implica la verificación por parte de algunas personas calificadas que no están involucradas en la implementación o desarrollo real de una aplicación o sistema.

He configurado miles de clientes con delegación, la mayoría de los no restringidos. Creo que es importante tener en cuenta que si no confía en su aplicación (digamos implementada en IIS) o si está dando sus credenciales de cuenta de servicio delegadas para que otros las usen libremente, entonces la delegación restringida es probablemente una buena idea. Sin embargo, si no espera que nadie tenga la capacidad de reescribir su aplicación, mantiene seguras las credenciales de su cuenta de servicio y confía en que sus aplicaciones solo van a delegar en los servicios para los que fueron diseñados, entonces Por lo general, no hay nada de qué preocuparse. He visto a algunos clientes "conscientes de la seguridad" centrarse mucho en problemas como este, mientras que sus recursos podrían gastarse mejor trabajando en amenazas de seguridad reales ...