ADFS 3.0 y SSL Bindings

¡Hola a todos! Hoy vamos a hablar de una de nuestras especialidades: ADFS. Con una pizca de PowerShell. Y una dosis de misterio.

Una de las partes más importantes en un despliegue de ADFS es el certificado de la máquina, que la identifica de forma unívoca y nos permite realizar el proceso de autenticación de forma segura. Pero como todo certificado tiene fecha de caducidad, debe ser renovado periódicamente.

En este artículo no vamos a entrar en cómo renovar el certificado de ADFS, sino en uno de los problemas que pueden aparecer cuando por cualquier motivo el certificado no se renueva correctamente.

En este caso de estudio, se dispone de un despliegue con varios servidores de ADFS con balanceo de carga para dar un servicio robusto de autenticación. El servicio está funcionando correctamente durante meses, y finalmente llega el día de la renovación: Los certificados se renuevan en cada máquina de la granja, quedando instalados en Cert:\LocalMachineMy y configurados en el servicio ADFS. Todo ha sido correctamente actualizado, los usuarios pueden iniciar sesión correctamente, y todo parece funcionar a la perfección.

Días después, empiezan a llegar avisos de que algunas personas no pueden iniciar sesión en Office 365 desde sus máquinas. ¡Algo está pasando!

Síntomas:

Hay un problema, que afecta a máquinas aleatorias. Todo el que intenta iniciar sesión en Office 365 desde esas máquinas no puede acceder a la página de inicio de sesión de ADFS. Cuando esos usuarios usan otras máquinas, todo funciona correctamente. El resto de usuarios no experimentan problema alguno desde sus equipos.

En principio, podemos pensar que tenemos un problema de red que está afectando específicamente a algunas máquinas de la red. Pero el Firewall, routers y todo parece estar funcionando bien, y sus configuraciones son correctas. Otra apuesta puede ser que haya un fallo relacionado con el sistema de balanceo de carga de los servidores ADFS. Pero después de hacer las comprobaciones oportunas y verificar que el balanceador funciona correctamente, el problema sigue apareciendo.

 

¿Qué más podemos hacer?

Comprobar el estado de las máquinas de la granja de ADFS. Una de las comprobaciones más importantes que podemos hacer es revisar el estado del registro de eventos del sistema. Y efectivamente, en una única máquina de la granja nos encontramos con una serie de eventos HTTP que apuntan a la causa del problema.

 

Errores con la configuración del endpoint de ADFS. Como el balanceador hace pruebas sobre el endpoint y puede conectar, no se elimina la máquina del grupo de balanceo. Pero como el problema está en el certificado SSL del Endpoint, la conexión se interrumpe y no se genera la página de inicio de sesión.

Este problema aparece cuando actualizando los certificados de ADFS, los certificados del servicio se actualizan pero los certificados del endpoint no se han actualizado. Esto provoca que aunque el registro de eventos de ADFS aparezca completamente libre de errores y problemas, el servicio en sí es completamente inalcanzable.

Es momento de comprobar el estado de los certificados. Esto se puede hacer fácilmente con PowerShell. Se puede observar que en la máquina afectada se ha instalado un certificado cuyo Hash (Thumbprint) empieza por 991EB2. :

A continuación, hay que comprobar si este certificado es el mismo que está utilizando el servicio de ADFS. En la siguiente captura de pantalla vemos que efectivamente, el certificado instalado en la máquina de la granja es el mismo que se utiliza en el servicio de ADFS (991EB2….), luego el error no está en que se haya realizado mal el proceso de actualización.

Esto se puede ver gracias al cmdlet Get-AdfsCertificate que se debe ejecutar en el servidor primario de la granja.

El siguiente paso, es comprobar el estado de los certificados de comunicaciones.

¡Eureka! ¡Aquí está el problema! Aunque se haya realizado correctamente el procedimiento para actualizar los certificados de ADFS, no se han actualizado los certificados de los endpoint de comunicaciones. Puesto que el certificado “antiguo” ya había sido eliminado del sistema, cuando se intenta realizar una conexión a los puertos 443 o 49443 de la máquina, se intenta realizar una validación de certificados… de un certificado inexistente (Con el hash 0CC244…). Ésta es la raíz de la situación que está provocando el error de conexión. Al hacerse referencia a un certificado inexistente, no se puede establecer el canal de comunicación, produciendo como resultado la pantalla de error que nos dice que la página de autenticación no se puede mostrar.

El proceso de corrección es bastante sencillo en este caso: Simplemente hay que eliminar los endpoint no válidos, y crearlos nuevamente, pero ahora especificando el certificado correcto. Es muy importante conservar la información completa de los endpoints originales, porque se necesita para recrearlos. Se puede copiar la salida de “netsh http show sslcert” en un notepad, o ejecutarlo en una shell diferente de donde se va a hacer la operación de actualización. Nota: Es necesario lanzar la PowerShell en modo Administrador para poder modificar los endpoints.

Una vez abierta la Shell de Administrador, se lanzan los siguientes comandos:

Con esto, se han eliminado todos los endpoints que utilizaban el certificado antiguo. A continuación, hay que volver a crear los endpoints. Para ello se lanza el comando “netsh http”, y una vez dentro de netsh, escribir lo siguiente:

Con esto, se han añadido nuevamente los endpoints al sistema, con el certificado con hash que empieza por 991EB2. Comprobamos con “netsh http show sslcert” que efectivamente todo está correcto ahora.

¡Y eso es todo! Una vez corregido el problema con el certificado, los errores de conexión dejaron de producirse, todas las máquinas de la red podían acceder a los servicios de Office 365, y finalmente se resolvió el misterio. Parafraseando a Sherlock Holmes… “Cuando todo aquello que es imposible ha sido eliminado, lo que quede, por muy improbable que parezca, es la verdad”