%20de%20Kerberos.png)
He estado explorando el inicio de sesión único (SSO) de Kerberos para reemplazar NTLM en una aplicación web alojada internamente dentro de un dominio de Windows.
Después de crear nombres principales de servicio (SPN) para un servicio de prueba (setspn -s), puedo ver claramente, usando Fiddler o WireShark, que la autenticación ha cambiado de NTLM a Kerberos.
Teniendo un equipo de infraestructura cauteloso, me gustaría demostrar que el cambio se puede revertir rápida y fácilmente. No deseo forzar NTLM a través de la configuración del servidor web. En consecuencia, los SPN se eliminan (setspn -d) y se confirma su eliminación (setspn -q).
Ejecuto el siguiente comando para eliminar todos los Tickets de servicio en el cliente:
C:\>klist purge
Current LogonId is 0:0x521ac
Deleting all tickets:
Ticket(s) purged!
C:\>
Cuando se produce una mayor interacción con la aplicación web, se crea otro ticket de servicio y Kerberos continúa siendo el mecanismo de autenticación SSO. Esto es válido para usuarios que no habían utilizado previamente el servicio. Este es el caso incluso al día siguiente, después de que toda la interacción haya estado inactiva durante la noche (12 a 14 horas).
Aunque he realizado repetidas búsquedas para encontrar una explicación a la persistencia observada, he llegado con las manos vacías. Sin embargo, creo que encontré una pista en el artículo;La función LsaLookupSids puede devolver el nombre de usuario anterior en lugar del nuevo nombre de usuario si el nombre de usuario ha cambiado:
La autoridad de seguridad local (LSA) almacena en caché la asignación entre el SID y el nombre de usuario en una caché local en la computadora miembro del dominio. El nombre de usuario almacenado en caché no está sincronizado con los controladores de dominio. El LSA en la computadora miembro del dominio primero consulta el caché SID local. Si ya hay una asignación existente en la caché SID local, LSA devuelve la información del nombre de usuario almacenada en caché en lugar de consultar los controladores de dominio. Este comportamiento está destinado a mejorar el rendimiento.
Las entradas de la caché vencen el tiempo de espera, sin embargo, es probable que las consultas recurrentes de las aplicaciones mantengan viva la entrada de la caché existente durante la vida útil máxima de la entrada de la caché.
¿Alguien puede confirmar si el Centro de distribución de claves (KDC) almacena en caché las entradas SPN de manera similar (o proporcionar una explicación alternativa)? Si es así, ¿cuáles son las vidas máximas de la entrada de caché?
Respuesta1
Descubrí el problema. El registro DNS del servicio no era un registro "A", sino un registro "CNAME". Esto significa que el navegador estaba creando una clave para la cuenta de servicio. Esto está relacionado con la configuración "useAppPoolCredentials" en el sitio/servidor que se configuró en "False" (el valor predeterminado). Los SPN a los que estaba realizando cambios no participaban en la autenticación Kerberos que se estaba llevando a cabo.