Comment résoudre le problème d’accès RDP sous Windows XP avec Windows 10 et Server 2016 RDS

Configurer Windows XP pour se connecter facilement à des serveurs de bureau à distance récents relève du casse-tête. Le client RDP de XP n’est tout simplement pas conçu pour les fonctionnalités de sécurité imposées par les systèmes d’exploitation Windows récents, notamment l’authentification au niveau du réseau (NLA).Si vous avez déjà rencontré des messages d’erreur tels que « En raison d’une erreur de sécurité, le client n’a pas pu se connecter à l’ordinateur distant » ou « L’ordinateur distant requiert une authentification au niveau du réseau, non prise en charge par votre ordinateur », ce guide est fait pour vous. L’objectif est souvent de permettre à un ancien poste XP de communiquer avec Windows Server 2016/2012 R2, voire Windows 10, sans trop compromettre la sécurité. Vous rencontrerez probablement des erreurs liées à CredSSP ou des échecs d’authentification, dus à la vulnérabilité du protocole ou à une incompatibilité de fonctionnalités.

En résumé, deux solutions principales permettent de résoudre ce problème : désactiver l’authentification authentifiée au niveau du réseau (NLA) côté serveur (ce qui n’est pas idéal en termes de sécurité, mais parfois nécessaire) ou activer la prise en charge de la NLA sous XP. La procédure se complique un peu à ce stade, mais ces étapes devraient vous permettre de vous en sortir. Attention : Microsoft n’a pas encore corrigé XP pour tous ces nouveaux protocoles ; il faudra donc souvent modifier des paramètres du registre ou désactiver des fonctionnalités essentielles. L’objectif principal est d’harmoniser le protocole de sécurité entre le client XP et le serveur.

Comment résoudre les problèmes de connexion RDP de Windows XP vers les systèmes d’exploitation Windows plus récents

Désactivation de NLA sur Windows Server 2016/2012 R2 ou Windows 10

C’est probablement la méthode la plus rapide et la plus brutale, mais elle a un coût. Désactiver l’authentification authentifiée (NLA) revient à supprimer certaines protections de sécurité, mais c’est parfois la seule solution si le client ne prend pas en charge cette technologie. Lorsque la NLA est désactivée, le serveur n’exige plus d’authentification du client avant d’établir la session, ce qui facilite la connexion des anciens clients, mais affaiblit votre système de sécurité.

  • Ouvrez le Gestionnaire de serveur. Sur un serveur, accédez à Services Bureau à distance > Collections.
  • Trouvez la collection sur laquelle vous travaillez, puis cliquez sur Tâches > Modifier les propriétés.
  • Dans l’ onglet Sécurité, recherchez « Autoriser les connexions uniquement à partir d’ordinateurs exécutant le Bureau à distance avec authentification au niveau du réseau » et décochez cette option.

Sur un poste de travail Windows 10 :

  • Accédez à Système > Paramètres à distance.
  • Décochez la case « Autoriser les connexions uniquement à partir d’ordinateurs exécutant le Bureau à distance avec l’authentification au niveau du réseau ».

Remarque : Cette action rend la connexion moins sécurisée ; il est donc déconseillé de désactiver l’authentification au niveau du réseau (NLA) indéfiniment. Sur certains ordinateurs, il peut être nécessaire de redémarrer le service Bureau à distance ou de redémarrer l’ordinateur pour que les modifications soient prises en compte. Sachez que cette action augmente les risques de sécurité potentiels.

Activer la prise en charge NLA sous Windows XP SP3 (si vous souhaitez vraiment conserver NLA)

Celui-ci est plus complexe. XP nécessite l’installation du Service Pack 3, car la prise en charge de NLA et de CredSSP a été introduite avec ce dernier. Sans cela, vous verrez des erreurs telles que « Une erreur d’authentification s’est produite, 0x80090327 ».

Tout d’abord, vérifiez que le SP3 est installé :

  • Faites un clic droit sur Poste de travail > Propriétés. Recherchez « Service Pack 3 » dans la section Informations. S’il n’y figure pas, téléchargez-le depuis le site de Microsoft et installez-le.

Une fois le SP3 installé, vous devez activer manuellement la prise en charge de CredSSP via des modifications du registre ; c’est un peu étrange, mais c’est comme ça que ça fonctionne :

  • Ouvrez l’Éditeur du Registre (regedit).
  • Accédez à HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders.
  • Trouvez la valeur SecurityProviders. Double-cliquez dessus et ajoutez-la , credssp.dllà la fin du texte existant, séparée par une virgule.
  • Allez à HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa.
  • Trouvez Security Packageset ajoutez tspkgà la liste.

Après avoir effectué ces modifications, redémarrez votre PC. Windows XP devrait désormais prendre en charge NLA et CredSSP, améliorant ainsi la compatibilité des connexions. Cependant, sachez que vous devrez toujours saisir à nouveau vos mots de passe, car les identifiants enregistrés fonctionnent rarement. C’est certes agaçant, mais c’est le prix à payer pour une meilleure compatibilité.

Correction de l’erreur de remédiation de l’oracle de chiffrement CredSSP

Cette vulnérabilité survient si votre serveur ou client possède les derniers correctifs de sécurité corrigeant la faille CVE-2018-0886. En clair, Microsoft a ajouté un correctif qui rend les anciens clients non mis à jour, notamment Windows XP, qui n’est plus mis à jour. Par conséquent, si vous rencontrez l’erreur « La fonction demandée n’est pas prise en charge » ou une erreur similaire après une mise à jour, c’est probablement dû à cette faille.

Dans les dernières mises à jour, Microsoft a introduit un paramètre de stratégie permettant de désactiver temporairement cette application. Pour résoudre ce problème, vous devez modifier le registre côté serveur :

  • Ouvrez l’Éditeur de stratégie de groupe ou l’Éditeur du Registre.
  • Accédez à Configuration ordinateur > Modèles d’administration > Système > Délégation d’informations d’identification.
  • Recherchez la stratégie « Remédiation de l’oracle de chiffrement » et définissez-la sur Atténuée.

Cela réduit la sécurité, mais permet aux anciens clients de se connecter. Vous pouvez le faire en modifiant directement le registre :

reg add "HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System" /v "AllowEncryptionOracle" /t REG_DWORD /d 2 /f

Remplacez la valeur par celle indiquée 2pour un support atténué. Attention : cela rend votre système plus vulnérable. Ne le faites qu’en cas d’absolue nécessité et après avoir bien compris les risques.

Si vous utilisez Windows XP (la version embarquée, Windows Embedded POSReady 2009), une mise à jour spécifique est disponible pour corriger la vulnérabilité CredSSP. Vous pouvez la tester sur la page de support Microsoft suivante : [page de support Microsoft](https://support.microsoft.com/en-us/help/4056564/security-update-for-vulnerabilities-in-windows-server-2008). Il est rare que Windows XP soit corrigé pour ce type de faille de sécurité, mais il est peu probable qu’une solution complète soit disponible prochainement.

En résumé, connecter un serveur XP à un serveur Windows récent via RDP est possible, mais nécessite quelques manipulations et n’est certainement pas sans risque. J’espère que cela vous sera utile et, croisons les doigts, permettra à au moins quelques vieux ordinateurs de communiquer avec le monde moderne.

Résumé

  • La désactivation de NLA sur le serveur peut faciliter la connexion des clients plus anciens, mais diminue la sécurité.
  • L’activation de la prise en charge NLA sous XP nécessite des modifications du registre et le Service Pack 3.
  • Soyez attentif aux vulnérabilités de CredSSP et ajustez vos politiques si nécessaire ; la sécurité est un compromis.
  • Des opérations comme la modification des chemins d’accès au registre, l’activation/désactivation de l’authentification NLA et la compréhension des implications en matière de sécurité sont essentielles.

Conclure

Gérer tout ça est plutôt frustrant : Microsoft semble prendre un malin plaisir à rendre obsolètes les anciens protocoles juste au moment où on en a le plus besoin. Mais en modifiant légèrement le registre, en désactivant l’authentification au niveau du réseau (NLA) ou en activant la prise en charge sous XP, il est possible de contourner le problème. Gardez simplement à l’esprit que baisser le niveau de sécurité n’est pas idéal ; pesez donc bien le pour et le contre.

J’espère que cela permettra à quelqu’un de gagner quelques heures. Bonne chance, et n’oubliez pas : le système XP est en train de couler, mais il existe des solutions pour le maintenir à flot pour le moment.