Ahora que las empresas están adoptando la computación en nube como parte de su modelo de negocio, un gran porcentaje está optando por conectar su entorno de Active Directory local a su homólogo en la nube, Azure Active Directory de Microsoft. Cuando amplía su AD local a Azure AD, tiene dos opciones sobre cómo desea que los usuarios locales se autentiquen en el servicio en la nube: federación de identidades y autenticación directa con Azure AD. Aunque la autenticación directa es técnicamente el método más sencillo de los dos, requiere activar una función conocida como sincronización de contraseñas. Y creo que la sincronización de contraseñas es una característica bastante mal entendida que merece más explicación.
Microsoft ofrece dos formas de gestionar la autenticación en Azure AD: federación de identidades o autenticación directa utilizando 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 redirigiendo a los usuarios desde el servicio en la nube a su AD local para la autenticación. La otra opción, la autenticación directa en Azure AD, requiere que el ID de usuario y la contraseña del usuario se almacenen localmente en el servicio en la nube. Para las empresas, esto debe hacerse con la función de sincronización de contraseñas del servicio AD Connect de Microsoft; ningún tercero proporciona una capacidad equivalente.
¿Qué es la sincronización de hash de contraseñas y por qué utilizarla?
En su nivel más simple, 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 de 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 same sign on. Es distinto del inicio de sesión único porque con la sincronización de hash de contraseña, 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é utilizar la sincronización de hash de contraseñas? Principalmente porque es más sencillo de implementar que un servicio de federación. Microsoft necesitaba proporcionar una forma sencilla de integrar los usuarios de AD local con Azure AD, y la sincronización de hash de contraseñas lo hace sin necesidad de un servicio de federación de alta disponibilidad y múltiples 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 si el servicio de federación sufre una interrupción.
¿Es segura la sincronización de contraseñas?
Ten en cuenta que describo esta función 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 sólo no es una buena idea, sino que ni siquiera es técnicamente posible porque Active Directory no tiene las contraseñas en texto claro. Cuando un usuario crea o actualiza su contraseña en AD, se almacena como un hash MD5 unidireccional en los DC del dominio. Este hash es lo 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 de la entrada del blog de Alex Simon AAD Password Sync, Encryption, and FIPS Compliance y algunas 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 obvia es que debe introducir sus credenciales corporativas una segunda vez, independientemente de si ha iniciado sesión en su red corporativa o fuera, en una red pública. Sin embargo, estos inicios de sesión pueden reducirse marcando la casilla "Mantener mi sesión iniciada" (KMSI). Al marcar esta opción, se crea una cookie de sesión que evita la autenticación durante un breve periodo de tiempo. El administrador de Azure AD puede activar o desactivar el comportamiento KMSI.
Desde el punto de vista del profesional de la identidad, el problema de la sincronización de hash de contraseñas es que estás distribuyendo la contraseña a más de un lugar para la autenticación. En cambio, la federación redirige todas las solicitudes de autenticación al proveedor de identidades. Microsoft ha hecho todo lo posible para garantizar la seguridad del proceso, pero es válido hacerse 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 popular para integrar sus identidades locales con Azure AD. No es tan elegante como utilizar la federación de identidades, pero es más sencilla. Como con cualquier decisión de diseño, asegúrese de haber analizado los puntos fuertes y débiles de esta solución y cómo se aplican a su situación.
