¿Miedo a compartir contraseñas con Microsoft al usar AD-CONNECT? Todos los que tenemos Office 365 y un directorio on-prem de Active Directory sabemos que tenemos que decidir cómo preferimos que se produzca la autenticación. En este artículo trataré de aclarar las ideas y como resultado, entender claramente que ADFS no es la mejor opción, al menos para la inmensa mayoría. 

AD-CONNECT, desde el punto de vista de la autenticación, es un motor que permite replicar los objetos de usuarios (y grupos) de ADDS en Azure Active Directory (AAD).  

¿Como debería almacenar mis contraseñas?

La cuestión más delicada para tratar y que supongo que es por la que estás leyendo este artículo, es que AAD almacena el hash de la contraseña de tus usuarios en la nube. De esta forma, cuando los usuarios quieren consumir servicios del cloud de Microsoft, no necesitan para nada ADDS, es más, incluso en el peor escenario que pudiera darse en nuestra infraestructura on-prem, los usuarios podrían seguir trabajando con la única necesidad de una conexión a Internet. 

Supongamos que ponemos en los dos platillos de una balanza estas cuestiones, es decir, en uno la garantía de acceso a los servicios cloud y, en el otro, ceder a Microsoft el hash de la contraseña. ¿Hacia dónde se inclinaría tu balanza?  

Muchas organizaciones no permiten, por normativa, compartir con un tercero, información relacionada con la autenticación. La cuestión aquí es la siguiente ¿Es el hash de la contraseña una información sensible? 

En teoría no lo es, ya que las funciones de hash, también llamadas algoritmos de sentido único, no pueden revertirse, y en este caso, compartir el hash no conduciría a revelar la contraseña en texto en claro, que sí sería un problema. 

Bueno, vale…, que has oído hablar de las rainbow tables.  

Contraseñas más seguras

Pues resulta que se han puesto a calcular el conjunto de todos los hashes asociados a una contraseña en claro de longitud N. Estas bases de datos son gigantescas, pero asumibles de descargar hoy en día por cualquiera y, mediante el software apropiado, poder obtener la contraseña en texto en claro. ¿Podría hacer Microsoft lo mismo? 

En teoría, si aumentamos la longitud de la contraseña, de forma que, si N es un número alto, el universo de claves posibles es tan exageradamente grande, que se considera computacionalmente seguro, es decir, se necesitaría una potencia informática que no existe en nuestros días para generar todo el conjunto de hashes. ¿Y cuánto vale N? 

Pues digamos que si N <= 10, reventar hashes es trivial. Tendríamos que irnos a valores mucho mayores (N > 30) para que la técnica de Rainbow Tables fuera computacionalmente imposible. Así que ya está, exigimos que las contraseñas de nuestros usuarios sean de 30 o más caracteres ¿no? 

Con los pies en el suelo, esto no va a ser posible, así que debemos dejarlas como están, pero lo que sí podemos hacer es agregar a la contraseña que escribe el usuario, una serie de caracteres adicionales, para que la longitud final sea del valor de N deseado. A esto lo llamamos “salt” o “saltear” el password. Ahora los hashes se calculan usando un valor de N apropiado, y este hash es el que se comparte con Microsoft… ¿o no? 

Gestión del hash de AD-CONNECT

Pues la verdad es que no. Es una simplificación de la gestión del hash que hace AD-CONNECT y de ahí la desconfianza que muchos tienen sobre esta cuestión. 

La realidad es la siguiente: 

1) Cada dos minutos, AD-CONNECT solicita hashes de contraseña (NO LA CONTRASEÑA) almacenados en el controlador de dominio, mediante una conexión RPC. 

2) Antes de que el DC envíe el hash al servicio AD-CONNECT, genera un nuevo hash usando el algoritmo MD4, mediante una clave que es un hash  MD5 de la clave de sesión RPC y valor de la “salt” elegida para ese usuario.  

3) El DC envía el resultado a AD-CONNECT. El controlador de dominio también pasa el valor de la “salt”. Esto permite que AD-CONNECT pueda descifrar y obtener el hash original del usuario en ADDS. 

4) AD-CONNECT nunca tiene acceso a la contraseña en texto en claro del usuario, solo al hash correspondiente. Ahora necesita subir esa información a la nube. 

5) AD-CONNECT amplía el hash de contraseña, que en ADDS es de 16 bytes a 64 bytes. Agrega una nueva “salt” por cada usuario, y los combina al pasarlos como parámetros a la entrada de la función PBKDF2 que realiza 1000 iteraciones usando el algoritmo de hash HMAC-SHA256. Es decir, toma el hash ampliado y su “salt” y calcula 1000 veces el hash del hash. ¿Tela no? 

6) El resultado del paso anterior es un hash de 32 bytes, que se concatena con la “salt” de ese usuario y se transmite en forma de string a AAD, protegido obviamente por una conexión TLS. Esto es lo que almacena realmente AAD en su base de datos. 

7) Cuando un usuario inicia sesión en AAD y escribe su password en el navegador, se envía hacia AAD (por medio de TLS) su hash MD4. Puesto que AAD ya tiene almacenada la “salt” para ese usuario, lo que calcula Azure es todo el proceso MD4+salt+PBKDF2+HMAC-SHA256 (1000 veces). Si el hash resultante coincide con el que está almacenado en AAD, se autentica al usuario, entregándolo un Access Token. 

¿Y ADFS? Cuestiones clave

En definitiva, no podemos simplificar y decir que AAD almacena el hash de ADDS, porque no es cierto. En realidad, el proceso garantiza la protección de la contraseña del usuario por parte del proveedor, pero ¿y ADFS? 

La federación permite que la autenticación del usuario en la nube se realice on-prem. No es el objetivo de este artículo profundizar en ello, pero sí atender a unas cuestiones claves. 

1. A) Hay que poner los servidores de federación en alta disponibilidad, ya que si se caen (o te deniegan servicios mediante un ataque) ningún usuario de tu organización podrá acceder a los servicios del cloud de Microsoft, y esto puede ser un gran problema. 
2. B)La recomendación mínima deADFS, según Microsoft, es de 4 servidores: 2 servidores de ADFS en la DMZ y 2 proxies de ADFS dando la cara en Internet. ADFS es complejo de administrar y cualquier implementación que use un único servidor ADFS está condenada a la interrupción del servicio  
3. C) Una vez que ADFS emiteel token (claim) de autenticación para el usuario,éste podrá ser autorizado en los servicios cloud, pero por ejemplo, si bloqueas la cuenta de ADDS de ese usuario, como la claim ya fue emitida, ese usuario podrá seguir usando los servicios cloud.  

Tomando decisiones  

Esta última consideración es muy importante. Si la autenticación fuera realizada por AAD, y ATP (Advanced Threat Protection) de Azure, por ejemplo, determina que el usuario está en peligro, le bloquea el inicio de sesión. Como AAD usa tokens de acceso (Access Tokens), entonces automáticamente se bloquearía a ese usuario el acceso a los recursos cloud. ADFS no puede hacer esto porque la autenticación no la realiza AAD y en consecuencia no se puede interactuar con el sistema de seguridad de Azure. 

Otro ejemplo serían las Directivas de Acceso Condicional de Azure, críticas hoy en día. Son muy simples de configurar con la autenticación AAD y complejas de administrar con la autenticación de ADFS. 

Por otro lado, AD-CONNECT al ser un único servidor, tiene la desventaja de que, si se cae, no se producen actualizaciones de los objetos de usuario en la nube. Los empleados podrán seguir usando el cloud de Microsoft sin problema alguno mientras dura esta caída. Desplegar un nuevo servidor AD-CONNECT desde cero es cuestión de minutos, y siempre es aconsejable tener un segundo AD-CONNECT en modo “staging” (reserva) que podemos activar con un clic. 

Por su parte, ADFS está recomendado para grandes empresas multinacionales con decenas de miles de empleados, que estén geográficamente dispersas o, si ya tienes desplegado SSO en tu organización, pero debemos tener claro que se pierden las nuevas funciones de seguridad de Azure, que, además, es por donde está evolucionando Microsoft en la actualidad. 

Así que… ¿siguen los platillos equilibrados, o no? 

Links de interés:  

• Implementación de la sincronización de hash de contraseñas mediante la sincronización de Azure AD Connect | Microsoft Docs 
• Authentication for Azure AD hybrid identity solutions – Active Directory | Microsoft Docs