Ahora que las empresas están adoptando la computación en la nube como parte de su modelo de negocio, un gran porcentaje de ellas está optando por conectar su entorno de Active Directory local con su equivalente en la nube: Azure Active Directory de Microsoft. Al ampliar tu AD local a Azure AD, tienes dos opciones para que los usuarios locales se autentiquen en el servicio en la nube: la federación de identidades y la autenticación directa con Azure AD. Aunque la autenticación directa es, técnicamente, el método más sencillo de los dos, requiere habilitar una función conocida como «sincronización de contraseñas». Y creo que la sincronización de contraseñas es una función bastante mal entendida que merece una explicación más detallada.
Microsoft ofrece dos formas de gestionar la autenticación en Azure AD: la federación de identidades o la autenticación directa mediante el propio Azure AD. La federación de identidades con un servicio de federación como AD FS o PingFederate proporciona un inicio de sesión único en Azure AD al redirigir a los usuarios desde el servicio en la nube de vuelta a su AD local para la autenticación. La otra opción, la autenticación directa en Azure AD, requiere que el nombre de usuario y la contraseña del usuario se almacenen localmente en el servicio en la nube. En el caso de las empresas, esto debe realizarse mediante la función de sincronización de contraseñas del servicio AD Connect de Microsoft; ningún tercero ofrece una funcionalidad equivalente.
¿Qué es la sincronización de hash de contraseñas y por qué utilizarla?
En su forma más sencilla, a nivel de un boceto en una servilleta de cóctel, la sincronización de hash de contraseñas (una descripción más precisa, que explicaré más adelante) copia la contraseña del usuario desde AD a Azure AD cada dos minutos. Esto permite a los usuarios iniciar sesión en Azure AD con el mismo nombre de usuario y contraseña que utilizan para iniciar sesión en AD. Microsoft denomina a este patrón «inicio de sesión único» (same sign-on). Se diferencia del «inicio de sesión único» (single sign-on) porque, con la sincronización de hash de contraseñas, se pedirá a los usuarios que inicien sesión en Azure AD además de cualquier inicio de sesión corporativo que hayan realizado.
¿Por qué querrías utilizar la sincronización de hash de contraseñas? Principalmente porque es más sencilla de implementar que un servicio de federación. Microsoft necesitaba ofrecer una forma sencilla de integrar a los usuarios de AD local con Azure AD, y la sincronización de hash de contraseñas lo consigue sin necesidad de un servicio de federación de alta disponibilidad que requiera varios servidores.
Y la solución más sencilla ha proporcionado ser popular; alrededor del 50% de las organizaciones que sincronizan con Azure AD utilizan la sincronización de hash de contraseña. De ese 50%, la mitad son pequeñas y medianas organizaciones. La sincronización de hash de contraseñas proporciona un camino sin problemas para que estas organizaciones pasen a una infraestructura de TI cloud-first o cloud-only, porque los usuarios ya se autentican directamente con el servicio Azure AD.
Otra ventaja de la sincronización de hash de contraseñas es que, a diferencia de la federación, no depende de un servicio de federación externo para procesar las autenticaciones. De hecho, Microsoft ofrece la sincronización de hash de contraseñas además de la federación, por lo que puede utilizarse como alternativa en caso de que tu servicio de federación sufra una interrupción del servicio.
¿Es segura la sincronización de contraseñas?
Ten en cuenta que describo esta característica como «sincronización de hash de contraseñas», no como «sincronización de contraseñas». Es una distinción importante. Las contraseñas en texto claro no se sincronizan entre AD DS y Azure AD. No solo no es una buena idea, sino que ni siquiera es técnicamente posible, ya que Active Directory no dispone de las contraseñas en texto claro. Cuando un usuario crea o actualiza su contraseña en AD, esta se almacena como un hash MD5 unidireccional en los servidores de dominio (DC) del dominio. Este hash es el que se sincroniza con Azure AD y se almacena en el almacén de credenciales del servicio.
¿Cómo funciona exactamente? He recopilado los siguientes pasos a partir de la entrada del blog de Alex Simon titulada «Sincronización de contraseñas, cifrado y cumplimiento de la norma FIPS en AAD», así como de otras fuentes:
- Las contraseñas de usuario se almacenan como un hash no reversible en los controladores de dominio (DC) de Active Directory de Windows Server. Cuando el agente de sincronización de contraseñas en AD Connect intenta sincronizar el hash de la contraseña, el DC cifra el hash. El cifrado se realiza con una clave derivada de la clave de sesión RPC mediante salting. La derivación de la clave es la siguiente [donde SaltedEncryptionKey = MD5 (clave de sesión RPC, sal aleatoria de 128 bits)]. El DC también pasa la sal al agente de sincronización utilizando el protocolo de replicación.
- El hash de la contraseña original se replica (utilizando el protocolo de replicación del DC) desde el DC al Agente de Sincronización de Contraseñas.
- El agente de sincronización de contraseñas descifra el hash cifrado derivando la clave como se ha descrito anteriormente. El agente de sincronización de contraseñas utiliza MD5 para realizar la derivación de la clave, ya que la derivación tiene que ser idéntica a la derivación que realizó el DC (cuando cifró los datos). Además, MD5 es el nivel más alto disponible para esta acción en el protocolo de replicación de DC de las implementaciones de Active Directory de Windows Server existentes.
- Una vez realizado el descifrado, el agente de sincronización toma el hash de la contraseña original resultante y lo convierte en un hash SHA256 utilizando el algoritmo de derivación de claves PKDF2 definido en el RFC 2898.
- A continuación, el agente de sincronización de contraseñas sincroniza ese hash de contraseña SHA256 por cable (un relé de bus de servicio cifrado dedicado al inquilino de Azure AD) con Azure AD.
- Una vez que la copia con hash SHA256 del hash de la contraseña original llega a Azure AD, Azure AD cifra el hash con el algoritmo AES antes de almacenarlo en la base de datos en la nube.
Lo único que cruza el cable de camino a Azure AD es una copia con hash SHA256 del hash de la contraseña original. El uso de MD5 por parte del agente de sincronización de contraseñas es estrictamente para la compatibilidad del protocolo de replicación con el DC, y solo se utiliza, en las instalaciones, entre el DC y el agente de sincronización de contraseñas.
Desventajas de la sincronización de contraseñas
Desde el punto de vista del usuario, la desventaja más evidente es que debe introducir sus credenciales corporativas por segunda vez, independientemente de si está conectado a la red corporativa o se encuentra fuera, en una red pública. No obstante, estos inicios de sesión pueden reducirse marcando la casilla «Mantenerme conectado» (KMSI). Al marcarla, se establece una cookie de sesión que omite la autenticación durante un breve periodo de tiempo. Tu equipo de seguridad deberá valorar esta cuestión, y el administrador de Azure AD puede habilitar o deshabilitar el comportamiento de KMSI.
Desde el punto de vista de los profesionales de la gestión de identidades, el problema de la sincronización de hash de contraseñas es que se distribuye la contraseña a más de un lugar para la autenticación. Por el contrario, la federación redirige todas las solicitudes de autenticación al proveedor de identidades. Microsoft ha hecho todo lo posible para garantizar que el proceso sea seguro, pero es legítimo plantearse preguntas sobre el ciclo de vida de la contraseña.
¿Cuándo se debe utilizar la sincronización de hash de contraseña?
Hay un caso de uso en el que debe utilizar la sincronización de hash de contraseña: si decide implementar los servicios de dominio de Azure AD. Esta función crea un controlador de dominio como servicio que las aplicaciones de Azure (como las máquinas virtuales que ejecutan aplicaciones dependientes de AD) pueden utilizar. Sin embargo, para que estos DC sean funcionalmente equivalentes a los DC locales, deben tener hashes de contraseñas de usuario y, por lo tanto, requieren una sincronización de hash de contraseñas para introducirlos en Azure.
La sincronización de hash de contraseñas es una solución muy utilizada para integrar tus identidades locales con Azure AD. No es tan elegante como utilizar la federación de identidades, pero resulta más sencilla. Al igual que con cualquier decisión de diseño, asegúrate de haber analizado detenidamente las ventajas y desventajas de esta solución y cómo se aplican a tu caso concreto.
