Problema

En entornos con controladores de dominio Windows Server 2022 o superiores, Microsoft está eliminando RC4 como algoritmo de cifrado para Kerberos. La directiva RC4DefaultDisablementPhase = 2 indica que el controlador ya no debe generar claves de sesión RC4, pero en la práctica se siguen observando eventos 4769 donde el Ticket Encryption Type es AES (0x12) y el Session Encryption Type es RC4 (0x17).

Este comportamiento se produce típicamente cuando un equipo (a menudo un appliance o un servidor Linux con Kerberos cliente) solicita un ticket TGT (krbtgt) y, pese a que la cuenta de equipo está configurada para AES‑128/256 únicamente (msDS-SupportedEncryptionTypes = 0x18), el controlador devuelve una clave de sesión RC4. El síntoma más visible son los eventos 4769 con “Session Encryption Type = 0x17” y la imposibilidad de pasar a una fase de pruebas sin RC4 sin que el cliente falle.

El problema no es exclusivo de un appliance concreto; cualquier cliente que todavía anuncie RC4 en su lista de etypes puede desencadenar este escenario, lo que complica la validación de la desactivación de RC4 antes de que Microsoft haga cumplir la política de forma obligatoria.

Causa

1. Cliente que sigue anunciando RC4

Kerberos negocia el algoritmo de cifrado basado en la intersección entre los etypes soportados por el cliente y los permitidos por la cuenta del servicio. Si el cliente incluye RC4 (0x17) en su lista, el KDC puede elegir RC4 para la clave de sesión aunque el ticket en sí se cifre con AES. Los clientes Windows modernos dejan de anunciar RC4 a partir de la actualización de hardening, pero muchos appliances, contenedores o versiones de krb5.conf heredadas siguen listándolo.

2. Configuración de msDS-SupportedEncryptionTypes incompleta

El atributo msDS-SupportedEncryptionTypes controla los algoritmos que el KDC permite para tickets y claves de sesión. Un valor de 0x18 (AES128 + AES256) debería bloquear RC4, pero si la cuenta de equipo tiene también la bandera DONT_REQUIRE_PREAUTH o está marcada como trusted for delegation, el KDC puede ignorar la restricción y usar RC4 para la sesión.

3. Políticas de dominio que sobrescriben la cuenta

Los objetos de política de dominio (GPO) pueden contener la opción “Network security: Configure encryption types allowed for Kerberos”. Cuando esa política está establecida en “RC4, AES128, AES256”, el KDC prioriza la lista de la política sobre la del objeto de cuenta, generando la mezcla ticket‑AES / sesión‑RC4.

4. Falta de actualización del KDC a la fase 2 completa

Aunque RC4DefaultDisablementPhase = 2 está configurado, el controlador necesita reinicio o una actualización de esquema para aplicar la regla de forma definitiva. En entornos de prueba aislados, es fácil pasar por alto que el DC aún está en “fase 1” y sigue aceptando RC4 para sesiones.

Solución

Paso 1 – Verificar los etypes anunciados por el cliente

En Linux o appliances con krb5.conf, inspecciona la sección [libdefaults] y busca default_tkt_enctypes y default_tgs_enctypes. Elimina cualquier referencia a rc4-hmac o rc4-hmac-n.

grep -E 'default_(tkt|tgs)_enctypes' /etc/krb5.conf

Ejemplo de corrección:

[libdefaults]
    default_tkt_enctypes = aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96
    default_tgs_enctypes = aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96

Reinicia el servicio Kerberos (o el daemon del appliance) para que tome la nueva configuración.

Paso 2 – Auditar y corregir msDS-SupportedEncryptionTypes

Usa PowerShell para listar todas las cuentas de equipo y confirmar que el atributo está en 0x18.

Get-ADComputer -Filter * -Properties msDS-SupportedEncryptionTypes |
    Where-Object { $_.'msDS-SupportedEncryptionTypes' -ne 24 } |
    Select-Object Name, msDS-SupportedEncryptionTypes

Para forzar el valor correcto:

Get-ADComputer -Identity "KAP-NUTA1$" |
    Set-ADComputer -Replace @{msDS-SupportedEncryptionTypes=24}

Paso 3 – Revisar la política de dominio

En la GPO que controla la encriptación Kerberos (Computer Configuration → Policies → Windows Settings → Security Settings → Account Policies → Network security: Configure encryption types allowed for Kerberos), asegúrate de que la opción esté establecida en “AES256, AES128” exclusivamente.

Get-GPResultantSetOfPolicy -ReportType Html -Path C:\temp\rsop.html
# Busca la sección “Encryption types allowed for Kerberos”

Si la política incluye RC4, edítala y actualiza los controladores con gpupdate /force.

Paso 4 – Confirmar la fase de desactivación en el DC

Comprueba que RC4DefaultDisablementPhase está en 2 y que el controlador ha sido reiniciado después del cambio.

Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters" -Name RC4DefaultDisablementPhase

Si el valor es 2 pero el DC no se ha reiniciado, hazlo. En entornos de prueba, un simple Restart-Computer es suficiente.

Paso 5 – Validar con eventos 4768/4769

Después de aplicar los cambios, genera una nueva solicitud TGT y revisa los eventos. El Ticket Encryption Type debe ser AES (0x12 o 0x13) y el Session Encryption Type también debe ser AES (0x12 o 0x13). No debe aparecer 0x17.

Cuándo aplicar esta solución

  • Síntomas: eventos 4769 con “Session Encryption Type = 0x17” mientras el ticket está cifrado con AES; fallos de autenticación en appliances que reportan “KDC_ERR_ETYPE_NOT_SUPPORTED”.
  • Entorno: dominios Windows Server 2022+ con RC4DefaultDisablementPhase = 2 o pruebas de hardening para CVE‑2026‑20833.
  • No aplica: entornos donde se mantiene intencionalmente RC4 por compatibilidad con aplicaciones legadas que no pueden ser actualizadas (en ese caso, se debe documentar una excepción y plan de migración).

Código

# Paso rápido: eliminar RC4 del cliente Kerberos en Linux
sed -i '/rc4-hmac/d' /etc/krb5.conf
systemctl restart sssd   # o el daemon Kerberos que corresponda

Verificación

  1. Generar un TGT nuevo 
    kinit -V -k -t /etc/krb5.keytab host/$(hostname)@TU.DOMINIO.COM
  2. Revisar los eventos del DC (Visor de eventos → Seguridad → 4768/4769).
    • Ticket Encryption Type debe ser 0x12 (AES256) o 0x13 (AES128).
    • Session Encryption Type debe coincidir (0x12 o 0x13).
  3. Comprobar la lista de etypes del ticket con klist -e.
    La salida debe mostrar solo aes256-cts-hmac-sha1-96 y aes128-cts-hmac-sha1-96.

Si los dos últimos pasos confirman que no aparece RC4, la desactivación está completa.

Notas adicionales

  • Algunos appliances utilizan librerías Kerberos propias (por ejemplo, OpenSSL‑based) que ignoran krb5.conf. En esos casos, revisa la documentación del vendor para desactivar RC4.
  • La combinación “ticket AES / sesión RC4” es una señal clara de que el cliente sigue anunciando RC4; el KDC nunca elige RC4 para la clave de sesión si el cliente no la propone.
  • Cuando se migra a Windows Server 2025, la política RC4DefaultDisablementPhase pasa automáticamente a 2 y la advertencia desaparece, pero sigue siendo buena práctica validar la lista de etypes del cliente.
  • Mantén una copia de la configuración original de krb5.conf y de la GPO antes de modificar, para poder revertir rápidamente en caso de interrupciones.