Remote Desktop Service ********************** Formateur:Bruno Dubois Présent: * Société Floch (alimentaire) * Alizée (éditeur ERP) * Somatel Informatique * CHU Le mans * SSII Intro ===== 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 .. figure:: data/tseimg001.png le protocole est le Remote Desktop Protocol (RDP) la bande passante est de 20kb /s pour un affichage déporté standard .. attention:: la bande passante est augmenté en cas d'impression ou de copie de fichier en local. un poste avec deux écran hautes définition prend beaucoup plus de bande passante 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. .. note:: pour connaitre la version du client il faut le lancer et voir le "à propos de" .. attention: la version du client est très importante et peut engendrer des problèmes ou des différences d'utilisation comme le NLA 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) .. warning:: pour faire du SSO il faut autoriser le poste client pour en faire. Il est donc possible d'avoir une flotte de poste client hétérogène: une partie fait du SSO et pas l'autre (exemple poste prod: session client prod1, session ts: user1,user2 -> pas de SSO; poste service généraux: session client user3, session ts user3 -> SSO) 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 .. figure:: data/tseimg002.png 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é .. figure:: data/tseimg003.png 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) .. figure:: data/tseimg004.png .. figure:: data/tseimg005.png .. note:: il faut pour un controleur de domaine ajouter les utilisateurs ayant une autorisation de connexion sur gpedit avec "ouverture d'une session locale" et "ouverture d'un bureau à distance" Le client RDP ------------- avec le client 6 pour ce connecté en console il faut faire un /admin .. figure:: data/tseimg005.png .. note:: le /admin permet de ne pas consommer de licence !!! et des connexions en mode "drain" Le mode DRAIN il est possible lors des phases de maintenance de bloquer les connexions (sauf /admin): mode "Drain" .. figure:: data/tseimg007.png 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 .. figure:: data/tseimg009.png Il existe des outils de contrôle de base des éléments RDP .. figure:: data/tseimg008.png le fichier rdp représente une configuration de connexion (enregistrer sous sur le client TS) .. note:: le password n'est jamais dans le fichier rdp mais dans le coffre windows du poste local (gestionnaire de certificat) 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 .. figure:: data/tseimg010.png il faut que le futur serveur TS soit dans le domaine avec une adresse IP fixe .. figure:: data/tseimg011.png .. figure:: data/tseimg012.png 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" .. figure:: data/tseimg013.png .. figure:: data/tseimg014.png on peut imposer on non NLA .. figure:: data/tseimg015.png 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) .. figure:: data/tseimg016.png .. note:: on peut par la suite modifier qui a le droit de ce connecter via la modification du groupe Utilisateurs du Bureau à distance .. note:: la partie aero demande des performances atypique pour un serveur .. warning:: il est préférable de n'installer aucun soft avant la mise en place du service RDS !!! sur le contrôleur de domaine ou prépare des OU et des utilisateurs .. figure:: data/tseimg017.png .. figure:: data/tseimg018.png (rds = serveur RDS) .. figure:: data/tseimg019.png on intègre des postes (déjà présent dans l'AD) dans notre OU .. figure:: data/tseimg020.png sur WIN7 on ce connecte avec test1 par défaut comme je suis sur win7 , il utilise le NLA par défaut .. figure:: data/tseimg021.png 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. .. figure:: data/tseimg022.png .. figure:: data/tseimg023.png .. figure:: data/tseimg024.png pour ajouter un certificat: lancer une console *mmc* et ajouter le composant certificats / un compte d'ordinateur .. figure:: data/tseimg025.png .. figure:: data/tseimg026.png .. figure:: data/tseimg027.png 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 .. figure:: data/tseimg028.png Un AC doit être dans la configuration des autorités de confiance .. figure:: data/tseimg029.png 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 .. figure:: data/tseimg030.png * 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 .. figure:: data/tseimg025.png .. figure:: data/tseimg026.png .. figure:: data/tseimg031.png comme le certificat est emis pour rds1.labs.local je lance mon client RDP avec pour cible rds1.labs.local .. figure:: data/tseimg032.png 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) .. figure:: data/tseimg033.png *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 .. figure:: data/tseimg034.png .. figure:: data/tseimg035.png .. figure:: data/tseimg036.png .. figure:: data/tseimg037.png laisser les élements par défaut pour le nom commun ne pas utiliser de caractères spéciaux .. figure:: data/tseimg038.png .. figure:: data/tseimg039.png .. 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 .. figure:: data/tseimg040.png 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 .. figure:: data/tseimg025.png .. figure:: data/tseimg026.png et on voir notre AC sur notre serveur RDS1 .. figure:: data/tseimg041.png sous un client win7 on peut utiliser les options IE pour voir si l'AC apparait .. figure:: data/tseimg042.png on va demander sur RDS un nouveau certificat .. figure:: data/tseimg043.png .. figure:: data/tseimg044.png .. figure:: data/tseimg045.png on a un certificat valable 1 an !!! .. figure:: data/tseimg046.png on peut faire des demandes automatique de renouvellement (via GP) .. figure:: data/tseimg047.png on indique maintenant que le service RDS utilise ce nouveau certificat .. figure:: data/tseimg048.png .. figure:: data/tseimg049.png .. figure:: data/tseimg050.png maintenant sur notre client WIN7, la connexion RDS1 est rapide .. figure:: data/tseimg051.png Gestionnaire de licence ----------------------- Pour l'instant nous n'avons pas de licence ce qui pose problème au bout de 120 jours .. figure:: data/tseimg052.png Il faut activer le serveur de licence Nous avons donc deux serveurs: * un serveur RDS * un serveur de licence .. note:: prendre l'infrastructure p24 du document de cours 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 .. figure:: data/tseimg053.png .. figure:: data/tseimg054.png .. figure:: data/tseimg055.png .. figure:: data/tseimg056.png .. figure:: data/tseimg057.png suite à l'installation, il faut activer ce serveur via internet (au bout de 120 jours il tombe). .. figure:: data/tseimg058.png .. figure:: data/tseimg059.png .. figure:: data/tseimg060.png notre serveur de licence fonctionne on peut maintenant ajouter nos licences .. figure:: data/tseimg061.png .. attention:: le serveur de licence doit être du même niveau que le serveur RDS (RDS sur 2008R2 -> serveur de licence 2008R2) mais on peut trouver sur un serveur de licence 2008R2 des licences 2003 .. warning:: sous 2003 il y a un bug qui fait que le controleur de licence ne compte pas les 2003 maintenant il faut lie le serveur RDS avec le serveur de licence sur le serveur RDS .. figure:: data/tseimg062.png on double clic .. figure:: data/tseimg063.png 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) .. figure:: data/tseimg064.png les outils de gestion sont .. figure:: data/tseimg065.png .. figure:: data/tseimg066.png Les onglets de la propriété RDP-Tcp nommé Environnement et Paramètres d'ouverture de session ne sert plus à rien .. figure:: data/tseimg067.png 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) .. figure:: data/tseimg068.png le contrôle à distance ce fait par l'outil gestionnaire de bureau à distance .. figure:: data/tseimg069.png On peut accorder le droit de crontrôle à distance .. figure:: data/tseimg070.png .. figure:: data/tseimg071.png .. figure:: data/tseimg072.png .. attention:: windows 2008 R2 n'est quand 64bits !!! il prend en charge les appli 32bits mais cela peut être compliqué 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 .. figure:: data/tseimg073.png 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 .. figure:: data/tseimg073.png .. figure:: data/tseimg074.png .. figure:: data/tseimg075.png .. figure:: data/tseimg076.png .. figure:: data/tseimg077.png .. figure:: data/tseimg078.png .. figure:: data/tseimg079.png .. figure:: data/tseimg080.png .. figure:: data/tseimg081.png .. figure:: data/tseimg082.png .. figure:: data/tseimg083.png .. note:: TERMSRV est un mot clé, on pourrait mettre TERMSRV/* pour ne pas s'embêter 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) .. figure:: data/tseimg084.png 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 .. attention:: a priori il existe le client 7 pour xp sur http://www.microsoft.com/fr-fr/download/details.aspx?id=20609 cela correspond aux KB969084 l'exe ce nomme WindowsXP-KB969084-x86-fra.exe .. attention:: la non utilisation du sso pour un xp (ou sur une platine) va imposer sur une ferme de serveur TS de s'identifier 2 fois (TS + broker) .. attention:: tester ce problème de double identification avec le wize et le FX170 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 .. figure:: data/tseimg085.png .. figure:: data/tseimg086.png Il s'agit d'une GP config utilisateur qu'il faut relier à l'utilisateur .. figure:: data/tseimg087.png .. figure:: data/tseimg088.png .. figure:: data/tseimg089.png .. attention:: cette GPO s'applique sur toutes les machines (Serveur TSE ou client ) , en local l'utilisateur n'a plus accès à ces lecteurs A,B,C,D on supprime le lien GP / groupe user on lie la GP aux serveur RDS .. figure:: data/tseimg090.png .. figure:: data/tseimg086.png 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 .. figure:: data/tseimg091.png 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 .. note:: il est préférable de fair une boucle de rappel en mode *remplacement* j'ai donc au niveau des GPO cette architecture .. figure:: data/tseimg093.png et je ne vois plus les lecteurs sur ma session ts .. figure:: data/tseimg092.png mais je les vois en local .. figure:: data/tseimg094.png .. warning:: cela est vrai aussi pour l'administrateur qui ce connecte aux serveur TS: il ne voit plus C !!! .. note:: a priori si on bloque l'accès à C .. on ne voit plus ces documents, solution placer les profils locaux dans D: et bloquer C: le déplacement des profils dans D ce fait sur le serveur (pas de GP) via une modification base de registre (HKLM\Software\microsoft\WindowsNT\CurrentVersion\ProfileList) donc pour modifier ce comportement on va dire que la GP n'est pas appliqué pour les utilisateurs admin .. figure:: data/tseimg095.png .. figure:: data/tseimg096.png .. figure:: data/tseimg097.png 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 .. figure:: data/tseimg098.png Il existe une stratégie pour le chemin de profil utilisateur .. figure:: data/tseimg099.png 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é .. figure:: data/tseimg100.png .. figure:: data/tseimg101.png .. note:: comme il sagit d'une GP ordinateur sur le serveur TS il faut faire un gpupdate /force sur le serveur RDS 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 .. figure:: data/tseimg102.png les lignes de commandes ~~~~~~~~~~~~~~~~~~~~~~~ * tscon * tsdiscons * logoff * msg * reset session * query * tskill * change (user | mode | port) exemple envoi d'un message à un utilisateur (liste des utilisateurs connectés obtenu par query Session 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 .. figure:: data/tseimg103.png 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 .. figure:: data/tseimg104.png 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é .. figure:: data/tseimg105.png .. note:: easy print existe en standard sous win7, sous XP il faut ajouter un easy print il existe des GPO pour gérer easyprint .. figure:: data/tseimg107.png 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 .. figure:: data/tseimg106.png 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 .. figure:: data/tseimg108.png 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 .. figure:: data/tseimg109.png .. figure:: data/tseimg110.png .. figure:: data/tseimg111.png .. figure:: data/tseimg112.png .. figure:: data/tseimg113.png 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) .. figure:: data/tseimg114.png (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) .. figure:: data/tseimg115.png .. note:: si on est pas en SSO il nous demanderait un mot de passe .. note:: le systray des TSE peut être dans le bureau local en utilisant des remoteApps 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 .. figure:: data/tseimg116.png .. warning:: en profil itinérant, avec deux sessions ouvertes (classique / AppRemote) le dernier qui fait la modification qui a raison .. attention:: pour fermer une session remoteApp, fermer les remoteApp ne suffit pas. la déconnexion se fera quand on aura dépasser le temps d'inactivité des sessions RemoteApp (GPO). .. figure:: data/tseimg117.png 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 .. figure:: data/tseimg119.png .. figure:: data/tseimg118.png Le msi nécessite comme même le client RDP 6.1 On peut manager les sessions de remoteApp (presse papier, signature, ...) .. figure:: data/tseimg120.png Pour ne pas avoir les warning de sécurité des AppRemote, il faut signer les remoteApp .. figure:: data/tseimg121.png lors de la creation du rdp il faut aller chercher le certificat .. figure:: data/tseimg122.png .. figure:: data/tseimg123.png 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) .. figure:: data/tseimg124.png .. figure:: data/tseimg125.png .. figure:: data/tseimg126.png .. note:: la clé SHA1 du certificat est récupérer à partir du RDS par un copier/coller de l'empreinte numérique en supprimant les espaces .. figure:: data/tseimg127.png .. figure:: data/tseimg128.png .. note:: sur l'autorité de certificat il faut peut être rajouter un modèle de certificat de type code Il est possible de déployer une remoteApp sur le portail Web (on peut affecter des utilisateurs à la remoteApp) .. figure:: data/tseimg129.png .. figure:: data/tseimg120.png .. figure:: data/tseimg121.png 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 .. figure:: data/tseimg130.png 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 .. figure:: data/tseimg131.png 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 .. figure:: data/tseimg132.png .. figure:: data/tseimg133.png .. figure:: data/tseimg134.png le site web est maintenant utilisable pour tout les clients avec l'adresse https://DC08R2/RDWeb .. figure:: data/tseimg135.png 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 .. figure:: data/tseimg136.png .. attention:: il faut un client windows + IE On peut supprimer une demande d'authentification en ajoutant toujours une signature à nos AppRemote .. figure:: data/tseimg137.png IIS nous demande une authentification ... il s'agit d'un problème de SSO IIS. Sur le serveur IIS .. figure:: data/tseimg138.png .. figure:: data/tseimg139.png devient .. figure:: data/tseimg140.png sur le IE du cleint on a .. figure:: data/tseimg141.png il faut donc ajouter notre IIS comme intranet .. figure:: data/tseimg142.png pour le certificat il faut un créer un et modifier les liaisons du site .. figure:: data/tseimg143.png Ferme TS ======== Afin d'assurer un service RDS sur plusieurs dizaines de sessions avec un taux de service important (redondance) il est nécessaire de cérer une ferme de serveur TS. Une ferme est composée: * au moins 2 serveurs TS * un repartiteur de charge (de connection) (service broker dans le rôle burezau à distance) qui ne soit pas un serveur RDS on utilisera aussi de DNS Round Robin assurant ainsi que quelque soit l'état des RDS, si au moins un RDS est en marche cela fonctionne . (le round robin assure la tolérance de panne des RDS) du Roubd Robin permet via un nom DNS de ping une machine parmi plusieurs machines on a deux RDS sur les IPs 192.168.255.11 / 12 La connexion depuis le client est réalisé ainsi * connexion depuis le client sur l'adresse du rouns robin * un des RDS prend en charge la connexion * le serveur RDS renvoi la connexion vers le Broker * le broker sélectionne le DS le moins chargé et renvoi la connexion sur ce dernier cette méthode sans SSO impose une double identification (RDS et broker) .. note:: en 2008 R2 a priori la double identification n'existe plus Si le broker casse cela fonctionne encore mais il n'y a plus de repartition de charge par le broker (mais uniquement par le round robin) Pour installer le round robin il faut modifier le DNS .. figure:: data/tseimg144.png .. figure:: data/tseimg145.png .. figure:: data/tseimg146.png Sur une nouvelle machine broker il faut ajouter le service broker du rôle Bureau distance .. figure:: data/tseimg147.png ce service génère un groupe *local* "ordinateur du service Session broker" dans lequel on ajoute les serveurs RDS (= le broker connait les membres de la ferme TS) .. figure:: data/tseimg148.png .. figure:: data/tseimg149.png il faut maintenant indiquer au serveur RDS: * le nom de la ferme * qui est le serveur RDS .. figure:: data/tseimg150.png .. figure:: data/tseimg151.png .. figure:: data/tseimg152.png .. figure:: data/tseimg153.png On peut réaliser cette configuration de ferme via une GPO (comme cela tout serveur RDS indiqué dans la même OU rentre directement dans la ferme) on génère une nouvelle OU (ce qui nous permettra peut être un jour d'avoir 2 fermes) sur laquelle on applique une nouvelle GP .. figure:: data/tseimg154.png .. figure:: data/tseimg155.png .. figure:: data/tseimg156.png .. figure:: data/tseimg157.png .. figure:: data/tseimg158.png .. figure:: data/tseimg159.png il faut faire un gpupdate ou redémarrer les serveurs RDS, et on constate sur les serveur RDS .. figure:: data/tseimg160.png On peut faire une charge de serveur non homogène via le paramètre "Poids relatif" On peut maintenant sur un client ce connecter à la ferme .. figure:: data/tseimg161.png et nous avons une répartition de session .. figure:: data/tseimg163.png il faut aller dans le certficat d'autorité et sur les certificats révoqués lancer une publication tout mais nous obtenons une erreur de certificat (le SSO ne fonctionne plus car il faut du NLA qui nécessite du SSL qui ne fonctionne pas) .. figure:: data/tseimg162.png Il faut donc regénéré un certificat le problème provient de notre certificat (dans le champ Délivré pour , c'est le CN: Nom Commun ou Common Name) .. figure:: data/tseimg164.png Sur l'autorité de contrôle * lancer mmc * ajouter composant certificat / compte ordinateur / local * aller dans modèle clic/droit gérer * choisir modèle serveur web * clic droit proriété / Sécurité * ajouter le droit d'inscrire à l'un des serveurs de la ferme (ex RDS2) * redémarrer le service d'autorité .. figure:: data/tseimg165.png .. figure:: data/tseimg166.png Sur le serveur "incrit" (ex RDS2) * lancer mmc * ajouter composant certificat / compte ordinateur / local * dans personnel demander un nouveau certificat personnel * choisir le modèle serveur web * détail propriété modifier dans onglet clé privé "autoriser l'exportation de la clef" et mettre comme Nom Commun (CN) fermets.labs.local (nom de la ferme dans le domaine) .. figure:: data/tseimg167.png .. figure:: data/tseimg168.png .. figure:: data/tseimg169.png .. figure:: data/tseimg170.png .. figure:: data/tseimg171.png .. warning:: tout les deux ans il faudra refaire le certificat (ou via GPO renouveler le certificat: stratégie/ Paaramètre windows / sécurite/ inscription automatique) .. figure:: data/tseimg172.png Il faut maintenant exporter le certificat *avec* la clé privé Sur les autres serveurs de la ferme il faut importer ce certificat pfx dans ordinateur/personnel * lancer mmc * ajouter composant certificat / compte ordinateur / local * dans personnel importer le certificat .. note:: toujours laisser la clé exportable .. figure:: data/tseimg173.png .. figure:: data/tseimg174.png Il faut maintenant associer sur tout les serveurs RDS , ce certificat au service RDS (propriété de la configuration du serveur d'hôte) .. figure:: data/tseimg175.png les remoteApp (qui ne sont que des fichier rdp) doivent être regénéré pour tenir compte de la ferme (et donc d'installer des postes client les anciens RemoteApp si besoin) Dans une ferme de TS il faut que les même remoteApp soient sur tout les RDS. Il faut modifier dans le gestionnaire de remoteApp le nom du serveur .. figure:: data/tseimg176.png il est possible à partir d'un serveur RDS de mettre à jours les remoteApp d'un autre serveur RDS .. figure:: data/tseimg177.png On peut maintenant regénérer les AppRemote .. figure:: data/tseimg178.png Concernant le portail web, la mise en place de la ferme à des impacts. Il faut le reconfigurer en local sur le serveur web. Et pour chaque serveur RDS, indiquer quel RDWeb peut être utilisé configuration sur le portail web .. figure:: data/tseimg179.png configuration sur le serveur RDS .. figure:: data/tseimg180.png réalisable via GPO .. figure:: data/tseimg181.png Passerelle TS/RDS ================= le principale problème est celui des certificats. Il faudra un certificat sur clé usb ou bien acheter un certificat. L'objectif est d'avoir un client sur internet. connexion https entre la paserelle RDS et le client (a travers le firewall) connexion RDP/SSL entre le serveur RDS et la passerelle RDS. La passerelle RDS est dans une DMZ Donc le client sur internet n'est pas en direct sur le serveur RDS .. figure:: data/tseimg182.png Il faudra un radius (relais d'authentification) entre la passerelle RDS (quin'apartient pas au doamine) et le serveur RDS. IL faut: * une IP public * une resolution de nom public * un radius * une paserelle sur l'autorité de controle ajouter deux extension .. figure:: data/tseimg183.png si on demande un nouveau certificat (utilisateur par exemple) sur un serveur RDS, on voit .. figure:: data/tseimg184.png il faut ajouter sur la passerelle RDS il faut ajouter dans le rôle bureau à distance le service Passerelle .. figure:: data/tseimg185.png on installe le RAP et CAP avec tout le monde .. figure:: data/tseimg186.png .. figure:: data/tseimg187.png on va demander le certificat via IIS .. figure:: data/tseimg188.png .. figure:: data/tseimg189.png .. figure:: data/tseimg190.png .. figure:: data/tseimg191.png .. figure:: data/tseimg192.png il faut maintenant sur la passerelle importer ce certificat .. figure:: data/tseimg193.png .. figure:: data/tseimg194.png il faut que le certificat soit disponibles sur la passerelles sur labs.crl .. figure:: data/tseimg195.png pour cela on va pousser ce certificat dans wwwroot .. figure:: data/tseimg196.png sur l'AC on va exporter notre certificat .. figure:: data/tseimg197.png .. figure:: data/tseimg198.png .. note:: notre passerelle s'appelle rdg .. note:: un export du certificat puis un copier/coller suffirait mais cela ne serait pas automatique on a maintenant sur notre passerelle, notre certificat .. figure:: data/tseimg199.png il faut recréer les remoteApp (rdp et msi) pour indiquer la paserelle donc sur un serveur RDS on regénère le msi .. figure:: data/tseimg200.png .. figure:: data/tseimg202.png le nom de la paserelle peut être retrouvé sur le certificat de la passerelle .. figure:: data/tseimg201.png on peut maintenant installer ce msi sur les postes locaux (n'utiliserons pas la passerelle) mais aussi sur les postes qui ce trouve sur internet (utiliserons la passerelle) ON peut aussi modifier au niveau global du rds cette information de passerelle (gateway) On peut modifier nosu même le client rdp en indiquant la passerelle .. figure:: data/tseimg203.png Quotas ====== Il est possible de mettre en place des quotas ram/cpu * par processus * par pool IIS * par session *RDS* On peut ainsi indiquer qu'une session RDS ne peux pas dépasser * 50% du CPU * 2Go de RAM La gestion des qutoas set réalisé par le service WSRM (fonctionnalité) et cela s'intalle par serveur RDS