Microsoft Windows Server 2008 R2 : Les certificats gèrent la sécurité RDS

  • Article

Certificats jouent un rôle énorme dans la sécurisation des connexions entre les clients et hôtes de Remote Desktop Services.

Kristin Griffin

Demander quels rôles utilisent des certificats est le type d'une question d'astuce. La vraie réponse est « tous. » Il est important de comprendre où vous devez utiliser des certificats dans les déploiements de Remote Desktop Services (RDS), et pourquoi vous les utilisez avec chaque service de rôle particulier RDS.

Vous aurez besoin de configurer la plupart des rôles, mais certains d'entre eux que vous ne (tels que le serveur de licences RD). Par défaut, vous aurez besoin de certificats SSL (x.509) à chaque étape de la connexion à une session ou hébergé machine virtuelle (VM). Vous utiliserez ces pour les trois objectifs principaux : pour sécuriser les communications entre le client et le serveur, afin de confirmer l'identité du serveur ou du site Web pour lequel le client se connecte et signe les fichiers de Remote Desktop Protocol (RDP) afin que vos utilisateurs connaissent le fichier RDP provient d'une source fiable et n'a pas été modifié.

Voici quelques exemples de comment RDS utilise des certificats :

  • Serveurs hôte de Session RD utilisent les certificats pour prouver leur identité. Cela s'appelle l'authentification du serveur.
  • Serveurs hôte de Session RD et hôte de virtualisation RD utiliser les certificats pour mettre en place un lien sécurisé entre le client et le serveur TLS 1.0.
  • RD Session hôte serveurs utilisent des certificats pour l'authentification du client pour l'authentification de niveau réseau (NLA), Single Sign-On (SSO) et application Web SSO.
  • Serveurs hôte de Session RD et RD connexion Broker utilisent un certificat SSL pour signer les fichiers RemoteApps et VM RDP, assurant aux utilisateurs qu'ils vous lancer un fichier de confiance.
  • Serveurs de passerelle RD utilisent des certificats pour crypter les communications avec les clients à l'aide de TLS 1.0.
  • Vous pouvez sécuriser le site de RD Web Access avec un certificat SSL pour s'assurer que les gens vont à un site de confiance (HTTPS).

Activation de la fonctionnalité RDS s'appuie sur des technologies spécifiques à l'appui de l'utilisation de certificats (voir Figure 1).

Enabling RDS functionality brings into play certain security technologies

La figure 1 fonctionnalité RDS permettant amène à jouent certaines technologies de sécurité.

Sécuriser le canal

TLS est la norme Internet Engineering Task Force (IETF) basée sur SSL version 3, publiée par Netscape. Parmi les améliorations apportées à TLS y nouveaux messages d'alerte, la capacité de certificats de la chaîne à un certificat d'autorité de certification (AC) intermédiaire au lieu du certificat d'AC racine et algorithmes de cryptage légèrement différente des certificats SSL.

Bien que TLS est basé sur SSL, les deux sont incompatibles. TLS peut, toutefois, mettre en oeuvre un mécanisme par lequel il peut se replier pour SSL version 3 si nécessaire. Pour établir un canal de communication sécurisée entre un client et un serveur à l'aide de TLS, le client et le serveur passent par un processus de messagerie, de réponse et de chiffrement (voir Figure 2).

The two-way encryption process for establishing a secure channel.

La figure 2 le processus de cryptage bidirectionnel pour établir un canal sécurisé.

Il y a deux conditions pour ce processus de fonctionner correctement.

  • Le client doit approuver l'autorité de certification qui signe le certificat du serveur SSL.
  • La connexion entre le serveur et le client doit utiliser de haut niveau (par défaut) ou cryptage Federal Information Processing Standard (FIPS). Cryptage faible crypte uniquement le trafic de client à serveur, pas de serveur à client, donc il n'est pas un moyen sécurisé pour envoyer des fonctions de sécurité ou des secrets partagés.

Si le niveau de cryptage et de connexion répond à ces deux exigences, le client et le serveur établissent la communication comme suit :

  1. Le client envoie un message hello avec une valeur aléatoire de longueur fixe. Le serveur répond avec une valeur aléatoire de longueur fixe. Lors de cet échange, le client indique au serveur le méthodes de compression, chiffrement et hachages que prend en charge. Il envoie également sa version de protocole et d'un ID de session sur le serveur. L'ID de session identifie la communi­canal cationique — ce n'est pas l'ID de Session sur un serveur hôte de Session RD.
  2. Le serveur choisit la méthode de cryptage plus haute qu'ils ont tous deux en charge et une fonction de chiffrement et de hachage de la liste du client. Puis il raconte le client qu'un il a cho­sen. S'il y a un niveau minimal défini pour le serveur et le client ne peut pas répondre à ce minimum, la connexion échoue.
  3. Le serveur envoie son certificat numérique du client. Ce certificat contient le nom du serveur, l'autorité de certification digne de confiance qui a signé le certificat et la clé publique du serveur.
  4. Le client vérifie que le certificat est valide et fiable. Le certificat utilisé pour signer le certificat de serveur sera dans le magasin d'autorités de Certification racines de confiance du client. Il crée ensuite un secret pre-master, crypte avec la clé publique du serveur et qu'il l'envoie au serveur.
  5. Le serveur reçoit et décrypte les secrets de pre-master avec sa clé privée. Ce serveur est le seul qui peut faire cela parce qu'il est le seul serveur avec la clé privée correspondante.
  6. Le serveur et le client ont le secret pre-master et nombres aléatoires ont échangé au début du processus. Ils utilisent ces valeurs afin de générer le secret de maître de 48 octets (également connu sous le nom le secret partagé). Après avoir généré le secret maître, suppriment le secret pre-master.
  7. Le client et le serveur puis le maître secret de 48 octets du hachage et l'utiliser pour générer le secret de MAC (la clé de session utilisée pour le hachage) et la clé de l'écriture (la clé de session utilisée pour le chiffrement). Ces clés de cryptent et décryptent la communication pour cette session. Issue de la session, les touches sont ignorées.

Si une étape de cette séquence ne fonctionne pas, la connexion n'a pas été entièrement garantie. Que se passe-t-il ensuite repose sur les paramètres de l'onglet avancé de la Connec bureau distant­tion (RDC) client. Dans le cas de l'échec de l'authentification, un utilisateur peut choisir de faire l'une des opérations suivantes :

  • Se connecter en tout cas sans en aviser le client il y avait un problème d'authentification du serveur.
  • Avertir le client, mais encore permettre la connexion (le paramètre par défaut).
  • Refuser la connexion si elle ne peut pas être vérifiée.

L'exception est si le serveur requiert un niveau de sécurité minimal. Si tel est le cas et que le client ne peut pas respecter le niveau minimum, la connexion échoue. Par défaut, le client et le serveur négocient et utiliser les paramètres de connexion plus sûrs, qu'ils ont tous deux en charge.

Titres de compétences de mise en cache avec CredSSP

Mise en cache des informations d'identification a été introduite avec Windows Vista et Windows Server 2008. Cela permet aux deux caractéristiques — qui permet à l'utilisateur et qui permet de protéger le serveur.

Mise en cache des informations d'identification permet aux utilisateurs de stocker des informations d'identification pour une connexion particulière donc ils n'ont de leur donner chaque fois qu'ils se connectent à ce serveur (il s'agit de SSO). Cela accélère la connexion. Sinon, une connexion par courtier doit être vérifiée à chaque étape.

Côté serveur, la mise en cache des informations d'identification fournit informations d'identification au serveur avant il établit une session. Cela évite les frais généraux d'une session si l'utilisateur n'est pas autorisée (c'est l'UÇK).

La pièce qui rend le travail de mise en cache des titres de compétence est le fournisseur de services de sécurité des informations d'identification (CredSSP). Cela est pris en charge par Windows 7, Windows Vista, Windows Server 2008 et Windows XP SP3. Il n'est pas lié à la version de la RDC parce que CredSSP fait partie du système d'exploitation utilisé. CredSSP exécute les fonctions suivantes :

  • Pour NLA, CredSSP fournit le cadre qui authentifie un utilisateur à un serveur hôte de Session RD avant tout établissement de la connexion.
  • Pour la reconnexion à une session dans une ferme, CredSSP accélère le processus de passage de la connexion sur le serveur approprié en laissant le serveur hôte de Session RD voir qui se connecte sans avoir à créer une session entière. NLA utilise dans un scénario légèrement différent.
  • De SSO, CredSSP stocke les informations d'identification utilisateur et les transmet au serveur hôte de Session RD pour automatiser l'ouverture de session.

CredSSP permet l'authentification mutuelle du client et serveur (voir Figure 3).

Authenticating both the server and client requires a secure channel.

Figure 3 authentifier le serveur et le client exige un canal sécurisé.

Ce processus d'authentification prend les mesures suivantes.

  1. Le client ouvre un canal sécurisé avec le serveur à l'aide de TLS. Le serveur transmet en retour le certificat avec son nom, le CA et la clé publique. Seul le serveur est identifié. À ce stade, le client reste anonyme.
  2. Lorsque la session est établie et une clé de session créée, CredSSP utilise le protocole Simple et protégé GSS-API négociation SPNEGO () à mutuellement authenti­cate le serveur et le client. Fondamentalement, ce mécanisme permet le client et le serveur s'entendre sur un mécanisme d'authentification, qu'ils ont tous deux en charge, tels que Kerberos ou Windows NT LAN Manager (NTLM).
  3. Après que l'authentification mutuelle est finie, CredSSP côté client crypte le certificat du serveur avec la clé de session créée au cours de l'étape 2 et qu'il l'envoie au serveur. Le serveur reçoit le certificat crypté, il déchiffre avec sa clé privée et ajoute ensuite au bit le plus significatif du numéro du certificat. Ensuite, il crypte le résultat et qu'il l'envoie au client. Assure le fonctionnement de ce dernier que personne ne peut intercepter les échanges entre le client et le serveur et usurpent le serveur.
  4. Le client examine le certificat crypté reçu par le serveur et com­pares il de son propre certificat.
  5. En supposant que les résultats correspondent, CredSSP côté client envoie les informations d'identification de l'utilisateur au serveur.

Authentifier l'identité du serveur

Un des dangers de communiquer avec un ordinateur distant, vous devez fournir vos informations d'identification, c'est que le serveur ne serait pas ce que vous pensez. Si c'est un serveur de rogue se faisant passer pour un digne de confiance, vous pouvez par mégarde taper vos informations d'identification dans le serveur. Cela donnerait tout ce que dont ils ont besoin pour se connecter à votre serveur ou de domaine attaquants.

RDP inclut le cryptage, mais le protocole n'a aucun moyen d'authentifier le serveur. C'est où TLS et CredSSP entrent. L'authentification de serveur vérifie le nom que vous entrez dans le client RDC (ou fichier RDP) contre le nom publié dans le certificat spécifié dans l'outil de Configuration de RD sur le serveur hôte de Session RD à laquelle elle est reliée.

Signature des fichiers RDP

Vous pouvez utiliser des certificats pour signer numériquement des fichiers de type RemoteApp, ainsi que les fichiers RDP utilisés pour se connecter à un pool ou personnelle VM (VDI). Signature de ces fichiers assure à l'utilisateur, qu'ils ont été créés par une source fiable. Elle assure également le fichier RDP de falsification.

Signature des fichiers de type RemoteApp est également requis pour la mise en oeuvre de Web SSO. Cela permet aux utilisateurs de signer en une fois sur le site Web de RD Web Access. Alors qu'ils peuvent lancer RemoteApps tout ferme sans avoir à fournir leurs informations d'identification à nouveau.

CredSSP ne peut passer des informations d'identification RD Web Access. L'utilisateur doit tout d'abord connectez-vous sur le site Web de stocker des informations d'identification. Alors ils ne doivent s'authentifier de nouveau pour démarrer des programmes RemoteApp. Pour fonctionner, le RemoteApps doit être signé et l'utilisateur doit approuver le certificat utilisé pour signer le RemoteApp.

Fichiers RDP créées lorsqu'un utilisateur lance une connexion RDP sous l'onglet ordinateurs de bureau RD Web Access sont créés à la volée. Les fichiers ne sont pas signés. Par conséquent, Web SSO ne fonctionne pas lors de la connexion à des ordinateurs de bureau. L'utilisateur devra se connecter au point de terminaison une fois la connexion établie. Web SSO ne fonctionne pas aussi pour les connexions à VMs commun ou personnels.

Sécurisation des connexions

RD passerelle utilise TLS 1.0 pour sécuriser les communications entre la passerelle RD et les clients de bureau distants, généralement situés à l'extérieur de votre réseau d'entreprise (sur Internet). TLS, comme décrit précédemment, il faut un certificat SSL. Vous pouvez également sécuriser les communications entre les clients et le serveur de RD Web Access à l'aide d'un certificat numérique pour chiffrer les sessions de site Web (HTTPS).

Les certificats sont une pièce essentielle d'un déploiement de RDS. RDS utilise des certificats pour sécuriser les communications et les fonctionnalités que permettent. Le mois prochain, je couvrirai la mise en place de services de rôle RDS à utiliser ces certificats.

Raymond Chen

Kristin Griffin est Remote Desktop Services MVP. Elle modère un forum de Microsoft dédié à aider la communauté informatique sur serveur (Remote Desktop Services) et tient à jour un blog RDS à blog.kristinlgriffin.com. Elle est un contributeur « Mastering Windows Server 2008 » de Mark Minasi (Sybex, 2008) et « Mastering Windows Server 2008 R2 » (Sybex, 2010). Elle a également coécrit « Microsoft Windows Server 2008 Terminal Services Resource Kit"(Microsoft Press, 2008) et"Microsoft Windows Server 2008 R2 Remote Desktop Services Resource Kit"(Microsoft Press, 2010) avec Christa Anderson.

Contenu associé