Migración de RC4 y AD: descubre los escenarios de fallo que se esconden en tu dominio de origen

Imagínate esto.

Durante una migración rutinaria de Active Directory, todo parece ir bien. Una cuenta de servicio se traslada sin problemas del dominio de origen al de destino. Los permisos parecen correctos. Las pertenencias a grupos se mantienen intactas. Se conserva el historial de SID.

Una semana después, la aplicación asociada a esa cuenta empieza a fallar de forma intermitente. Para cuando alguien relaciona los fallos con la migración, el servicio de asistencia técnica ya tiene 40 incidencias abiertas. Y nadie sabe explicarlo.

¿Qué ha cambiado? La cuenta tenía claves Kerberos basadas únicamente en RC4 en el origen. Las herramientas de migración estándar copiaron el hash NTLM. El dominio de destino —recién creado, con los parches instalados y la configuración predeterminada de AES— no tiene claves AES para esa cuenta.

Y a partir del 14 de abril de 2026, los DC actualizados ya no recurrirán implícitamente al cifrado RC4 para las cuentas que no tengan una configuración explícita de RC4. La autenticación simplemente se detendrá.

Si está llevando a cabo un proyecto de migración, consolidación o gestión de identidades basado en relaciones de confianza de Active Directory que se prolongue más allá de la fecha límite de aplicación del RC4, fijada para julio de 2026, es posible que este riesgo ya esté presente en su entorno.

En el blog Cómo auditar su entorno en busca de cifrado RC4, mis colegas Guido Grillenmeier y Rich Peckham proporcionan ejemplos de consultas que puede utilizar como plantillas para auditar su entorno y localizar cuentas que dependan de RC4.

Lo que necesitas ahora es un plan de acción que te ayude a evitar esos posibles fallos en las cuentas.

Lo que aprenderás en este artículo

• Dónde es más probable que se produzcan fallos de migración relacionados con RC4
• Los tipos de fallos que pueden producirse y a qué hay que prestar atención
• Cómo evaluar sistemáticamente tu entorno y detectar cuentas con riesgo de fallo
• ¿Qué herramientas gratuitas pueden ayudarte en tu investigación?
• Medidas que debes tomar ahora mismo para adelantarte a la transición al sistema AES

¿Por qué los proyectos de migración se ven especialmente afectados por los cambios en RC4?

El calendario de obsolescencia de RC4 está bien documentado.

• Enero de 2026: Microsoft introdujo la auditoría y el RC4DefaultDisablementPhase clave del Registro.
• Abril de 2026: Microsoft ha cambiado la configuración predeterminada del KDC a AES únicamente para las cuentas que no tienen el msDS-SupportedEncryptionTypes atributo establecido explícitamente.
• Julio de 2026: Microsoft elimina el modo de auditoría y deja de respetar el RC4DefaultDisablementPhase revertir por completo la clave del registro, de modo que solo las cuentas con excepciones RC4 explícitas sigan pudiendo recibir tickets RC4.

La publicación sobre el recorrido de auditoría de Semperis aborda en detalle el proceso de detección en estado estable. Lo que ese recorrido no aborda es el escenario de migración, en el que el riesgo se manifiesta de tres formas concretas:

• Las migraciones trasladan las cuentas a través de los límites de seguridad. Una cuenta que hoy se autentica correctamente en el sistema de origen puede fallar en cuanto llega a un sistema de destino con una aplicación más estricta de las políticas, incluso si el sistema de origen tiene una política permisiva.
  
• Las herramientas de migración gestionan las credenciales de forma asimétrica. Las herramientas de migración estándar copian el hash NTLM, pero no copian las claves AES. La serie «AD Hardening» de Microsoft, en su cuarta parte, lo explica claramente: si el dominio de destino no es compatible con RC4, será necesario restablecer la contraseña de la cuenta en el dominio de destino para que Kerberos funcione. Esto es así para todas las cuentas cuyas claves del lado de origen sean exclusivamente RC4.
  
• Los fallos son silenciosos. Las dependencias de RC4 en estado estable se manifiestan como eventos KDCSVC 201-209. Los fallos provocados por la migración, en cambio, a menudo no lo hacen. En su lugar, se presentan como errores de aplicación sin una relación evidente con el tipo de cifrado. La causa raíz debe deducirse, no observarse.

En conjunto, estos factores hacen que una sola consulta de PowerShell resulte insuficiente. Los equipos de migración necesitan un proceso de análisis estructurado.

¿Qué cuentas corren el riesgo de sufrir fallos en la migración relacionados con RC4?

Antes de continuar, una aclaración. Las actualizaciones de abril de 2026 se implementaron sin los fallos generalizados que anticipaban algunos medios especializados, al menos según lo que hemos observado en la práctica. En la mayoría de los entornos de los clientes, el cifrado Kerberos configurado se mantiene y la autenticación sigue funcionando con normalidad.

Este artículo no pretende alarmar.
Lo que sí sostiene es que persiste un modo de fallo concreto e identificable, y que las transiciones de migración son precisamente los acontecimientos que más probabilidades tienen de ponerlo de manifiesto.

Tres situaciones que ponen en riesgo una cuenta

Los errores silenciosos de migración relacionados con RC4 suelen producirse cuando se dan las tres condiciones siguientes:

• Se indicó el AES, pero no se entregó. La cuenta msDS-SupportedEncryptionTypes El atributo se rellena con bits AES o queda en blanco si el valor predeterminado del dominio es AES. El KDC interpreta esto como «AES es compatible» e intenta emitir tickets AES para la cuenta.
  
• No hay claves AES en el sistema de destino. Las claves AES solo se generan cuando se establece una contraseña en un entorno DFL 2008 o superior. Las cuentas de mayor riesgo son las antiguas que nunca se han restablecido y las cuentas migradas en las que se copiaron las credenciales sin regenerar las claves AES. El atributo indica «AES», pero las claves solo indican «RC4».
  
• La cuenta se está autenticando activamente a través de Kerberos. El fallo solo se detecta cuando la cuenta solicita un ticket de Kerberos. En ese momento, el KDC intenta utilizar AES (según la condición 1), no encuentra ninguna clave AES (según la condición 2) y la autenticación falla. Las cuentas inactivas y las que se autentican únicamente a través de NTLM pasan desapercibidas, ya que nunca se pone a prueba ese estado defectuoso.

¿Qué tipos de cuentas corren mayor riesgo?

En la mayoría de las empresas, el conjunto de cuentas en riesgo no es aleatorio. Suele agruparse en cinco tipos de cuentas, categorías que conviene tener en cuenta en cualquier reunión de análisis previo a la migración.

• Cuentas de servicio heredadas de la implementación inicial de Active Directory, creadas entre los años 2000 y 2010 y cuyas contraseñas nunca se han cambiado. Estas constituyen el grupo más numeroso dentro de la población en riesgo.
• Cuentas con PASSWD_CANT_CHANGE o DONT_EXPIRE_PASSWORD Indicadores UAC activados. Estos indicadores guardan una estrecha relación con las contraseñas que se establecen una sola vez durante el aprovisionamiento y nunca se cambian.
• Sistemas que no sean Windows con credenciales Kerberos almacenadas localmente: hosts Linux con archivos keytab, servidores de aplicaciones Java con credenciales codificadas de forma fija krb5.conf, dispositivos NAS incorporados al dominio, dispositivos de red con credenciales almacenadas en caché.
• Cuentas de servicio que pertenecían a administradores que ya no están en la empresa, en las que existen credenciales, pero se ha perdido el conocimiento interno sobre qué depende de dicha cuenta.
• Cuentas informáticas en las que ha fallado la rotación automática de contraseñas: equipos que llevan mucho tiempo sin conectarse, cuentas huérfanas, cuentas con PasswordNeverExpires configurado incorrectamente.

¿Cuántas cuentas pueden verse afectadas por RC4 durante la migración a Active Directory, de media?

Según la experiencia práctica adquirida en proyectos de migración, el número de cuentas en riesgo en un entorno determinado suele situarse dentro de estos rangos.

Tipo de entorno	Población media en situación de riesgo
Entornos de nueva creación implantados a partir de 2010 con una sólida gestión de identidades	0-10 cuentas
Empresa típica de tamaño mediano a grande con una trayectoria de al menos una década en Active Directory	Entre 20 y 200 cuentas
Entornos creados mediante fusiones y adquisiciones sin una posterior consolidación de la identidad	Entre varios cientos y unos pocos miles
Entornos adquiridos en los que la organización adquirente aún no ha completado la racionalización de identidades	Muy variable, llegando a veces a superar el rango de fusiones y adquisiciones

NOTA: Estos son puntos de partida para definir el alcance de las conversaciones, no cifras concretas. La población real solo podrá confirmarse mediante el trabajo de análisis que vamos a llevar a cabo.

Por qué la migración de Active Directory concentra el riesgo

Estas cuentas que dependen de RC4 pueden permanecer en el entorno de producción durante años sin fallar. Su autenticación Kerberos se basa en tickets almacenados en caché y en una reautenticación poco frecuente, lo que hace que la falta de claves AES pase desapercibida durante el funcionamiento normal.

La transición de la migración cambia todo eso. Invalida simultáneamente las credenciales almacenadas en caché en todo el sistema, obliga a enviar nuevas solicitudes AS-REQ y TGS-REQ en un breve intervalo de tiempo y pone de manifiesto el modo de fallo justo en el momento en que los conocimientos de los responsables ya han quedado obsoletos y el análisis de la causa raíz resulta más complicado.

Los dos tipos de fallos que estás buscando

Antes de entrar en la metodología de análisis, conviene identificar las dos categorías distintas de riesgo de fallo que se pretende detectar.

• Desviación latente de la configuración. Cuentas que hoy parecen estar en orden, pero que fallarán cuando se apliquen las medidas de cumplimiento: la población en riesgo definida anteriormente. Los atributos de AD indican una cosa, pero el material de clave real indica otra. Esto no se puede detectar consultando únicamente los atributos de AD.
  
• Riesgo relacionado con el mecanismo de migración. Fallos que se derivan específicamente de la forma en que la migración transfiere los datos de identidad. Estos no aparecen en la telemetría en estado estable de ninguna de las dos partes e incluyen:
  • Dependencias históricas del SID
  • Escenarios de doble ejecución en los que la misma identidad lógica se autentica desde ambos dominios
  • El valor objetivo de DFL es inferior al de 2008 (se incumple de forma silenciosa cada vez que se restablece la contraseña tras la migración)
  • Discrepancias en los atributos de confianza.

Ambas categorías requieren pruebas para poder identificarlas. Ninguna de ellas puede detectarse de forma fiable mediante herramientas que solo analizan una fuente de datos.

Cómo prepararse para la transición de RC4 a AES: una metodología de análisis de la migración en seis fases

Comprender el contexto en el que operan tus cuentas que dependen de RC4 —así como los posibles tipos de fallos con los que te puedes encontrar— te proporciona un marco de referencia sobre el que basarte a medida que avanzas en el proceso de localizar dichas cuentas y configurarlas para AES.

Esta es la secuencia probada en la práctica que utilizamos con los clientes en los proyectos de migración. Cada fase aporta datos que se incorporan a la matriz final de escenarios de fallo.

Fase 0: Establecer las reglas del juego

Antes de buscar problemas, documenta tanto el entorno de origen como el de destino. La asimetría entre ambos constituye en sí misma una superficie de riesgo principal.

Para cada dominio, anota:

• Nivel funcional de bosque y dominio
• Versión del sistema operativo de cada servidor de dominio
• Última actualización acumulativa
• El valor de RC4DefaultDisablementPhase en cada controlador de dominio (DC)

Es posible que algunos centros de distribución no dispongan de RC4DefaultDisablementPhase o DefaultDomainSupportedEncTypes no está configurado en absoluto. Esto suele significar que el parámetro no se ha configurado explícitamente y que el servidor de dominio sigue el comportamiento predeterminado actual para su sistema operativo y su nivel de parches.

Lo que importa ahora es si ese comportamiento eficaz es coherente en todo el ámbito y entre la lengua de origen y la de destino.

      $path = 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\' +
    'Policies\System\Kerberos\Parameters'
Invoke-Command -ComputerName (Get-ADDomainController -Filter *).HostName -ScriptBlock {
    Get-ItemProperty -Path $using:path -ErrorAction SilentlyContinue |
        Select-Object PSComputerName, RC4DefaultDisablementPhase,
                               DefaultDomainSupportedEncTypes
}

Busca asimetrías: si un dominio de origen en DFL 2003 tiene la fase sin configurar y se empareja con un destino en DFL 2016 que ya se encuentra en la fase 2, todas las cuentas migradas que carezcan de claves AES dejarán de funcionar en el momento de la transición.

Atención a todos los servidores DC que ejecuten Server 2012 o 2012 R2 con ESU caducadas: estos no recibirán los parches de julio de 2026 y son fuentes RC4 inamovibles.

Si faltan las claves del Registro: comprueba la versión del sistema operativo del servidor de dominio (DC), el nivel de parches y si otros servidores de dominio del mismo dominio muestran valores explícitos. La señal de alerta no es la ausencia de la clave en sí, sino un entorno heterogéneo en el que algunos servidores de dominio se comportan de una manera y otros de otra.

Considera la falta de coincidencia entre origen y destino como una señal de riesgo: la ausencia de claves en el origen junto con configuraciones de fase explícitas en el destino, o valores predeterminados nulos en un lado y excepciones RC4 explícitas en el otro, son precisamente las combinaciones que ocultan los casos de fallo en la migración hasta el momento de la transición.

Documentar el fideicomiso de migración: Un fideicomiso con msDS-SupportedEncryptionTypes Si se establece en 0x4 (solo RC4), se garantiza que se alcanzará el punto de ruptura en julio de 2026. Una confianza con el atributo «null» sigue el comportamiento predeterminado más reciente de AES y es mucho menos probable que se alcance el punto de ruptura que en el caso de una confianza fijada explícitamente en RC4.

Fase 1: Comprueba que ambos dominios puedan ver el tráfico RC4

No se puede encontrar lo que no se registra. Comprueba la auditoría de Kerberos en todos los servidores de dominio de ambos dominios:

      auditpol /get /subcategory:"Servicio de autenticación Kerberos"
auditpol /get /subcategory:"Operaciones con tickets de servicio Kerberos"

Ambos deberían notificar tanto los éxitos como los fallos. Si no es así, aplica el objeto de política de grupo (GPO) de auditoría estándar de Kerberos en la unidad organizativa (OU) del controlador de dominio antes de continuar.

En los servidores DC con parches aplicados hasta enero de 2026 o posteriores, el registro del sistema también debería estar registrando los eventos 201-209 del proveedor KDCSVC. La ausencia total de estos eventos en un entorno con aplicaciones heredadas conocidas suele indicar una falta de registro más que un entorno limpio, por lo que conviene verificar la aplicación de los parches y la recopilación de datos antes de dar por sentado que no existe exposición a RC4.

Presta atención también a la visibilidad parcial: la auditoría activada en algunos servidores de dominio pero no en otros, eventos reenviados solo desde una parte del entorno, o ventanas de retención demasiado cortas para detectar cuentas de servicio de baja frecuencia.

Fase 2: Detección de la capa de configuración

Esta fase identifica los escenarios de fallo que se pueden detectar únicamente a partir de los atributos de AD. La vía más rápida es el código abierto RC4-ADAssessment Módulo de PowerShell, que se ejecuta en ambos dominios:

      Install-Module -Name RC4-ADAssessment
Import-Module RC4-ADAssessment

Invoke-RC4Assessment -Domain source.contoso.com -ExportResults
Invoke-RC4Assessment -Domain target.contoso.com -ExportResults

Este módulo recoge:

• Configuración del cifrado de corriente continua
• Cifrado de confianza
• Antigüedad de la contraseña KRBTGT
• Todas las cuentas de servicio marcadas como «solo RC4» o «compatibles con DES»
• Cuentas con el USE_DES_KEY_ONLY Indicador UAC
• Cuentas con excepciones RC4 explícitas
• Cuentas con contraseñas caducadas

Cada hallazgo se exporta con comandos de corrección listos para copiar y pegar. Considera el resultado como una lista de candidatos priorizados, más que como una prueba definitiva. La fase 2 te indica dónde investigar, pero son los datos de los eventos y el contexto de la aplicación los que confirman un escenario real de fallo en la migración.

Presta especial atención a las cuentas de servicio cuyas PasswordLastSet es anterior a la actualización de DFL del dominio de origen a la versión 2008. Estos son candidatos de alta prioridad para la población de riesgo definida anteriormente y deben contrastarse con los datos de eventos y el historial migratorio.

Fase 3: Descubrimiento conductual

La configuración te indica lo que está permitido. Los eventos te indican lo que está ocurriendo realmente. A menudo no coinciden.

Ejecuta la evaluación con el análisis del registro de eventos activado o consulta directamente Sentinel o Splunk:

      Invoke-RC4Assessment -Domain source.contoso.com `
-AnalyzeEventLogs -EventLogHours 168 -ExportResults

El resultado más significativo es la discrepancia entre la configuración de AES y el uso de RC4: cuentas en las que AD indica que «admite AES», pero los registros de eventos muestran que se emiten tickets con RC4. Esa discrepancia es precisamente el tipo de fallo que se pondrá de manifiesto durante la migración.

En lo que respecta específicamente a los proyectos de migración, se deben incluir también las solicitudes TGS entre dominios. En 4769 eventos, busca los tickets de servicio en los que ServiceName está en otro mundo y TicketEncryptionType es 0x17. El tráfico RC4 entre dominios actúa como indicador de fallos en la ruta de confianza de la migración cuando se aplica la política, y hasta los hallazgos de bajo volumen merecen una investigación directa, ya que la aplicación afectada puede ser crítica para el negocio.

Presta también atención a las cuentas de servicio que solo se autentican durante las ventanas de procesamiento por lotes, el procesamiento de fin de mes o las tareas programadas; es fácil pasarlas por alto en ventanas de recopilación breves y, a menudo, son las que provocan las sorpresas más desagradables durante la transición.

Fase 4: Detección en la capa de aplicación

Es aquí donde la mayoría de las migraciones fracasan, y donde las herramientas compatibles con Active Directory ofrecen menos visibilidad.

Analiza todos los hosts de Linux, Java y dispositivos de red que utilicen Kerberos basado en Active Directory.

Lista de archivos keytab; cualquier cosa que contenga únicamente arcfour-hmac Las entradas están fijadas con RC4. Es probable que aún existan algunos sistemas que no sean de Windows que sigan utilizando keytabs generados hace años.

Comprobar /etc/krb5.conf para valores fijos default_tkt_enctypes o permitted_enctypes en la que solo figura RC4. Ambas dejarán de funcionar a partir de julio de 2026, independientemente de lo que haga AD, y la actualización de la tabla de claves (keytab) para el dominio de destino requiere que la cuenta migrada cuente con claves AES, lo que nos lleva de nuevo a las conclusiones de la Fase 2.

Para cada aplicación que utilice la autenticación Kerberos, explique al propietario lo siguiente:

• La cuenta de servicio que se está utilizando actualmente y su msDS-SupportedEncryptionTypes valor
• Dónde está alojada la aplicación
• Si se está utilizando un keytab y cuándo se generó
• Si la documentación del proveedor especifica los tipos de cifrado Kerberos obligatorios
• Si la preautenticación utiliza RC4 con clave fija

Hay que contar con lagunas en la documentación. Muchos propietarios no sabrán cuándo se generó el keytab ni si el proveedor es compatible con AES de forma adecuada, y esa incertidumbre es en sí misma un indicador útil del riesgo.

Busca también configuraciones de cifrado fijadas en código en aquellos lugares a los que el descubrimiento de atributos de AD no llega en la seguridad de la red:

• En Network security: Configure encryption types allowed for Kerberos Configuración de GPO
• Servidores vinculados de SQL Server
• Identidades de grupos de aplicaciones de IIS con contraseñas caducadas
• Aplicaciones Java con -Dsun.security.krb5.permitted_enctypes Parámetros de la JVM

Fase 5: Riesgos específicos de la migración

Los posibles fallos que detectaremos en esta fase solo se producen durante la transición de la migración. Se trata de características propias del mecanismo de migración, y no de ninguno de los dos dominios en estado estable.

Analiza cómo gestiona las contraseñas tu herramienta de migración. Si la herramienta copia las contraseñas, copiará cualquier tipo de credencial que exista. Una cuenta que en el origen solo tenga claves RC4 llegará al destino con claves RC4 únicamente. La medida de mitigación habitual —el restablecimiento forzado de la contraseña tras la migración— puede provocar fallos en los servicios dependientes si la aplicación está en ejecución.

Cada cuenta de servicio debe contar con un plan documentado de restablecimiento tras la migración que incluya una ventana de mantenimiento.

Evalúa con objetividad los métodos de sincronización de contraseñas. Algunas herramientas de migración ofrecen filtros de sincronización de contraseñas que registran los cambios en los servidores de dominio de origen y los reproducen en el destino. Estos resuelven el problema de la generación de claves AES en el destino, pero:

• Instalar una ruta de código con privilegios en los servidores de dominio de origen
• Exponer texto sin cifrar de forma temporal en la memoria
• Activar solo en caso de cambios de contraseña (sin tener en cuenta en absoluto las cuentas inactivas ni las cuentas de servicio que no cambian de contraseña)
• Se asume un riesgo operativo si el filtro falla de forma silenciosa

El uso de estas herramientas es legítimo en marcos de coexistencia delimitados en los que las compensaciones están documentadas y aceptadas, pero no sustituye al trabajo de exploración mencionado anteriormente.

Identifique los casos en los que un mismo sistema se ejecuta en dos entornos. Durante el periodo de migración, es posible que los usuarios y los servicios existan tanto en el entorno de origen como en el de destino. Identifique los casos en los que una misma identidad lógica se autentica desde ambos lados, lo que suele ocurrir en relaciones de confianza entre dominios, en entornos de federación o en un inquilino de Entra ID sincronizado.

Cada uno de ellos es un posible punto de fallo, ya que la negociación del cifrado varía según la parte.

Identificar las dependencias del historial de SID. El historial de SID preserva el acceso a los recursos; sin embargo, las claves de cifrado son independientes. Una aplicación que autorice mediante el historial de SID pero que emita tickets utilizando las claves de la cuenta de destino puede fallar si dichas claves solo admiten RC4.

Comprueba que el DFL de destino sea, como mínimo, 2008. En las consolidaciones que implican entornos adquiridos, el DFL de destino a veces acaba siendo inferior al esperado. Por debajo del DFL 2008, los restablecimientos de contraseña no generan claves AES, por lo que todo el plan de restablecimiento posterior a la migración falla sin que se detecte. Compruébalo antes de la transición. No durante la misma.

El verdadero riesgo en esta fase reside en las combinaciones, no en los hechos aislados. Por ejemplo:

• Migraciones con copia de contraseñas sin un plazo de restablecimiento documentado
• Identidades de ejecución dual sin comprobación ruta por ruta
• El historial de SID se considera una solución de autenticación
• Un problema con el sistema DFL detectado solo tras la puesta en marcha de la fase piloto

Estos son los patrones específicos de la migración que convierten los hallazgos manejables en situaciones de interrupción del servicio.

Fase 6: Elaborar la matriz de escenarios de fallo

El resultado de las cinco primeras fases no es una lista genérica de riesgos. Se trata de una matriz de escenarios de fallo: una fila para cada forma identificable en la que la migración pueda fallar. Hazla concisa. Para cada fila, describe el escenario, qué lo desencadena, cómo se manifestará y las medidas necesarias antes de la conmutación.

Los resultados de las fases 2, 3 y 4 suelen constituir las primeras filas.

La fase 5 incorpora los escenarios exclusivos de migración que no aparecen en el análisis en estado estable.

Una vez completada, esta matriz se convierte en el registro de seguimiento de la transición y en la base para la decisión de seguir adelante o no.

Situación	Disparador	Cómo se manifiesta	Medidas previas a la transición
La cuenta de servicio se ha migrado con AES configurado, pero sin claves AES	Cambio de sistema o primera solicitud Kerberos nueva	La autenticación de la aplicación falla tras la migración; las tareas programadas o los servicios comienzan a fallar una vez que caducan los tickets almacenados en caché	Restablece la contraseña en el sistema de destino, comprueba que se ha generado correctamente la clave AES, vuelve a probar la aplicación y programa el cambio para una ventana de mantenimiento
Servidor Linux o Unix con un keytab que solo admite RC4	Julio de 2026: aplicación o transición al dominio de destino	La autenticación Kerberos falla desde el host que no es Windows; el servicio recurre a un método alternativo o se detiene	Vuelve a generar el keytab con credenciales compatibles con AES tras confirmar que la cuenta migrada dispone de claves AES
Confianza entre dominios vinculada explícitamente a RC4	Entrada en vigor en julio de 2026	Las solicitudes de tickets entre dominios fallan durante la coexistencia o el acceso por etapas	Elimine la configuración de confianza exclusiva para RC4 y compruebe el comportamiento de la confianza mediante tráfico de prueba directo antes de la transición
Dominio de destino por debajo de DFL 2008	Plan de restablecimiento tras la migración	El restablecimiento de la contraseña parece completarse con éxito, pero nunca se generan las claves AES y la aplicación sigue fallando	Aumentar el DFL objetivo antes de la migración, o rediseñar la ruta de corrección antes de la primera prueba piloto
Configuración de Kerberos en Java, en un dispositivo o local fijada de forma estática en RC4	Cambio de sistema, aplicación de la normativa o primera solicitud de un nuevo billete	Un nivel de la aplicación falla, aunque la configuración del lado de AD parece correcta	Eliminar la fijación de RC4, comprobar que el proveedor es compatible con AES y probar la ruta exacta de la aplicación antes de la puesta en producción
Identidad de doble ejecución que se autentica de forma diferente en el origen y en el destino	Ventana de coexistencia o ola de migración por etapas	El comportamiento del acceso varía según el dominio, el servidor o la ruta, lo que provoca un impacto desigual en los usuarios	Documenta el comportamiento de cada ruta, reduce los solapamientos siempre que sea posible y comprueba explícitamente la coexistencia de las rutas

Lo que realmente encontrarás

En los proyectos relacionados con la migración, los resultados más relevantes suelen clasificarse en cuatro categorías:

• Cuentas de servicio con AES configurado pero sin claves AES. A menudo se trata de cuentas antiguas que nunca se han restablecido o de cuentas migradas en las que se copió el material de credenciales sin regenerar las claves AES. El atributo de AD es erróneo. La correlación del registro de eventos de la Fase 3 es la única forma fiable de detectarlas. Además, son las más fáciles de solucionar. Un restablecimiento de contraseña en un entorno DFL 2008 o superior genera las claves AES. A veces se recomienda realizar dos restablecimientos consecutivos con un intervalo de tiempo entre ellos como medida de seguridad para la replicación.
• Servidores Linux con keytabs que solo admiten RC4. SSSD, Samba, Apache mod_auth_kerb, PostgreSQL con GSSAPI: todas son comunes y generan keytabs según los tipos de cifrado existentes en el momento de la generación. La solución consiste en volver a generar las claves para el dominio de destino tras la migración, pero para ello es necesario que la cuenta migrada disponga primero de claves AES.
• El DFL del entorno adquirido da sorpresas. Cuando la entidad adquirida era la más pequeña, o cuando las consolidaciones se realizaron en la dirección incorrecta, el DFL acaba situándose por debajo de los niveles de 2008 y nadie se da cuenta hasta el momento de la transición. Verifíquelo en la Fase 0; vuelva a verificarlo antes de cada fase de migración.
• Confianzas con atributos RC4 explícitos. Menos habitual que los demás, pero con gran repercusión cuando se da. Un fideicomiso con msDS-SupportedEncryptionTypes = 0x4 fallará el propio mecanismo de migración, no solo cuentas concretas.

Si el tiempo disponible es limitado, da prioridad a la correlación de la Fase 3 (configurada para AES pero que utiliza RC4) y al inventario de keytabs de la Fase 4. En conjunto, suelen generar entre el 60 % y el 80 % de la lista de contraseñas descifradas.

Herramientas y recursos

El trabajo de detección descrito anteriormente puede llevarse a cabo utilizando herramientas de código abierto y comandos nativos de Active Directory. A continuación se indican algunos recursos fiables para la detección y mitigación de cuentas que dependen de RC4; todos ellos son de libre acceso.

• Guía de auditoría de RC4 de Semperis: «Cómo auditar tu entorno en busca de cifrado RC4», por Guido Grillenmeier y Rich Peckham. Consultas KQL y Splunk en estado estable sobre los eventos 4768 y 4769. (El artículo complementario a esta entrada.)
• El módulo de PowerShell «RC4-ADAssessment», creado por Jan Tiedemann (BetaHydri). Correlación de configuraciones y registros de eventos entre dominios. Disponible en PowerShell Gallery en su versión 4.0.0.
• Repositorio Kerberos-Crypto de Microsoft. Scripts oficiales de PowerShell, entre los que se incluyen Get-KerbEncryptionUsage.ps1 y List-AccountKeys.ps1, del equipo de Kerberos de Windows.
• KB5073381. La guía de implementación oficial de Microsoft para CVE-2026-20833.
• Detectar y corregir el uso de RC4 en Kerberos en Microsoft Learn. La guía oficial de procedimientos para la detección de RC4 en todo el entorno.
• Serie «AD Hardening» de Jerry DeVore — Parte 4: Aplicación de AES para Kerberos. La fuente oficial de Microsoft con información detallada sobre la gestión de credenciales en las herramientas de migración.

Para las organizaciones que llevan a cabo esta evaluación como parte de un proyecto de migración en curso, Semperis Professional Services aplica esta metodología de forma habitual como fase previa a la migración. La comunidad dedicada a la migración también está trabajando activamente en estrategias que reduzcan el coste de las molestias causadas a los usuarios por el restablecimiento de contraseñas tras la migración; en una próxima publicación se abordarán estas estrategias a medida que vayan madurando.

¿Por dónde empezar esta semana?

Si tienes un proyecto de migración que se prolongará hasta julio de 2026 y aún no has comenzado con este trabajo, empieza por estos cuatro pasos:

• Ejecuta hoy la Fase 0. Se trata de un ejercicio de 30 minutos por dominio que pone de manifiesto las asimetrías entre el DFL y el estado del parche, que determinan todo lo demás.
• Comprueba que la auditoría esté activa en ambos dominios (Fase 1). Si no lo está, soluciona el problema esta semana. Cada día que falte la telemetría es un día de riesgo de fallo que no puedes detectar.
• Correr RC4-ADAssessment con -AnalyzeEventLogs en ambos ámbitos (fases 2 y 3 combinadas). La categoría de resultados «Configurado para AES pero se utiliza RC4» es la que ofrece el mayor valor.
• Programa las visitas de los responsables de las aplicaciones de la Fase 4. Este es el eslabón más débil. Empieza ya y llévalas a cabo en paralelo con el resto de tareas.

La transición a la migración y la fecha límite de cumplimiento de julio de 2026 son dos acontecimientos distintos. El trabajo de análisis que te prepara para uno te prepara también para el otro.

Empieza ahora y la matriz que crees servirá de herramienta de seguimiento para ambos.

¿Tienes alguna pregunta sobre esta metodología o sobre cómo Semperis puede ayudarte con un proyecto de migración en curso? Ponte en contacto con nosotros: estamos aquí para ayudarte.