Signer les fichiers RDP et sécuriser les fermes RDS après les mises à jour Windows d’avril 2026

Windows Server 2019Windows Server 2022Windows Server 2025

Depuis les mises à jour de sécurité publiées en avril 2026 (notamment le Patch Tuesday), Microsoft a profondément modifié le comportement du client Bureau à distance afin de renforcer la sécurité autour des connexions RDP. Désormais, l’ouverture d’un fichier .rdp déclenche systématiquement de nouveaux avertissements, avec une mise en avant des paramètres de connexion utilisés et des restrictions plus strictes, notamment sur les redirections locales.

Ce changement n’est pas anodin : les fichiers RDP sont devenus une cible fréquente dans les campagnes de phishing, car ils peuvent contenir des paramètres permettant d’accéder à des ressources locales (presse-papiers, disques, identifiants, etc.) sans que l’utilisateur en ait pleinement conscience. Microsoft a donc décidé de rendre leur utilisation plus transparente… mais aussi plus contraignante pour les administrateurs et les utilisateurs.

Concrètement, un fichier .rdp est un simple fichier de configuration utilisé par le client Bureau à distance (mstsc). Il contient toutes les informations nécessaires pour établir une connexion vers un serveur ou une ferme RDS : adresse du serveur, options d’affichage, redirections de périphériques, authentification, etc. Lorsqu’on double-clique dessus, la connexion est automatiquement préparée avec ces paramètres.

Avec les évolutions introduites en avril 2026, plusieurs impacts apparaissent immédiatement :

  • apparition de messages de sécurité supplémentaires à l’ouverture des fichiers RDP
  • affichage détaillé des paramètres avant connexion
  • désactivation par défaut de certains réglages sensibles
  • nécessité de signer les fichiers RDP pour éviter les alertes et garantir leur intégrité

Dans ce tutoriel, nous allons voir comment s’adapter à ces changements en mettant en place une signature des fichiers .rdp, mais aussi en configurant correctement votre environnement RDS afin de supprimer les avertissements tout en conservant un niveau de sécurité conforme aux nouvelles exigences de Windows.

Signature dans le cas d’une ferme RDS

C’est le cas, si vous avez configurer correctement les certificats de la ferme RDS sur la Broker, l’environnement est configuré pour signer les fichiers RDP, il faut juste configurer la stratégie de groupe avec l’empreinte du certificat (SHA) qui est configuré.

Depuis le serveur Broker, dans la vue d’ensemble du déploiement, cliquer sur TACHES puis sur Modifier les propriétés de déploiement.

Sur la fenêtre de propriété de déploiement, aller sur Certificats pour identifier celui qui est configurer pour : Service Broker pour les connexions Bureau à distance – Publication, une fois sélectionner, vous pouvez voir en dessous de la liste le certificat utilisé.

En cliquant sur Afficher les détails, vous pourrez copier le Empreinte numérique du certificat.

Pour le moment si je me connecte depuis l’interface Web, j’ai le message d’avertissement, on peut voir l’éditeur qui est correspond au certificat qui a signé le fichier.

Signer un fichier .rdp

Le second cas que nous allons traiter concerne les fichiers .rdp que vous pouvez fournir à vos utilisateurs, que ce soit pour des accès internes à votre infrastructure ou pour des connexions vers des services externes. Avec les nouvelles exigences introduites par les mises à jour d’avril 2026, l’ouverture de ces fichiers déclenche désormais un avertissement de sécurité plus strict, pouvant perturber l’expérience utilisateur et générer des incompréhensions.

Pour éviter l’apparition de ce message, il est nécessaire de signer les fichiers RDP afin de garantir leur intégrité et leur provenance. Si vous avez déjà mis en place la signature de scripts PowerShell, le principe est assez similaire : on utilise un certificat pour attester que le fichier n’a pas été modifié et qu’il provient d’une source de confiance.

Dans le cas des fichiers RDP, Microsoft fournit un outil dédié nommé rdpsign.exe, spécialement conçu pour appliquer cette signature. C’est cet outil que nous allons utiliser dans la suite de ce tutoriel pour sécuriser vos fichiers et supprimer les avertissements côté utilisateur.

Pour signer un fichier .rdp, vous avez besoin d’avoir un certificat de signature de code.

On ouvre maintenant une fenêtre PowerShell et on commence par récupérer l’empreinte du certificat (Thumbprint) de votre certificat.

Get-ChildItem -Path Cert:\CurrentUser\My | Format-List

Dans la liste de certificat qui s’affiche, copier la valeur du champ Thumbprint du certificat correspondant.

Signer la fichier RDP avec rdpsign.exe :

rdpsign.exe /sha256 <Thumbprint> C:\Path\rdp-file.rdp

La commande retour simplement : Tous les fichiers rdp ont été signés.

Si vous êtes curieux, ouvrez le fichier .rdp avec la bloc note, à la fin de celui-ci, vous pourrez voir la signature.

Une fois le fichier .rdp signé, il ne doit plus être modifié. En effet, la signature repose sur l’intégrité du contenu : la moindre modification (même minime, comme un changement de paramètre ou une ligne ajoutée) invalide la signature. Le fichier sera alors de nouveau considéré comme non fiable par le client Bureau à distance, et les avertissements de sécurité réapparaîtront.

Il est donc important de finaliser entièrement la configuration du fichier .rdp avant de procéder à sa signature, puis de le distribuer tel quel aux utilisateurs sans y apporter de modification par la suite.

Comme pour une ferme RDS, lorsque vous exécutez un fichier .rdp signé, le client Bureau à distance affiche les informations relatives à l’éditeur du fichier. Cela permet à l’utilisateur de vérifier rapidement l’origine de la connexion et de s’assurer qu’elle provient d’une source de confiance.

Dans le cas d’une autorité de certification interne, c’est généralement le nom du compte utilisateur associé au certificat qui est affiché. Même si l’utilisation de comptes génériques n’est pas toujours recommandée d’un point de vue sécurité, il peut être pertinent ici de créer un compte dédié à la signature, avec un nom explicite et rassurant pour les utilisateurs, par exemple DSI Entreprise Name.

L’objectif est double :

  • apporter de la cohérence dans l’affichage côté utilisateur
  • renforcer la confiance en identifiant clairement l’origine des fichiers RDP distribués

Cela évite d’exposer des comptes techniques ou personnels tout en conservant une bonne lisibilité dans les messages de sécurité.

Configurer les empreintes de confiance RDP via une stratégie de groupe

La dernière étape pour ne plus avoir de message d’avertissement consiste à configurer les empreintes de confiance à l’aide d’une GPO. Cette configuration permet d’indiquer explicitement aux postes clients quels certificats sont considérés comme fiables pour les connexions Bureau à distance, évitant ainsi l’affichage des alertes de sécurité lors de l’ouverture des fichiers .rdp ou de la connexion à une ferme RDS.

En définissant ces empreintes dans une stratégie de groupe, vous centralisez la gestion de la confiance et assurez une expérience utilisateur fluide, sans compromettre le niveau de sécurité imposé par les nouvelles mises à jour Windows.

Je ne vais pas reprendre ici tout le processus de création d’une stratégie de groupe. En fonction de votre environnement, vous pouvez soit créer une nouvelle GPO, soit configurer ce paramètre dans une stratégie existante si cela est cohérent avec votre organisation.

La configuration se fait au niveau ordinateur, ce qui permet d’appliquer ce paramétrage de manière globale sur les postes concernés.

Depuis l’éditeur de gestion des stratégies de groupe, aller à l’emplacement suivant : Configuration ordinateur / Stratégies / Modèles d’administration / Composants Windows / Services Bureau à distance / Client Connexion Bureau à distance et ouvrir le paramètre : Spécifier les empreintes numériques SHA1 des certificats représentant des éditeurs .rdp approuvés 1.

Activer le paramètre 1 et indiquer le ou les empreintes numérique SHA1 des certificats 2, si vous indiquez plusieurs, il faut les séparer par une virgule, puis cliquer sur OK 3 pour enregistrer la configuration.

Une fois la stratégie appliquée sur les ordinateurs, les utilisateurs ne devraient plus avoir de message d’avertissement.

Aller plus loin dans la sécurisation des fichiers .rdp

Il est possible de durcir encore le comportement des fichiers .rdp sur Windows en modifiant les paramètres suivants :

  • Autoriser les fichiers .rdp issus d’éditeur inconnu : Ce paramètre de stratégie permet de spécifier si les utilisateurs peuvent exécuter les fichiers .rdp (Remote Desktop Protocol) non signés ou issus d’éditeurs inconnus sur l’ordinateur client.
  • Autoriser les fichiers .rdp issus d’éditeurs valides et les paramètres .rdp par défaut de l’utilisateur : Ce paramètre de stratégie permet de spécifier si les utilisateurs peuvent exécuter un fichier .rdp (Remote Desktop Protocol) issu d’un éditeur qui l’a signé avec un certificat valide. Un certificat valide est un certificat délivré par une autorité reconnue par le client, telle que l’un des émetteurs appartenant au magasin de certificats des autorités de certification racines de confiance tierces du client. Ce paramètre de stratégie détermine également si l’utilisateur peut démarrer une session RDP à l’aide des paramètres .rdp par défaut (par exemple lorsqu’un utilisateur ouvre directement le client Connexion Bureau à distance sans spécifier de fichier .rdp).

Si votre environnement le permet, je vous recommande d’activer ces deux paramètres. Cela vous permet de mieux contrôler le comportement des utilisateurs face aux connexions Bureau à distance, tout en réduisant les risques liés à l’utilisation de fichiers .rdp non approuvés ou modifiés et des connexions depuis le client mstsc.exe.

Conclusion

Les évolutions introduites par Windows en avril 2026 marquent un renforcement clair de la sécurité autour du Bureau à distance et des infrastructures RDS. Entre la signature obligatoire des fichiers .rdp, les nouveaux avertissements côté client et la nécessité de déclarer des empreintes de confiance via GPO, l’objectif est évident : mieux encadrer les connexions distantes et limiter les risques d’usurpation ou de fichiers modifiés à l’insu des utilisateurs.

En mettant en place la signature avec rdpsign.exe et en configurant correctement vos stratégies de groupe, vous retrouvez un environnement propre, maîtrisé et surtout sans alertes intempestives pour les utilisateurs finaux. Cela permet de conserver une expérience fluide tout en respectant les nouvelles exigences de sécurité de Windows.

Il existe effectivement des méthodes de contournement permettant de supprimer ou de masquer les messages d’avertissement liés aux fichiers .rdp ou aux connexions RDS. Cependant, volontairement, je ne les aborderai pas dans ce tutoriel.

Aujourd’hui, avec l’évolution des menaces cyber et la multiplication des techniques de phishing ou d’usurpation de connexion, ces avertissements jouent un rôle important dans la protection des utilisateurs. Les contourner revient souvent à réduire le niveau de sécurité global de l’environnement, ce qui n’est plus une bonne pratique dans les infrastructures modernes.

L’objectif ici est donc de rester dans une approche sécurisée et conforme aux recommandations Microsoft, en acceptant ces nouvelles contraintes et en les intégrant correctement via la signature des fichiers et la configuration des stratégies de groupe.

FAQ

Pourquoi Windows affiche-t-il désormais des avertissements sur les fichiers .rdp ?

Microsoft a renforcé la sécurité pour limiter les risques de phishing et d’exécution de fichiers RDP modifiés ou malveillants. Les fichiers sont désormais analysés plus strictement avant connexion.

Est-il obligatoire de signer tous les fichiers .rdp ?

Non, mais fortement recommandé. Sans signature, les utilisateurs verront des avertissements de sécurité lors de l’ouverture des fichiers ou de la connexion.

Peut-on modifier un fichier .rdp après signature ?

Non. Toute modification invalide la signature et réactive les alertes de sécurité côté client.

Quel est l’objectif des empreintes de confiance via GPO ?

Elles permettent de définir quels certificats sont considérés comme fiables pour les connexions Bureau à distance, afin d’éviter les avertissements inutiles.

Est-ce que cette configuration impacte les connexions RDS existantes ?

Non, elle n’empêche pas les connexions existantes, mais elle sécurise et normalise le comportement des clients RDP lors des nouvelles connexions.

Romain Drouche
Romain Drouche
Architecte Système | MCSE: Core Infrastructure
Expert en infrastructures IT avec plus de 15 ans d’expérience sur le terrain. Actuellement Chef de projet Systèmes et Réseaux et Référent SSI (Sécurité des Systèmes d’Information), je mets mon expertise au service de la fiabilité et de la sécurité des environnements technologiques.

Laisser un commentaire