Tenemos varios sitios alojados en IIS que utilizan autenticación de Windows. Algunos de nuestros usuarios pueden iniciar sesión en uno de los sitios, pero obtienen un desafío de autenticación interminable en otro (el segundo se usa en un iframe del primero). Descubrimos que los usuarios que no pueden iniciar sesión utilizan la autenticación Kerberos (otros NTLM). Todos los sitios utilizan la misma configuración de autorización (useAppPoolCredentials establecido en verdadero). Por lo tanto, los usuarios pueden acceder a un sitio pero no pueden acceder al segundo con la misma configuración. El usuario de identidad del grupo de aplicaciones está en el grupo de administradores y en el grupo IIS_IUSRS. También intenté usar la cuenta de usuario del dominio para iniciar sesión en el sitio desde la máquina virtual y recibí el mismo mensaje de autenticación interminable debido a Kerberos. Leí el artículo de Chiranth Ramaswamy sobre la autenticación IIS pero desafortunadamente no pude encontrar la solución al problema. ¿Hay alguna forma de solucionar el problema?
EDITAR: También tenemos un segundo servidor con los mismos sitios y configuraciones.
EDITAR2: descubrí que puedo iniciar sesión si estoy usando la misma cuenta de usuario de dominio sinoescriba dominio al iniciar sesión. Por lo tanto, "Nombre de usuario" funciona y "Nombre de dominio\Nombre de usuario" no.
Respuesta1
Hay poco que solucionar allí, y sería útil tener más detalles, incluido cómo configurar Curb, qué otros sitios hay y las URL en uso.
En resumen: creo que Kerb está roto. Y que para que funcione, podrías utilizar una dirección IP en lugar del nombre. (Kerb solo funciona si usa un nombre, no una dirección IP).
Sospecho que no estás decodificando los tickets en el contexto de la cuenta del grupo de aplicaciones (que, por cierto, casi nunca debería ser un administrador).
Esto podría deberse a un SPN duplicado o a algún otro aspecto de Curb roto.
También es posible que sea una configuración del navegador del lado del cliente como "Habilitar autenticación integrada de Windows" frente a una secuencia de comandos PAC y/o configuraciones de zona.
¡Entonces! Lista de la compra:
Verifique las zonas en las que se está cargando el sitio si usa IE.
Marque la configuración Habilitar Windows integrado si usa IE.
Reinicie un cliente roto (o al menos
klist purge) y luego obtenga un rastro de netmon o wirehark de una conexión fallida, desde el lado del cliente. Esto podría identificar algunos problemas de respuesta del KDC, es decir, errores de Kerberos que se devuelven y que proporcionan una pista sobre lo que podría estar rompiendo Curb.Si está utilizando useAppPoolCredentials, es probable que haya utilizado SetSPN. Compruebe si hay duplicados de todos los SPN relacionados con los nombres del sitio.
Finalmente, si no está utilizando la delegación, considere eliminar useAppPoolCredentials de todos modos, ya que de forma predeterminada, la cuenta del sistema decodificará los tickets para todos los grupos de aplicaciones si no hay una anulación de SPN implementada.
Respuesta2
Después de reiniciar el servidor, descubrí que useApplicationCredentials volvió a ser falso. Lo cambié a verdadero y reinicié IIS. Después ese problema no ocurre. Pero no estoy seguro si no es una coincidencia. Tenemos el mismo problema en el otro servidor. 4 máquinas con la misma configuración de IIS. 2 no funciona correctamente a través de Kerberos, dos sí. SPN no se configuró para ninguno de ellos. Además, los dos que funcionan tienen false en useApplicationCredentials.
Intentaré el mismo método reiniciar: configurar useApplicationCredentials en verdadero si no es así y luego iisreset. Pero estoy bastante seguro de que esto no es un problema. No puedo entender por qué Kerberos funciona si el SPN no está configurado