¿Por qué usar Kerberos en lugar de NTLM en IIS?

Esto es algo que nunca he podido responder tan bien como me gusta: ¿Cuál es la ventaja real de usar la autenticación Kerberos en IIS en lugar de NTLM?

He visto a muchas personas realmente tener dificultades para configurarlo (incluido yo mismo) y no he podido encontrar una buena razón para usarlo. Sin embargo, debe haber algunas ventajas bastante significativas, de lo contrario no valdría la pena configurarlo, ¿verdad?

Desde una perspectiva de Windows solamente:

NTLM

• funciona tanto con clientes externos (no de dominio) como internos
• funciona con cuentas de dominio y cuentas de usuario locales en el cuadro IIS
  • usando cuentas de dominio, solo el servidor requiere conectividad directa a un controlador de dominio (DC)
  • usando cuentas locales, no necesita conectividad en ningún lado :)
  • no necesita iniciar sesión como el usuario en cuestión para usar una credencial
  • Aparte : que no es tan raro que un DC para ser abrumado por un servidor ocupado NTLM (IIS, Exchange, TMG / ISA, etc) con el volumen de solicitudes NTLM (para mitigar: MaxConcurrentAPI, AuthPersistSingleRequest(falso) ., Más rápido DC) ( Auto bonificación referencial .)
• requiere conectividad del cliente solo con el servidor IIS (en el puerto del sitio, nada más. Es decir, todo sucede a través de HTTP (o HTTPS)).
• puede atravesar cualquier proxy que soporte HTTP Keep-Alive s
  • puede usar TLS / SSL para trabajar con otros
• requiere múltiples viajes de ida y vuelta para autenticarse, con pequeños paquetes
  • (el patrón de registro es 401.2, 401.1, 200 con nombre de usuario)
• no se puede usar en escenarios donde se requiere autenticación de doble salto
  • es decir, las credenciales del usuario deben enviarse a un servicio en otra computadora
• admite clientes antiguos (<Win2000)
• Es susceptible a discrepancias de nivel de autenticación LM (no coincidente lmcompatibilitylevel)
• se usa como reserva por el paquete Negotiate si Curb falla.
  • ( no "si se deniega el acceso con Curb", Curb debe interrumpirse para que se use NTLM; por lo general, parece que no se obtiene un ticket. Si el cliente recibe un ticket y no es perfecto, eso no causa un retroceso).

Kerberos

• funciona solo con clientes actualmente unidos a un dominio
  • requiere la conectividad del cliente a un AD DC (tcp / udp 88) Y al servidor (el cliente recupera los tickets del DC a través del puerto Curb, y luego los proporciona al servidor usando HTTP)

• es posible que pueda atravesar un proxy, pero vea el punto DC arriba: aún necesita estar en la misma red que un DC activo, al igual que el servidor .

  • entonces, en teoría, si tuviera un dominio en el que los clientes conectados a Internet chatearan directamente a un DC conectado a Internet, es viable. Pero no hagas eso a menos que ya lo supieras.
  • En escenarios de proxy inverso (ISA / TMG), el servidor de transición de protocolo debe estar en esa red, es decir, no el cliente ... pero entonces el cliente no es realmente el que está haciendo el bit Kerberos (necesariamente, piense en Forms auth to Curb transición).

• El ticket es de larga duración (10 h), lo que significa menos comunicación DC durante la vida útil del ticket, y para enfatizar: esto podría ahorrar de miles a millones de solicitudes por cliente durante esa vida útil ( AuthPersistNonNTLMtodavía es una cosa; la validación Kerberos PAC solía ser una cosa)

• requiere un solo viaje de ida y vuelta para autenticarse, pero el tamaño de la carga útil de autenticación es relativamente grande (comúnmente 6-16K) ( 401 , {tamaño de token (codificado)} 200 )
• se puede usar con la delegación (por favor, siempre restringida ) para habilitar la autenticación de Windows del usuario que se conecta al siguiente servicio
  • por ejemplo, para permitir el UserAacceso a IIS y usar esa misma cuenta de usuario cuando IIS accede a SQL Server, esto es "delegación de autenticación".
  • ( Restringido en este contexto significa "pero no otra cosa", por ejemplo, Exchange u otro cuadro SQL)
• actualmente es el paquete de seguridad principal para la autenticación de negociación
  • lo que significa que los miembros del dominio de Windows lo prefieren cuando pueden obtenerlo
• requiere el registro de SPN , lo que puede ser complicado. Reglas que ayudan .
• requiere el uso de un nombre como destino, no una dirección IP
• razones por las que Curb podría fallar:
  • usando una dirección IP en lugar de un nombre
  • no SPN registrado
  • SPN duplicados registrados
  • SPN registrado contra cuenta incorrecta ( KRB_ERR_AP_MODIFIED)
  • sin cliente DNS / DC conectividad
  • Configuración del proxy del cliente / Zona de intranet local no utilizada para el sitio de destino

Mientras estamos en eso:

BASIC

• puede multi-hop. Pero lo hace exponiendo su nombre de usuario y contraseña directamente a la aplicación web de destino
  • que puede hacer lo que quiera con ellos. Cualquier cosa .
  • "Oh, ¿un administrador de dominio solo usó mi aplicación? ¿Y acabo de leer su correo electrónico? ¿Luego restablecí su contraseña? Awww. Lástima "
• necesita seguridad de la capa de transporte (es decir, TLS / SSL) para cualquier forma de seguridad.
  • y luego, vea el número anterior
• funciona con cualquier navegador
  • (pero vea el primer número )
• requiere un solo viaje de ida y vuelta para autenticarse ( 401 , 200 )
• se puede usar en escenarios de varios saltos porque Windows puede realizar un inicio de sesión interactivo con credenciales básicas
  • Es posible LogonTypeque deba configurarse para lograr esto (piense que el valor predeterminado cambió a texto sin formato de red entre 2000 y 2003, pero podría estar recordando erróneamente)
  • pero nuevamente , vea el primer número .
  • ¿Tienes la impresión de que el primer problema es realmente importante? Es.

Para resumir:

Puede ser difícil configurar Curb, pero hay muchas guías (la mía ) que intentan simplificar el proceso, y las herramientas han mejorado enormemente de 2003 a 2008 ( SetSPNpuede buscar duplicados, que es el problema de ruptura más común) ; useSETSPN -S cada vez que vea una guía para usar -A, y la vida será más feliz).

Delegación restringida vale la pena el costo de la entrada.

• Kerberos tiene la reputación de ser un mecanismo de autenticación más rápido y seguro que NTLM.
• Históricamente, también ha sido más fácil conectarse a través de servidores proxy que NTLM, debido a la naturaleza de NTLM basada en la conexión.
• Dicho esto, como notará, Kerberos es más difícil de poner en funcionamiento y requiere una conexión al AD que no siempre es práctica.

Otro enfoque sería establecer la autenticación negotiatey usar ambos en lugar de uno en lugar del otro.

Desde el verificador de aplicaciones de Microsoft , que detecta errores comunes del desarrollador. Uno de esos errores es el uso de NTLM :

NTLM es un protocolo de autenticación obsoleto con fallas que potencialmente comprometen la seguridad de las aplicaciones y el sistema operativo. La deficiencia más importante es la falta de autenticación del servidor, lo que podría permitir a un atacante engañar a los usuarios para que se conecten a un servidor falso. Como corolario de la falta de autenticación del servidor, las aplicaciones que usan NTLM también pueden ser vulnerables a un tipo de ataque conocido como ataque de "reflexión". Esto último permite a un atacante secuestrar la conversación de autenticación de un usuario en un servidor legítimo y usarla para autenticar al atacante en la computadora del usuario. Las vulnerabilidades de NTLM y las formas de explotarlas son el objetivo de aumentar la actividad de investigación en la comunidad de seguridad.

Aunque Kerberos ha estado disponible durante muchos años, muchas aplicaciones todavía están escritas para usar solo NTLM. Esto reduce innecesariamente la seguridad de las aplicaciones. Sin embargo, Kerberos no puede reemplazar NTLM en todos los escenarios, principalmente aquellos en los que un cliente necesita autenticarse en sistemas que no están unidos a un dominio (una red doméstica quizás sea la más común de estas). El paquete de seguridad Negotiate permite un compromiso compatible con versiones anteriores que utiliza Kerberos siempre que sea posible y solo vuelve a NTLM cuando no hay otra opción. Cambiar el código para usar Negotiate en lugar de NTLM aumentará significativamente la seguridad para nuestros clientes al tiempo que introduce pocas o ninguna compatibilidad de aplicaciones. Negociar por sí solo no es una bala de plata: hay casos en los que un atacante puede forzar la degradación a NTLM, pero estos son significativamente más difíciles de explotar. Sin embargo, una mejora inmediata es que las aplicaciones escritas para usar Negotiate correctamente son automáticamente inmunes a los ataques de reflexión NTLM.

A modo de advertencia final contra el uso de NTLM: en futuras versiones de Windows será posible desactivar el uso de NTLM en el sistema operativo. Si las aplicaciones dependen mucho de NTLM, simplemente no podrán autenticarse cuando NTLM esté deshabilitado.

Deberías agregar un punto muy importante:

Kerberos ha sido un protocolo estándar y abierto en Unix durante más de 20 años, mientras que NTLM es una solución exclusiva de Microsoft y solo Microsoft la conoce.

Se requiere Kerberos si necesita suplantar al usuario para acceder a recursos que no están en el servidor iis.