Comment configurer une passerelle de bureau à distance sur un serveur Windows

Comment configurer et dépanner une passerelle de bureau à distance sur un serveur Windows

Si vous rencontrez des difficultés lors du déploiement d’une passerelle Bureau à distance (RD Gateway), rassurez-vous, vous n’êtes pas seul. Le processus d’installation peut parfois s’avérer complexe, notamment lorsqu’il s’agit de gérer les certificats SSL, les stratégies et de garantir la connexion sans problème de vos clients. Ce guide a pour but de vous aider à y voir plus clair. Qu’il s’agisse de stratégies peu claires ou d’erreurs de certificat, vous y trouverez des solutions pour identifier les problèmes et les résoudre. Au final, vous obtiendrez une configuration d’accès à distance plus sécurisée et fiable, parfaitement fonctionnelle en cas de besoin.

Déploiement du rôle de passerelle RDS sur un serveur Windows

Méthode 1 : Installation via le Gestionnaire de serveur ou PowerShell

En général, il faut commencer par vérifier que le rôle de passerelle Bureau à distance est installé sur un serveur dédié ou avec les autres rôles RDS. Dans la plupart des cas, l’utilisation de PowerShell est plus rapide, car Windows a tendance à compliquer les choses inutilement. Si Active Directory et RDS sont déjà déployés, il suffit d’installer le rôle de passerelle et de le configurer.

Pour vérifier si le rôle est déjà installé, exécutez la commande suivante dans PowerShell :

Get-WindowsFeature RDS-Gateway

S’il n’est pas présent, installez-le avec :

Install-WindowsFeature RDS-Gateway -IncludeAllSubFeature -IncludeManagementTools

Cela activera également les rôles IIS et NPS, permettant ainsi le fonctionnement complet du package. Une fois l’installation terminée, vous devrez créer des groupes d’accès dans Active Directory via ` dsa.msc`, comme suit :

rdgwExtUsers — pour les utilisateurs autorisés à s’authentifier ;
rdgwExternalAdmins — pour les utilisateurs qui peuvent se connecter aux hôtes RDS internes ;
mun-rdsfarm — tous vos hôtes RDS et le serveur de connexion RD que vous souhaitez rendre accessibles via la passerelle.

Méthode 2 : Utilisation de l’interface graphique et de PowerShell pour les stratégies

Une fois le rôle installé, l’étape suivante consiste à configurer les stratégies d’autorisation dans le Gestionnaire de passerelle Bureau à distance (`tsgateway.msc`).Créez une stratégie d’autorisation de connexion (RD CAP) – qui détermine qui peut se connecter – et une stratégie d’autorisation de ressources (RD RAP) – qui détermine les serveurs internes auxquels les utilisateurs peuvent accéder. La configuration par défaut convient généralement pour les tests, mais soyez vigilant face aux problèmes courants tels que des groupes d’utilisateurs incorrects ou des ressources réseau incohérentes.

Par exemple, la création d’un groupe d’accès Bureau à distance (RD CAP) pour vos utilisateurs externes peut impliquer le choix d’un groupe comme rdgwExtUsers et la configuration de l’authentification sur mot de passe uniquement ou carte à puce. N’oubliez pas de spécifier les options de redirection de périphérique et les délais d’expiration de session, car il arrive que les sessions se bloquent sans raison apparente.

Si vous préférez PowerShell, voici un exemple rapide pour le CAP :

Import-Module -Name RemoteDesktopServices New-Item -Path 'RDS:\GatewayServer\CAP' -Name 'rdgwAllowAutht-CAP' -UserGroups rdgwExtUsers -AuthMethod '1'

De même, créez le RAP pour l’accès interne, en utilisant soit l’interface graphique, soit PowerShell, comme suit :

New-Item -Path RDS:\GatewayServer\RAP -Name allowextAdminMunRDS -UserGroups "rdgwExternalAdmins" -ComputerGroup "mun-rdsfarm" -Port 3389

Solution 1 : Configuration du certificat SSL – Assurez-vous que la connexion est sécurisée

L’ajout d’un certificat SSL robuste est absolument essentiel. Non seulement il chiffre les données, mais les clients ne pourront pas se connecter si le certificat SSL n’est pas approuvé. Vous pouvez opter pour un certificat auto-signé (pour vos tests), mais cela engendre souvent des problèmes de confiance. En général, un certificat valide délivré par une autorité de certification (comme Let’s Encrypt ou un fournisseur payant) est préférable, surtout si vos clients se trouvent en dehors de votre domaine.

Accédez à la console de la passerelle Bureau à distance, ouvrez l’ onglet Certificat SSL et importez votre certificat approuvé existant ou créez-en un auto-signé. N’oubliez pas d’inclure le nom de domaine complet (FQDN) de votre serveur dans le nom du sujet (SAN) ; sinon, les clients recevront des erreurs d’incompatibilité de noms.

Les ports 443 (TCP) et 3391 (UDP) doivent être ouverts dans votre pare-feu, afin d’acheminer le trafic public vers votre serveur de passerelle Bureau à distance. Car, bien sûr, Windows ne peut s’empêcher de compliquer les choses !

Solution 2 : Configurer correctement le client RDP

Une fois la configuration côté serveur terminée, quelques ajustements sont nécessaires côté client. Lancez ` mstsc.exe` et, dans l’ onglet Avancé, cliquez sur Paramètres sous « Se connecter de n’importe où ».

Définissez le nom d’hôte du serveur de passerelle Bureau à distance (par exemple, gw.votredomaine.com ) — celui-ci doit correspondre à celui du certificat SSL.
Si vous avez utilisé un port différent, spécifiez-le après le nom d’hôte, comme gw.votredomaine.com:4443.
Cochez la case « Utiliser mes informations d’identification de passerelle Bureau à distance pour l’ordinateur distant » pour éviter les problèmes de connexion.

Attention : si votre certificat est auto-signé, vous devrez l’importer dans le magasin des autorités de certification racines de confiance sur le client, sinon la connexion sera bloquée et des erreurs s’afficheront. Dans certaines configurations, cela reste fastidieux, notamment avec de nombreux utilisateurs distants ou des politiques de sécurité strictes.

Solution 3 : Dépannage des erreurs de connexion — Causes fréquentes

Si la connexion ne s’établit pas, vérifiez les points suivants :

Assurez-vous que les noms du certificat SSL correspondent parfaitement au nom DNS utilisé par le client. Toute différence entraîne des échecs de connexion (« Votre ordinateur ne peut pas se connecter… »).
Vérifiez que les ports sont ouverts et correctement redirigés. Exécutez `netstat -an` sur le serveur pour vérifier si les ports 443 et 3391 sont à l’écoute ;
Vérifiez les règles de votre pare-feu : règles entrantes pour TCP 443/3391 et règles sortantes autorisant le trafic de retour ;
Consultez les journaux de l’Observateur d’événements sous Journaux des applications et des services > Microsoft > Windows > TerminalServices-Gateway pour rechercher des ID comme 205 afin de confirmer les connexions réussies ou les erreurs.
Assurez-vous que vos clients font confiance au certificat SSL, surtout s’il s’agit d’un certificat auto-signé. Dans certains cas, l’importation du certificat racine chez les clients résout le problème.

La plupart des problèmes sont dus à des noms DNS incorrects, à une mauvaise configuration des ports ou à des certificats non approuvés. De petites erreurs, certes, mais qui bloquent toute tentative d’accès à distance.

Solution 4 : Exécution de la passerelle Bureau à distance sans Active Directory (configuration de groupe de travail)

Ne vous inquiétez pas si vous n’êtes pas dans un domaine. Vous pouvez tout de même déployer la passerelle Bureau à distance dans un environnement de groupe de travail, mais cela nécessite une configuration manuelle supplémentaire. Installez le rôle via PowerShell :

Install-WindowsFeature RDS-Gateway -IncludeAllSubFeature -IncludeManagementTools

Ouvrez le Gestionnaire de passerelle Bureau à distance et créez les stratégies nécessaires, comme précédemment. Veillez à configurer un certificat SSL valide ; un certificat auto-signé fonctionne, mais un certificat à long terme simplifie la vie des clients.

Pour plus de sécurité, ouvrez PowerShell et générez un certificat auto-signé avec davantage de SAN, notamment si votre nom d’hôte ou vos adresses IP changent :

$todaydate = Get-Date $addyear = $todaydate. AddYears(5) New-SelfSignedCertificate -dnsname gw1.yourdomain.com, 10.11.12.13, rdgw.yourdomain.com -notafter $addyear -CertStoreLocation cert:\LocalMachine\My

Ce certificat doit ensuite être importé dans le magasin personnel et attribué dans les propriétés de la passerelle Bureau à distance, sous l’ onglet « Certificat SSL ». Exportez également le certificat (sans la clé privée) pour l’installer sur les clients, afin qu’ils fassent confiance à la passerelle.

Conclure

Configurer la passerelle Bureau à distance peut s’avérer complexe, notamment avec les certificats SSL et les stratégies de sécurité. Cependant, une fois correctement configurée, elle représente une nette amélioration par rapport à l’accès direct au protocole RDP sur Internet. Veillez simplement à éviter les incohérences de noms et assurez-vous que vos ports sont ouverts et correctement redirigés. Après cela, la plupart des problèmes de connexion client devraient se résoudre d’eux-mêmes.

Résumé

Installation du rôle RDS-Gateway via PowerShell ou le Gestionnaire de serveur
Stratégies d’autorisation configurées et redirection des appareils
Installation de certificats SSL de confiance et ouverture des ports nécessaires (443/3391).
Clients RDP configurés avec les noms de serveur et les certificats corrects
J’ai vérifié les journaux de l’Observateur d’événements pour voir si la connexion avait réussi ou si des erreurs s’étaient produites.

J’espère que ça aidera.

Assurez-vous que vos certificats SSL sont toujours à jour et vérifiez la configuration DNS et les ports en cas de problème. Cela devrait vous faire gagner du temps ; j’ai testé cette méthode sur plusieurs configurations, alors n’hésitez pas !