Vous tentez d’ouvrir une session Bureau à distance RDP depuis un portable Windows 10 22H2 vers une station Windows 11 24H2 et vous tombez systématiquement sur le message : « An authentication error has occurred (CredSSP encryption oracle remediation) ». Cet article détaille l’origine de l’erreur, la méthode rapide pour la résoudre (désactivation temporaire de NLA), puis les bonnes pratiques pour éliminer le problème sans sacrifier la sécurité du poste.
Comprendre l’erreur « CredSSP / Encryption Oracle Remediation »
Depuis la mise à disposition du correctif CVE‑2018‑0886 (mars 2018), Windows vérifie que le CredSSP du client et celui du serveur parlent le même « dialecte » cryptographique. Si leurs niveaux de correctifs ou leurs stratégies diffèrent, l’authentification s’interrompt avant même le début de la session RDP ; le client affiche alors l’avertissement « Encryption Oracle Remediation ».
Dans la plupart des cas, deux paramètres entrent en conflit :
- Le niveau de correctif mensuel installé (Windows Update).
- La stratégie de groupe
Encryption Oracle Remediation(ou sa clé registre équivalente).
Pourquoi la désactivation de NLA débloque (presque) toujours la situation
Le composant incriminé est NLA (Network Level Authentication), qui requiert une autorisation Kerberos/NTLM préalable à la création de la session Bureau à distance. NLA s’appuie sur CredSSP ; le moindre décalage de version entraîne l’erreur. Lorsque vous décochez l’option « Autoriser les connexions uniquement à partir des ordinateurs exécutant le Bureau à distance avec authentification au niveau réseau », vous retirez CredSSP de l’équation : l’authentification se produit alors après l’établissement du tunnel RDP. D’un point de vue dépannage, c’est immédiat ; d’un point de vue sécurité, c’est plus discutable (voir plus loin).
Étapes pas‑à‑pas : résolution express
- Sur le clientet sur le serveur :
- Appuyez sur Win + R, tapez
sysdm.cplpuis Entrée. - Allez dans l’onglet Accès distant.
- Dans la zone Bureau à distance, décocher la case :
« Autoriser les connexions uniquement à partir des ordinateurs… (NLA) ». - Validez par OK.
- Appuyez sur Win + R, tapez
- Fermez/Rouvrez votre client RDP : la session doit s’établir sans erreur.
Important : cette méthode élimine toute protection NLA. Une machine malveillante située sur le même réseau pourrait se connecter et lancer des attaques par force brute. Ne laissez ce réglage actif que sur un réseau domestique ou isolé, le temps de corriger la cause racine.
Tableau de synthèse
| Aspect | Détail |
|---|---|
| Origine de l’erreur | CredSSP refuse les échanges si client & serveur ne partagent pas le même niveau de correctif ou la même stratégie Encryption Oracle Remediation. |
| Impact sécurité | Sans NLA, l’authentification RDP intervient « après » la création du canal. Une IP interne/un attaquant local peut tester plusieurs comptes. |
| Alternative plus sûre | Laisser NLA activé et : • installer les mises à jour cumulatives récentes ; • définir Force Updated Clients côté client, Mitigated côté serveur ; • redémarrer chaque machine. |
| Équivalent registre | HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\CredSSP\Parameters\AllowEncryptionOracle0 = Force Updated Clients 1 = Mitigated 2 = Vulnerable |
| Rétablissement | Une fois les deux systèmes patchés et harmonisés, recocher Exiger NLA pour revenir à un niveau de sécurité recommandé. |
Comment régler proprement la stratégie « Encryption Oracle Remediation »
Pour éviter de désactiver NLA, synchronisez les versions de CredSSP, puis forcez le mode adéquat :
- Installez les mises à jour cumulatives
• Lancez Paramètres > Windows Update, recherchez les mises à jour.
• Redémarrez. - Configurez la stratégie de groupe
Ouvrezgpedit.mscet rendez‑vous dans :
Configuration ordinateur ▸ Stratégies ▸ Modèles d’administration ▸ Système ▸ Délégation d’informations d’identification ▸ Encryption Oracle Remediation.- Sur le client : Activé / Force Updated Clients
- Sur le serveur : Activé / Mitigated
gpupdate /force, puis redémarrez.
Pas de GPO ? Passez par le registre
Pour les éditions Windows Home ou les machines non jointes à un domaine :
REG ADD "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\CredSSP\Parameters" ^
/v AllowEncryptionOracle /t REG_DWORD /d 0 /f :: Force Updated Clients (Client)
REG ADD "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\CredSSP\Parameters" ^
/v AllowEncryptionOracle /t REG_DWORD /d 1 /f :: Mitigated (Serveur)
Redémarrez ensuite les deux machines.
Vérifier la cause exacte via l’Observateur d’évènements
Pour confirmer que CredSSP est bien en faute, ouvrez Event Viewer :
- Chemin : Journal des applications et des services ▸ Microsoft ▸ Windows ▸ TerminalServices‑ClientActiveXCore
- Les évènements :
ID 1026ouID 1130mentionnent explicitement CredSSP / Encryption Oracle Remediation.
Bonnes pratiques de sécurité RDP
- Limiter l’exposition réseau
Évitez d’ouvrir le port 3389/TCP sur Internet. Passez par un VPN ou par Azure Bastion/Remote Desktop Gateway. - Employer MFA
Activez l’authentification multifacteur (Azure AD, Duo, etc.) si disponible. - Renommer le compte administrateur
Réduisez les attaques par dictionnaire basique. - Configurer un verrouillage de compte
Stratégie de sécurité locale : Computer Configuration ▸ Policies ▸ Windows Settings ▸ Security Settings ▸ Account Lockout Policy. - Surveiller les journaux
Centralisez Security et TerminalService events pour détecter les tentatives d’authentification suspectes.
Cas particuliers
Station hors ligne, sans WSUS ni Internet
Sur des environnements isolés (OT, SCADA, laboratoires), il peut être difficile d’installer les cumulative updates. Conservez alors l’ancienne DLL CredSSP tampon ; fixez Force Updated Clients comme décrit, ou envisagez de migrer le flux RDP au sein d’un tunnel SSH qui fournit le chiffrement/identité.
Utilisation via un jump host
Lorsque l’accès s’effectue via un serveur rebond RD Gateway, la négociation NLA a lieu entre le client et le serveur interne ; il faut donc aligner les correctifs sur toute la chaîne (portable → RD Gateway → cible) sous peine de voir l’erreur se répercuter.
FAQ : questions fréquemment posées
Q : Puis‑je simplement passer la stratégie sur « Vulnerable » ?
Oui, cela fonctionne, mais cela revient à désactiver entièrement la vérification CredSSP, ce qui laisse la porte ouverte aux attaques “man‑in‑the‑middle”. Préférez « Mitigated » ou « Force Updated Clients » selon le poste.
Q : Le problème concerne‑t‑il aussi Windows Server 2025 ?
Toute version de Windows comportant le correctif 2018 ou ultérieur applique la vérification. Les préversions de Windows Server 2025/24H2 sont donc également concernées.
Q : Comment vérifier la version de la DLL CredSSP ?
Dans %systemroot%\system32\, faites un clic droit sur credssp.dll → Propriétés → Détails. La version 10.0.17134.x (ou supérieure) inclut le correctif. Mettez à jour tout poste affichant une version inférieure.
Procédure de rétablissement : revenir à un niveau de sécurité recommandé
- Réactivez la case « Exiger NLA » dans sysdm.cpl.
- Conservez la stratégie
Force Updated ClientsetMitigateden production. - Contrôlez régulièrement les mises à jour cumulatives, surtout après un Patch Tuesday (2ᵉ mardi du mois).
Vous disposez désormais d’un poste RDP fonctionnel et sécurisé, sans devoir renoncer à NLA.
Résumé
L’erreur « CredSSP / Encryption Oracle Remediation » apparaît lorsque le client RDP et le serveur ne partagent pas la même politique CredSSP/NLA. La solution d’urgence – décocher NLA – restaure la connexion immédiatement, mais augmente la surface d’attaque. Pour un correctif définitif, installez les mises à jour cumulatives sur les deux machines et alignez la stratégie « Encryption Oracle Remediation » (ou la valeur registre AllowEncryptionOracle). Une fois les correctifs appliqués, réactivez NLA afin de conserver le niveau de sécurité attendu sur votre infrastructure Windows 10/11.