Comment mettre en place une passerelle RDP sous Windows Server 2022 ?

I. Présentation

Dans ce tutoriel, nous allons voir comment mettre en place une passerelle RDP, appelée Remote Desktop Gateway, sur Windows Server 2022.

Remote Desktop Gateway est un rôle de Windows Server qui fournit une connexion sécurisée aux serveurs Windows de votre infrastructure, par l’intermédiaire du protocole RDP, auquel s’ajoute la connexion à la passerelle sécurisée par le protocole TLS. La particularité d’une passerelle RDP, c’est que le trafic réseau transite non pas par le port 3389 par défaut, mais utilise une surcouche TLS, afin que l’intégralité des flux soit encapsulée par cette surcouche protocolaire. On peut nommer ça de cette manière aussi de cette façon : « RDP over HTTPS ». Autrement dit, les flux entre le poste client et la passerelle RDP sont chiffrés.

Généralement, on met en place une passerelle RDP afin d’accéder, depuis l’extérieur (et donc depuis Internet), à un ou plusieurs serveurs situés sur son infrastructure interne. Plutôt que d’exposer un serveur en RDP directement,  on le rend accessible via cette passerelle qui s’appuie sur une connexion HTTPS, comme je le mentionnais précédemment.

Néanmoins, même si cela peut s’avérer utile, il faut garder à l’esprit qu’il y a un toujours un risque à exposer un service publiquement. Autrement dit, gardez en tête qu’un minimum de services de votre réseau d’entreprise doit être accessible depuis Internet. La passerelle RDG peut-être publiée sur Internet par l’intermédiaire d’un reverse proxy ou d’une DMZ publique.

Si l’on met en place une passerelle RDP sur un réseau local (réseau privé), on peut en quelque sorte obfusquer le service RDP, en n’exposant pas directement ce service (cf. la capture d’écran du scan Nmap en fin d’article).

II. Environnement

Avant de passer à la pratique, voici une présentation de l’environnement que je vais utiliser dans le cadre de cette démo.

• Une machine sous Windows Server 2022 qui va devenir ma passerelle RDG, dans mon cas cette machine est un contrôleur de domaine, mais cela peut très bien être un autre serveur faisant partie du domaine.
  • Rôles installés avant de procéder à l’installation de la RDG : ADDS/DNS)
  • DNS : dc.lgds.local – IP : 192.168.130.100/24
• Une machine Windows 10 21H2 et aussi avec Windows 11. Dans le cadre du tutoriel : nom de mon domaine est LGDS.LOCAL. Dans mon cas, les machines seront intégrées dans le domaine mais ce n’est pas une obligation car on autorisera des utilisateurs.

Le serveur Windows Server 2022 va héberger le rôle de Remote Desktop Gateway, mais également un serveur IIS nécessaire au bon fonctionnement de ce rôle.

Dans le cadre de ce tutoriel, je vais utiliser un certificat auto-signé pour la connexion à ma passerelle « Bureau à distance » (RDG). Néanmoins, il est tout à fait possible d’utiliser un certificat généré à partir d’une autorité de certification d’entreprise, telle que ADCS. Il est également possible d’acheter un certificat SSL sur Internet si vous envisagez d’utiliser un nom de domaine public (par exemple : domaine.fr). Ces deux dernières options sont d’ailleurs recommandées.

III. Installation du rôle

Même si vous pouvez automatiser l’installation du rôle avec PowerShell, je vous propose de suivre l’installation du rôle pas à pas à partir de l’interface graphique. En effet, je trouve que cela est plus pédagogique que de « balancer du code » dans une console, sans chercher à comprendre ce qu’il fait réellement. C’est parti !

Depuis, le Server Manager, ouvrez l’assistant d’ajout de rôles et fonctionnalités. Passez les différentes étapes, jusqu’au le choix des rôles, afin d’ajouter le rôle « Remote Desktop Services ».

À l’étape suivante, sélectionnez le service « Remote Desktop Gateway » que nous souhaitons installer aujourd’hui.

Comme le trafic RDP va être encapsulé via HTTPS (TLS), vous devez obligatoirement installer un serveur IIS. Ce service fera donc office de portail de connexion « fictif » avant de pouvoir atteindre votre machine via RDP. Il va agir comme un relai entre votre PC et le serveur distant sur lequel vous souhaitez établir une connexion « Bureau à distance« .

Note : Dans le cadre de ce tutoriel, nous n’accéderons à aucun moment au service web IIS.

Cliquez ensuite sur l’option « Restart the destination server automatically if required » afin de redémarrer le serveur à la fin de l’installation du rôle.

Une fois que le rôle s’est bien installé, et que votre serveur a appliqué les changements requis à la suite de son redémarrage automatique, ouvrez la console : Remote Gateway Manager

Nous devons configurer les règles de bases de notre RD Gateway. Pour cela nous allons créer une nouvelle « Politique » en sélectionnant le mode  « Wizard ».

Il s’agit d’un mode pas-à-pas qui se décompose en plusieurs étapes :

• Authorization Policies (type de politique à choisir : cf l’image ci-dessous)
• Connection Authorization Policy
• Ressource Authorization Policy

Donnez un petit nom à cette « Politique d’autorisation de connexion » :

Puis sélectionnez un groupe d’utilisateurs que vous allez autoriser explicitement à accéder à la passerelle de bureau à distance. Évitez d’ajouter « tous les utilisateurs » (Groupe Users), mais choisissez un groupe de sécurité restreint qui contient les utilisateurs qui doivent pouvoir utiliser ce service. Dans cet exemple, j’utilise le groupe des administrateurs du domaine (« Domain Admins » dans mon cas) mais en production, c’est totalement déconseillé.

La deuxième zone nommée « Client computer group membership » vous permet d’ajouter un groupe d’ordinateurs. Dans mon cas, je ne vais pas ajouter de groupe d’ordinateurs, car la passerelle RDP va me servir simplement pour accéder à mon ADDS à savoir le même serveur qui héberge ma passerelle RDP (il s’agit d’un lab pour des tests).

Les deux prochaines fenêtres vous permettront de pouvoir gérer :

• La portée du presse-papier (copier/coller)
• Le nombre maximum de minutes d’inactivités autorisées pour la connexion RDP (timeout)

Ajustez cela en fonction de votre configuration.

Puis, donnez un nom à Politique d’autorisation des ressources.

Choisissez-le ou les groupes d‘utilisateurs que vous avez renseignés plus haut (dans mon cas : Domain Admins). En production, n’utilisez pas le groupe « Domain Admins » mais plutôt un groupe de sécurité spécifique permettant de contrôler l’accès à la passerelle RDG.

Comme je n’ai pas choisi d’ajouter un groupe d’ordinateurs, choisissez la dernière option « Allow users to connect to any network resource (computer)« .

Modifiez ou non le port par défaut, tout en sachant que par défaut le protocole RDP fonctionne sur le port 3389/TCP (port obfusqué, non visible par défaut depuis l’extérieur à moins d’utiliser la connexion au travers de notre passerelle RDG). En cochant « Allow connections only to port 3389« , on autorise seulement la connexion à des ressources via le port 3389.

Enfin, cliquez sur « Finish » :

Suite à cette action, cliquez sur le nom de votre serveur en haut à gauche puis :

• Clic-droit Properties > SSL Certificate > Create a self-signed certificate
  • Puis, choisissez-lui un nom et un emplacement pour stocker celui-ci.

Dans mon cas, le certificat sera stocké ici : C:\Users\Administrator\Documents\dc.lgds.local

Une fois que cela est fait, cliquez sur Apply et OK.

Ensuite, rendez-vous dans la console de gestion des services afin de rechercher le service nommé « Remote Desktop Gateway ». À partir des propriétés, modifiez le type de démarrage de ce service pour le passer de « Automatic (Delayed) » à « Automatic« .

Note : Cela vous évitera d’attendre parfois de longues minutes après le redémarrage de votre serveur que le service passerelle RDP démarre.

Vérifier bien que le service Remote Desktop Gateway est toujours actif suite à vos modifications. Si ce n’est pas le cas, démarrez-le manuellement avec la fenêtre ci-dessus. Voici le statut que doit avoir votre service Remote Desktop Gateway après les actions précédentes.

Note importante : il se peut qu’en fonction de votre configuration, vous soyez obligé d’ouvrir le port 443, sur votre routeur/firewall.

Pour rappel, même si le service RDG obfusque RDP et que cela réduit votre surface d’attaque, le fait d’exposer de manière indirecte (le trafic transite uniquement par HTTPS/443), un service RDP sur internet constitue toujours une porte d’entrée très intéressante pour un attaquant.

Ci-dessous, après un petit scan de mon serveur Windows, vous pouvez constater que le port 443 est seulement accessible. Le port 3389 quant à lui n’est pas ouvert même si sur le serveur en lui-même le service RDP fonctionne par l’intermédiaire de ce port.

Le firewall de mon serveur Windows Server 2022 est bien entendu actif.

IV. Connexion à la passerelle depuis un client Windows

Le certificat que nous avons généré précédemment doit être importé sur le poste client puisqu’il s’agit d’un certificat autosigné. Je vous laisse choisir la méthode d’import en fonction de votre environnement.

Double-cliquez sur le certificat, puis suivez les étapes surlignées en jaune en partant de la gauche. Après avoir sélectionné le « magasin de certificat », cliquer sur suivant puis terminer.

Cliquez sur OK et confirmez bien l’importation du certificat en ignorant de message d’avertissement.

Afin d’établir une connexion « Bureau à distance », nous devons ouvrir l’outil « Connexion Bureau à distance » intégré à Windows, même si l’on pourrait utiliser un utilitaire de gestion de connexions RDP. Une fois que l’outil est ouvert, cliquez sur l’onglet « Avancé » puis sur « Paramètres…« .

Renseignez le nom d’hôte de votre passerelle, dans mon cas dc.lgds.local, puis :

• décochez la case « Ignorer le serveur de passerelle Bureau à distance pour les adresses locales.« 
• cocher la case « Utiliser mes informations d’identification de passerelle bureau à distance pour l’ordinateur distant »
  • Dans mon cas : Administrator (Compte faisant partie du groupe autorisé lors de la configuration de la passerelle RDP)

Retournez dans l’onglet Général et renseignez le nom/ip du serveur que vous souhaitez atteindre en RDP et cliquez sur connexion :

Entrez vos informations d’identification.

Une erreur de certificat s’affiche, ce qui est normal donc cliquez sur « Oui » pour établir la connexion.

Voilà, on peut voir qu’à partir de mon PC, j’accède bien à mon serveur distant au travers d’une connexion RDP qui passe par ma passerelle « RDG ».

Vous pouvez effectuer la même démarche à partir d’un poste client qui tourne sur Windows 11. Aucune étape ne varie entre Windows 10 et Windows 11, à l’exception de la surcouche graphique de Windows 11 que je trouve plutôt sympathique :

V. Tests complémentaires

Pour vérifier si la passerelle autorise bel et bien uniquement les utilisateurs du groupe LGDS\Domain Admins, essayez de renseigner un autre compte ne faisant pas partie du groupe « Domain Admins » (ou du groupe que vous avez explicitement autorisé lors de la configuration).

Après quelques secondes, vous vous faites éjecter de la passerelle, car votre compte n’est pas reconnu comme un compte « autorisé ».

A. Certificat invalide (non signé par une autorité de confiance)

Si vous obtenez l’erreur « Cet ordinateur ne peut pas vérifier l’identité de la passerelle Bureau à distance…« , c’est que vous êtes allez trop vite et que vous n’avez pas importé le certificat correctement sur votre poste client. « Try Again » 🙂

Essayez de l’importer de nouveau puis relancez la connexion !