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

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 revertir el resultado de una función unidireccional a la versión en 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. No puede modificar la frecuencia de este proceso. 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 la autenticación multifactor de Microsoft Entra, el acceso condicional, la Protección de id. de Microsoft Entra 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 en el entorno 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. La sesión actual del servicio en la nube no se ve afectada inmediatamente por un cambio de contraseña sincronizado, mientras ha iniciado sesión, en un 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 la 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 se necesita ningún servidor adicional y se elimina la dependencia de 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.

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 del conector AD DS 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, para que el agente pueda 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. La utilización de MD5 por parte del agente de sincronización de hash de contraseñas es estrictamente para la compatibilidad del protocolo de replicación con el controlador de dominio y 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 1.000 iteraciones del algoritmo hash con clave HMAC-SHA256. Para más información, vea las notas del producto de Microsoft Entra.

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 hash almacenado en Microsoft Entra ID, significa que el usuario ha escrito la contraseña correcta y se ha autenticado.

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. Como resultado, 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 en texto sin formato de la contraseña no se expone a la característica de sincronización de hash de contraseñas 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 este hash SHA256 no se puede descifrar, no se puede devolver 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 de Active Directory local reemplazan a las directivas de complejidad en la nube para los usuarios sincronizados. Puede usar todas las contraseñas válidas de su instancia de Active Directory local 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 manera 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 el 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 el valor predeterminado), Microsoft Entra Connect actualiza el atributo PasswordPolicies de los usuarios sincronizados a "DisablePasswordExpiration". Esta actualización se realiza 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 los comandos siguiente con el módulo Graph de PowerShell:

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

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

Nota

Debe instalar el módulo de PowerShell de MSGraph para que el script anterior funcione. Si recibe algún error relacionado con privilegios insuficientes, asegúrese de que ha dado consentimiento al ámbito de la API correctamente mediante el siguiente comando al conectarse Connect-MgGraph -Scopes "OnPremDirectorySynchronization.ReadWrite.All"

Una vez que se ha habilitado, Microsoft Entra ID no accede 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 en el etorno 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. Pero si la directiva de AD no es de 90 días, puede actualizar la directiva de contraseñas de Microsoft Entra para que coincida mediante el comando Update-MgDomain de PowerShell.

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 agregar este valor, ejecute 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 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.

A fin de admitir contraseñas temporales en Microsoft Entra ID para usuarios sincronizados, puede habilitar la característica ForcePasswordChangeOnLogOn mediante la ejecución de los comandos siguientes con el módulo Graph de PowerShell:

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

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

Nota

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 en la organización se 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.

Sincronización de hash de contraseñas y autenticación de tarjeta inteligente

Los clientes pueden requerir que sus usuarios inicien sesión en dominios de Windows con una tarjeta inteligente física CAC/PIV. Para ello, deben configurar la propiedad de usuario Tarjeta inteligente necesaria (SCRIL) para el inicio de sesión interactivo en Active Directory.

Cuando SCRIL está habilitado en un objeto de usuario, el controlador de dominio asigna aleatoriamente la contraseña de AD del usuario a un valor que nadie conoce, y el usuario tiene que inscribirse y autenticarse posteriormente en el dominio de Windows a través de la tarjeta inteligente.

Con la sincronización de hash de contraseña habilitada, este hash de contraseña de AD se sincroniza con Microsoft Entra ID para que también se pueda usar para la autenticación en la nube.

Nota

Con el lanzamiento de la versión 2.4.18.0 de Microsoft Entra Connect Sync, se ha corregido un problema que se producía cuando SCRIL se vuelve a habilitar en un objeto de usuario. Volver a habilitar SCRIL es habitual en escenarios en los que un usuario pierde su tarjeta inteligente, lo que necesita que SCRIL esté deshabilitado y el usuario se proporcione con una contraseña temporal hasta que se emita una nueva tarjeta inteligente

Anteriormente, cuando SCRIL se volvía a habilitar y se generaba una nueva contraseña de AD aleatoria, el usuario todavía podía usar su contraseña antigua para autenticarse en el identificador de Microsoft Entra. Ahora, Connect Sync se ha actualizado para que la nueva contraseña de AD aleatoria se sincronice con Microsoft Entra ID y la contraseña antigua no se pueda usar una vez que se habilite el inicio de sesión de tarjeta inteligente.

Se recomienda que los administradores realicen una sincronización completa si tiene usuarios con un bit SCRIL en el dominio de AD. Si realiza una sincronización completa, es posible que se pida a los usuarios finales que vuelvan a iniciar sesión con la contraseña actualizada si no se usa la autenticación basada en certificados.

Sobrescritura de las contraseñas sincronizadas

Una persona con rol de 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 en el entorno 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. La sesión actual del servicio en la nube no se ve afectada inmediatamente por un cambio de contraseña sincronizado, mientras ha iniciado sesión, en un 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 a fin de proporcionar autenticación antigua para las aplicaciones y los servicios que necesitan usar Kerberos, LDAPS o NTLM, algunos procesos adicionales forman parte del flujo de sincronización de hash de contraseña. Microsoft Entra Connect usa el siguiente proceso para sincronizar los valores hash de contraseña con Microsoft Entra ID a 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 Microsoft Entra Domain Services para volver a sincronizar objetos con Microsoft Entra ID.

Microsoft Entra Connect solo sincroniza los valores hash de contraseña antiguos 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 antiguas no utilizan la autenticación NTLM ni enlaces simples LDAPS, 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 los conjuntos de cifrados poco seguros y la sincronización de hash de credenciales de NTLM.

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 en el entorno 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 estos 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 desencriptar la clave simétrica AES.
   • Usa la clave simétrica AES con el vector de inicialización para desencriptar 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 desde AD FS (u otras tecnologías de federación) a la sincronización de hash de contraseña, vea 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.

Sincronización de hash de contraseñas y FIPS

Si el servidor está bloqueado según el Estándar federal de procesamiento de 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 entren en vigor.

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ña con la sincronización de Microsoft Entra Connect.

Pasos siguientes

• Microsoft Entra Connect Sync: comprender y personalizar la sincronización
• Más información sobre la ¿Qué es la identidad híbrida con Microsoft Entra ID?
• Recursos para migrar aplicaciones a Microsoft Entra ID