Mi cliente requiere SSO en el dominio de Windows para mi servidor web/de aplicaciones basado en Linux. El servidor tiene su propia tabla de claves instalada y todo funciona bien. El dominio de Windows (EJEMPLO.ORG) tiene una cuenta de usuario de servicio con SPN HTTP/servidor.ejemplo.org asociado. Mi servidor de aplicaciones (WildFly) requiere autenticación Kerberos y niega la autenticación NTLM.
Tengo un dominio de prueba (basado en 2016) que se creó con la configuración predeterminada. Estoy intentando repetir esta configuración en el dominio de prueba y no puedo hacer que Kerberos funcione. Veo una solicitud de negociación del servidor, pero el cliente siempre devuelve el ticket NTLM.
WWW-Authenticate: Negotiate (request)
Authorization: Negotiate TlRMTVNTU..... (reply)
En la infraestructura del cliente veo lo mismo con el ticket de Kerberos.
WWW-Authenticate: Negotiate (request)
Authorization: Negotiate YIIHmAYGKw.... (reply)
La única diferencia (además de GPO) que veo es que mi SPN no está dentro del mismo dominio DNS. Mi dominio AD es tdm.sample.org y el servidor es server.sample.org, no sé si eso importa.
Hace un tiempo también tuve el mismo problema dentro del dominio. Tanto el cliente IE como Windows Server 2016 con IIS unidos en el mismo dominio también usaban NTLM.
Creo que hay pocas configuraciones de GPO que regulan cómo el cliente puede autorizar o no, pero ninguno de los documentos que he leído ayudó.
¿Existe alguna descripción clara de las restricciones que tiene la autenticación del cliente Kerberos o alguna sugerencia o estrategia de depuración que pueda aplicarse?
Respuesta1
Existen varias restricciones cuando Windows ni siquiera intenta la autorización Kerberos.
1. SPN apunta a PTR, no a un alias web
Si su servidor web que no es miembro del dominio tiene un alias, no necesita asignar SPN a ese alias. Se compararía con el registro DNS real de ese servidor.
Digamos que tienes esto:
A record server.example.org -> 10.0.0.1
PTR record 10.0.0.1 -> server.example.org
CNAME record webapp.example.org -> server.example.org
Accediendowebapp.ejemplo.orgno necesitas SPNHTTP/webapp.ejemplo.org, deberías asignarHTTP/servidor.ejemplo.orgal registro de servicio SOLAMENTE. Creo que debería ser una dirección IP si tampoco hay un registro PTR.
2. Los miembros del dominio NO deben recibir ningún otro nombre.
Tengo un servidor miembro de dominio con IIS y la autenticación integrada de Windows habilitada. Debido a la configuración de mi red, tiene configuración DNS tanto en la red de dominio como en la que no es de dominio:
srv.example.org -> 10.0.0.1
10.0.0.1 -> srv.example.org
Y también se registró en el dominio:
srv.tdm.example.org -> 10.0.0.1
Este servidor no permitiría Kerberos si se accede como srv.example.org, Kerberos funcionará sólo si se accede como srv.tdm.example.org. Incluso no funcionará si se accede a través de una dirección IP.
Supongo que la naturaleza de este hecho es causada por la resolución de nombres de Windows en el dominio, que generalmente ocurre antes que DNS.
Continuaré buscando y actualizaré esta respuesta.