Implementación de la sincronización de hash de contraseña con la sincronización de Microsoft Entra Connect

  • Artículo

En este artículo se ofrece información necesaria para sincronizar las contraseñas de usuario de una instancia de Active Directory local con otra de Microsoft Entra basada en la nube.

Funcionamiento de la sincronización de hash de contraseñas

El servicio de dominio de Active Directory almacena contraseñas en forma de representación de valor hash de la contraseña de usuario real. Un valor hash es el resultado de una función matemática unidireccional (el algoritmo hash). No hay ningún método para volver del resultado de una función unidireccional a la versión de texto sin formato de una contraseña.

Para sincronizar la contraseña, la sincronización de Microsoft Entra Connect extrae el hash de contraseña de la instancia de Active Directory local. Se aplica un procesamiento de seguridad adicional al hash de contraseña antes de que se sincronice con el servicio de autenticación de Microsoft Entra. Las contraseñas se sincronizan usuario por usuario y en orden cronológico.

El flujo de datos reales del proceso de sincronización de hash de contraseñas es similar al de sincronización de datos de usuario. De todas formas, las contraseñas se sincronizan con más frecuencia que la ventana de sincronización de directorios estándar para otros atributos. El proceso de sincronización de hash de contraseñas se ejecuta cada 2 minutos. La frecuencia de este proceso no se puede modificar. Al sincronizar una contraseña, esta sobrescribe la contraseña existente en la nube.

La primera vez que se habilita la característica de sincronización de hash de contraseñas, se realiza una sincronización inicial de las contraseñas de todos los usuarios dentro del ámbito. El lanzamiento preconfigurado permite probar de forma selectiva grupos de usuarios con funcionalidad de autenticación en la nube, como Microsoft Entra Multifactor Authentication, acceso condicional, Identity Protection para credenciales filtradas, Identity Governance, etc., antes de transicionar sus dominios. No puede definir explícitamente un subconjunto de contraseñas de usuario que quiera sincronizar. Pero si hay varios conectores, es posible deshabilitar la sincronización de hash de contraseña en algunos conectores, pero no en otros, mediante el cmdlet Set-ADSyncAADPasswordSyncConfiguration.

Al cambiar una contraseña local, la contraseña actualizada se sincroniza más a menudo en cuestión de minutos. La característica de sincronización de hash de contraseñas reintenta automáticamente los intentos fallidos de sincronización. Si se produce un error al intentar sincronizar una contraseña, se registra un error en el visor de eventos.

La sincronización de una contraseña no influye en el usuario que actualmente ha iniciado sesión. Si se sincroniza un cambio de contraseña mientras tiene iniciada sesión en un servicio en la nube, este cambio no afectará de inmediato a la sesión actual del servicio en la nube. Sin embargo, cuando el servicio en la nube requiera de nuevo su autenticación, deberá proporcionar la nueva contraseña.

Un usuario debe proporcionar sus credenciales corporativas una segunda vez para autenticarse en Microsoft Entra ID, independientemente de que haya iniciado sesión o no en la red corporativa. Pero este patrón puede reducirse si el usuario activa la casilla "Mantener la sesión iniciada" (KMSI) en el inicio de sesión. Esta opción establece una cookie de sesión que omite la autenticación durante 180 días. El comportamiento de KMSI lo puede habilitar o deshabilitar el administrador de Microsoft Entra. Además, puede reducir los mensajes de petición de contraseña. Para ello, configure Unión a Microsoft Entra o Unión híbrida a Microsoft Entra, que permite a los usuarios iniciar sesión automáticamente en dispositivos corporativos conectados a la red de la empresa.

Ventajas adicionales

  • Por lo general, la sincronización de hash de contraseñas es más fácil de implementar que un servicio de federación. No requiere ningún servidor adicional y elimina la dependencia en un servicio de federación de alta disponibilidad para autenticar a los usuarios.
  • También se puede habilitar la sincronización de hash de contraseñas además de la federación. Puede usarse como reserva en caso de que el servicio de federación experimente una interrupción del servicio.

Nota:

Solo se admite la sincronización de la contraseña para el usuario del tipo de objeto de Active Directory. No se admite para el tipo de objeto iNetOrgPerson.

Descripción detallada de cómo funciona la sincronización de hash de contraseñas

En la sección siguiente se describe con detalle cómo funciona la sincronización de hash de contraseñas entre Active Directory y Microsoft Entra ID.

Detailed password flow

  1. Cada dos minutos, el agente de sincronización de hash de contraseñas en el servidor de AD Connect solicita hashes de contraseña almacenados (el atributo unicodePwd) desde un controlador de dominio. Esta solicitud es a través del protocolo de replicación MS-DRSR estándar que se utiliza para sincronizar datos entre controladores de dominio. La cuenta de servicio debe tener los permisos para replicar cambios de directorio y para replicar cambios de directorio en todos los AD (se conceden de manera predeterminada en la instalación) para obtener los hashes de contraseña.
  2. Antes del envío, el controlador de dominio cifra el hash de contraseña MD4 mediante una clave que es un hash de MD5 de la clave de sesión RPC y valor sal. Después envía el resultado al agente de sincronización de hash de contraseñas a través de RPC. El controlador de dominio también pasa el valor sal al agente de sincronización mediante el protocolo de replicación del controlador de dominio, por lo que el agente podrá descifrar el sobre.
  3. Cuando el agente de sincronización de hash de contraseñas tiene el sobre cifrado, usa MD5CryptoServiceProvider y el valor sal para generar una clave para descifrar los datos recibidos en su formato original de MD4. El agente de sincronización de hash de contraseñas nunca tiene acceso a la contraseña de texto no cifrado. El uso del agente de sincronización de hash de contraseñas de MD5 se usa estrictamente para la compatibilidad del protocolo de replicación con el controlador de dominio; igualmente, solo se usa en el entorno local entre el controlador de dominio y el agente de sincronización de hash de contraseñas.
  4. El agente de sincronización de hash de contraseñas amplía el hash de contraseña binario de 16 bits a 64 bytes al convertir en primer lugar el hash con una cadena hexadecimal de 32 bytes y, después, convertir esta cadena de nuevo en binario con codificación UTF-16.
  5. El agente de sincronización de hash de contraseñas agrega un valor sal por usuario, que consta de un valor sal de longitud de 10 bytes, al archivo binario de 64 bits para proteger aún más el valor hash original.
  6. El agente de sincronización de hash de contraseñas combina el hash MD4 con el valor sal por usuario y los introduce en la función PBKDF2. Se usan 1000 iteraciones del algoritmo hash con clave HMAC-SHA256. Para obtener más información, consulte el documento Microsoft Entra y residencia de datos.
  7. El agente de sincronización de hash de contraseña toma el hash de 32 bits resultante, concatena el valor sal por usuario y el número de iteraciones de SHA256 con él (para usarlo con Microsoft Entra ID) y después transmite la cadena desde Microsoft Entra Connect a Microsoft Entra ID a través de TLS.
  8. Cuando un usuario intenta iniciar sesión en Microsoft Entra ID y escribe su contraseña, esta se ejecuta con el mismo proceso MD4 + sal + PBKDF2 + HMAC-SHA256. Si el hash resultante coincide con el valor hash almacenado en Microsoft Entra ID, el usuario ha especificado la contraseña correcta y se autentica.

Nota:

El hash MD4 original no se transmite a Microsoft Entra ID. En su lugar, se transmite el hash SHA256 del algoritmo hash MD4 original. Por consiguiente, si se obtiene el hash almacenado en Microsoft Entra ID, no se puede usar en un ataque Pass-the-Hash en el entorno local.

Nota:

El valor de hash de contraseñas NUNCA se almacena en SQL. Estos valores solo se procesan en memoria antes de enviarlos a Microsoft Entra ID.

Consideraciones sobre la seguridad

Al sincronizar contraseñas, la versión de texto sin formato de la contraseña no se expone a la característica de sincronización de hash de contraseña ni a Microsoft Entra ID ni a ninguno de los servicios asociados.

La autenticación del usuario tiene lugar en Microsoft Entra, no en la propia instancia de Active Directory de la organización. Los datos de la contraseña SHA256 almacenados en Microsoft Entra ID, un hash del hash MD4 original, son más seguros que los que se almacenan en Active Directory. Además, como no se puede descifrar este hash SHA256, no se vuelve al entorno de Active Directory de la organización y se presenta como una contraseña de usuario válida en un ataque pass-the-hash.

Consideraciones de la directiva de contraseña

Existen dos tipos de directivas de contraseña que se ven afectados por la habilitación de la sincronización de hash de contraseñas:

  • Directiva de complejidad de contraseñas
  • Directiva de expiración de contraseñas

Directiva de complejidad de contraseñas

Cuando se habilita la sincronización de hash de contraseñas, las directivas de complejidad de contraseñas en su instancia local de Active Directory reemplazan a las directivas de complejidad en la nube para los usuarios sincronizados. Puede usar todas las contraseñas válidas de su instancia local de Active Directory para acceder a servicios de Microsoft Entra.

Nota:

Las contraseñas para los usuarios que se crean directamente en la nube siguen estando sujetas a las directivas de contraseñas tal como se definen en la nube.

Directiva de expiración de contraseñas

Si un usuario está en el ámbito de sincronización de hash de contraseñas, de forma predeterminada la contraseña de cuenta en la nube se establece en No caduca nunca.

Puede seguir iniciando sesión en los servicios en la nube con una contraseña sincronizada que haya expirado en su entorno local. La contraseña en la nube se actualizará la próxima vez que cambie la contraseña en el entorno local.

CloudPasswordPolicyForPasswordSyncedUsersEnabled

Si hay usuarios sincronizados que solo interactúan con servicios integrados de Microsoft Entra y también deben cumplir una directiva de expiración de contraseñas, puede obligarlos a cumplir la directiva de expiración de contraseñas de Microsoft Entra habilitando la característica CloudPasswordPolicyForPasswordSyncedUsersEnabled (en el módulo MSOnline de PowerShell en desuso se denominaba EnforceCloudPasswordPolicyForPasswordSyncedUsers).

Cuando CloudPasswordPolicyForPasswordSyncedUsersEnabled está deshabilitado (que es la configuración predeterminada), Microsoft Entra Connect establece el atributo PasswordPolicies de los usuarios sincronizados en "DisablePasswordExpiration". Esto se hace cada vez que se sincroniza la contraseña de un usuario e indica a Microsoft Entra ID que omita la directiva de expiración de contraseñas en la nube para ese usuario. Puede comprobar el valor del atributo mediante el módulo de PowerShell de Microsoft Graph con el siguiente comando:

(Get-MgUser -UserId <User Object ID> -Property PasswordPolicies).PasswordPolicies

Para habilitar la característica CloudPasswordPolicyForPasswordSyncedUsersEnabled, ejecute el siguiente comando con el módulo Graph de PowerShell, tal como se muestra a continuación.

$OnPremSync = Get-MgDirectoryOnPremiseSynchronization
$OnPremSync.Features.CloudPasswordPolicyForPasswordSyncedUsersEnabled = $true

Update-MgDirectoryOnPremiseSynchronization `
  -OnPremisesDirectorySynchronizationId $OnPremSync.Id `
  -Features $OnPremSync.Features

Una vez habilitado, Microsoft Entra ID no va a cada usuario sincronizado para quitar el valor DisablePasswordExpiration del atributo PasswordPolicies. En su lugar, el valor DisablePasswordExpiration se quita de PasswordPolicies durante la siguiente sincronización de hash de contraseña para cada usuario, tras el siguiente cambio de contraseña en AD local.

Una vez habilitada la característica CloudPasswordPolicyForPasswordSyncedUsersEnabled, los nuevos usuarios se aprovisionan sin un valor PasswordPolicies.

Sugerencia

Se recomienda habilitar CloudPasswordPolicyForPasswordSyncedUsersEnabled, antes de habilitar la sincronización de hash de contraseñas, para que la sincronización inicial de los hashes de contraseñas no agregue el valor DisablePasswordExpiration al atributo PasswordPolicies para los usuarios.

La directiva de contraseñas predeterminada de Microsoft Entra requiere que los usuarios cambien la contraseña cada 90 días. Si la directiva de AD es también de 90 días, las dos directivas deben coincidir. Sin embargo, si la directiva de AD no es de 90 días, puede actualizar la directiva de contraseñas de Microsoft Entra para que coincida por medio del comando de PowerShell Update-MgDomain.

Microsoft Entra ID admite una directiva de expiración de contraseñas independiente por dominio registrado.

Advertencia: Si hay cuentas sincronizadas que necesitan contraseñas que no expiren en Microsoft Entra ID, debe agregar explícitamente el valor DisablePasswordExpiration al atributo PasswordPolicies del objeto de usuario en Microsoft Entra ID. Para ello, puede ejecutar el siguiente comando.

Update-MgUser -UserID <User Object ID> -PasswordPolicies "DisablePasswordExpiration"

Nota:

En el caso de los usuarios híbridos que tienen un valor PasswordPolicies establecido en DisablePasswordExpiration, este valor cambia a None después de ejecutar un cambio de contraseña en el entorno local.

Nota:

El comando de PowerShell Update-MgDomain no funciona en dominios federados.

Nota:

El comando de PowerShell Update-MgUser no funciona en dominios federados.

Sincronización de contraseñas temporales y "Forzar cambio de contraseña en el siguiente inicio de sesión"

Es habitual exigir al usuario a cambiar la contraseña durante el primer inicio de sesión, especialmente después de que se produzca un restablecimiento de la contraseña de administrador. Normalmente se conoce como establecer una contraseña "temporal" y se completa mediante la comprobación de la marca "El usuario debe cambiar la contraseña en el siguiente inicio de sesión" en un objeto de usuario de Active Directory (AD).

La funcionalidad de contraseña temporal ayuda a garantizar que la transferencia de propiedad de la credencial se complete al usarse por primera vez, con el fin de minimizar la duración del tiempo en el que más de un usuario tiene conocimiento de esa credencial.

Para admitir contraseñas temporales en Microsoft Entra ID para usuarios sincronizados, puede habilitar la característica ForcePasswordChangeOnLogOn, ejecutando el siguiente comando en el servidor de Microsoft Entra Connect:

Set-ADSyncAADCompanyFeature -ForcePasswordChangeOnLogOn $true

Nota:

Forzar a un usuario a cambiar su contraseña en el siguiente inicio de sesión requiere un cambio de contraseña al mismo tiempo. Microsoft Entra Connect no recoge la marca de forzar el cambio de contraseña por sí mismo. Es complementario al cambio de contraseña detectado que se produce durante la sincronización de hash de contraseñas.

Si el usuario tiene la opción "La contraseña no expira nunca" establecida en Active Directory (AD), la marca para forzar el cambio de contraseña no se establecerá en Active Directory (AD), por lo que no se le pedirá al usuario que cambie la contraseña durante el siguiente inicio de sesión.

Un nuevo usuario creado en Active Directory con la marca "El usuario debe cambiar la contraseña en el siguiente inicio de sesión" siempre se aprovisiona en Microsoft Entra ID con una directiva de contraseña para "Forzar el cambio de contraseña en el siguiente inicio de sesión", independientemente de que la característica ForcePasswordChangeOnLogOn tenga el valor true o false. Esta es una lógica interna de Microsoft Entra, ya que el nuevo usuario está aprovisionado sin contraseña, mientras que la característica ForcePasswordChangeOnLogOn solo afecta a escenarios de restablecimiento de contraseña de administrador.

Si se creó un usuario en Active Directory con "El usuario debe cambiar la contraseña en el siguiente inicio de sesión" antes de habilitar la característica, el usuario recibirá un error al iniciar sesión. Para corregir este problema, desactive y vuelva a comprobar el campo "El usuario debe cambiar la contraseña en el siguiente inicio de sesión" en Usuarios y equipos de Active Directory. Después de sincronizar los cambios en el objeto de usuario, el usuario recibe el mensaje previsto en Microsoft Entra ID para actualizar su contraseña.

Precaución

Solo debe usar esta característica cuando SSPR y la escritura diferida de contraseñas estén habilitados en el inquilino. De este modo, si un usuario cambia la contraseña a través de SSPR, se sincroniza con Active Directory.

Expiración de la cuenta

Si su organización usa el atributo accountExpires como parte de la administración de cuentas de usuario, este atributo no se sincroniza con Microsoft Entra ID. Por tanto, una cuenta de Active Directory expirada en un entorno configurado para la sincronización de hash de contraseña sigue activa en Microsoft Entra ID. Se recomienda usar un script de PowerShell programado que deshabilite las cuentas de AD de los usuarios cuando expiren (use el cmdlet Set-ADUser). Por el contrario, durante el proceso de eliminación de la expiración de una cuenta de AD, se debe volver a habilitar la cuenta.

Sobrescritura de las contraseñas sincronizadas

Un administrador puede restablecer manualmente la contraseña directamente en Microsoft Entra ID usando PowerShell (a menos que el usuario esté en un dominio federado).

En este caso, la nueva contraseña reemplaza a la contraseña sincronizada y todas las directivas de contraseñas definidas en la nube se aplican a la nueva contraseña.

Si vuelve a cambiar la contraseña local, la nueva contraseña se sincroniza con la nube y reemplaza a la contraseña actualizada manualmente.

La sincronización de una contraseña no influye en el usuario de Azure que ha iniciado sesión. Si se sincroniza un cambio de contraseña mientras tiene iniciada sesión en un servicio en la nube, este cambio no afectará de inmediato a la sesión actual del servicio en la nube. KMSI prolonga la duración de esta diferencia. Cuando el servicio en la nube requiera de nuevo su autenticación, deberá proporcionar la nueva contraseña.

Proceso de sincronización de hash de contraseña para Microsoft Entra Domain Services

Si usa Microsoft Entra Domain Services para proporcionar autenticación heredada para las aplicaciones y los servicios que necesitan usar Keberos, LDAP o NTLM, algunos procesos adicionales forman parte del flujo de sincronización de hash de contraseña. Microsoft Entra Connect usa el siguiente proceso adicional para sincronizar los valores hash de contraseña con Microsoft Entra ID con el fin de usarlos en Microsoft Entra Domain Services:

Importante

Microsoft Entra Connect solo debe instalarse y configurarse para la sincronización con entornos de AD DS locales. No se admite la instalación de Microsoft Entra Connect en un dominio administrado de Domain Services de Microsoft Entra para volver a sincronizar objetos con Microsoft Entra ID.

Microsoft Entra Connect solo sincroniza los valores hash de contraseña heredados cuando habilita Microsoft Entra Domain Services para su inquilino de Microsoft Entra. Los siguientes pasos no se usan si solo utiliza Microsoft Entra Connect para sincronizar un entorno de AD DS local con Microsoft Entra ID.

Si las aplicaciones heredadas no utilizan la autenticación NTLM ni enlaces simples LDAP, se recomienda deshabilitar la sincronización de hash de contraseña de NTLM para Microsoft Entra Domain Services. Para más información, consulte Deshabilitación de la sincronización de hash de credenciales NTLM y de conjuntos de cifrado débil.

  1. Microsoft Entra Connect recupera la clave pública para la instancia del inquilino de Microsoft Entra Domain Services.
  2. Cuando un usuario cambia la contraseña, el controlador de dominio local almacena el resultado del cambio de contraseña (hashes) en dos atributos:
    • unicodePwd para el hash de contraseña de NTLM.
    • supplementalCredentials para el hash de contraseña de Kerberos.
  3. Microsoft Entra Connect detecta los cambios de contraseña a través del canal de replicación de directorios (los cambios de atributo deben replicarse en otros controladores de dominio).
  4. Para cada usuario cuya contraseña ha cambiado, Microsoft Entra Connect realiza los siguientes pasos:
    • Genera una clave simétrica AES de 256 bits aleatoria.
    • Genera un vector de inicialización aleatorio necesario para la primera ronda de cifrado.
    • Extrae los valores hash de contraseña de Kerberos de los atributos supplementalCredentials.
    • Comprueba el valor SyncNtlmPasswords de la configuración de seguridad de Microsoft Entra Domain Services.
      • Si esta configuración está deshabilitada, genera un hash de NTLM aleatorio y de alta entropía (diferente de la contraseña del usuario). Después, este hash se combina con los hashes de contraseña de Kerberos extraídos del atributo supplementalCrendetials en una estructura de datos.
      • Si está habilitada, combina el valor del atributo unicodePwd con los hash de contraseña de Kerberos extraídos del atributo supplementalCredentials en una estructura de datos.
    • Cifra la estructura de datos única mediante la clave simétrica AES.
    • Cifra la clave simétrica AES usando la clave pública de Microsoft Entra Domain Services del inquilino.
  5. Microsoft Entra Connect transmite a Microsoft Entra ID la clave simétrica AES cifrada, la estructura de datos cifrada que contiene los valores hash de contraseña y el vector de inicialización.
  6. Microsoft Entra ID almacena la clave simétrica AES cifrada, la estructura de datos cifrada y el vector de inicialización para el usuario.
  7. Microsoft Entra ID envía a Microsoft Entra Domain Services la clave simétrica AES cifrada, la estructura de datos cifrada y el vector de inicialización usando un mecanismo de sincronización interno a través de una sesión HTTP cifrada.
  8. Microsoft Entra Domain Services recupera de Azure Key Vault la clave privada de la instancia del inquilino.
  9. Para cada conjunto de datos cifrado (que representa el cambio de contraseña de un solo usuario), Microsoft Entra Domain Services realiza los siguientes pasos:
    • Usa su clave privada para descifrar la clave simétrica AES.
    • Usa la clave simétrica AES con el vector de inicialización para descifrar la estructura de datos cifrados que contiene los hash de contraseña.
    • Escribe los valores hash de contraseña de Kerberos que recibe en el controlador de dominio de Microsoft Entra Domain Services. Los valores hash se guardan en el atributo supplementalCredentials del objeto de usuario que se cifra con la clave pública del controlador de dominio de Microsoft Entra Domain Services.
    • Microsoft Entra Domain Services escribe el hash de contraseña de NTLM que ha recibido en el controlador de dominio de Microsoft Entra Domain Services. El hash se guarda en el atributo unicodePwd del objeto de usuario que se cifra con la clave pública del controlador de dominio de Microsoft Entra Domain Services.

Habilitación de la sincronización de hash de contraseñas

Importante

Si va a migrar de AD FS (u otras tecnologías de federación) a la sincronización de hash de contraseña, consulte Recursos para migrar aplicaciones a Microsoft Entra ID.

Cuando se instala Microsoft Entra Connect con la opción Configuración rápida, la sincronización de hash de contraseña se habilita automáticamente. Para obtener más información, consulte Introducción a Microsoft Entra Connect mediante la configuración rápida.

Si usa una configuración personalizada al instalar Microsoft Entra Connect, la sincronización de hash de contraseña está disponible en la página de inicio de sesión del usuario. Para obtener más información, consulte Instalación personalizada de Microsoft Entra Connect.

Enabling password hash synchronization

Sincronización de hash de contraseñas y FIPS

Si el servidor se bloquea según el Estándar Federal de Procesamiento de la Información (FIPS), se deshabilita el hash MD5.

Para habilitar el MD5 para la sincronización de hash de contraseñas, realice los pasos siguientes:

  1. Vaya a %programfiles%\Microsoft Azure AD Sync\Bin.
  2. Abra miiserver.exe.config.
  3. Vaya al nodo configuration/runtime (al final del archivo).
  4. Agregue el siguiente nodo: <enforceFIPSPolicy enabled="false" />
  5. Guarde los cambios.
  6. Reinicie el sistema para que los cambios surtan efecto.

Como referencia, este fragmento de código debe ser similar al siguiente:

    <configuration>
        <runtime>
            <enforceFIPSPolicy enabled="false" />
        </runtime>
    </configuration>

Para obtener información sobre la seguridad y FIPS, consulte Sincronización de hash de contraseña de Microsoft Entra, cifrado y conformidad con FIPS.

Solución de problemas de sincronización de hash de contraseñas

Si tiene problemas con la sincronización de hash de contraseñas, vea Solución de problemas de sincronización de hash de contraseñas.

Pasos siguientes