Services RDS de Windows Server 2008 R2

Transcription

1 296 Services RDS de Windows Server 2008 R2 Le service Termsrv (Termsrv.dll tourne à l'intérieur d'un processus svchost.exe) héberge un écouteur qui communique avec un pilote TDI (mode noyau) afin d'écouter les requêtes de connexions. Il interagit également avec le serveur de licences, la pile de protocole RDP ou encore avec le Gestionnaire de Sessions Locales. En outre, désormais seul le gestionnaire de sessions locales fonctionne avec un compte de service système, le service Termsrv tourne lui avec un compte de service réseau ce qui permet d'améliorer la sécurité. Enfin, voici deux tableaux récapitulant les services et les fichiers importants utilisés sous Windows 2008 R2 : Services : Nom du Service Services Bureau à distance (TermServices) Configuration des services Bureau à distance (SessionEnv) Passerelle des services Bureau à distance (TSGateway) Service Broker pour les connexions Bureau à distance (Tssdis) Redirecteur de port du mode utilisateur des services Bureau à distance (UMRdpService) Localisation termsvcs %systemroot%\system32\termsrv.dll netsvcs %systemroot%\system32\sessenv.dll tsgateway %systemroot%\system32\aaedge.dll %systemroot%\system32\tssdis.exe LocalSystemNetworkRestricted %systemroot%\system32\umrdp.dll Editions ENI - All rights reserved

2 Concepts avancés Chapitre Fichiers : Composant AACLIENT.DLL CREDSSP.DLL MSTSCAX.DLL MSTSC.EXE RDPCFGEX.DLL RDPD3D.DLL RDPDD.DLL RDPINIT.EXE RDPSHELL.EXE RDPSIGN.EXE RDPWSX.DLL RDPDD.DLL RDPCLIP.EXE TERMSRV.DLL TSDDD.DLL WINLOGON.EXE WINSTA.DLL WINMM.DLL WTSAPI32.DLL Description TS Web Access Support du SSO ActiveX de contrôle TS Exécutable du bureau à distance Extension de configuration des connexions Extension de rendu Direct 3D (Dx10) Pilote vidéo Utilisé pour l'initialisation de RemoteApp (lancé par USERINIT.EXE) Shell pour RemoteApp (remplace explorer.exe) Permet de signer les fichiers.rdp Utilisé pour les opérations de connexion/déconnexion Pilote écran TS Redirection du presse-papier Gestion de la pile de connexion Pilote écran pour une connexion console Fournit les opérations de connexion/déconnexion [Ctrl+Alt+Suppr] Fournit les informations de session (durée d'inactivité par exemple) Support des services multimédia Api de développement

3 298 Services RDS de Windows Server 2008 R2 1.2 Isolation de la session 0 Une des nouvelles fonctionnalités permettant d'accroître la sécurité du système est l'isolation de la session 0. Sous Windows 2003, les applications et les services tournaient tous dans la session 0 (appelée session console) ce qui n'était pas sans risque dans la mesure où de nombreux services fonctionnent avec des privilèges systèmes. Dès Windows 2008, seuls les services tournent dans la session 0 (plus de connexion interactive), les applications, elles, fonctionnent dans d'autres sessions (un programme malveillant ne pourra plus utiliser une application mal codée pour attaquer un service afin d'élever son niveau de droits) Les différents états des sessions Dès lors qu'un utilisateur se connecte à un serveur (localement ou à distance), il ouvre ce que l'on appelle une session interactive. Cette session contient aussi bien des processus systèmes, que des applications ou encore le bureau de l'utilisateur. Sous Windows 2008 R2, le premier ID des sessions interactives est le 1 (l'id 0 est réservé aux services), que l'utilisateur soit connecté localement (à la console du serveur) ou à distance. Durant sa vie, une session passe par plusieurs états dont les plus intéressants sont actif et déconnecté : Etat actif : l'utilisateur travaille actuellement dans sa session. Etat déconnecté : l'utilisateur n'est pas connecté à la session mais les applications continuent de s'y exécuter. Editions ENI - All rights reserved

4 Concepts avancés Chapitre Terminal local ou distant Quand une session est active, celle-ci est attachée à un certain nombre de périphériques d'entrée/sortie (clavier, écran ) qui forment ce que l'on appelle un terminal. Le terminal peut être soit local (s'il s'agit des éléments physiquement connectés sur le serveur), soit distant (s'il s'agit d'une liaison avec les entrées/sorties du client). Dans le cas d'un terminal distant, celui-ci est également associé à un objet de connexion qui contient notamment des informations sur la pile de protocole ou encore les pilotes d'extension. Quand une session est déconnectée, elle n'est plus attachée à aucun terminal. S'il s'agit d'une connexion distante, le terminal et l'objet connexion sont alors détruits. En revanche, un terminal local n'est jamais détruit de manière permanente. Quand la session attachée à un terminal local passe à l'état déconnecté, une nouvelle session console est générée et un nouveau terminal local y est rattaché (bien que la session ne soit pas active, elle est quand même attachée au terminal local). Ce type de session est dans un état appelé connecté (affichage de l'écran [Ctrl][Alt][Suppr]) Reconnexion de session Une session déconnectée doit être rattachée à un nouveau terminal (local ou distant) avant de pouvoir être réutilisée. Voici les différentes étapes qui se déroulent dans ce cas : Si l'utilisateur se connecte localement sur le serveur, une session (ID 1) est attachée au terminal local et passe dans l'état actif. La session créée porte le nom de session console. Quand l'utilisateur se déconnecte (ou verrouille sa machine), la session passe dans l'état déconnecté. À cet instant, la session 1 n'est plus attachée à aucun terminal. Quand le terminal a fini de se fermer, une nouvelle session (ID 2) est créée et rattachée au terminal local (session dans l'état connecté). La session d'id 1 reste, elle, dans l'état déconnecté et le nom console est assigné à la session d'id 2. Si le même utilisateur se connecte à distance sur le serveur, un nouveau terminal distant est créé et rattaché à sa session déconnectée (ID 1). La session d'id 1 passe dans l'état actif avec ce terminal distant.

5 300 Services RDS de Windows Server 2008 R2 Lorsque l'utilisateur se déconnecte, le terminal distant est détruit et la session repasse dans l'état déconnecté. La session d'id 1 ne sera fermée que lorsque l'utilisateur initiera une fermeture de session (ou que l'administrateur forcera la fermeture) Option /console du client RDC Sous Windows 2003, la session d'id 0 est appelée session console et rattachée au terminal local. Lorsqu'un utilisateur ouvre une session locale, il est de fait connecté sur la session d'id 0 (qui n'est fermée que lors d'un arrêt du système). Dans les faits, certaines opérations, telles que des installations d'applications ou l'affichage de certaines boîtes de dialogues, ne peuvent se faire qu'à la console. Pour permettre aux administrateurs d'accéder à la session 0 à distance, le commutateur /console a donc été ajouté au client RDC. Comme dit précédemment, depuis Windows 2008, la session d'id 0 n'est plus interactive (réservée aux services). La session dite console, quant à elle, est simplement celle qui est connectée au terminal local, ce qui signifie, en d'autres termes, que n'importe quelle session (quel que soit son ID) peut être associée au terminal local et donc être de type console. Contrairement à ce qui existe sous Windows 2003, il n'y a plus de raison, avec Windows 2008 et 2008 R2, de chercher à se connecter à distance au terminal local (session dite console) car l'ensemble des sessions distantes bénéficient des mêmes fonctions que celle-ci. De fait, le commutateur /console, disponible jusqu'à présent dans les clients RDC, ne sert sous Windows 2008 qu'à administrer le serveur sans consommer de licence TSE CAL. Depuis la version du client RDC 6.1, le commutateur /admin a été introduit en remplacement du commutateur /console, dévolu aux tâches d'administrations. Enfin, il faut savoir que le commutateur /admin ne sert que si l'on se connecte à un serveur Windows 2008 Terminal Server ou Windows 2008 R2 RDS (pour ne pas consommer de CAL). L'utilisation de ce commutateur sur un serveur en mode administration à distance n'a aucun effet. Editions ENI - All rights reserved

6 Concepts avancés Chapitre Support des polices ClearType Avec la démocratisation des écrans LCD, l'arrivée de Windows 7 en remplaçant direct de Vista et d'office 2007, les polices ClearType revêtent un caractère primordial. En effet, de nombreuses polices sont désormais optimisées pour l'utilisation de ClearType et apparaîtraient bien fade si sa prise en charge n est pas activée. Pour autant, la finesse des polices a un coût. Normalement, sous RDS (sans activer le lissage des polices), les polices sont transmises vers le client sous forme de caractères, ce qui est géré de manière efficace (mise en cache) par le protocole RDP afin de limiter la consommation de bande passante. En revanche avec l'activation du ClearType, les polices sont transmises sous forme d'images ce qui conduit à une augmentation significative de la consommation de bande passante. D'après les tests réalisés par Microsoft, l'activation du lissage des polices conduirait à une surconsommation de bande passante de l'ordre de quatre à dix fois celle mesurée lors de la transmission des polices en mode caractère. 1.4 Prioritisation de l'affichage Le client RDC 6 et 6.1 résout le problème de la prioritisation d'affichage en ajoutant la possibilité de contrôler les canaux virtuels. Cela permet de positionner une importance plus faible pour les flux annexes tels que l'impression ou le transfert de fichiers. Le paramétrage, défini par défaut est de 70 % pour l'affichage et les entrées sorties (clavier/souris) et de 30 % pour le reste des flux. Ce paramétrage peut être ajusté à l'aide des clefs de registre suivantes (Type DWORD) : Sous HKLM\SYSTEM\CurrentControlSet\Services\TermDD : FlowControlDisable : positionner cette entrée à 1 pour désactiver la prioritisation de l'affichage. Les requêtes seront alors traitées par un classique mécanisme de First In, First Out (Premier Entré, Premier Sorti).