Remote Desktop Service¶

Principe du protocole¶

Nous utilisons hyperV pour faire du maquettage.

Cette maquette utilise:

• un serveur de domaine, DHCP nommée DC08R2

  • IP 192.168.255.0
  • domaine LABS
  • Administrateur: Admin , password Pa$$0rd

• un serveur WS08R2

• un client XP

• un client Windows 7

le protocole est le Remote Desktop Protocol (RDP)

la bande passante est de 20kb /s pour un affichage déporté standard

On a toujours une session console. On a deux sessions Administrateur gratuite

Il faut pour une utilisation client:

• licence windows 2008 R2 par serveur
• licence CAL RDS par user
• licence CAL par user (car connexion au domaine et utilisation du réseau)
• licence par user pour les applicatifs contenus sur le serveur

Le NLA nécessite le client RDP 6.1. NLA permet de gérer une authentification globale sur le réseau. Cela est difficile à mettre en place sur XP.

L’objectif de NLA est:

• autentifier le serveur par le poste client en SSL
• authentifier l’utilisateur pour ouvrir une session
• pour faire du SSO (une seule identification à l’ouverture de la session du poste client)

Le serveur RDP¶

sous 2008 on peut avoir deux sessions administrateurs en simultanée (la console 0 fait partie des deux)

sur un poste classique (version =< 2003) on active ou pas le bureau à distance sur les postes (version >= 2008 R2) on active ou pas le bureau à distance et l’utilisation ou pas de NLA

... attention:

sur les postes verison >= NT6 il faut activer l'autorisation de l'utilisation du NLA ou pas

si on active l’obligation de l’utilisation de NLA sur un 2008 (ou 7) ... il ne sera possible de ce connecter dessus avec un client 6 (client RDP de XP)

Quand on fait du NLA on a pas une mire de login mais cette fenêtre de sécurité

Le NLA cherche à valider l’authentification avant la connexion au serveur TS (contrairement au mode non NLA)

donc si on veut ce connecter sur un serveur il faut:

• activer la prise à distance (NLA ou pas)
• autoriser les utilisateurs de l’AD pouvant prendre la main (ou ajouter les utilisateur dans le groupe local “utilisateur du bureau à distance”)
• lancer le client RDP (attention à la version si on autorise que le NLA sur le serveur)

Le client RDP¶

avec le client 6 pour ce connecté en console il faut faire un /admin

Le mode DRAIN

il est possible lors des phases de maintenance de bloquer les connexions (sauf /admin): mode “Drain”

On peut passer en mode drain en console (sur le serveur TS)

CHANGE LOGON /DRAIN

pour le réactiver

CHANGE LOGON /ENABLE

pour une réactivation automatique au reboot

CHANGE LOGON /DRAINUNTIRESTART

Il existe des outils de contrôle de base des éléments RDP

le fichier rdp représente une configuration de connexion (enregistrer sous sur le client TS)

il est aussi possible d’utiliser uniquement la commande mstsc avec des paramètres (mais on peut enregistre ces paramètres dans le fichier rdp)

le rôle RDS (service et rôle)¶

un rôle est un ensemble de chose qu’on peut sélectionner

le gestionnaire de rôle est accessible via le gestionnaire de serveur

il faut que le futur serveur TS soit dans le domaine avec une adresse IP fixe

on ce connecte par la suite comme administrateur du domaine (et non l’administrateur local)

maintenant on lance le gestionnaire de serveur et on ajoute le rôle “bureau à distance”

on peut imposer on non NLA

on gère plus tard la gestion des licences

on identifie qui a le droit de ce connecter (içi tout les utilisateurs de domaine)

sur le contrôleur de domaine ou prépare des OU et des utilisateurs

(rds = serveur RDS)

on intègre des postes (déjà présent dans l’AD) dans notre OU

sur WIN7 on ce connecte avec test1

par défaut comme je suis sur win7 , il utilise le NLA par défaut

cela est très long !!!!et le sso ne fonctionnera jamais car très long

Avec un client XP cela va super vite !!!

Cela provient du lien NLA et SSL. Le NLA utilise le SSL et donc l’utilisation des certificats.

pour rappel : le NLA valide l’authentification (cf plus haut)

Hors on a pas encore géré les certificats du serveur RDS1.

pour ajouter un certificat: lancer une console mmc et ajouter le composant certificats / un compte d’ordinateur

notre certificat généré par défaut pose à priori soucis (on ne fait pas confiance à nous même)

qu’est ce qu’un certificat¶

Un certificat est emis pour un nom DNS ou une adresse IP , une machine n’a pas le même certificat pour son Nom ou pour son adresse IP.

Note

ici le SSL qui permet de crypter des données, ne crypte que l’authentification le protocole RDP est déjà crypté

un certificat est emis et délivré par une autorité de certification (AC)

On peut avoir des certificat autosigné (sans passer par une AC)

1 AC a pour but de vérifier que celui qui demande le certificat est bien celui qui prêtant être. A AC est un tiers de confiance.

Attention

un certificat à une date de validité, il faut donc le renouveler régulièrement

Un AC doit être dans la configuration des autorités de confiance

retour au rds¶

il faudrait que nous fassions confiance à rds1.labs.local pour que le certificat ne pose pas de problème sur le client.

sinon il faut faire un nouveau certificat.

solution1: modifier le certificat actuel

• exporter le certificat du serveur rds1

• récupérer le certificat du serveur rds1 sur le poste client WIN7
• sur le poste WIN7 (en administrateur!!!) , il faut lancer une console cmd en administrateur, lancer mmc et ajouter le composant certificats / un compte d’ordinateur pour ajouter le certificat comme certificat de confiance

comme le certificat est emis pour rds1.labs.local je lance mon client RDP avec pour cible rds1.labs.local

et la cela fonctionne et de facon rapide

Note

on fait un certificat pour un ordinateur et non utilisateur car on identifie les machines avec le SSL pas les utilisateurs le NLA s’occupe des utilisateurs

Note

on peut mettre un certificat par GPO

L’objectif de cette solution est que le client WIN7 considère le certificat du serveur comme un certificat de confiance

Il est possible de déactiver le NLA côté serveur, en modifiant la couche de sécurité (prendre RDP classique)

solution2: générer un nouveau certificat

l’objectif est de prendre une autorité de confiance ... et pour cela on va créer notre autorité

L’autorité est un rôle windows. Il existe le mode:

• entreprise
• autonome

On prend le mode entreprise: comme cela toute la forêt aura confiance dans cette autorité (on peut avoir sur une forêt plusieurs autorité)

En générale on l’installe sur une machine dédié ou sur le controleur de domaine

• lancer le gestionnaire de serveur
• ajouter un role de certificat d’active directory

laisser les élements par défaut

pour le nom commun ne pas utiliser de caractères spéciaux

Note

une AC ne donne pas de certificat ayant une validité supérieur à la sienne ... donc mettez 100 ans

pour que l’AC soit visible par les serveurs il faut attendre 48h ... (il n’y a pas de commande cmd)

si on est presser il faut redémarrer dans l’ordre:

• AC (= AD chez nous)
• AD
• client

on peut vérifier que l’AC est bon, sur le serveur qui comporte l’AC, dans le gestionnaire de serveur on peut le voir

maintenant il faut créer le certificat pour le RDS

sur le RDS1 , il faut lancer une console cmd en administrateur, lancer mmc et ajouter le composant certificats / un compte d’ordinateur pour ajouter le certificat comme certificat de confiance

et on voir notre AC sur notre serveur RDS1

sous un client win7 on peut utiliser les options IE pour voir si l’AC apparait

on va demander sur RDS un nouveau certificat

on a un certificat valable 1 an !!!

on peut faire des demandes automatique de renouvellement (via GP)

on indique maintenant que le service RDS utilise ce nouveau certificat

maintenant sur notre client WIN7, la connexion RDS1 est rapide

Gestionnaire de licence¶

Pour l’instant nous n’avons pas de licence ce qui pose problème au bout de 120 jours

Il faut activer le serveur de licence

Nous avons donc deux serveurs:

• un serveur RDS
• un serveur de licence

Il existe deux modes de licences:

• par user
• par périphérique

en cas de dépassement de nombre de personne par rapport notre nombre de licence on rentre dans un temporaire de 120j.

un absence de connexion pendant 120 jours fait que la licence lié à cet utilisateur redevient disponible.

Nous allons le service de licence sur le controleur de domaine.

Il s’agit d’un élements du rôle bureau à distance

suite à l’installation, il faut activer ce serveur via internet (au bout de 120 jours il tombe).

notre serveur de licence fonctionne

on peut maintenant ajouter nos licences

maintenant il faut lie le serveur RDS avec le serveur de licence

sur le serveur RDS

on double clic

on redémarre le serveur RDS pour bien prendre en compte le serveur de licence

Configuration RDS / TS¶

ne pas installer

• un RDS sur serveur un active directory
• de logiciel avant le rôle RDS

sur le serveur RDS il faut ajouter dans le groupe local “utilisateur de Bureau à distance” les utilisateurs autorisés à utiliser les connexion RDP (=client RDS)

les outils de gestion sont

Les onglets de la propriété RDP-Tcp nommé Environnement et Paramètres d’ouverture de session ne sert plus à rien

On trouve dans la propriété RDP-Tcp la gestions:

• des temps d’inactivité ou d’activité de sessions (inactivité correspond à aucune modification écran, animation clavier ou souris, une page IE avec un logo qui tourne cela n’est jamais inactif )
• paramètre de client (limitations des paramètre du client, quelques soient les infos du client) (lecteur local, imprimante, nombre d’écran, ...)
• normalement on ne touche pas
• contrôle à distance: permet à un administrateur (ou autre) avec une session RDS de prendre la main sur une session RDS d’un autre utilisateur (pour faire de l’observation ou du controle à distance)

le contrôle à distance ce fait par l’outil gestionnaire de bureau à distance

On peut accorder le droit de crontrôle à distance

Dans un système 64bits on a 2 dossiers important:

• system32 (contient les prg 64 bits)
• syswow64 (contient les prg 32 bits)

il existe deux config odbc: 32 et 64 bits

si on a une appli 32 bit il faut configurer l’odbc 32 bits (par défaut c’est le 64 bits qui est lancé)

le configurateur odbc 32 bit est dans syswow64

cette duplicité 32b / 64b existe aussi pour la base registre. Il existe

• regedit 32b
• regedit 64b

Il existe dans le regedit 64 , un noeud wow6432Node

Quand je lance le regedit 32, je ne vois que le contenu du wow6432Node du regedit 64

Exploitation¶

un outil principal

pour les fermes, il est possible de faire des groupes

Le SSO permet d’éviter des identifications multiples.

Pour faire du SSO il faut

• du NLA (et donc du SSL) au niveau serveur
• une configuration du client

le SSO ce configure via une GPO sur le client (GPO pouvant être distribué par l’Active directory)

ajout de la GP sur l’AD

tout les postes compris dans cours / postes auront cette GP

si je me connecte maintenant il ne me demande plus mon user / password (mais prend celui de la session)

cela fonctionne simplement sur des clients WIN7.

Pour un client XP sp3, il faut:

• activer CredSSP
• installation HotFix
• activer la délégation d’auth via une GPO

On peut aussi mettre en place une SSO sur les clients web

Il est possible via un GPO de bloquer:

• accès au panneau de configuration
• masqué les lecteurs (ex A,B,C,D correspondant aux lecteur locaux)
• supprimer les outils d’administration
• ...

Pour cela on génère sur le serveur AD une nouvelle GP nommée FiltreTS

Il s’agit d’une GP config utilisateur qu’il faut relier à l’utilisateur

on supprime le lien GP / groupe user

on lie la GP aux serveur RDS

mais on a pas d’utilisateur dans le groupe rds mais que des serveur RDS.

Il faut faire une “boucle de rappel” qui permet de dire: tout utilisateurs qui ce connecte sur l’ordinateur sur lequel il y a la GPO ce voit appliquer la GPO

Pour mettre en place cette boucle de rappel il faut modifier la GPO

donc cette GPO est appliquer que sur le groupe RDS qui ne contient que des serveurs, mais elle appliquera (en fusion ou en remplacement) la gestion de l’utilisateur

j’ai donc au niveau des GPO cette architecture

et je ne vois plus les lecteurs sur ma session ts

mais je les vois en local

donc pour modifier ce comportement on va dire que la GP n’est pas appliqué pour les utilisateurs admin

et maintenant quand on ce connecte en TS sur le serveur TS avec un compte admin on voit les lecteurs (comportement souhaité)

On peut gérer par GPO le menu démarrer

Il existe une stratégie pour le chemin de profil utilisateur

cette notion de profils itinérants est important dans le cas de ferme TS.

cela permet d’avoir le même profil (et donc la même configuration) quelques soient le serveur TS utilisé

Virtualisation des adresses IP¶

Si on utilise un outil qui identifie les clients suivant les adresses IP des clients, l’utilisation sous session TSE pose problème (puisque n sessions avec la même adresse IP) la virtualisation des adresses IP permet de fournir pour chaque session une adresse IP différentes

Les impressions¶

la gestion des impressions sous windows fonctionne ainsi:

• une appli (app.exe) génère un fichier EMF à imprimer (décrit l’impression)
• ce fichier est envoyé à un spooler
• un pilote d’impressions prend le fichier EMF et le transforme en RAW ou PS
• le pilote envoi à l’imprimante le fichier RAW ou PS (imprimante locale ou réseau)

Le format EMF est beaucoup plus compressé que le format RAW

Une imprimante locale peut être sur le réseau (port TCP/IP)

Une imprimante réseau est un imprimante qui est connecté sur un serveur (souvent contenu dans l’imprimante et donc caché)

Un serveur RDS possède:

• 1 session
• un spooler avec des pilotes

quand dans la session 1 j’utilise app.exe pour imprimer j’envoie un EMF envoyé au spoller du RDS qui le transforme en RAW. ce fichier RAW est envoyé sur le réseau à l’imprimante réseau .

Je fais donc transféré sur le réseau un fichier raw

schema d’impression sur une imprimante locale du client ou serveur d’impression ou imprimante connecté au serveur

Il est possible vi aun client easy print (installé sur le client) d’échanger entre le client et le serveur RDS non pas un RAW mais un fichier XPS. Un Xps est un fichier PDF made in microsoft qui permet sur le client easy print de regénérer un EMF qui sera envoyé sur le spoll du client local

le but de easy print est d’utiliser les imprimantes locales du postes

Note

pour voir les imprimantes locales sur la session RDS il faut l’autoriser, mais seul le format XPS est compréssé

Note

easy print existe en standard sous win7, sous XP il faut ajouter un easy print

il existe des GPO pour gérer easyprint

Il existe des outils tiers permettant d’optimiser les flux d’impression

• ThinPrint: fait transferer de l’EMF compressé, nécessite un un client ThinPrint et un serveur (gestion QOS possible)
• ...

Il est possible d’utiliser des serveurs d’impressions. L’imprimante est connecté sur un serveur. On peut utiliser des GPO pour installer dans la session RDS les imprimantes du serveur d’impressions

le lien entre session RDS et serveur d’imprimante est peut être un format RAW ... donc cela pose problème

Attention

voir comment résoudre ce problème pour VI en sachant qu’on va avoir des clients légers (donc pas de XPS) voir si wize peut gérer le XPS

Environnement Applicatif¶

Pour installer un outil il faut:

• Personne sur le serveur
• passer en mode installation
• installer selon les procédure spécifique TS
• lancer une première fois l’appli (certaines applis terminent leurs installations au premier lancement)
• sortir du mode installation
• rebooter si besoin
• tester (avec deux utilisateurs utilisant le soft en même temps)

pour passer en mode installe on utilise la commande change

si on lance le msi, un fichier install.exe, le mode install est lancer automatiquement

Pour rendre disponible une application on peut faire une RemoteApp

il est possible de générer un fichier rdp de cette AppRemote permettant de lancer cette remoteApp

(il faudra déployer ce fichier rdp sur chaque client)

(pour l’instant on ne touche a rien)

quand sur un client win7 on lance le rdp , on obtient après un ou deux messages de warning une fenêtre correspondant à notre application (on rend le bureau invisible)

Si on a plusieurs AppRemote de lancer pour un utilisateur sur un serveur RDS, on a par utilisateurs qu’une session (plusieurs remoteApp dans une même session)

Par contre un utilisateur peut avoir:

• une session classique RDS
• une session pour les remoteApp

On peut lancer les remoteApp dans une session d’un serveur RDS

On peut aussi générer des msi pour déployer ces RemoteApp. On peut ensuite déployer ce msi par GPO.

Avec un msi, on peut lier une extension avec une remoteApp. Par exemple je met Acrobate Reader comme remoteApp déployer par msi. Sur le client, le double clic sur tutu.pdf lance la remoteApp Acrobate Reader

Le msi nécessite comme même le client RDP 6.1

On peut manager les sessions de remoteApp (presse papier, signature, ...)

Pour ne pas avoir les warning de sécurité des AppRemote, il faut signer les remoteApp

lors de la creation du rdp il faut aller chercher le certificat

on obtient un message qui fait moins peur, mais on a toujours un message

On peut supprimer le message en utilisant une GPO qui s’applique sur le poste client (donc chez nous la GPO SSO par exemple)

Il est possible de déployer une remoteApp sur le portail Web (on peut affecter des utilisateurs à la remoteApp)

il faut installer le service “accès à bureau à distance via le web” du rôle service TS (le rôle IIS sera installer en même temps)

Ce service ne doit pas forcement installer sur le serveur RDS

le lien web est par exemple https://DC08R2/RDWeb

Il faut ajouter sur le serveur RDS dans le groupe”ordinateur de l’accès web” le serveur portant IIS

Il faut maintenant dire au portail web que les remoteApp sont portés par le serveur RDS (avec le filtre utilisateur)

Sur le serveur portant l’IIS

le site web est maintenant utilisable pour tout les clients avec l’adresse https://DC08R2/RDWeb

mais on ne gère pas de SSO

Le serveur web permet seulement de télécharger un fichier rdp qui est lancer sur le poste client.

Cela impose que le client qui utilise le serveur web possède un client RDP et utilise IE.

Pour afficher un bureau dans le serveur web il faut modifier sur le serveur RDS le gestionnaire App

On peut supprimer une demande d’authentification en ajoutant toujours une signature à nos AppRemote

IIS nous demande une authentification ... il s’agit d’un problème de SSO IIS. Sur le serveur IIS

devient

sur le IE du cleint on a

il faut donc ajouter notre IIS comme intranet

pour le certificat il faut un créer un et modifier les liaisons du site