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

L'utilisation de certificats est un élément important de la sécurisation des communications pour les services Bureau à distance. Voici le reste de l'histoire sur la façon de les installer sur chacun de vos serveurs.

Kristin Griffin

Certificats jouent un rôle important dans les déploiements de Remote Desktop Services (RDS). Ils aident à sécuriser les communications entre le client et le serveur. Ils confirment l'identité du serveur ou du site Web auquel vous êtes connecté. Il signe également les fichiers de Remote Desktop Protocol (RDP) pour vous assurer ils sont d'une source fiable.

Vous devez utiliser des certificats avec chaque service de rôle RDS. Voici ce que vous devez savoir pour installer les certificats sur chaque serveur de rôle à l'aide des outils des ou stratégie de groupe. Tout d'abord, vous configurez tous les hôte de Session RD par serveur connexion paramètres de sécurité de l'onglet général de la proto­col écouteur de la boîte de dialogue de l'outil de Configuration de RD. Pour s'y rendre, allez à outils administratifs | Services Bureau à distance | Desktop Session Host Configuration à distance. Puis double-cliquez sur RDP-Tcp dans la section connexions du volet central. C'est également où vous ajoutez le certificat du serveur SSL.

Vous pouvez configurer ces paramètres sur une base par serveur. Vous pouvez également configurer ces paramètres à l'aide de la stratégie de groupe en appliquant l'ensemble des paramètres d'objet de stratégie de groupe (GPO) suivants à l'hôte de Session RD serveur unité d'organisation (UO) à Configuration de l'ordinateur | Politiques | Modèles d'administration | Composants Windows | Services Bureau à distance | Hôte de Session bureau distant | Sécurité :

• Niveau de cryptage de connexion client set
• Nécessitent l'utilisation de la couche de sécurité spécifiques pour les connexions à distance (RDP)
• Modèle de certificat d'authentification serveur
• Exiger l'authentification des utilisateurs pour les connexions d'accès distant à l'aide de l'authentification réseau-niveau (NLA)

Authentification au niveau du réseau

NLA n'est pas requis par défaut. D'exiger l'utilisation de l'UÇK pour se connecter au serveur hôte de Session RD, sélectionnez l'ivants­mangé la case à cocher. Cela empêchera tout les clients qui ne supportent pas NLA (n'importe quel client exécute le RDC avant de version 6.x et tout système d'exploitation qui ne prennent en charge des titres de compétences Security Support Provider, ou CredSSP) de se connecter au serveur. CredSSP en charge uniquement les clients exécutant Windows 7, Windows Vista et Windows XP SP3.

Authentification du serveur

Définir le serveur de paramètres d'authentification de la section de la couche de sécurité. La valeur par défaut est négo­énumérés, sens que client et serveur seront tous les deux utiliser Transport Layer Security (TLS) pour l'authentification du serveur, si c'est sup­porté.

Vous pouvez modifier ce paramètre pour forcer l'authentification du serveur à l'aide de TLS. Si vous ne peut pas authentifier le serveur, vous pouvez définir le comportement du client des paramètres sous l'onglet avancé du Client Remote Desktop :

• Ne pas connecter si l'authentification échoue
• M'avertir si l'authentification échoue
• Toujours se connecter, même si l'authentification échoue

Vous pouvez choisir le certificat, que le serveur doit utiliser pour s'authentifier en cliquant sur Select près du bas de l'écran. Si vous cliquez sur Select, vous pouvez obtenir plus détails sur le certificat, y compris ce qu'il est utilisé, le nom de l'autorité de certification (CA), et lors de son expiration.

Le certificat doit contenir le nom DNS du serveur hôte de Session RD. Ce sera quelque chose comme rdsh1.domain.local, par exemple. Si vous avez mis en place une batterie de serveurs, le certificat doit contenir le nom DNS de la ferme de serveur hôte de Session RD — par exemple, farm.domain.local.

Le serveur hôte de Session RD est configuré pour utiliser un certificat auto-signé par défaut. Ce certificat n'est pas destiné à être utilisé dans des environnements de production pour trois raisons :

• Le certificat d'authenticité n'est pas du tout approuvé.
• Le certificat n'est pas approuvé par les clients parce qu'il n'est pas signé par une personne digne de confiance (comme une autorité de certification publique ou solution d'infrastructure à clé publique interne de votre entreprise).
• Si vous êtes mettant en œuvre une ferme, le nom du certificat par défaut ne correspond le nom de batterie de la serveur hôte de Session RD, afin de vérifier l'identité du serveur échoue.

Signature en commun et personnel SMV

Vous pouvez ont mis en commun et le personnels des machines virtuelles (VM) signé en installant un certificat SSL sur la RD connexion Broker à l'aide du gestionnaire de connexion RD (se Figure 1).

La figure 1 vous pouvez utiliser le gestionnaire de connexion RD pour signe commun ou uniques VMs.

Signature RemoteApps

Signer RemoteApps utilisant le certificat installé dans le gestionnaire RemoteApp sur le serveur hôte de Session RD (voir Figure 2).

La figure 2 vous pouvez également signer RemoteApps ; utiliser le certificat dans le gestionnaire RemoteApp.

Si vous configurez une ferme de serveur hôte de Session RD, assurez-vous d'installer le certificat même exact sur tous les serveurs de l'hôte de Session RD dans la ferme et dans les autres fermes que vous déployez. De cette façon Web single sign-on (SSO) travailleront à travers tous les membres de la ferme et toutes les fermes.

Pour ce faire, exportez le certificat, y compris la clé privée, d'un serveur. Importer l'autre serveur à l'aide du composant logiciel enfichable certificats dans la Console de gestion Microsoft (MMC), ajoutez le compte d'ordinateur, pas le compte d'utilisateur.

Si vous êtes mise en oeuvre de Web SSO avec RD Web Access et que vous êtes à l'aide de RD connexion Broker comme source de RD Web Access, puis vous devez installer le certificat même dans la RD connexion Broker que vous faites sur tous les serveurs hôte de Session RD (le même certificat que vous utilisez pour signer RemoteApps). Cela peut être source de confusion pour deux raisons :

1. La section où vous installer le certificat sur RD connexion Broker est appelée « Bureau virtuel : Ressources et Configuration, » qui est trompeur. Le certificat installé ici ne sert pas seulement pour la signature de VMs virtual desktop infrastructure (VDI), il est également utilisé dans le processus de Web SSO pour signature RemoteApps quand il s'agit de RD connexion Broker. Les certificats de signature de RD connexion Broker et hôte de Session RD serveur gestionnaire RemoteApp doivent correspondre ou Web SSO échouera.
2. Lorsque vous démarrez une application RemoteApp et que le certificat installé sur la RD connexion Broker est différent de celle installée sur les serveurs hôte de Session RD, Web SSO ne fonctionne pas. Rien n'indique, toutefois, le certificat est effectivement différent sur RD connexion Broker. La fenêtre contextuelle montre seulement le certificat défini dans le gestionnaire RemoteApp, donc il est difficile de dire qu'il y a un problème de certificat.

Vérifiez le blog « présentant Web Single Sign-On pour RemoteApp et Bureau Connections » pour plus d'informations sur la configuration Web SSO.

Sécurisation de la RD Web Access Site

Sécurisation d'un site Web n'est pas spécifique à RDS. Pour sécuriser le site Web de RD Web Access, ajoutez un certificat avec le nom DNS du site Web dans IIS (voir Figure 3).

Figure 3 Ajout d'un certificat avec le nom DNS peut garantir un site de RD Web Access.

Certificats installés dans le magasin de meubles ordinateur du serveur qui possède la clé privée incluse apparaîtront comme des options dans la zone déroulante correspondante dans le menu Edition.

Configuration de passerelle RD avec un certificat

L'installation de la passerelle RD exige un certificat pour chiffrer les communications entre le client et le serveur, notamment sur Internet. Le certificat SSL doit contenir le nom DNS du serveur passerelle RD qui peuvent résoudre des utilisateurs externes (le nom du DNS externe, par exemple : rdgateway.domain.com).

Vous installez le certificat de passerelle RD via l'onglet certificat SSL dans les propriétés du gestionnaire de passerelle RD (voir Figure 4). Voir plus d'informations sur RD passerelle certificats dans la bibliothèque TechNet.

Figure 4 installer le certificat de passerelle RD.

Vous pouvez configurer les certificats dans votre déploiement de RDS pour sécuriser les communications et authentifier le client et le serveur. Il y a des exigences de certificat spécifique pour chaque service de rôle. Cela devrait vous aider à comprendre pourquoi vous avez besoin de certificats dans les implémentations de RDS et comment et où mettre les certificats avec chaque service de rôle RDS.

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é

• Microsoft Windows Server 2008 R2 : Certificats lecteur RDS sécurité
• Windows Server 2008 R2 : Services Bureau à distance - Manuel du propriétaire
• Microsoft Windows Server 2008 R2 : Comprendre la RD connexion Broker

À l'aide de certificats avec RDS Q & A

**Q :**Comment puis-je ajouter les certificats sur mon serveur donc je peux les utiliser dans mes services du rôle Remote Desktop Services (RDS) ?

**R :**Certificats situés dans informatique compte personnel magasin votre serveur sera disponibles pour que vous puissiez ajouter des implémentations de RDS. Pour ajouter des certificats à l'ordinateur compte personnel magasin :

1. Créer un composant logiciel enfichable Microsoft Management Console (MMC) (type MMC dans la zone exécuter ou recherche)
2. Ajouter le composant logiciel enfichable certificats (fichier, ajouter/supprimer Snap-ins)
3. Choisir le compte d'ordinateur, ajouter, puis cliquez sur OK
4. Naviguez dans le dossier personnel, puis dans le dossier certificats
5. Faites un clic droit et choisissez importer pour importer le certificat que vous avez reçu de votre autorité de certification

Gestionnaire de passerelle RD est plus facile à cet égard parce qu'il vous donne un bouton importer dans l'interface de sorte que vous ne devez pas créer manuellement un composant logiciel enfichable MMC.

**Q :**Comment pour supprimer tous les messages d'avertissement lorsqu'un utilisateur démarre un fichier signé de Remote Desktop Protocol (RDP) ?

**R :**Activez le paramètre de stratégie. Spécifier le pouce Secure Hash Algorithm (SHA1) des certificats représentant les éditeurs .rdp approuvés. Lorsque vous activez cette stratégie, vous spécifiez les certificats que le client se verra comme dignes de confiance. Quand vous dites le client que fait confiance à un certificat, tout fichier RDP signé par ce certificat est approuvé. Ainsi, vous ne recevrez aucun pop-up d'avertissement vous demandant de vérifier que vous avez confiance à l'éditeur. Vérifiez ici pour plus d'informations sur ce paramètre.

Q: j'ai les certificats corrects en place sur les serveurs de mon hôte de Session RD, mais j'ai encore des problèmes de connexion.

**R :**Il y a quelques problèmes connus en matière de certificats et des implémentations de RDS :

1. À l'aide de certificats Server Gated Cryptography (SGC) semble causer des problèmes. Assurez-vous que vos certificats ne sont pas les certificats SGC. Pour plus d'informations, voir les threads de Forum RDS ici et ici.
2. Si votre connexion clients obtiennent l'erreur, « le certificat n'est pas valide pour cet usage, » la chaîne de certificats pour le certificat sur le serveur hôte de Session RD peut être trop longue. Voir ce fil Forum RDS pour plus d'informations.

**Q :**Puis-je utiliser un certificat wildcard ou un certificat de Storage Area Network (SAN) avec mon implémentation de RDS ?

**R :**Oui, vous pouvez. Un certificat SAN est un certificat qui a plus d'un nom d'hôte. Parce qu'un certificat SAN contient plusieurs noms de sujet, vous pouvez utiliser un seul certificat à plusieurs endroits qui nécessitent un certificat. Un exemple d'un certificat SAN pourrait être celui qui contient votre passerelle RD et vos noms de RD Web Access DNS, ainsi que le nom que vous allez utiliser pour signer vos fichiers RemoteApp :

• rdgateway.domain.com
• rdweb.domain.com
• Sign.domain.com

En utilisant un certificat wildcard, vous devez aussi peu que deux certificats pour mettre en œuvre un déploiement typique petite ferme. La ferme d'hôte de Session RD doit toujours référence au nom DNS de la ferme, et ce nom est généralement un nom DNS interne (domain.local). Ce n'est pas identique à celui de votre zone DNS externe (domain.com), donc vous aurez besoin d'avoir un certificat séparé pour cela.

**Q :**J'ai plusieurs services de rôle installés sur un serveur. Ai-je encore besoin d'installer des certificats dans tous les services de rôle, que j'ai utilisé ?

**R :**Oui. Chaque service de rôle utilise des certificats à des fins spécifiques. Même si les services de rôles peuvent être combinés sur un seul serveur, considérer comme des entités distinctes lorsque vous implémentez des certificats.

— K.G.