Procédure pas à pas de Terminal Server : démarrage, connexion et application

Cet article décrit le processus d’initialisation d’un serveur Terminal Server et décrit ce qui se produit lorsqu’un utilisateur se connecte au serveur et exécute une application.

S’applique à : Windows Server 2012 R2
Numéro de la base de connaissances d’origine : 186572

Initialisation du serveur Terminal Windows

Lorsque le serveur Terminal Windows démarre et charge le système d’exploitation principal, le service Terminal Server (Termsrv.exe) est démarré et crée des piles d’écoute (une par paire de protocole et de transport) qui écoutent les connexions entrantes. Chaque connexion reçoit un identificateur de session unique ou « SessionID » pour représenter une session individuelle pour le serveur Terminal Server. Chaque processus créé au sein d’une session est « étiqueté » avec le SessionID associé pour différencier son espace de noms de tout autre espace de noms de connexion.

La session de console (clavier, souris et vidéo Terminal Server) est toujours la première à charger et est traitée comme une connexion cliente de cas spécial et sessionID. La session de console commence comme une session système Windows NT normale avec les pilotes d’affichage, de souris et de clavier Windows NT configurés chargés.

Le service Terminal Server appelle ensuite le Gestionnaire de session Windows NT (Smss.exe) pour créer deux sessions client inactives (par défaut = 2) (après avoir créé la session de console) qui attendent les connexions clientes. Pour créer les sessions inactives, le Gestionnaire de sessions exécute le processus de sous-système d’exécution client/serveur Windows NT (Csrss.exe), et un nouvel Id de session est affecté à ce processus. Le processus CSRSS appelle également le processus Winlogon (Winlogon.exe) et le module noyau Win32k.sys (Gestionnaire de fenêtres et interface de périphérique graphique - GDI) sous le SessionID nouvellement associé. Le chargeur d’images Windows NT modifié reconnaît cette Win32k.sys en tant qu’image pouvant être chargée par SessionSpace par un jeu de bits prédéfini dans l’en-tête d’image. Il déplace ensuite la partie de code de l’image dans la mémoire physique, avec des pointeurs à partir de l’espace d’adressage du noyau virtuel pour cette session, si Win32k.sys n’a pas déjà été chargé. Par conception, il est toujours attaché au code d’une image précédemment chargée (Win32k.sys) s’il en existe déjà une en mémoire. Par exemple, à partir d’une application ou d’une session active.

La section données (ou non partagée) de cette image sera ensuite allouée à la nouvelle session à partir d’une section de mémoire du noyau paginable SessionSpace nouvellement créée. Contrairement à la session de console, les sessions clientes Terminal Server sont configurées pour charger des pilotes distincts pour l’affichage, le clavier et la souris.

Le nouveau pilote d’affichage est le pilote d’affichage rdp (Remote Desktop Protocol), Tsharedd.dll. Les pilotes de souris et de clavier communiquent dans la pile via le gestionnaire de pile de plusieurs instance, termdd.sys. Termdd.sys enverra les messages pour l’activité de la souris et du clavier vers et à partir du pilote RDP, Wdtshare.sys. Ces pilotes permettent à la session cliente RDP d’être disponible à distance et interactive. Enfin, Terminal Server appelle également un thread d’écouteur de connexion pour le protocole RDP, à nouveau géré par le gestionnaire de pile de plusieurs instance (Termdd.sys), qui écoute les connexions clientes RDP sur le port TCP numéro 3389.

À ce stade, le processus CSRSS existe sous son propre espace de noms SessionID, avec ses données instanciées par processus si nécessaire. Tous les processus créés à partir de ce SessionID s’exécutent automatiquement dans l’espace de session du processus CSRSS. Cela empêche les processus avec des Id de session différents d’accéder aux données d’une autre session.

Connexion cliente

Le client RDP peut être installé et exécuté sur n’importe quel terminal Windows (basé sur WinCE), Windows pour workgroups 3.11 exécutant TCP/IP-32b ou la plateforme basée sur l’API Microsoft Win32. Les clients non basés sur Windows sont pris en charge par le module complémentaire Citrix Metaframe. Le fichier exécutable du client RDP Windows pour workgroups a une taille d’environ 70 Ko, utilise un jeu de travail de 300 Ko et utilise 100 Ko pour les données d’affichage. Le client Win32 a une taille d’environ 130 Ko, utilise un jeu de travail de 300 Ko et 100 Ko pour les données d’affichage.

Le client établit une connexion au serveur Terminal Server via le port TCP 3389. Le thread d’écouteur RDP Terminal Server détecte la demande de session et crée une pile RDP instance pour gérer la nouvelle demande de session. Le thread d’écouteur remettra la session entrante à la nouvelle pile RDP instance et continuera à écouter sur le port TCP 3389 pour d’autres tentatives de connexion. Chaque pile RDP est créée au fur et à mesure que les sessions clientes sont connectées pour gérer la négociation des détails de configuration de session. Les premiers détails seront l’établissement d’un niveau de chiffrement pour la session. Le serveur Terminal Server prend initialement en charge trois niveaux de chiffrement : faible, moyen et élevé.

Un chiffrement faible chiffre uniquement les paquets envoyés du client au serveur Terminal Server. Ce chiffrement « entrée uniquement » vise à protéger l’entrée de données sensibles, telles que le mot de passe d’un utilisateur. Le chiffrement moyen chiffrera les paquets sortants du client de la même façon que le chiffrement de bas niveau, mais chiffrera également tous les paquets d’affichage retournés au client à partir du serveur Terminal Server. Cette méthode de chiffrement sécurise les données sensibles, car elles transitent sur le réseau pour être affichées sur un écran distant. Le chiffrement faible et moyen utilise l’algorithme Microsoft-RC4 (algorithme RC4 modifié avec des performances améliorées) avec une clé 40 bits. Un chiffrement élevé chiffre les paquets dans les deux sens, vers et depuis le client, mais utilise l’algorithme de chiffrement RC4 standard du secteur, là encore avec une clé de 40 bits. Une version non export de Windows NT Terminal Server fournit un chiffrement RC4 de haut niveau 128 bits.

Un échange de polices se produit entre le client et le serveur pour déterminer quelles polices système courantes sont installées. Le client informe le serveur Terminal Server de toutes les polices système installées, afin d’accélérer le rendu du texte pendant une session RDP. Lorsque le serveur Terminal Server sait quelles polices le client a disponibles, vous pouvez économiser la bande passante réseau en passant des chaînes de caractères Unicode et de police compressées, plutôt que des bitmaps plus grandes, au client.

Par défaut, tous les clients réservent 1,5 Mo de mémoire pour un cache bitmap utilisé pour mettre en cache des bitmaps, telles que des icônes, des barres d’outils, des curseurs, etc., mais qui n’est pas utilisé pour contenir des chaînes Unicode. Le cache est paramétrable (via une clé de Registre) et remplacé à l’aide d’un algorithme LRU (Least Recently Used). Le serveur Terminal Server contient également des mémoires tampons pour permettre le passage contrôlé par flux des actualisations d’écran aux clients, plutôt qu’un flux binaire constant. Lorsque l’interaction utilisateur sur le client est élevée, la mémoire tampon est vidée environ 20 fois par seconde. Pendant le temps d’inactivité, ou en l’absence d’interaction de l’utilisateur, la mémoire tampon est ralentie pour ne vider que 10 fois par seconde. Vous pouvez régler tous ces nombres via le registre.

Une fois les détails de session négociés, la pile RDP du serveur instance pour cette connexion est mappée à une session utilisateur Win32k inactive existante, et l’utilisateur est invité à afficher l’écran d’ouverture de session Windows NT. Si la connexion automatique est configurée, le nom d’utilisateur et le mot de passe chiffrés sont transmis au serveur Terminal Server et l’ouverture de session continue. S’il n’existe actuellement aucune session Win32k inactive, le service Terminal Server appelle le Gestionnaire de session (SMSS) pour créer un espace utilisateur pour la nouvelle session. Une grande partie de la session utilisateur Win32k utilise du code partagé et se charge nettement plus rapidement après le chargement préalable d’un instance.

Une fois que l’utilisateur a tape un nom d’utilisateur et un mot de passe, les paquets sont envoyés chiffrés au serveur Terminal Server. Le processus Winlogon effectue ensuite l’authentification de compte nécessaire pour s’assurer que l’utilisateur dispose du privilège de connexion et transmet le domaine et le nom d’utilisateur de l’utilisateur au service Terminal Server, qui gère une liste SessionID de domaine/nom d’utilisateur. Si un SessionID est déjà associé à cet utilisateur (par exemple, une session déconnectée existe), la pile de session actuellement active est attachée à l’ancienne session. La session Win32 temporaire utilisée pour l’ouverture de session initiale est ensuite supprimée. Sinon, la connexion se poursuit normalement et le service Terminal Server crée un nouveau mappage SessionID de domaine/nom d’utilisateur. Si, pour une raison quelconque, plusieurs sessions sont actives pour cet utilisateur, la liste des sessions s’affiche et l’utilisateur décide de celle qu’il doit sélectionner pour la reconnexion.

Exécution d’une application

Après l’ouverture de session de l’utilisateur, le bureau (ou l’application si en mode application unique) s’affiche pour l’utilisateur. Lorsque l’utilisateur sélectionne une application 32 bits à exécuter, les commandes de la souris sont passées au serveur Terminal Server, qui lance l’application sélectionnée dans un nouvel espace de mémoire virtuel (application de 2 Go, noyau de 2 Go). Tous les processus sur le serveur Terminal Server partagent le code dans les modes noyau et utilisateur dans la mesure du possible. Pour obtenir le partage de code entre les processus, le gestionnaire de mémoire virtuelle Windows NT utilise la protection de page de copie sur écriture. Lorsque plusieurs processus souhaitent lire et écrire le même contenu de mémoire, le gestionnaire de machines virtuelles attribue une protection de page de copie en écriture à la région de mémoire. Les processus (sessions) utilisent le même contenu de mémoire jusqu’à ce qu’une opération d’écriture soit effectuée, à quel moment le gestionnaire de machines virtuelles copie le cadre de page physique vers un autre emplacement, met à jour l’adresse virtuelle du processus pour pointer vers le nouvel emplacement de la page et marque la page comme étant en lecture/écriture. La copie en écriture est utile et efficace pour les applications s’exécutant sur un serveur Terminal Server.

Lorsqu’une application Win32 telle que Microsoft Word est chargée en mémoire physique par un processus (session), elle est marquée comme copie sur écriture. Lorsque de nouveaux processus (sessions) appellent également Word, le chargeur d’images pointe simplement les nouveaux processus (sessions) vers la copie existante, car l’application est déjà chargée en mémoire. Lorsque des mémoires tampons et des données spécifiques à l’utilisateur sont nécessaires (par exemple, l’enregistrement dans un fichier), les pages nécessaires sont copiées dans un nouvel emplacement de mémoire physique et marquées comme étant en lecture/écriture pour le processus individuel (Session). Le gestionnaire de machines virtuelles protège cet espace mémoire contre d’autres processus. Toutefois, la plupart d’une application est du code partageable et n’aura qu’une seule instance de code en mémoire physique, quel que soit le nombre d’exécutions.

Il est préférable (bien que non nécessaire) d’exécuter des applications 32 bits dans un environnement Terminal Server. Les applications 32 bits (Win32) permettent le partage de code et s’exécutent plus efficacement dans les sessions multi-utilisateurs. Windows NT permet aux applications 16 bits (Win16) de s’exécuter dans un environnement Win32 en créant un ordinateur virtuel MS-DOS (VDM) pour chaque application Win16 à exécuter. Toute la sortie 16 bits est traduite en appels Win32, qui effectuent les actions nécessaires. Étant donné que les applications Win16 s’exécutent dans leur propre VDM, le code ne peut pas être partagé entre les applications dans plusieurs sessions. La traduction entre les appels Win16 et Win32 consomme également des ressources système. L’exécution d’applications Win16 dans un environnement Terminal Server peut potentiellement consommer deux fois plus de ressources qu’une application Win32 comparable.

Déconnexion de session et déconnexion de l’utilisateur

Déconnexion de session

Si un utilisateur décide de déconnecter la session, les processus et tout l’espace de mémoire virtuel restent et sont paginés sur le disque physique, si la mémoire physique est nécessaire pour d’autres processus. Étant donné que le serveur Terminal Server conserve un mappage du domaine/nom d’utilisateur et de son SessionID associé, lorsque le même utilisateur se reconnecte, la session existante est chargée et rendue à nouveau disponible. Un autre avantage de RDP est qu’il peut modifier les résolutions d’écran de session, en fonction de ce que l’utilisateur demande pour la session. Par exemple, supposons qu’un utilisateur s’était précédemment connecté à une session Terminal Server avec une résolution de 800 x 600 et s’était déconnecté. Si l’utilisateur se déplace ensuite vers un autre ordinateur qui ne prend en charge que la résolution 640 x 480 et se reconnecte à la session existante, le bureau est redessiné pour prendre en charge la nouvelle résolution.

Déconnexion de l’utilisateur

La déconnexion est généralement simple à implémenter. Une fois qu’un utilisateur se déconnecte de la session, tous les processus associés à SessionID sont arrêtés et toute mémoire allouée à la session est libérée. Si l’utilisateur exécute une application 32 bits telle que Microsoft Word et se déconnecte de la session, le code de l’application elle-même reste en mémoire jusqu’à ce que le dernier utilisateur quitte l’application.