Cuando intentas conectarte por Escritorio Remoto (RDP) entre un equipo con Windows 10 22H2 y otro con Windows 11 24H2 puede aparecer el mensaje “An authentication error has occurred. The function requested is not supported. Remote computer: … CredSSP Encryption Oracle Remediation”. Provoca que la sesión se bloquee antes de mostrar siquiera la credencial de inicio. A continuación encontrarás un compendio exhaustivo del problema y todas las soluciones disponibles, desde las más inmediatas hasta las más seguras a largo plazo.
Entendiendo el error CredSSP
CredSSP (Credential Security Support Provider) es el componente que permite que el cliente RDP delegue las credenciales de inicio de sesión al host remoto de forma cifrada. Microsoft reforzó su seguridad a partir de la actualización de marzo de 2018 (CVE‑2018‑0886). Cuando un equipo está actualizado y el otro no, o bien sus directivas se han endurecido, la negociación de cifrado falla y aparece el error.
Causas habituales
- Parcheo asimétrico: un equipo tiene el parche CredSSP y el otro no.
- Directiva Encryption Oracle Remediation: en gpedit.msc → Configuración del equipo → Plantillas administrativas → Sistema → Delegación de credenciales puede imponerse un nivel que el otro extremo no cumple.
- NLA (Network Level Authentication): el host exige autenticación a nivel de red antes de establecer el canal RDP. Si el cliente no puede negociar CredSSP seguro, la sesión se aborta.
Solución rápida: deshabilitar NLA temporalmente
En el foro original, el usuario desmarcó “Permitir conexiones solo desde equipos que ejecutan Escritorio remoto con Autenticación a nivel de red (recomendado)”. Ruta:
- Ejecuta
sysdm.cpl
. - Pestaña “Acceso remoto”.
- En Escritorio remoto, desmarca la casilla mencionada y aplica.
Ventajas: elimina el problema de inmediato y permite seguir trabajando. Desventaja clave: sin NLA el canal RDP se abre antes de autenticar, lo que facilita ataques de fuerza bruta y consume más recursos del host.
Soluciones permanentes y recomendadas
1. Actualizar ambos sistemas operativos
Instalar todas las actualizaciones acumulativas corrige el desfase de protocolo y te devuelve la compatibilidad manteniendo NLA habilitado. Comprueba que los parches mensuales de seguridad estén instalados en Windows Update o en Settings → Windows Update → Check for updates.
2. Ajustar la directiva “Encryption Oracle Remediation”
Si necesitas compatibilidad con equipos antiguos, modifica la GPO en ambos extremos a un nivel coherente:
Nivel | Descripción | Seguridad | Compatibilidad |
---|---|---|---|
Force Updated Clients | Solo permite clientes totalmente parcheados | Alta | Baja |
Mitigated | Permite clientes parcheados y cae a modo de compatibilidad si falla la negociación | Media | Media |
Vulnerable | Permite cualquier cliente, incluso sin parche | Baja | Alta |
Pasos: abre gpedit.msc
→ navega a la ruta indicada → habilita la directiva → selecciona el nivel deseado → gpupdate /force.
3. Cambiar el registro si no tienes edición Pro
En ediciones Home sin Editor de directivas:
reg add HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\CredSSP\Parameters /v AllowEncryptionOracle /t REG_DWORD /d 2 /f
Valores: 2 (Vulnerable)
, 1 (Mitigated)
, 0 (Force Updated Clients)
. Reinicia para aplicar.
4. Reforzar TLS y protocolos RDP
- En gpedit.msc → Configuración del equipo → Plantillas administrativas → Componentes de Windows → Servicios de escritorio remoto → Seguridad fuerza la capa de cifrado a SSL (TLS 1.2).
- Deshabilita RC4 y 3DES en
gpedit.msc → Configuración del equipo → Configuración de Windows → Configuración de seguridad → Directivas locales → Opciones de seguridad → Cifrado del sistema
. - Usa certificados actualizados con SHA‑256.
Comparativa de métodos
Método | Facilidad | Seguridad | Cuándo usarlo |
---|---|---|---|
Deshabilitar NLA | Inmediato | Baja | Prueba rápida o entorno aislado |
Parchear SO | Automático vía Windows Update | Alta | Escenario corporativo o doméstico normal |
Modificar GPO | Media | Variable | Compatibilidad con equipos legados |
Editar registro | Avanzado | Variable | Windows Home o scripting masivo |
Procedimiento paso a paso recomendado
- Verifica versiones: en ambos equipos ejecuta
winver
y anota compilaciones. - Instala actualizaciones: si algún equipo está desfasado, aplica parches y reinicia.
- Comprueba NLA: deja marcada la casilla solo si ambos sistemas están al día.
- Revisa la directiva CredSSP:
- Si ambos equipos son Windows 10/11 actualizados, selecciona Force Updated Clients.
- Si debes conectar con Windows 7 o Server 2008, usa Mitigated mientras planificas la migración.
- Prueba conexión RDP: si la autenticación fluye, restablece NLA para cerrar la brecha temporal.
- Añade reglas de firewall (3389/TCP) solo para redes privadas.
- Monitoriza: revisa el Visor de eventos (Aplicación → Microsoft‑Windows‑RemoteDesktopServices‑RdpCoreTS/Operational) para detectar alertas CredSSP.
Preguntas frecuentes
¿Puedo dejar “Vulnerable” indefinidamente?
No. Ese ajuste permite ataques man‑in‑the‑middle que fuerzan downgrade de cifrado y roban credenciales. Solo úsalo como paliativo mientras actualizas.
¿Por qué la casilla de NLA viene marcada por defecto?
Porque NLA autentica antes de abrir el canal RDP, reduce el consumo de recursos y mitiga ataques de denegación de servicio y enumeración de usuarios.
¿Se puede automatizar la corrección en un dominio?
Sí. Distribuye la directiva GPO a nivel de dominio con Force Updated Clients. Asegúrate de que WSUS o Intune publiquen las actualizaciones CredSSP antes de aplicar la directiva, o todos los clientes quedarán bloqueados.
¿Qué pasa con conexiones desde macOS o Linux?
Los clientes oficiales de Microsoft RDP para macOS y para Android ya incluyen el parche, pero muchos clientes open‑source en Linux aún negocian niveles inferiores. Ajusta Mitigated y comprueba registros para evitar degradar a Vulnerable.
Buenas prácticas generales
- Mantén Windows Update habilitado y supervisa fallos de instalación.
- Exige NLA + TLS 1.2 salvo en laboratorios.
- Limita RDP a redes privadas mediante VPN o túnel SSH.
- Habilita bloqueo de cuenta después de N intentos fallidos (gpedit.msc → Configuración de Windows → Configuración de seguridad → Directivas de cuenta).
- Usa un certificado de servidor emitido por tu PKI o por Let’s Encrypt para evitar advertencias de identidad.
- Configura auditoría avanzada de inicio de sesión para detectar accesos no autorizados.
- En entornos corporativos, considera reemplazar RDP expuesto por Azure Bastion o Remote Desktop Gateway.
Conclusión
El error “CredSSP Encryption Oracle Remediation” no es realmente un “fallo” sino una medida de seguridad: indica que uno de los equipos no cumple los requisitos de cifrado. Deshabilitar NLA resuelve al instante, como descubrió el autor del hilo, pero abre grietas importantes. La solución sólida consiste en:
- Parchear ambos extremos.
- Configurar la directiva “Encryption Oracle Remediation” en un nivel seguro y coherente.
- Usar TLS 1.2 y un certificado confiable.
- Restaurar NLA una vez comprobada la compatibilidad.
Si sigues estos pasos tendrás un RDP funcional y, sobre todo, protegido frente a ataques de suplantación y robo de credenciales.