¿RC4 deshabilitado tras las actualizaciones de abril de 2026? Excepción temporal para migrar hashes NT

Microsoft está reduciendo gradualmente el uso de RC4 en Kerberos, y muchos entornos de Active Directory avanzan hacia la autenticación exclusivamente con AES. Esta mejora de seguridad puede revelar un problema de compatibilidad concreto durante los proyectos de migración de contraseñas o cuentas.

En el escenario de migración Kerberos con RC4 que se describe aquí, si solo se migra el hash NT de la contraseña de un usuario, la cuenta de destino dispone del material necesario para autenticarse mediante Kerberos compatible con RC4 y mediante NTLM. Sin embargo, las claves Kerberos AES se derivan de la contraseña en texto claro mediante un proceso que incorpora una sal. No se pueden recrear únicamente a partir del hash NT. Este es el caso específico de migración de Active Directory al que se refiere el artículo tras la fase de actualizaciones de abril de 2026 que afecta a RC4.

Por ello, los entornos que deshabilitan RC4 pueden experimentar problemas de autenticación para los usuarios migrados si la migración se basa únicamente en sus hashes NT. En este caso concreto, puede ser necesaria una autorización temporal y específica de RC4 para las cuentas afectadas, hasta que sus contraseñas se cambien o sincronicen de forma que se generen claves AES válidas en el dominio de destino.

Los hashes NT son material de credenciales sensible. Las indicaciones siguientes se destinan exclusivamente a casos de compatibilidad controlados en los que realmente se necesita migrar hashes NT. No constituyen una recomendación general de seguridad ni una reversión amplia de las restricciones sobre RC4; tampoco se aplican a las migraciones exclusivamente con AES que utilizan sincronización de contraseñas en lugar de hashes NT. Si su escenario requiere una migración exclusivamente con AES, consulte el artículo Migrar contraseñas de Active Directory con RC4 deshabilitado (Kerberos AES).

CopyRight2, compilación 727 y posteriores: ya no se necesita un script de transformación de usuarios para permitir temporalmente RC4 al migrar hashes NT. En su lugar, active la opción «Temporarily allow RC4» en la página de configuración del trabajo de migración de usuarios y grupos.

En compilaciones anteriores de CopyRight2, puede establecer los tipos de cifrado Kerberos admitidos por el usuario de destino con este script de transformación:

Destination("msDS-SupportedEncryptionTypes")=60

El valor decimal 60 equivale a 0x3C en hexadecimal. Incluye RC4-HMAC, AES128, AES256 y compatibilidad con claves de sesión AES. En la práctica, permite que la cuenta migrada siga funcionando durante la fase temporal de compatibilidad con el hash NT al autorizar explícitamente RC4 junto con las marcas de cifrado AES. Así se evita configurar la cuenta exclusivamente para AES antes de que disponga de claves Kerberos AES actuales. Puede utilizar la calculadora de tipos de cifrado para visualizar la máscara de bits y comprobar o modificar las opciones habilitadas.

Utilice esta configuración únicamente como ayuda específica para usuarios u oleadas de migración que realmente requieran hashes NT. No sustituye al trabajo general de retirada de RC4, como revisar los eventos en los controladores de dominio de Windows Server, planificar el modo Enforcement o revertir de forma general las restricciones de cifrado RC4. Documente a qué usuarios se aplicó, asegúrese de que posteriormente admitan AES mediante sincronización, restablecimiento o cambio de contraseña y, cuando corresponda, implique a los responsables de seguridad.

Las cuentas de servicio deben revisarse por separado, ya que normalmente no cambian la contraseña mediante un inicio de sesión interactivo. Si las aplicaciones solicitan tickets de servicio Kerberos para estas cuentas, abandonar RC4 puede requerir un restablecimiento planificado de la contraseña, una actualización de las credenciales en la aplicación o la conversión a cuentas de servicio administradas, incluidas las cuentas de servicio administradas de grupo.

Esta configuración no crea claves AES para la cuenta. Sigue siendo necesario cambiar, restablecer o sincronizar la contraseña para que el dominio de destino disponga de claves Kerberos actuales derivadas de ella.

Importante para SID-History: habilitar RC4 temporalmente no elimina la necesidad de claves AES cuando los usuarios migrados recurren a su historial de SID para acceder a recursos que aún están en el dominio de origen, donde RC4 también está deshabilitado, al igual que en el dominio de destino, tras las actualizaciones de Windows de abril de 2026. Si un usuario del dominio de destino no ha cambiado su contraseña desde la migración, es posible que su cuenta todavía no tenga claves AES. Sin una clave AES, la autenticación para acceder a un recurso del dominio de origen puede fallar con el mensaje «Access is denied» («Acceso denegado»), aunque el SID anterior esté presente en sIDHistory y el usuario pueda iniciar sesión en el dominio de destino gracias al tipo de cifrado Kerberos RC4 habilitado temporalmente. Asegúrese de que cada usuario afectado obtenga claves AES antes de necesitar el acceso basado en SID-History. Puede combinar la solución temporal de RC4 con un cambio obligatorio de contraseña en el primer inicio de sesión. También puede utilizar el complemento de sincronización de contraseñas para que los usuarios migrados dispongan de claves AES desde el primer inicio de sesión y conserven su contraseña actual.

Una vez terminado el período de compatibilidad, retire la autorización temporal de RC4 o restablezca la configuración habitual de cifrado Kerberos de su organización. Cambiar la contraseña por sí solo no borra el atributo msDS-SupportedEncryptionTypes ni elimina el bit de RC4 si se estableció explícitamente.

Un procedimiento práctico es el siguiente:

1. Identifique los usuarios u oleadas que realmente requieran migrar hashes NT.
2. Habilite «Temporarily allow RC4» solo para esos usuarios.
3. Si lo desea, configure en el trabajo un cambio obligatorio de contraseña en el primer inicio de sesión en el dominio de destino.
4. Complete la migración.
5. Si impuso el cambio de contraseña, compruebe que todos los usuarios hayan iniciado sesión al menos una vez y cambiado su contraseña. Como alternativa, espere a que transcurra el período máximo de validez definido para las contraseñas.
6. Retire la autorización temporal de RC4 o restablezca la configuración habitual de tipos de cifrado.
7. Documente la excepción y su retirada para que la configuración temporal no permanezca más tiempo del necesario.

Este procedimiento mantiene disponible la vía de migración sin convertir una necesidad puntual de compatibilidad en una excepción de seguridad permanente.

Para conocer los detalles de migración del producto, consulte la guía de administración del complemento de sincronización y migración de contraseñas. Si no sabe si su entorno requiere esta configuración, póngase en contacto con el soporte de Sys-Manage antes de cambiar el plan de migración. Podemos ayudarle a determinar si el problema está relacionado con RC4 deshabilitado para las cuentas de Active Directory/Kerberos afectadas, si realmente se necesitan migrar hashes NT, si conviene más sincronizar las contraseñas y qué tareas de limpieza deben planificarse después de la migración.