Bonjour. Dans cette vidéo, je vais vous montrer les étapes nécessaires à la configuration d’un serveur de passerelle des services Bureau à distance. Un serveur de passerelle RDS est utile si vous souhaitez autoriser l’accès à votre environnement RDS aux utilisateurs qui se trouvent en dehors du pare-feu d’entreprise. Un serveur de passerelle RDS utilise SSL pour chiffrer la communication entre les clients et les serveurs RDS.
Cela est possible grâce à un certificat installé sur le serveur de passerelle RDS approuvé par l’appareil de l’utilisateur final. Le composant de passerelle RDS utilise également IIS pour l’authentification. Grâce à IIS, nous pouvons créer certaines règles pour définir de manière granulaire quels utilisateurs doivent avoir accès à quelles ressources. Je le montrerai plus loin dans cette vidéo également. Cette démonstration suppose qu’un déploiement RDS existe déjà.
Si vous avez besoin de plus d’informations sur la configuration d’un déploiement RDS de base ou avancé, je vous suggère de consulter les vidéos précédentes de cette série. Ici, j’affiche les machines virtuelles que je vais utiliser. « RDSlab-DC » est un contrôleur de domaine. Le rôle de licence RD est également installé. Toutes les autres machines virtuelles sont jointes au domaine hébergé dans ce contrôleur de domaine. « RDSlab-CB » est le courtier de connexion pour le déploiement. « SH1 » et « SH2 » sont les hôtes de session de la batterie de serveurs. Cette autre machine virtuelle, je l’ai nommée « RDSFarm », et c’est la machine que je vais configurer en tant que serveur de passerelle RDS. Il héberge également le rôle RD Web Access. J’ai créé cet environnement RDS à l’aide de ces cinq lignes PowerShell, que j’ai incluses dans la description vidéo et dont j’ai parlé dans les vidéos précédentes.
Ainsi, pour configurer le serveur RD Gateway, je vais ouvrir la console sur la machine virtuelle qui héberge le rôle de courtier de connexion pour le déploiement. Ouvrez le Gestionnaire de serveur et cliquez sur le nœud Services Bureau à distance. La section servers indique que tous les rôles sont configurés pour ce déploiement, à l’exception du rôle de passerelle RD. C’est pourquoi ce rôle s’affiche avec un signe plus vert ici sous la section Overview, indiquant qu’il est en attente de déploiement.
Pour le configurer, ajoutons d’abord le rôle au serveur cible. Cliquez sur « Gérer », puis sur « Ajouter des rôles et des fonctionnalités ». Sélectionnez « Role-based or feature-based installation », je vais sélectionner le serveur cible pour le rôle de passerelle Bureau à distance dans ce déploiement, puis cliquer sur « Next ». Développez « Services Bureau à distance » et cochez la case « Passerelle Bureau à distance ». Cliquez sur « Ajouter des fonctionnalités » pour installer les conditions préalables, puis sur « Suivant » sur l’écran de confirmation et enfin sur « Installer ». Attendez la fin de l’installation, puis cliquez sur « Close ». De retour dans Server Manager, si je clique pour actualiser le déploiement, il n’y a aucun changement. Cela est dû au fait que les fichiers binaires ont été installés, mais que le déploiement lui-même n’a pas été configuré avec un serveur de passerelle RD.
Pour résoudre ce problème, cliquez sur le signe plus vert au-dessus de « RD Gateway » pour démarrer l’assistant. Sélectionnez le serveur qui sera configuré en tant que passerelle RD, déplacez-le sur le côté droit, puis cliquez sur « Next ». Cet assistant me demandera de configurer un certificat auto-signé et je saisirai ici le nom de domaine complet du sujet sur ce certificat. Ce n’est cependant pas le certificat que je vais utiliser pour cette démo. Pour l’instant, cliquez sur « Next ». Cliquez sur « Add » pour confirmer l’ajout au déploiement. Attendez la fin de l’installation du rôle, puis notez l’avertissement indiquant qu’un certificat doit être configuré, mais cliquez sur Fermer pour l’instant. En actualisant le déploiement une fois de plus, vous constaterez qu’un serveur de passerelle Bureau à distance est désormais présent, sous « Deployment Overview », cliquez sur « Tasks », puis sur « Edit Deployment Properties ». Notez que la section « RD Gateway » a été automatiquement configurée avec certains paramètres. Cliquez sur le nœud « Certificats » et remarquez qu’aucun certificat n’est configuré pour RD Web Access ni pour les rôles RD Gateway. Je vais d’abord cliquer sur le rôle de la passerelle RD. Voici l’option qui permet de créer un certificat.
À des fins de test, il est possible d’utiliser un certificat auto-signé créé ici, ou similaire à celui qui a été créé automatiquement précédemment dans l’assistant. Pour cette démo, je vais configurer un certificat provenant d’une autorité de certification publique de confiance. De cette façon, ce certificat n’a pas besoin d’être installé sur les ordinateurs clients ; Ils lui feront simplement confiance dès la sortie de la boîte. Je vais donc cliquer sur « Select existing certificate » ici. Je dois saisir le chemin d’accès au certificat. Pour cette démo, je l’ai copié à la racine du lecteur C dans le contrôleur de domaine. Je vais ensuite saisir le mot de passe avec lequel il a été enregistré, cliquer pour cocher cette case « Autoriser », puis cliquer sur « OK ». Notez l’état « Prêt à appliquer » sur l’écran de configuration du déploiement.
Cliquons donc sur « Apply ». Au bout de quelques instants, l’écran indique que l’opération s’est terminée avec succès et la colonne Niveau reconnaît le certificat comme étant de confiance. Si j’utilisais un certificat auto-signé, il s’afficherait différemment. Nous appliquons le certificat, mais il s’affiche comme non fiable et je dois copier ce certificat sur les ordinateurs clients, puis l’installer. C’est l’un des principaux avantages de l’utilisation d’un certificat basé sur un domaine ou d’une autorité de certification publique, comme c’est le cas dans cette démo. Cliquez ici dans « Afficher les détails » pour afficher l’objet du certificat, qui se trouve être le nom d’hôte Windows de la machine virtuelle de la passerelle RD. Je vais répéter ces étapes pour le rôle RD Web Access, de cette façon, ce même certificat est utilisé pour IIS. Cliquez ensuite sur « OK » pour quitter l’écran de configuration du déploiement.
C’est tout ce que nous avons à faire dans le courtier de connexion. L’étape suivante consiste à configurer une règle d’autorisation de connexion et une règle d’autorisation de ressource. J’en parlerai plus en détail au fur et à mesure que je les créerai. Je vais maintenant passer à la machine virtuelle de la passerelle RDS. Ouvrez Server Manager, cliquez sur « Tools », « Remote Desktop Services », puis sur « Remote Desktop Gateway Manager ». Tout d’abord, ajustons les propriétés du serveur sous l’onglet « Parc de serveurs ». Ajoutons ce serveur de passerelle RD et cliquons sur « Apply ».
Cette erreur concernant un équilibreur de charge est attendue. Dans cette démo, je n’équilibre pas la charge du service RD Gateway, il s’agit uniquement d’un serveur RD Gateway. Il vous suffit donc de cliquer une fois de plus sur « OK », puis sur « Apply ». Dans l’onglet « Certificat SSL », je peux afficher et modifier la configuration du certificat du serveur de la passerelle Bureau à distance, et même créer un nouveau certificat à signature automatique si nécessaire. Cependant, tout cela a déjà été configuré dans le courtier de connexion, je vais donc cliquer sur « OK » pour quitter l’écran des propriétés. De retour sur l’écran principal de RD Gateway Manager, je développe le serveur, puis je clique sur « Policies ».
Il existe deux types de stratégies dans ce contexte, comme illustré ici : les « Stratégies d’autorisation de connexion » vous permettent de spécifier qui est autorisé à se connecter à ce serveur de passerelle RDS, tandis que les « Politiques d’autorisation des ressources » vous permettent de spécifier les serveurs ou ordinateurs auxquels les utilisateurs autorisés auront accès. En d’autres termes, l’une des politiques porte sur les personnes qui y auront accès et l’autre sur ce à quoi elles auront accès. Cliquez avec le bouton droit de la souris sur « Connection Authorization Policies », puis sur « Create New Policy », puis sur « Wizard ». Vous pouvez créer la stratégie séparément, mais je vais suivre l’option recommandée ici, qui consiste à créer à la fois la stratégie d’autorisation de connexion au bureau à distance et la stratégie d’autorisation des ressources du bureau à distance dans le même assistant, puis à cliquer sur « Next ». Saisissez un nom pour le RD CAP, cliquez sur « Next », puis sur « Add Group », puis saisissez le nom du groupe contenant les utilisateurs qui seront autorisés à se connecter. Je saisis « Domain Users » pour cette démo, puis je clique sur « Next ». Je conserve les valeurs par défaut dans les étapes « Device Redirection » et « Session Timeout » en cliquant sur « Next » sur les deux écrans, ainsi que dans l’écran récapitulatif, puis je poursuis avec la politique d’autorisation des ressources RD. Saisissez un nom, puis cliquez sur « Next ».
Conservez la valeur par défaut dans la section « User Groups », puis cliquez sur « Next ». Encore une fois, ici sur l’écran « Network Resource », si j’avais un groupe Active Directory contenant les comptes d’ordinateur des serveurs hôtes de session de ce déploiement RDS, je pourrais le spécifier. Pour cette démo, cependant, je vais simplement choisir l’option « Autoriser les utilisateurs à se connecter à n’importe quelle ressource réseau ou ordinateur », puis cliquer sur « Suivant ». Je vais laisser le port par défaut 3389 pour la passerelle Internet pour la communication des hôtes de la session RDS, puis je clique sur « Next ». Cliquez sur « Finish » dans l’écran récapitulatif, puis sur « Close ». Ainsi, à ce stade, ce serveur de passerelle RDS est prêt à être placé au-delà du pare-feu, face aux internautes. Un utilisateur qui tente de se connecter aux hôtes de session RDS à partir d’un domicile ou d’un bureau distant via Internet doit d’abord passer par ce serveur de passerelle RDS.
Je vais montrer ici, sur cet ordinateur client connecté à Internet via une liaison complètement distincte de celle du serveur de passerelle RD, comment un utilisateur distant doit configurer la connexion sur l’application Connexion Bureau à distance. Je vais d’abord saisir le nom de l’hôte de session RD. N’oubliez pas que cet hôte de session n’est pas connecté à Internet. Cliquez sur le bouton Show Options, sur l’onglet Advanced, puis sur la section Connect from anywhere. Cliquez sur « Settings ». Cliquez sur le bouton radio « Utiliser ces paramètres de serveur de passerelle RD » et saisissez le nom DNS public de la passerelle RDS.
Pour que cela fonctionne, bien sûr, ce nom DNS public doit se résoudre en l’adresse IP publique attribuée à la machine de passerelle RDS. Vous devez effectuer cette configuration dans les paramètres du service DNS public utilisé. Je clique également pour décocher « Bypass RD Gateway for local addresses » et pour cocher l’option Use my RD Gateway Credentials pour l’ordinateur distant, car il s’agit des mêmes informations d’identification pour les deux machines. Cliquez ensuite sur « OK » et sur « Connect ». Saisissez le nom d’utilisateur et le mot de passe du domaine, et vous verrez que la connexion réussit. Notez qu’il n’a pas été nécessaire d’installer de certificat sur l’ordinateur client.
Il n’y avait pas non plus de message nous avertissant de faire confiance à la machine à laquelle le client voulait se connecter. En effet, le certificat que nous utilisons provient d’une autorité de certification publique de confiance. De retour sur la machine de la passerelle RDS, dans RD Gateway Manager et sous « Surveillance », nous pouvons voir les détails de la connexion. En outre, dans l’Observateur d’événements du journal opérationnel de la passerelle des services Terminal Server, notez une série d’événements documentant les étapes. L’événement 312 indique la connexion initiée à partir de l’ordinateur client et l’événement 200 indique que les informations d’identification utilisées respectent la politique d’autorisation de connexion. L’événement 300 indique que la politique d’autorisation des ressources a également été respectée, donc l’accès est autorisé, et enfin l’événement 302 indique que la connexion a réussi et que le protocole de connexion est HTTP.
Cela est dû au fait que le trafic entre le client et la passerelle RDS s’effectue via HTTPS, qui utilise le chiffrement pour sécuriser les communications. Si la machine de la passerelle RDS se trouve derrière un pare-feu ou un périphérique réseau, le seul port qui doit être autorisé est le port 443. C’est ce que j’ai fait dans le routeur utilisé pour cette démo. Il vient d’être configuré pour transférer le port 443 vers la machine de la passerelle RDS. Il s’agit donc d’une démo sur la façon d’intégrer un serveur de passerelle RDS à un déploiement de services Bureau à distance standard, afin de permettre un accès chiffré sécurisé à partir d’un domicile ou d’un emplacement Internet public.
J’espère qu’elle vous sera utile et je tiens à vous remercier de votre attention.
