Tenemos una configuración de IDAM un poco complicada:
Es decir, la máquina y el navegador del usuario final se encuentran en una red con el AD principal, y nuestra aplicación basada en Jetty y el AD con el que puede hablar (AD local) se ubican en la otra.
Hay una confianza bidireccional entre los dos AD. El navegador en la red principal tiene el dominio local en sitios confiables.
La configuración del servidor Jetty es la siguiente:
- utiliza un archivo de tabla de claves generado contra un principal en el AD local
- se ejecuta como un servicio de Windows bajo un usuario definido en el AD local
- el dominio, el mapeo dominio-dominio y kdc se definen contra el dominio del AD local
- utiliza spnego: isInitiator se establece en falso; doNotPrompt es verdadero; storeKey es cierto
El problema es:
- como una prueba, el acceso al servidor desde un navegador dentro de la red local (es decir, ligada a la AD local) funciona - Kerberos información de depuración aparece en los registros, puedo ver correcta negociación de Kerberos en el tráfico HTTP, y el usuario se suscribe de forma automática . Brillante.
sin embargo , ¡acceder al servidor desde un navegador dentro de la red principal (que es como nuestros usuarios harán las cosas) no funciona! El navegador recupera una 401 unauth pero luego solicita credenciales, que cuando se ingresan dan una pantalla en blanco. Luego, hacer clic en la barra de direcciones y presionar Intro hace una de dos cosas, dependiendo de si las credenciales son para el AD remoto o local:
- Las credenciales locales de AD luego inician sesión bien, con Kerberos desde cero en los registros (solicitud GET, respuesta 401 nouth, solicitud de encabezados Kerberos, etc.)
- AD credenciales remotas no conectarse (petición GET, 401 unauth respuesta, lo que parece ser una cabecera NTLM:
Authorization: Negotiate <60 or so random chars>
)
De cualquier manera, ¡el hecho de que está provocando está mal!
¿Hay alguna explicación para estos síntomas? ¿Puede la configuración que tenemos hacer lo que queremos?
En cuanto a la descripción anterior, podría estar equivocada: cualquier configuración que he mencionado con respecto al servidor Jetty debería ser precisa, como lo hice. Estoy feliz de proporcionar más detalles. Cualquier configuración relacionada con AD o el navegador de red principal es potencialmente sospechosa, porque no está bajo mi control y me han informado de la configuración en lugar de haberla visto por mí mismo.
fuente
Respuestas:
Sin ver la captura de paquetes, supongo que el SPN de HTTP / www.website.com debe registrarse en la cuenta que ejecuta la aplicación. El equipo de servicios de directorio de Microsoft tiene una excelente publicación de varias partes que aborda este tema en la siguiente URL.
https://blogs.technet.microsoft.com/askds/2008/05/29/kerberos-authentication-problems-service-principal-name-spn-issues-part-1/
Ejecute una captura de paquetes (netmon, wireshark) desde un cliente en cada entorno para identificar qué SPN se está buscando. Una vez que esté determinado, use el cmd setspn para registrarlo en la cuenta que ejecuta la aplicación.
FWIW, Kerberos solo funciona mientras está en la LAN. Si alguien necesita acceso donde los controladores de dominio no son accesibles, entonces querrá considerar un SSO como Shibboleth o ADFS.
EDITAR: como mencionó @ alex-h , los navegadores deberán configurarse para autenticarse silenciosamente a través de Kerberos.
Por último, este es un problema común con las implementaciones de Microsoft Sharepoint. Quieren que el SSO a través de Kerberos ocurra en silencio una vez que los usuarios se hayan autenticado en el dominio. Por lo tanto, si las respuestas anteriores no resuelven su problema, intente revisar sus foros como los siguientes:
Kerberos en Chrome, Safari o Firefox
fuente
Pruebe primero desde un navegador que no tenga NTLM habilitado (Chrome / Firefox). Parece que el problema es que tiene habilitada la autenticación previa y es posible que no exista la confianza bidireccional.
Para la autenticación previa, eche un vistazo aquí https://support.microsoft.com/en-us/kb/2749007 y aquí https://hc.apache.org/httpcomponents-client-ga/tutorial/html/authentication.html .
fuente