Procédure pas à pas pour le serveur 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.

Version du produit d’origine :   Windows Server 2012 R2
Numéro de la ko d’origine :   186572

Initialisation de Windows Terminal Server

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

La session de console (clavier Terminal Server, souris et vidéo) est toujours la première à charger et est traitée comme une connexion client spéciale et sessionID affectée. La session console démarre 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 sessions Windows NT (Smss.exe) pour créer deux sessions client inactives (par défaut = 2) (après la création de la session console) qui attendent les connexions client. Pour créer les sessions inactives, le Gestionnaire de session exécute le processus de sous-système d’exécution client/serveur Windows NT (Csrss.exe), et un nouvel SessionID est affecté à ce processus. Le processus CSRSS appelle également le processus Winlogon (Winlogon.exe) et le module de 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îtra ce Win32k.sys comme une image chargeable par SessionSpace par un bit prédéféré dans l’en-tête de l’image. Elle déplacera ensuite la partie code de l’image dans la mémoire physique, avec des pointeurs à partir de l’espace d’adressaie 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à un en mémoire. Par exemple, à partir d’une application ou d’une session active.

La section données (ou non partagées) de cette image sera ensuite allouée à la nouvelle session à partir d’une nouvelle section de mémoire pagnable du noyau SessionSpace. Contrairement à la session console, les sessions client 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 de périphérique 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 instances, termdd.sys. Termdd.sys les messages d’activité de souris et de clavier vers et depuis le 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’écoute de connexion pour le protocole RDP, de nouveau géré par le gestionnaire de pile de plusieurs instances (Termdd.sys), qui écoute les connexions client RDP sur le port TCP 3389.

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

Connexion client

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

Le client initiera une connexion au serveur Terminal Server via le port TCP 3389. Le thread d’écoute RDP Terminal Server détecte la demande de session et crée une nouvelle instance de pile RDP pour gérer la nouvelle demande de session. Le thread d’écoute passe la session entrante à la nouvelle instance de pile RDP et continue à écouter sur le port TCP 3389 pour d’autres tentatives de connexion. Chaque pile RDP est créée lorsque les sessions clientes sont connectées pour gérer la négociation des détails de configuration de session. Les premiers détails seront d’établir un niveau de chiffrement pour la session. Le serveur Terminal Server prendra 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 » est pour protéger l’entrée de données sensibles, telles que le mot de passe d’un utilisateur. Un chiffrement moyen chiffre les paquets sortants du client de la même manière que le chiffrement de bas niveau, mais chiffre également tous les paquets d’affichage renvoyés au client à partir du serveur Terminal Server. Cette méthode de chiffrement sécurisation les données sensibles, telles qu’elles circulent 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. Le 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é 40 bits. Une version non exportée de Windows NT Terminal Server fournira un chiffrement RC4 de haut niveau 128 bits.

Un échange de polices se produit entre le client et le serveur pour déterminer les polices système courantes installées. Le client informera le serveur Terminal Server de toutes les polices système installées, pour permettre un rendu plus rapide du texte pendant une session RDP. Lorsque le serveur Terminal Server connaît les polices disponibles pour le client, 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 tunable (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 la transmission contrôlée par le flux d’actualisations d’écran aux clients, plutôt qu’un flux de bits constant. Lorsque l’interaction de l’utilisateur au niveau du client est élevée, la mémoire tampon est vidée environ 20 fois par seconde. Pendant les périodes d’inactivité ou lorsqu’il n’y a aucune interaction utilisateur, la mémoire tampon est ralentie pour être vidée 10 fois par seconde uniquement. Vous pouvez régler tous ces numéros via le Registre.

Une fois que les détails de session ont été négociés, l’instance de pile RDP du serveur pour cette connexion est mappée à une session utilisateur Win32k inactive existante et l’utilisateur est invité à s’y rendre avec 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 la connexion se poursuit. S’il n’existe actuellement aucune session Win32k inactive, le service Terminal Server appelle le Gestionnaire de sessions (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 sensiblement plus rapidement après le chargement d’une 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 a le privilège de se connecter et transmet le domaine et le nom d’utilisateur de l’utilisateur au service Terminal Server, qui conserve 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 sessions 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 déroule normalement et le service Terminal Server crée un mappage SessionID 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 à sélectionner pour la reconnexion.

Exécution d’une application

Une fois l’utilisateur ouvert, le bureau (ou l’application s’il est en mode d’application unique) s’affiche pour l’utilisateur. Lorsque l’utilisateur sélectionne une application 32 bits à exécuter, les commandes de la souris sont transmises au serveur Terminal Server, qui lance l’application sélectionnée dans un nouvel espace mémoire virtuel (application de 2 Go, noyau de 2 Go). Dans la mesure du possible, tous les processus sur le serveur Terminal Server partageront du code dans le noyau et les modes utilisateur. Pour obtenir le partage de code entre les processus, le gestionnaire de mémoire virtuelle Windows NT (VM) 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 l’environnement de gestion des VM attribue une protection de page de copie sur écriture à la région mémoire. Les processus (Sessions) utilisent le même contenu mémoire jusqu’à ce qu’une opération d’écriture soit effectuée, auquel moment le gestionnaire de l’environnement de développement virtuel copie le cadre de page physique vers un autre emplacement, met à jour l’adresse virtuelle du processus pour qu’il pointe vers le nouvel emplacement de page et marque à présent la page comme étant en lecture/écriture. La copie sur écriture est utile et efficace pour les applications qui s’exécutent sur un serveur Terminal Server.

Lorsqu’une application Win32 telle que Microsoft Word est chargée dans la 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 requises (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 lues/écritures pour le processus individuel (Session). Le gestionnaire de la VM protège cet espace mémoire contre d’autres processus. Toutefois, la plupart d’une application est un code partageable et n’aura qu’une seule instance de code dans la mémoire physique, quel que soit le nombre d’utilisations.

Il est préférable (mais pas nécessaire) d’exécuter des applications 32 bits dans un environnement Terminal Server. Les applications 32 bits (Win32) autorisent 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 basé sur MS-DOS (VDM) pour chaque application Win16 à exécuter. Toutes les sorties 16 bits sont converties 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 mémoire virtuel resteront et seront pagés sur le disque physique, si la mémoire physique est requise pour d’autres processus. Étant donné que le serveur Terminal Server conserve un mappage de domaine/nom d’utilisateur et son SessionID associé, lorsque le même utilisateur se reconnecte, la session existante est chargée et à nouveau disponible. Un autre avantage de RDP est qu’il est en mesure de 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 à une résolution de 800 x 600 et qu’il était déconnecté. Si l’utilisateur se déplace ensuite vers un autre ordinateur qui prend uniquement en charge la résolution 640 x 480 et se reconnecte à la session existante, le Bureau est réessiné pour prendre en charge la nouvelle résolution.

User Logoff

La ff de logo 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 terminé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.