Jusqu’à ce que je découvre RD Gateway, j’avais le port 3389 grand ouvert sur mon serveur de test. Chaque nuit, une armada de bots asiatiques tentait admin/admin avec une régularité d’horloge. Le lendemain, les logs ressemblaient à un poème épique d’échecs de connexion. Pourtant, la solution était là, intégrée à Windows Server depuis des années, et je passais à côté par méconnaissance.
C’est le paradoxe de l’administration système: on vous vend le RDP comme l’outil universel de prise en main à distance, mais on oublie de vous dire que l’ouvrir au monde, c’est comme laisser la clé de la maison sous le paillasson. RD Gateway corrige cette folie en encapsulant le protocole de bureau distant dans un tunnel HTTPS standard. Plus de port 3389 exposé, donc plus de brute force scripté à l’aveugle. Et en prime, vous bénéficiez d’une chaîne d’authentification complète qui peut s’appuyer sur un certificat TLS, un NLA (Network Level Authentication) et des stratégies conditionnelles.
Dans cet article, on va poser la mécanique de la passerelle RD Gateway, comprendre comment l’installer, comment la sécuriser sans s’arracher les cheveux, et surtout déterminer si elle a encore sa place en 2026 face au rouleau compresseur Azure Virtual Desktop. Parce que oui, ce composant de la suite « Remote Desktop Services » n’a pas pris une ride, mais il souffre d’un déficit de pédagogie. On répare ça.
La promesse d’un bureau à distance qui ne crie pas « hackez-moi »
Le fond du problème, c’est que le RDP Brut a été conçu pour un LAN de confiance, pas pour Internet. Quand vous vous connectez directement, le port 3389 répond au premier venu. Avec un RDS Gateway (ou passerelle des services Bureau à distance), vous contactez un serveur en HTTPS sur le port 443, et c’est ce serveur qui ouvre le RDP vers la machine cible interne, après avoir vérifié qui vous êtes et ce que vous avez le droit de faire.
Concrètement, du point de vue du pare-feu, vous n’avez qu’une seule règle à maintenir: le port 443 vers votre serveur Gateway. Le reste de vos machines Windows, serveurs de sessions ou postes de travail, peut rester dans un réseau interne, sans que leurs adresses IP soient jamais routées publiquement. Et puisque la passerelle s’appuie sur IIS, elle bénéficie de toute la pile de protection HTTPS: chiffrement TLS 1.2+, vérification du certificat serveur, et même des stratégies d’authentification avancée comme Kerberos delegé.
C’est un changement de mentalité important: vous n’ouvrez plus une porte d’entrée sur votre LAN, vous mettez en place un sas avec un garde permanent. Une fois que vous avez goûté à ça au boulot ou sur un homelab un peu sérieux, vous regardez le RDP direct avec le même dédain qu’un mot de passe en clair.
La mécanique RD Gateway: comment le HTTPS encapsule le RDP
Plutôt que de parler de magie réseau, déroulons le flux réel tel qu’il se produit avec une passerelle RD Gateway.
Quand vous utilisez le client Bureau à distance (mstsc), vous ne spécifiez plus l’adresse IP et le port de la machine distante. Vous renseignez l’URL de la passerelle, puis le nom interne de la ressource souhaitée. Le client RDP utilise alors le canal HTTPS (port 443) pour contacter le serveur Gateway. Ce dernier réalise un double jeu: il authentifie l’utilisateur via NLA, vérifie les politiques d’accès (CAP, Connection Authorization Policies) et les politiques de ressources (RAP, Resource Authorization Policies), puis autorise une redirection du flux RDP pur vers le serveur de destination. Le canal entre le client et la passerelle reste chiffré en TLS, et le flux RDP entre la passerelle et le serveur interne peut être protégé par son propre chiffrement ou, au minimum, soutire sa sécurité du fait qu’il circule en intérieur.
Le résultat, c’est que la charge utile RDP n’est jamais interprétée par la passerelle. Elle transite, point. Mais la couche d’autorisation s’arrête au niveau de l’utilisateur et de la machine, pas au niveau de l’application. Cela signifie qu’un administrateur peut autoriser une seule personne à se connecter à un poste de travail très précis, et empêcher toute autre combinaison.
Mentionnons rapidement une petite astuce peu documentée: le client RDP accepte des paramètres additionnels dans l’URL de connexion. Par exemple, https://votre-gateway/connect?usemultimon=1 force le multi-moniteur dans le fichier RDP généré automatiquement (source c-nergy.be, basée sur le projet open source rdpgw de Bolke de Bruin). Ce genre de finesse permet de standardiser des déploiements sans pousser un fichier .rdp manuellement sur chaque poste.
Les rôles voisins: ce que le Gateway orchestre sans qu’on le voie
RD Gateway ne travaille pas seul. Il appartient à la famille Remote Desktop Services (RDS), qui compte trois autres rôles critiques pour que l’accès distant fonctionne de façon cohérente. Détaillons-les rapidement pour comprendre où se situe la passerelle dans l’écosystème.
RD Web Access
C’est le portail web (en HTTPS, encore) que vos utilisateurs vont voir dans leur navigateur avant de lancer le client RDP. Il publie les icônes RemoteApp et les bureaux à distance disponibles. Pas obligatoire si vous distribuez vous-même les fichiers RDP, mais très pratique pour un usage par des collaborateurs moins techniques.
RD Session Host
Le serveur d’hôtes de session: c’est lui qui exécute les sessions distantes. La passerelle, elle, ne fait qu’acheminer le trafic jusqu’à cet hôte. Une installation RDS basique peut très bien combiner la passerelle et l’hôte de session sur la même machine, mais en production on les sépare généralement pour des raisons de sécurité et de montée en charge.
RD Licensing
Le gestionnaire de licences. Dès que vous utilisez RDS au-delà de la période de grâce de 120 jours, il vous faut des licences d’accès client (RDS CAL). Le serveur de licences les distribue. Une erreur fréquente consiste à oublier d’activer ce rôle, ce qui aboutit à des sessions qui refusent de s’ouvrir après expiration.
Cette architecture modulaire est la raison pour laquelle la mise en place d’un RDS Gateway n’est pas un simple clic. Vous devez penser domaine Active Directory, DNS interne, certificats et gestion des licences. La promesse du bureau distant centralisé est forte, mais la courbe d’apprentissage est raide.
Installer le rôle Passerelle RDS: la procédure pas à pas
Ici, on entre dans le concret. Le but n’est pas de faire un copier-coller d’une documentation Microsoft, mais de poser les étapes cruciales que tout admin doit suivre sans en sauter une, sous peine de se perdre dans des messages d’erreur cryptiques.
Tout d’abord, assurez-vous d’avoir un serveur Windows membre du domaine qui tourne sous Windows Server 2016, 2019, 2022 ou 2025 (c’est supporté, nous explique Microsoft dans son article sur le rôle RD Gateway). Le scénario à 5 cents « serveur en workgroup » ne fonctionnera pas: la passerelle doit pouvoir interroger l’Active Directory pour valider les utilisateurs et appliquer les stratégies.
La vidéo ci-dessous montre, en anglais, chaque clic de l’installation depuis le Gestionnaire de serveur jusqu’à la configuration des politiques d’autorisation. Elle vaut tous les longs discours.
Une fois le rôle ajouté via l’assistant, vous devez impérativement associer un certificat SSL. Un certificat auto-signé vous coûtera des alertes de sécurité sur chaque poste client non configuré manuellement pour le faire confiance. Autant dire que pour un usage régulier, mieux vaut passer par une autorité de certification interne (une PKI Windows Server) ou un certificat public de type Let’s Encrypt (ce qui suppose quelques acrobaties sur l’obtention automatique). Avec un certificat valide et un accès HTTPS correct, la passerelle est opérationnelle, mais il reste le plus délicat: les politiques.
CAP et RAP: le vrai verrou de la passerelle RDS
Ne vous laissez pas intimider par les acronymes. Les Connection Authorization Policies (CAP) déterminent qui peut se connecter via la passerelle. Les Resource Authorization Policies (RAP) définissent quelles ressources (machines, sessions, RemoteApps) ces utilisateurs peuvent ensuite atteindre.
Qui peut se connecter?
Une CAP se base sur l’appartenance à un groupe Active Directory. Vous créez un groupe « Utilisateurs_RDGateway », vous y placez les comptes autorisés, et vous liez ce groupe à la politique CAP. Vous pouvez aussi exiger que l’utilisateur soit membre d’un certain domaine, ou encore contraindre la méthode d’authentification.
Quelles ressources sont accessibles?
La RAP, elle, filtre par groupe d’utilisateurs ET par groupe de machines. Exemple: le groupe « Comptables » ne pourra atteindre que le pool de sessions « Finance », alors que le groupe « IT » aura accès à toutes les machines. C’est ici qu’on évite qu’un stagiaire se retrouve sur le serveur de paie par erreur.
L’erreur classique du nouvel admin, c’est d’oublier de lier le compte ordinateur de la passerelle aux groupes nécessaires, ou de ne pas configurer les RAP pour les ressources internes. On se retrouve alors avec des connexions qui prennent fin sur un message « l’ordinateur distant n’est pas autorisé ». Les logs d’événements (Outils d’administration > Observateur d’événements > Services Bureau à distance) sont votre meilleur ami pour diagnostiquer ces blocages.
Certificat, TLS 1.2 et Kerberos: le tiercé gagnant pour une passerelle blindée
Une fois la mécanique CAP/RAP en place, penchons-nous sur la couche transport. En 2026, il n’est plus question d’accepter TLS 1.0 ou 1.1. Votre passerelle doit être configurée pour n’utiliser que TLS 1.2 (ou 1.3 si votre version d’IIS le permet). Le paramétrage se fait via la base de registre sur les clés SCHANNEL ou via un outil comme IISCrypto.
L’authentification Network Level Authentication (NLA) est obligatoire sur la plupart des déploiements récents. Elle a l’avantage de vérifier les crédentiels avant même d’établir une session complète, ce qui réduit la surface d’attaque. Du côté Kerberos, la passerelle peut déléguer l’authentification pour que l’utilisateur ne subisse pas de double demande de mot de passe lorsqu’il franchit le cap du Gateway vers l’hôte de session. Cela suppose un SPN (Service Principal Name) correctement configuré et une confiance du domaine pour la délégation. Si le paramétrage est bancal, vous verrez apparaître des erreurs « CredSSP » qui vous forceront à appliquer le correctif d’oracle remediation, en clair, à mettre à jour vos clients et serveurs.
Un autre point rarement évoqué: la personnalisation des fichiers RDP distribués via le portail Web. Vous pouvez contrôler la redirection des périphériques (imprimantes, presse-papiers, disques) pour éviter les fuites de données. Combinez ça avec une autorité de certification interne et des politiques de groupe qui imposent le certificat aux clients, et vous obtenez une chaîne de confiance vraiment robuste.
Dépannage: les 5 erreurs qui vous attendent la première fois
Aucune installation de RD Gateway ne se passe sans un minimum de grincements. Voici les principaux coupables, et la logique pour les résoudre.
Le certificat n’est pas approuvé. Le client RDP rejette la connexion avec une alerte de sécurité. La cause est simple: le poste client ne fait pas confiance à l’autorité de certification qui a émis le certificat de la passerelle. La solution consiste à importer le certificat racine de votre PKI dans le magasin « Autorités de certification racines de confiance » du poste, ou à utiliser un certificat émis publiquement.
Erreur CredSSP: Oracle Remediation. Ce message cryptique apparaît quand le serveur et le client ne négocient pas la même version du protocole CredSSP, souvent après une mise à jour de sécurité. La correction exige d’appliquer les dernières mises à jour des deux côtés et, éventuellement, d’ajuster une clé de registre AllowEncryptionOracle.
Échec d’authentification. Le serveur Gateway refuse la connexion après avoir validé le certificat. Vérifiez les paramètres NLA et assurez-vous que le compte utilisateur fait bien partie des groupes spécifiés dans la CAP.
Résolution DNS interne. Le client RDP configure souvent « passerelle RD » avec une URL publique, mais l’hôte de session est désigné par son nom NetBIOS ou FQDN interne. Si la résolution DNS ne fonctionne pas depuis le serveur Gateway lui-même, la redirection échoue. Testez toujours un nslookup nominterne depuis la passerelle.
Journaux muets. Si la passerelle ne logue rien d’utile, activez le journal analytique via PowerShell avec Get-WinEvent ou le canal « Microsoft-Windows-TerminalServices-Gateway/Operational ». Vous y découvrirez souvent l’erreur exacte que le client ne vous montre pas.
RD Gateway vs VPN, Azure Virtual Desktop: pourquoi la passerelle tient encore la route
À l’heure où Microsoft pousse Azure Virtual Desktop (AVD) comme alternative native cloud, et où n’importe quel boîtier grand public sait monter un VPN en deux clics, est-ce encore rationnel de déployer une passerelle RD Gateway on-premises en 2026?
La réponse, comme souvent en infra, dépend de votre existant et de vos contraintes de latence. RD Gateway s’intègre directement à un domaine Active Directory local, sans consommation de crédit Azure ni frais récurrents. Pour une PME qui détient déjà ses serveurs, ses licences Windows Server et un parc de postes en RDS, le coût marginal est quasi nul. En revanche, elle hérite de la responsabilité de maintenir la sécurité, les mises à jour et la disponibilité de l’infrastructure physique.
Azure Virtual Desktop déporte cette charge, apporte une évolutivité automatique et une intégration native à Azure AD avec authentification moderne (OpenID Connect), ce que RD Gateway ne maîtrise qu’avec des contournements basés sur une fédération AD FS. Mais AVD suppose une connectivité Internet fiable en permanence et accepte mal les applications héritées qui exigent un accès direct au réseau local en couche 2.
Le VPN, enfin, ouvre un tuyau réseau complet: une fois connecté, le collaborateur peut accéder à tout le LAN, pas seulement à son bureau à distance. Cela peut poser un problème de surface d’attaque si son poste n’est pas maîtrisé. RD Gateway limite strictement l’accès aux ressources RDS autorisées.
La vidéo suivante illustre cette tension architecturale avec un argumentaire détaillé de Microsoft en faveur d’AVD, à connaître pour sortir des discours marketing.
Quand choisir RD Gateway aujourd’hui? C’est un bon pari si vous avez un parc significatif de serveurs de sessions Windows, des compétences internes pour administrer un domaine, et que vous voulez garder la main sur les données et la latence. Dans ce contexte, la passerelle reste un outil fiable, éprouvé et largement documenté, même si elle exige une hygiène de configuration que nombre d’entreprises négligent.
Questions fréquentes
RD Gateway fonctionne-t-il avec des clients autres que Windows?
Oui. Le protocole RDP est implémenté dans le client Bureau à distance pour macOS, iOS et Android. La passerelle étant standard, ces clients savent négocier un tunnel HTTPS vers elle. En revanche, certaines options avancées comme la redirection de carte à puce peuvent être limitées selon la plateforme.
Faut-il absolument un certificat payant pour RD Gateway?
Pas nécessairement. Un certificat auto-signé fonctionne techniquement, mais chaque poste client doit alors l’importer et lui faire confiance. Pour un homelab ou un test, c’est acceptable. Pour des utilisateurs finaux, investir dans un certificat d’une autorité reconnue évite des appels récurrents au support. Une PKI interne avec une racine d’entreprise bien déployée fait aussi l’affaire.
Peut-on utiliser RD Gateway sans domaine Active Directory?
La question revient souvent, notamment dans les communautés comme Spiceworks. La réponse courte est non, pas de manière officielle. Même si des projets open source tentent de contourner cette limitation, le rôle RD Gateway de Microsoft exige un domaine pour valider les politiques CAP et RAP. Un serveur en workgroup ne suffit pas.
RD Gateway est-il compatible avec des solutions tierces comme TSplus ou Citrix?
Ces solutions ont généralement leur propre mécanisme de gateway. La passerelle RD Gateway native de Microsoft ne s’intercale pas automatiquement avec ces produits, sauf si ces derniers utilisent le protocole RDP standard et passent par la même pile d’authentification. Dans la pratique, mieux vaut opter pour le composant d’accès distant proposé par l’éditeur tiers si vous utilisez leur hyperviseur de sessions.
Votre recommandation sur rd gateway en 2026
Trois questions pour optimiser l'entretien et le matériel de votre bassin.
Merci, voici notre conseil personnalisé sur rd gateway en 2026.
D'après vos réponses, le mieux est de reprendre l'article ci-dessus en focalisant sur les passages qui parlent de votre situation : c'est là que se trouvent les recommandations les plus concrètes pour vous. Bonne lecture !
