Dans mon précédent article, je vous ai détaillé étapes par étapes comment provisionner une petite infrastructure Remote Desktop Services sur Windows Server 2012 R2. Je vous propose de voir aujourd’hui comment étendre notre infra et y ajouter une RDS Gateway.
Mais avant d’aller plus loin, je vous propose de résumer à quoi sert ce composant :
Une Gateway RDS sur un serveur permet à des clients / utilisateurs distants de se connecter à votre infrastructure de manière sécurisée en https (via le port 443). De cette manière, les serveurs auxquels vous souhaitez accéder ne sont pas directement visibles depuis Internet.
Un serveur hébergeant le rôle de RD Gateway se place bien souvient en DMZ (cela dit ce n’est pas une obligation si vous avez une appliance de type SOPHOS ou pfSense et que vous gérer vous même le NAT entre les différents composants de votre infrastructure).
Contexte
Dans mon précédent article, je vous ai expliqué que j’avais à ma disposition les serveurs / machines virtuelles suivantes :
- 1 VM AKL-RDBRK pour le Connection Broker,
- 1 VM AKL-RDWAC pour le Web Access,
- 1 VM AKL-RDGAT pour la Gateway RDS (sera déployé dans un prochain article car non nécessaire à une infrastructure standard RDS),
- 2 VM : AKL-RDSH1 + AKL-RDSH2 pour nos serveurs Session Host qui vont héberger nos RemoteApps.
Il ne nous manque donc plus qu’à voir ensemble comment installer notre Gateway RDS sur notre VM dédiée. Si vous n’êtes intéressé que par la partie RDS Gateway, je vous recommande tout de même la lecture du précédent article pour être plus à l’aise avec le contexte de mon architecture de test. 🙂
Installation du rôle RDS Gateway
Comme précédemment, je me connecte sur ma machine AKL-RDBRK sur laquelle j’ai créé un groupe de serveurs et je vais procéder au déploiement du rôle RDS Gateway sur le serveur AKL-RDGAT directement depuis le Server Manager AKL-RDBKR.
Cliquez sur Add Roles and Features.
A noter que vous pourriez tout à fait réaliser cette opération directement sur le serveur cible (mais comme dans le précédent article, je voulais tester les groupes de serveurs et cette possibilité de déployer à distance les rôles Windows Server).
Sélectionnez le serveur cible. Dans mon cas, il s’agit du AKL-RDSGAT.
Rappel : étant donné le nombre de screens, si une capture d’écran n’est pas présente, vous pouvez considérer qu’il faut utiliser l’option par défaut ou simplement cliquez sur Next.
Cochez RDS Gateway, cela va générer l’installation de dépendances. Acceptez-les simplement.
Cliquez sur Next.
L’installation est à présent terminée. Cliquez sur Close. Aucun redémarrage n’est nécessaire pour l’installation de ce rôle.
Configuration du rôle RDS Gateway
Directement sur le serveur hébergeant le rôle de RDS Gateway, depuis le Server Manager rendez-vous dans la section Remote Desktop Services, effectuez un clic droit sur le serveur en question et ouvrez la RD Gateway Manager.
Première chose à faire pour la configuration, vous devez disposer d’un certificat SSL pour le https/443. Dans le cas d’une infrastructure de Production, vous généreriez bien entendu un véritable certificat auprès de votre AD CS (ou ailleurs). Dans le cas présent, il s’agit d’une archi de test nous allons donc utiliser un certificat auto-signé.
La contrainte avec ce mode d’utilisation, c’est que le poste client qui souhaite utiliser la Gateway par la suite devra disposer de ce certificat sur son poste.
Veillez à garder le nom affiché pour le certificat afin qu’il corresponde bien au FQDN de la VM. En revanche, vous pouvez modifier sans problème l’emplacement de sauvegarde du certificat.
Cliquez sur OK.
De retour dans la RD Gateway Manager, nous allons maintenant configurer les Policies. Je vais vous proposer une configuration tout ce qu’il y a de plus standard mais n’hésitez pas à adapter en fonction de vos besoins.
Cliquez sur la droite, sur Create new Authorization Policies.
Nommez votre Policy et cliquez sur Next.
Dans mon cas je n’aurais que les MDP comme méthode d’authentification. Renseignez un groupe AD si nécessaire pour définir les utilisateurs qui seront autorisés à utiliser la Gateway. Cliquez sur Next.
Que ce soit dans RDS ou Citrix, vous avez la possibilité de choisir ou non de rediriger certains flux de l’ordinateur client vers les serveurs. Vous pouvez utiliser l’option de base qui n’impose aucun restriction. Personnellement, je ne souhaite pas rediriger les imprimantes et certains Ports. Cliquez sur Next.
Là encore, vous pouvez adaptez en fonction de vos besoins. Personnellement, j’ai abaissé les délais de déconnexion en cas d’Idle et autre. Cliquez sur Next une fois votre choix terminé.
Récapitulatif de la Policy. Cliquez sur Next.
On passe maintenant à la Policy PAP.
Choisissez si vous souhaitez autoriser tous les utilisateurs à se connecter et sur quel(s) port(s) la Gateway doit rediriger par défaut. Dans mon cas, je ne suis intéressé que par les connexion RDP et donc le port 3389.
Vos Policies sont maintenent créées et votre RD Gateway Manager est à présent configurée.
Avant d’aller plus loin, pensez qu’en fonction de type d’infrastructure que vous avez à votre disposition, vous devrez peut-être adapter votre configuration NAT ou procéder à des redirections de flux pour que la Gateway fonctionne. Cette partie dépend complètement de vous (en cas de besoin, utilisez les commentaires). Par exemple, moi j’utilise un appliance Sophos qui me sert de Firewall et pour le NAT. 🙂
Test de la RDS Gateway
Il ne nous reste plus qu’à tester la connexion.
Pour cela, ouvrez l’outil Remote Desktop Connect sur une machine de votre infrastructure et configurez le comme suit. Comme d’habitude, indiquez l’adresse IP du serveur que vous souhaitez rejoindre par exemple 10.0.0.14 pour moi correspond à un AD. Ne cliquez pas encore sur Connect !
Allez ensuite dans l’onglet Advanced et renseignez les détails de votre RD Gateway.
Une fois terminée cliquez sur Connect.
And voilà ! Si vous avez tout bien suivi, il n’y a rien à faire d’autre et vous êtes connectés sur la machine cible via la RD Gateway.
Vous pouvez vous en rendre compte dans la fenêtre RDP et voir un petit changement graphique avec un cadenas indiquant que vous utilisez bien votre RDS Gateway :
Point d’attention
Comme la plupart des articles qui traitent de la RD Gateway, en fonction de ce que vous cherchez à faire il est possible que vous ayez le message d’erreur suivant : You computer can’t connect to the remote computer because the Remote Desktop Gateway server address requested and the certificate subject name do not match. Contact you network administrator for assistance.
Cette erreur provient du fait que le FQDN de votre RD Gateway et l’adresse que vous tapez pour vous y connectez doivent être identiques. Si vous trouvez un work arround sur ce point, je suis preneur. Même en chargeant le certificat à la main sur le poste client, si les noms sont différents la connexion refusera de s’établir (en tout cas dans mes tests jusqu’à présent). De ce fait, dans mon cas, je n’ai pas pu simplement rediriger les flux avec mon appliance Sophos mais j’ai dû positionner la RD Gateway avec une patte en interne et sur l’externe.
Bonjour j’ai suivis la totalité des tutos mais je me heurte à un problème.
tous mes tests fonctionne quand je suis en interne mais des que je passe en extérieure j’ai le message suivant qui s’affiche
Bonjour Pierre, comment as-tu géré ton nom d’accès pour l’extérieur ? As-tu bien un véritable certificat SSL validé par une autorité externe pour le nom DNS que tu utilises pour te connecter ? Cela pourrait expliquer le souci.
Bonjour merci pour ta réponse.
Il me manqué juste la configuration du Gateway pour que les remotapps ainsi que le rdweb soit bien redirigé.
Si c’est résolu c’est le principal 🙂
bonjour et merci pour ce tuto
Est ce qu’il faut ouvrir le port 443 et 3389 sur le parefeu pour que cela fonctionne ou seulement le 443 sur la Gateway RDS et cette derniere fera le lien avec le serveur en 3389?
Merci
Si tu utilises une Gateway RDS, le principe s’est justement de n’avoir PAS besoin d’ouvrir le port 3389. Donc depuis l’extérieur tu n’utilise que le port 443 pour accéder ta Gateway RDS. En revanche en interne, il faut bien entendu que ta Gateway puisse faire du RDP en interne (et donc que le RDP soit autorisé. Est-ce que c’est plus clair ?