Como administradores de sistemas, tarde o temprano nos encontramos con el temido mensaje al intentar conectar por Escritorio Remoto (RDP):
Error de autenticación. No se permite la función solicitada.
Puede deberse a una corrección de oráculo de cifrado CredSSP.Este error puede aparecer en servidores totalmente actualizados, en equipos nuevos o incluso después de aplicar políticas de seguridad.
En esta guía te explico de forma simple y directa qué significa este mensaje y cómo corregirlo en cuestión de minutos.
No importa si trabajas con Windows 10, 11 o Windows Server: estas soluciones funcionan para todos los escenarios.
Índice
- ¿Qué es CredSSP y por qué aparece este error?
- Configurar “Corrección de oráculo de cifrado” en el cliente
- Usar el registro del cliente (rápido y efectivo)
- Usar siempre RDP por nombre en lugar de IP
- Comprobar actualizaciones CredSSP en el servidor
- Corregir problemas comunes de Kerberos
- Pc fuera del dominio no puede conctar
- Conclusión
¿Qué es CredSSP y por qué aparece este error?
CredSSP (Credential Security Support Provider) es el mecanismo que usa RDP para transmitir credenciales de forma segura entre el cliente y el servidor.
A partir del parche de seguridad de 2018, Windows endureció CredSSP, lo que provoca:
- Los clientes modernos exigen un cierto nivel de cifrado
- Los servidores desactualizados no pueden cumplirlo
- Resultado: el cliente bloquea la conexión por seguridad
La clave:
Este error casi siempre se corrige desde el CLIENTE, no desde el servidor.
2. Configurar “Corrección de oráculo de cifrado” en el cliente (la recomendada)
Si el equipo está en dominio con plantillas ADMX actualizadas:
- Abre
gpedit.mscen el cliente - Ve a:
Configuración del equipo
→ Plantillas administrativas
→ Sistema
→ Delegación de credenciales
→ Corrección del oráculo de cifrado- Configura:
Estado: Habilitado
Nivel de protección: Mitigated¿Qué hace “Mitigated”?
Permite que el cliente se conecte incluso si el servidor usa un modo CredSSP menos estricto, pero manteniendo la seguridad adecuada.
Nota fundamental
Configurar esta política en el servidor NO soluciona nada.
El que decide bloquear o permitir es el cliente.
3. Usar el registro del cliente (rápido y universal)
Si la política no existe (ADMX antiguo o cliente fuera de dominio), esta solución funciona siempre.
Ejecuta en el cliente:
reg add HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System\CredSSP\Parameters /v AllowEncryptionOracle /t REG_DWORD /d 2 /fEsto equivale a habilitar “Mitigated”.
Reinicia → prueba RDP → debería funcionar.
4. Probar siempre RDP usando el NOMBRE y no la IP
Esta es una de las causas más ocultas y frecuentes.
Cuando conectas por:
mstsc → 192.168.x.x→ Kerberos NO funciona
→ RDP intenta NTLM
→ Si hay cualquier problema con NTLM o CredSSP → aparece el error
Siempre prueba así:
NOMBRE_SERVIDOR
NOMBRE_SERVIDOR.Dominio.localSi por nombre funciona pero por IP no → CredSSP no es el problema, es Kerberos.
5. Comprobar y aplicar actualizaciones CredSSP en el servidor
Aunque el error sea del cliente, el servidor también debe estar parcheado.
En el servidor:
wmic qfe | findstr KBDebe contener alguna de estas actualizaciones:
- KB4103723
- KB4103725
- O cualquier acumulativo posterior a junio 2018 (o actual)
Si faltan → instala todas las actualizaciones de Windows Update.
6. Verificar Kerberos en el servidor
Si Kerberos falla, RDP usa NTLM, y si NTLM falla → aparece el “error de CredSSP” aunque el origen sea otro.
Comprobación de canal seguro:
nltest /sc_verify:DOMINIODebe decir:
The secure channel is OKComprobación de tickets:
klistDebes ver un ticket:
krbtgt/DOMINIOComprobación de SPNs:
setspn -L NOMBRE_SERVIDORDebe existir:
TERMSRV/NOMBRE_SERVIDOR
TERMSRV/NOMBRE_SERVIDOR.Dominio.localSi faltan → Kerberos no funciona → RDP fallará.
PC Fuera del dominio no puede conctar
La opción “Requerir equipos usen autenticación a nivel de red (NLA)” obliga a que la autenticación se realice antes de establecer la sesión RDP. Para ello, Windows solo permite dos mecanismos:
- Kerberos
- CredSSP + NTLMv2
El problema es que un equipo fuera del dominio no puede usar Kerberos.
Por tanto, depende exclusivamente de NTLMv2 para autenticarse.
Si el servidor tiene cualquier restricción de seguridad aplicada (por ejemplo, endurecimiento NTLM, políticas CredSSP estrictas, configuración TLS limitada, o simplemente una GPO más restrictiva), entonces el cliente externo no puede completar la autenticación NTLM previa a la sesión, y NLA bloquea la conexión mostrando el típico error de CredSSP.
Cuando se desactiva NLA, RDP vuelve al modo clásico:
la autenticación ocurre después de abrir la sesión gráfica.
Esto permite que los equipos externos —que no pueden usar Kerberos— puedan conectarse aunque NTLM esté parcialmente limitado.
En resumen:
- ✔ Equipos del dominio → Kerberos → NLA funciona sin problemas
- ❌ Equipos fuera del dominio → dependen de NTLM → si el servidor está endurecido → NLA les bloquea
- ✔ Desactivar NLA → permite acceso RDP desde clientes externos o no unidos al dominio
Solucion rápida:
Desactiva esta opción en el servidor: esta no es la alternativa más segura, pero te funcionara.
Alternativas para NO desactivar NLA (si quieres mantener seguridad):
Si queréis mantener la seguridad activando NLA, hay que hacer una de estas cosas:
Unir el cliente al dominio
→ Se usa Kerberos → 100% compatible con NLA.
Permitir NTLM entrante en el servidor específico
(pero NO en todo el dominio)
Lsa\MSV1_0 → RestrictReceivingNTLMTraffic = 0Conclusión
El error de CredSSP no es complicado, pero puede ser confuso si no conocemos cómo funciona la autenticación en RDP.
En resumen:
- La solución casi siempre está en el CLIENTE, no en el servidor
- La política “Corrección del oráculo de cifrado” → Mitigated es la solución principal
- Conectar por nombre y no por IP evita fallos con Kerberos
- Asegúrate de que el servidor tiene las actualizaciones CredSSP
- Verifica que Kerberos está funcionando correctamente
Con estas medidas, podrás solucionar el error en cuestión de minutos y evitar que vuelva a aparecer.
