Introduction
Aujourd’hui je vous propose de voir ensemble comment déployer le composant Microsoft appelé Remote Desktop Gateway. Ce composant ne demande pas de licence ou de coût spécifique en dehors de la licence pour Windows Server 2016. Le rôle peut être activé directement depuis le Server Manager.
Pour rappel, une Gateway RDS permet à des utilisateurs distants de se connecter à l’ensemble de votre infrastructure et de vos serveurs en RDP sans pour autant ouvrir le port 3389 pour chacun des serveurs. C’est le même principe qu’un bastion SSH pour les serveurs Linux. Notre Remote Gateway va en effet servir de relais pour nous connecter à tous les serveurs de notre réseau informatique.
Evidemment, si vous disposez d’un firewall (type Pfsense ou autre) il n’est même pas nécessaire de mettre votre serveur RD Gateway en DMZ car vous pourrez faire une règle NAT pour rediriger les 2 ports nécessaires vers notre serveur Remote Desktop Gateway. C’est le scénario que je vais réaliser ici. 😉
Je vous propose de faire ça en mode tutorial avec des captures d’écran. Comme d’habitude sur ce blog, si une capture est manquante par rapport à ce que vous voyez cela signifie que vous pouvez faire suivant ou simplement conserver les paramètres par défaut. 😉
Etape 1 : Installation du rôle
Une fois connecté en RDP sur le serveur que vous souhaitez utiliser. Ouvrez le Server Manager et ajoutez un nouveau rôle ou fonctionnalité (Add Roles and Features).
Dans mon cas, j’ai décidé de dédier une machine virtuelle de mon infrastructure pour jouer ce rôle. Vous voyez donc que ma VM s’appelle en effet AKL-RDGW. Mais vous pouvez tout à fait mutualiser le rôle de RD Gateway sur d’autres serveurs membres de votre infrastructure.
Sélectionnez le rôle Remote Desktop Services puis cliquez sur Suivant. Puis cliquez directement à gauche sur la partie Role Services sous Remote Desktop Services (ou cliquez plusieurs fois sur Suivant pour y arriver).
Choisissez uniquement le rôle Remote Desktop Gateway. Cliquez encore quelques fois sur Suivant et conservez les options par défaut pour la partie Web Server Role (IIS).
Finalement, cliquez sur Install pour déployer le rôle.
Après quelques instants, votre nouveau rôle est installé. Vous pouvez fermer la fenêtre.
Dans le menu Démarrer, vous trouverez dans les Administrative Tools une nouvelle application : RD Gateway Manager. Démarrez cette application.
Etape 2 : Prérequis avant de configurer votre RD Gateway – Nom DNS à utiliser
Avant d’aller plus loin dans la configuration de votre Remote Desktop Gateway, vous devez définir le nom DNS que vous allez utiliser pour accéder à votre Remote Desktop Gateway. Par exemple : remote.votredomaine.net. Si ce n’est pas déjà fait, vous devrez créer une nouvelle entrée de type A pour votre domaine.
Mon domaine est géré par OVH. Je redirige donc ce nom vers l’IP externe de mon serveur. Il s’agit d’une IP Fail-Over associée à mon serveur ESXi hébergé chez Online.net.
Etape 3 : Prérequis avant de configurer votre RD Gateway – Certificat SSL
Vous aurez également besoin d’un certificat SSL associé au précédent nom DNS que vous avez créé. Vous pouvez tenter d’utiliser un certificat Let’s Encrypt cela vous demandera quelques étapes de plus. Pour ce besoin, je vous encourage à consulter cet article. Pour ma part, j’utilise un certificat SSL que j’ai obtenu par le biais du site NameCheap pour un prix d’environ ~7,50 € / année.
Evidemment, je ne vais pas pouvoir tout détailler sur la génération du certificat car elle pourra être un peu différente selon que vous utilisez NameCheap ou n’importe quel autre fournisseur de certificats ou même votre PKI privée.
Toujours sur le même serveur, cherchez dans le menu Démarrer, IIS Manager et lancez l’outil. Dans la partie à gauche, positionnez-vous sur le nom de votre serveur et sélectionnez l’option Certificates au centre.
Dans la partie à droite, cliquez sur Create Certificate Request. Nous aurons besoin de ce fichier pour pouvoir générer notre certificat.
Remplissez bien l’ensemble des informations et n’oubliez pas que la ligne Common name doit correspondre au nom d’accès que vous avez prévu d’utiliser pour votre Gateway RDS. Cliquez sur Next.
Choisissez les options Microsoft RSA… et 2048. Attention, je réalise ces choix car je sais qu’ils sont compatibles avec mon certificat NameCheap. Il est possible que ces réglages nécessitent une configuration différente pour votre cas de figure.
Choisissez un emplacement pour sauvegarder votre certificate request.
Une fois que c’est bon, vous aurez simplement un fichier texte avec plein de caractères dont nous aurons besoin sur le site NameCheap pour générer notre certificat SSL. Copiez tout le contenu.
Je vais vous montrer à quoi ça ressemble de mon côté sur NameCheap mais là encore la procédure peut être différente selon l’autorité de certificat que vous utilisez. 🙂
Je copie-colle dans mon espace client le contenu de mon CSR.
J’indique qu’il s’agit bien d’un serveur de type Windows IIS. Ensuite, je dois confirmer mon identité et je reçois au final mon certificat correctement généré par NameCheap. Il s’agit d’un fichier qui porte l’extension .CER.
Il me reste à charger ce certificat sur notre serveur. Pour ce faire, on retourne en RDP sur le serveur et on lance l’application IIS Manager. Toujours en sélectionnant le nom du serveur, puis Certificates, on peut alors choisir l’option à droite Complete certificate request.
Notre certificat est à présent dans la bibliothèque de certificats et nous pourrons l’utiliser pour la configuration de notre Remote Desktop Gateway.
Etape 4 : Configuration de notre RD Gateway
Retournez dans l’application RD Gateway Manager. Positionnez-vous sur le nom du serveur à gauche et cliquez sur View or modify certificate properties au centre de la fenêtre.
Dans l’onglet SSL Certificates, cliquez sur Import Certificate et sélectionnez le précédent certificat que nous avons importé.
Une fois que vous avez importé votre certificat vous allez voir qu’il nous reste encore quelques étapes de configurations ! 🙂
Toujours dans l’outil RD Gateway Manager, positionnez-vous sur Policies, effectuez un clic droit et sélectionnez l’option Create new Authorization rules. Et suivez l’assistant de configuration…
Nommez votre URL d’accès à votre RD Gateway (correspond toujours au même nom DNS pour lequel nous avons créé une entrée A puis générer un certificat…). 😉
Ici, vous pouvez définir des groupes Active Directory vous permettant de restreindre l’utilisation de votre Gateway à certains utilisateurs ou uniquement pour certains serveurs. Dans mon cas, je restreins l’utilisation à un groupe AD d’utilisateurs mais je ne mets aucune limitation concernant les serveurs.
Ici, vous avez la possibilité – si vous le souhaitez, de définir une timeout pour déconnecter les utilisateurs au bout d’un certain moment d’inactivité. Pour ma part, je n’active pas ces options.
Notre RD Gateway permettra uniquement de faire du port 3389 et donc d’ouvrir des sessions RDP vers d’autres serveurs. C’est son but premier donc on peut laisser ce réglage par défaut. 😉
La configuration de notre Remote Desktop Gateway est à présent terminée. Il nous reste à effectuer quelques ultimes réglages… qui peuvent varier en fonction de votre infrastructure / réseau. 😉
Etape 6 : Ouvrir les flux
Par défaut, notre RD Gateway aura besoin de 2 ports à ouvrir : le port 443/TCP (https) et le port 3391/UDP. Je réalise donc ces 2 ouvertures de flux que je redirige vers notre RD Gateway (j’utilise personnellement Pfsense pour gérer mon réseau – mais vous aurez peut-être autre chose tel que Sophos, etc.).
L’adresse IP 10.0.0.5 correspond à mon serveur RD Gateway.
Etape 7 : Tester la connexion
Finalement, il ne nous reste plus qu’à tester. 🙂
J’utilise Remote Desktop Manager comme outil de RDP. Mais la configuration sera très similaire quelque soit l’outil que vous pouvez utiliser.
Commencez par indiquer le nom interne du serveur auquel vous souhaitez accéder. Dans mon cas, je souhaite me connecter à l’un de mes Domain Controller.
Puis dans l’onglet Connection, j’indique la référence à ma RD Gateway avec son nom DNS. Par défaut, la connection s’effectuera via le port 443/TCP. Pour tous les outils de RDP, vous aurez probablement une case à cocher pour utiliser le même login/mot de passe pour s’authentifier sur votre RD Gateway ainsi que sur le serveur cible.
Voilà, c’est terminé ! 😉
Vous pouvez désormais accéder à tous vos serveurs en RDP sans avoir à ouvrir un port pour chaque machine. Ce qui est quand même beaucoup plus pratique et plus sécuritaire !
Bonjour Merci votre article 🙂 pouvons nous mettre en place une gateway pouvant gerer plusieurs domaines separer des vlans ?
Bonjour Gio, je n’ai pas eu l’occasion de tester personnellement ce scénario. Cela dit pour moi, une RD Gateway doit pouvoir être utilisée dans le cadre de multiple domaines Active Directory. Dès lors que ces différents domaines appartiennent à la même forêt, cela ne devrait pas poser de difficultés. En revanche, si vos domaines n’appartiennent pas à la même foret, cela ne fonctionnera pas. En tout cas pas sans TRUST entre les différents domaines concernés. Voir cet article.
Merci Pour votre retour en effet dans un scenario d’une même foret cela devrait logiquement fonctionner l’idée était de mutualisé la gateway entre des organisations séparé virtuellement et pas de TRUST prévu malheureusement :).
Je vais jéter un coup d’oeil à l’article et si je trouve une solution je reviendrai vers vous merci.
Bonjour,
Merci pour cet article.
Quelle est la meilleure pratique en termes de sécurité, entre la mise en place de ce serveur dans une DMZ et la création de règles NAT ?
Hello Jeo, désolé pour le délai de ma réponse… J’avais un peu déconnecté avec les vacances.
Alors ta réponse demande de prendre en compte l’environnement en question et ce que tu vas publier avec ta ferme RDS (critique, sensible… ou pas). D’un point de vue purement sécurité et si on revient aux bases : tous les serveurs d’une infrastructure RDS sont des serveurs membres de l’Active Directory donc en tant que serveur membre il n’est PAS recommandé de les mettre dans une DMZ ou avec une patte sur Internet (peu importe le format). Donc à partir de là, l’idéal serait donc d’avoir ta RD Gateway au sein du LAN et faire du NAT avec ton FW ou ton appliance réseau pro. Maintenant, pour des POC ou environnements de tests, avoir une RD GW en DMZ est tout à fait faisable.
Bonsoir, pour cet article complet 🙂 J’ai une question, le certificat est valable pour le serveur mais je peux l’utiliser aussi sur les 40 postes de mon réseau ? Merci
Bonjour Séb, Non ce n’est pas l’objectif. Avoir un véritable certificat signé par une authorité extérieure vous permet de pouvoir accéder à votre RDGW depuis n’importe quel poste. En revanche, dans le cas où vous utilisez un certificat auto-signé (clairement pas pour ouvrir sur Internet) alors oui il peut être nécessaire d’ajouter le certificat sur les postes clients pour qu’il soit trusté… Mais ce n’est vraiment pas l’objectif.