Aller au contenu

(Cours/TP) Windows Server - Remote Desktop Services

Cet atelier vous permet de déployer et de configurer les services de Bureau à distance (RDS) sur un serveur Windows Server. L’objectif est de fournir des bureaux ou des applications à distance aux utilisateurs en s’appuyant sur un contrôleur de domaine AD.

Présentation : RDS/RDP ?

Le service RDS (Remote Desktop Services) ou services de Bureau à distance repose sur un modèle client léger où la majorité des traitements, ressources et applications s’exécutent directement sur le serveur. Les utilisateurs y accèdent via une simple session distante (protocole RDP) plutôt que d’installer et d’exécuter chaque logiciel localement sur leur poste.

Modèle client lourd vs client léger

Client lourd :

  • Les applications sont installées et exécutées sur chaque poste de travail.

  • Les ressources matérielles (CPU, RAM, stockage) du poste de travail conditionnent les performances de l’application.

  • Les mises à jour et la maintenance doivent être effectuées individuellement sur chaque poste.

  • L’infrastructure est décentralisée : chaque ordinateur est relativement autonome.

Client léger :

  • Les applications sont installées, configurées et exécutées principalement sur les serveurs.

  • Les postes de travail peuvent être de simples terminaux (peu puissants) puisqu’ils ne font que déporter l’affichage et la saisie vers le serveur.

  • La gestion se fait à un seul endroit (le serveur). Ce qui simplifie le support et les mises à jour.

  • L’infrastructure est centralisée : le serveur RDS mutualise la puissance et les ressources. Il envoie uniquement l’interface d’affichage aux utilisateurs.

Le protocole RDP

Pour établir la connexion entre le serveur RDS et le poste client, Microsoft utilise le protocole RDP (Remote Desktop Protocol). Celui-ci se charge de :

  • Transmettre l’affichage graphique et le son du serveur vers le client (Outpout).

  • Récupérer les entrées clavier/souris du client pour les renvoyer vers le serveur (Input).

  • Gérer la redirection d’imprimantes, de disques locaux, de presse-papiers, etc.

Le RDP est donc un protocole optimisé pour le bureau à distance. Il compresse et encode les flux graphiques pour limiter la consommation de bande passante tout en offrant de nombreuses fonctionnalités de redirection (périphériques, audio, etc.).

Échanges de flux dans le cas du client léger RDS

  • Input : Les périphériques d’entrée (clavier, souris) envoient leurs interactions au serveur à travers le réseau via le protocole RDP.

  • Outpout : Le protocole RDP renvoie vers le poste client l’affichage (vidéo) et le son.

  • Les fichiers et les données demeurent centralisés sur le serveur, réduisant les besoins en stockage local et en puissance de calcul côté client.

Avantages du client léger RDS

1) Réduction des coûts

  • Matériel : les postes clients peuvent être moins coûteux et durent plus longtemps (ils n’ont pas besoin d’être très puissants).

  • Maintenance : une seule installation centralisée au lieu de déployer une application sur chaque poste.

  • Énergie : un poste client léger consomme moins d’électricité qu’un PC classique.

2) Meilleure qualité de service

  • Les mises à jour et correctifs sont gérés depuis un point unique (le serveur).

  • Le support technique est simplifié (pas besoin d’intervenir physiquement sur chaque poste).

3) Réponse à des contraintes spécifiques

  • Dans certains environnements (sites distants, milieux hostiles, réseau limité...), le modèle client lourd peut être difficile à administrer.

  • RDS via RDP offre un environnement complet accessible via une simple liaison réseau.

4) Sécurité renforcée

  • Les données sont stockées et traitées sur le serveur, limitant ainsi le risque de fuite, de corruption ou de vol de données en local.

  • Les postes clients sont réduits à un rôle de terminaux, plus simples à sécuriser.

Limites d’une infrastructure centralisée

  • Criticité accrue du serveur : en cas de panne du serveur RDS ou du réseau, beaucoup d’utilisateurs sont impactés.

  • Dépendance réseau : un accès stable et fiable est nécessaire (latence, débits).

  • Cas d’usages non adaptés : applications très exigeantes en ressources locales (ex. logiciel de CAO) peuvent mal tolérer la latence.

  • Conduite du changement : il faut accompagner et former les utilisateurs à ce nouveau mode de fonctionnement.

En résumé, RDS et le protocole RDP permettent de mutualiser les ressources et de simplifier la gestion applicative, tout en réduisant les coûts matériels et la consommation énergétique. Cette approche client léger s’avère extrêmement avantageuse dans des environnements multi-utilisateurs ou lorsque l’on souhaite déployer rapidement des applications sur de nombreux postes. Toutefois, la centralisation entraîne des exigences plus fortes en matière de disponibilité réseau et de performance des serveurs.

TP

Prérequis

  • Un contrôleur de domaine déjà installé et fonctionnel (ADDS) avec une arborescence AD.

  • Un serveur Windows Server (Standard ou Datacenter) à jour, membre du domaine, sur lequel on installera les rôles RDS.

  • Un poste client Windows 10/11 pour tester la connexion RDS.

Maquette

Nom du serveur Rôle OS Réseau
srv-rds-01 Contrôleur de domaine + RDS Windows Server dernière verwion Interne
cli-w10-001 Poste client Windows 10/11 Interne

Note : On combine les rôles (ADDS et RDS) sur un même serveur pour économiser des ressources dans votre lab mais il est recommandé de séparer les rôles.

1. Préparer le serveur

1) Mettre en réseau votre serveur Windows (Windows Update).

2) Active Directory : rejoindre le domaine existant ou créer une nouvelle forêt AD si le serveur RDS n’est pas déjà contrôleur de domaine.

3) Installer les éventuelles applications à publier (ex. Libre Office).

4) Vérifier que le pare-feu autorise les connexions RDP (3389).

Attention au port 3389 !

RDP utilise le port 3389 par défaut qui est très souvent attaqué sur Internet. Si vous devez exposer votre RDS à l’extérieur, il est vivement conseillé de changer ce port ou mieux de passer par un VPN ou un bastion (voir dans la partie "Conclusion") afin de limiter drastiquement les tentatives de connexions malveillantes.

2. Installer et configurer les services de Bureau à distance (RDS)

Sous Windows Server, le rôle RDS se décompose en 6 services de rôle. Chacun de ces rôles peut être installé sur un serveur unique (déploiement basique) ou réparti sur plusieurs serveurs pour une meilleure charge et disponibilité.

Les 6 services de rôle et les licences RDS

Services de rôle

  • RD Session Host (RDSH) : Héberge les bureaux ou applications que les utilisateurs exécutent à distance.

  • RD Web Access (RDWA) : Fournit une interface web pour accéder aux applications et bureaux publiés.

  • RD Connection Broker (RDCB) : Gère la répartition de charge et la reconnexion des sessions déconnectées.

  • RD Licensing (RDL) : Gère les licences RDS et s’assure que chaque utilisateur/équipement est autorisé.

  • RD Gateway (RDG) : Permet d’accéder aux ressources RDS via une passerelle HTTPS en sécurisant les connexions depuis Internet sans exposer directement le port RDP.

  • RD Virtualization Host (RDVH) : Gère les machines virtuelles pour les déploiements de type VDI (Virtual Desktop Infrastructure).

Pour un déploiement RDS basé sur des sessions (bureaux ou applications) et conforme aux bonnes pratiques, vous avez besoin a minima des rôles suivants : RD Session Host (RDSH), RD Connection Broker (RDCB) et RD Licensing (RDL).

Licences et les CAL RDS

Les CAL RDS (Client Access Licenses) sont des licences obligatoires permettant aux utilisateurs ou aux appareils d’accéder aux services Bureau à distance (RDS) sur un serveur Windows. Sans ces licences, l’accès aux sessions RDS sera bloqué après la période de grâce de 120 jours.

  • CAL par utilisateur : Associée à un compte Active Directory, elle permet à un utilisateur de se connecter depuis plusieurs appareils.

  • CAL par appareil : Associée à un poste de travail spécifique, elle permet à plusieurs utilisateurs de se connecter depuis cette machine.

  • Un serveur RD Licensing (RDL) est requis pour distribuer et gérer les CAL.

  • Les CAL ne sont pas incluses avec le rôle RDS et doivent être achetées séparément.

  • Il est crucial de choisir le bon type de CAL en fonction du mode d’utilisation (appareils partagés ou utilisateurs nomades).

Pour un déploiement basique sur un seul serveur :

1) Ouvrez le Gestionnaire de serveur.

2) Cliquez sur Ajouter des rôles et fonctionnalités.

3) Sélectionnez Installation des services Bureau à distance.

4) Sélectionnez le type de déploiement : Standard (Déploiement classique).

5) Sélectionnez le scénario : Déploiement de bureaux basés sur une session (les utilisateurs obtiennent un bureau complet ou des applications publiées).

6) Sélectionnez les services de rôle Sesion Host, Connection Broker et Web Access à installer sur le serveur.

7) Indiquez le serveur qui hébergera ces rôles.

8) Poursuivre l’assistant jusqu’à la fin puis redémarrez si nécessaire.

À l’issue de l’installation, vous disposez d’un environnement RDS minimal :

  • Session Host : permet d’héberger des sessions Bureau à distance ou RemoteApp.

  • Connection Broker : gère la répartition et la reconnexion des sessions.

  • Web Access : portail pour accéder aux applications distantes (RDWeb).

3. Créer une collection RDS et configurer les accès

1) Dans le Gestionnaire de serveur, cliquez sur Services Bureau à distance.

2) Sélectionnez Collections puis Tâches et Créer une collection de session.

3) Attribuez un Nom à votre collection (ex. "Collection-Direction").

4) Sélectionnez votre serveur dans la section Serveur hôte de session...

5) Définissez quel Groupe d’utilisateurs pourra ouvrir des sessions (ex. uniquement le Groupe Global "GG-Direction").

6) N'activez pas les disques de profil utilisateur dans ce cas où vous n'avez qu'un serveur hôte.

Vous disposez désormais d’une collection RDS à laquelle les utilisateurs autorisés peuvent se connecter en Bureau à distance ou via le Portail Web.

Autorisations

Les autorisations de base s’appliquent au niveau de la collection. Cela signifie que pour accorder des droits d’accès Bureau à distance différents à plusieurs groupes ou utilisateurs, vous devrez généralement créer autant de collections que nécessaire.

En pratique :

  • Si vous souhaitez uniquement autoriser ou refuser l’accès à une collection pour certains utilisateurs, vous devez gérer ces autorisations au niveau de la collection (et potentiellement créer plusieurs collections pour les séparer).

  • En revanche, si vous avez une seule collection et que vous désirez contrôler l’accès à plusieurs RemoteApps différentes pour divers groupes d’utilisateurs, vous pouvez le faire directement sur chaque RemoteApp, sans avoir besoin de créer de nouvelles collections.

4. Tester la connexion RDP depuis un poste client

1) Sur le poste client Windows : Ouvrez le cient Bureau à distance (mstsc.exe) > Entrez le nom ou l’IP du serveur RDS (srv-rds-01) > Utilisez un compte membre du groupe autorisé.

2) Vous devriez voir un bureau / une session s’ouvrir depuis le serveur RDS.

3) Testez avec un compte non autorisé pour valider que l’accès est refusé.

4) Activez la redirection du disque C : Ouvrez le client Bureau à distance (mstsc.exe). Cliquez sur Afficher les options > Ressources locales > Autres... > Développez Lecteurs et cochez Disque local (C:) et testez depuis la session Bureau à distance que le disque C du client apparaît dans l'explorateur Windows (ex. Disque local sur CLIENT-PC). Essayez d’accéder aux fichiers du disque redirigé pour valider le bon fonctionnement.

5. Publier des applications en RemoteApp

Plutôt que de fournir un Bureau complet, on peut seulement publier des applications :

1) Depuis le Gestionnaire de serveur > Services Bureau à distance > Collections.

2) Cliquez sur votre Collection (ex. "Collection-Direction").

3) Dans la section Programmes RemoteApp, cliquez sur Publier des programmes RemoteApp.

4) Sélectionnez les applications installées sur le serveur que vous souhaitez rendre acessibles (ex. LibreOffice Writer)

5) Validez et refermez l’assistant.

Pour y accéder, deux options :

  • Portail Web https://FQDN_du_serveur/RDweb : on retrouve les RemoteApps publiées.

  • Fichier RDP exporté : l’utilisateur lance l’application à distance depuis un raccourci sur son poste.

6. Vérifier l’accès et les restrictions

1) Depuis le poste client, ouvrez un navigateur et tapez https://FQDN_du_serveur/RDweb.

2) Connectez-vous avec un compte membre de la Direction.

3) Vous devriez voir les RemoteApps (ex. LibreOffice Writer).

4) Lancez l’application à distance pour valider son bon fonctionnement.

5) Essayez avec un compte non autorisé, vous ne devriez pas accéder aux RemoteApps.

(Optionnel) Personnaliser la collection et le portail Web

  • Regrouper les applications dans un dossier (ex. "Bureautique").

  • Limiter l’accès à certaines applications en définissant les groupes ou utilisateurs concernés.

7. Administration complémentaire

  • Gérer les sessions depuis le Gestionnaire de serveur > Services Bureau à distance > Collections > Connexions.

  • Testez les fonctionnalités de gestion des connexions : Déconnexion / Envoyer un message / Cliché instantané / Fermer la session.

  • Surveiller les performances via des outils intégrés (Gestionnaire des tâches, Moniteur de ressources).

Vérification finale

1) Connexion RDP : Valider que les utilisateurs autorisés ouvrent une session distante.

2) RemoteApps : Vérifier que les applications se lancent correctement via le portail RDWeb.

3) Gestion des accès : Confirmer que seuls les membres autorisés peuvent se connecter.

Conclusion

Vous avez désormais un serveur RDS opérationnel qui fournit soit un bureau à distance complet, soit des applications publiées (RemoteApp) aux utilisateurs de votre domaine.

Cette infrastructure peut être étendue ou personnalisée pour mieux répondre à vos besoins. Par exemple, vous pouvez ajouter une passerelle RDS pour l’accès externe ou créer une ferme (cluster) de plusieurs serveur RDS pour de la haute disponibilité où mettre en oeuvre un bastion d'administration avec la solution open-source Teleport !

C'est quoi un bastion d'administration ?

Pour sécuriser et centraliser davantage l’accès à vos serveurs RDS, vous pouvez mettre en place un bastion d’administration comme Teleport.

Qu’est-ce qu’un bastion ?

C’est un serveur intermédiaire qui sert de « porte d’entrée » unique pour les connexions vers d’autres machines (Windows, Linux, etc.). Tous les accès RDP (ou SSH et autres protocoles pris en charge) passent alors par ce point central.

Pourquoi c’est utile ?

  • Sécurité : vous n’exposez qu’un seul serveur (le bastion) au réseau externe, limitant la surface d’attaque.

  • Audit : vous pouvez enregistrer et tracer les connexions pour savoir qui a fait quoi et quand.

  • Contrôle des accès : gestion simplifiée des permissions et renforcement de l’authentification (possible via SSO, MFA, etc.).

Est-ce applicable aux utilisateurs ?

  • Oui, si nécessaire : les utilisateurs peuvent se connecter d’abord au bastion puis accéder à leur session RDS.

  • Mais c'est surtout intéressant pour les administrateurs qui peuvent alors centraliser toutes les connexions RDP/SSH et tous les protocoles pris en charge.

En vulgarisant, un bastion Teleport est comme une porte d’immeuble équipée d’un interphone et d’un badge. Avant, vous aviez plein d’entrées possibles et il fallait gérer les clés pour chaque porte (chaque serveur). Maintenant, tous passent par une seule porte, on sait qui entre et quand et si besoin on peut couper l’accès d’un simple clic.

FIN ! 🥳

Références

Services Bureau à distance (RDS)

Déployer des bureaux basés sur une session

Bastion d'administration Teleport