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. 😉
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.
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.
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.
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. 😉
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.
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 !
Microsoft 365 : l'abonnement mensuel pour les entreprises va augmenter (encore) Microsoft vient d'annoncer une…
Un fléau quotidien Le démarchage téléphonique abusif a longtemps été une plaie pour de nombreux…
Un Basculement Historique En 2024, le monde du développement a assisté à un événement marquant…
Une nouvelle ère pour la retouche photo sur Mac ? Dans une annonce qui a…
La version finale de Windows Server 2025 est disponible Windows Server 2025 est désormais disponible…
Locaux Google France à Paris Introduction L'intelligence artificielle révolutionne tous les secteurs, et le développement…