Publié pour la première fois sur TECHNET le janvier 24, 2014
Bonjour AskPerf! Kiran ici avec une question pour vous: Pourquoi avons-nous besoin de certificats? Eh bien, les certificats sont utilisés pour signer la communication entre deux machines. Lorsqu’un client se connecte à un serveur, l’identité du serveur qui reçoit la connexion et, à son tour, les informations du client, est validée à l’aide de certificats.
Ceci est fait pour prévenir d’éventuelles attaques de l’homme du milieu. Lorsqu’un canal de communication est configuré entre le client et le serveur, l’autorité qui émet/génère le certificat garantit l’authenticité du serveur.
Ainsi, tant que le client fait confiance au serveur avec lequel il communique, les données envoyées vers et depuis le serveur sont considérées comme sécurisées. Cela m’amène à la question suivante:
Quel type de certificat est requis pour RDS?
Le blog suivant contient des informations concernant le type de certificats et la façon dont vous pouvez les créer à l’aide de l’autorité de certification interne du domaine.
http://blogs.msdn.com/b/rds/archive/2010/04/09/configuring-remote-desktop-certificates.aspx
Exigences de base pour les certificats de bureau à distance:
- Le certificat est installé dans le magasin de certificats » personnel » de l’ordinateur.
- Le certificat a une clé privée correspondante.
- L’extension » Utilisation améliorée des clés » a une valeur de » Authentification du serveur » ou » Authentification du bureau à distance » (1.3.6.1.4.1.311.54.1.2). Des certificats sans extension » Utilisation améliorée des clés » peuvent également être utilisés.
Comme le suggère la fonction qu’il exécute, nous avons besoin d’un certificat d’authentification du serveur. Ce certificat peut être généré à l’aide du modèle ‘Workstation Authentication’ (si nécessaire).
Voici le processus exact:
- Ouvrez CERTSRV.MSC et configurez les certificats.
- Autorité de certification ouverte.
- Dans le volet Détails, développez le nom de l’ordinateur instructeur.
- Cliquez avec le bouton droit sur Modèles de certificats et sélectionnez Gérer. Cliquez avec le bouton droit sur Authentification du poste de travail et cliquez sur Dupliquer le modèle.
- Sous l’onglet Général, modifiez le nom d’affichage du modèle en Authentification Client-serveur et vérifiez Publier le certificat dans Active Directory.
- Sous l’onglet Extensions, cliquez sur Stratégies d’application, puis sur Modifier. Cliquez sur Ajouter, puis sélectionnez Authentification du serveur. Cliquez sur OK jusqu’à ce que vous reveniez à la boîte de dialogue Propriétés du nouveau modèle.
- Cliquez sur l’onglet Sécurité. Pour les ordinateurs de domaine, cochez la case » Autoriser l’inscription automatique « . Cliquez sur OK. Fermez la console Modèles de certificats.
- Dans le composant logiciel enfichable certsrv, cliquez avec le bouton droit sur Modèles de certificats et sélectionnez Nouveau puis Modèle de certificat à émettre.
- Sélectionnez Authentification Client-serveur, puis cliquez sur OK.
Cela sera visible lors de l’affichage du certificat dans le composant logiciel enfichable MMC ‘Certificats’, comme ci-dessous:
Lorsque vous ouvrez le certificat, l’onglet » Général » contiendra également le but de ce certificat d’être » Authentification du serveur » comme indiqué ci-dessous:
Une autre façon de valider cela serait d’aller dans la section « Détails » du certificat et de regarder la propriété « Utilisation améliorée de la clé »:
Le moyen le plus simple d’obtenir un certificat, si vous contrôlez les machines clientes qui se connecteront, consiste à utiliser les services de certificat Active Directory. Vous pouvez demander et déployer vos propres certificats et ils seront approuvés par toutes les machines du domaine.
Si vous souhaitez autoriser les utilisateurs à se connecter en externe et qu’ils ne feront pas partie de votre domaine, vous devrez déployer des certificats à partir d’une autorité de certification publique. Exemples comprenant, mais sans s’y limiter: GoDaddy, Verisign, Entrust, Thawte, DigiCert
Maintenant que vous savez de quel type de certificat vous avez besoin, parlons du contenu du certificat.
Dans Windows 2008/2008 R2, vous vous connectez au nom de la batterie, qui, selon DNS round robin, est d’abord dirigé vers le redirecteur, à côté du courtier de connexion et enfin vers le serveur qui hébergera votre session.
Dans Windows 2012, vous vous connectez au courtier de connexion et il vous achemine vers la collection en utilisant le nom de la collection.
Les certificats que vous déployez doivent avoir un nom de sujet ou un autre nom de sujet qui correspond au nom du serveur auquel l’utilisateur se connecte. Ainsi, par exemple, pour la publication, le certificat doit contenir les noms de tous les serveurs RDSH de la collection. Le certificat pour RDWeb doit contenir le nom de domaine complet de l’URL, en fonction du nom auquel les utilisateurs se connectent. Si des utilisateurs se connectent en externe, il doit s’agir d’un nom externe (qui doit correspondre à ce à quoi ils se connectent). Si des utilisateurs se connectent en interne à RDweb, le nom doit correspondre au nom interne. Pour l’authentification unique, le nom du sujet doit à nouveau correspondre aux serveurs de la collection.
Pour notre exemple, considérons que mon déploiement RDS contient les machines suivantes :
RDSH1.RENDER.COM Hôte de session avec des applications distantes configurées
RDSH2.RENDER.COM Hôte de session avec des applications distantes configurées
RDVH1.RENDRE.Hôte de virtualisation COM avec des machines virtuelles VDI configurées
RDVH2.RENDER.COM Hôte de virtualisation avec des machines virtuelles VDI configurées
RDCB.RENDER.COM Courtier de connexion
RDWEB.RENDER.COM Serveur RDWeb et passerelle
Lorsque mon client se connecte en interne, il entre le nom de domaine complet du serveur qui héberge la page Web, c’est-à-dire : RDWEB.RENDER.COM .
Le nom du certificat doit être ce nom, de l’URL à laquelle l’utilisateur va initier la connexion. Mais nous devons nous rappeler que la connexion ne s’arrête pas là. La connexion passe ensuite du serveur Web à l’un des hôtes de session ou des hôtes de virtualisation, ainsi qu’au courtier de connexion.
Le certificat peut être commun sur tous ces serveurs. C’est pourquoi nous recommandons que le nom alternatif Sujet du certificat contienne les noms de tous les autres serveurs faisant partie du déploiement.
En bref, le certificat pour mon environnement serait le suivant :
Type: Authentification du serveur
Nom: RDWEB.RENDER.COM
SAN: RDSH1.RENDER.COM ; RDSH2.RENDER.COM ; RDVH1.RENDER.COM ; RDVH2.RENDRE.COM; RDCB.RENDER.COM
C’est tout ce dont vous avez besoin tant que vous avez 5 serveurs ou moins dans le déploiement. Mais nous avons un problème lorsque nous avons plus de serveurs dans le déploiement. En effet, de par sa conception, le SAN (Nom alternatif du sujet) sur un certificat ne peut contenir que 5 noms de serveur. Si vous en avez plus, vous devrez obtenir un certificat générique pour couvrir tous les serveurs du déploiement. Ici, mon certificat change comme suit:
Type: Authentification du serveur
Nom: RDWEB.RENDER.COM
SAN: *.RENDRE.COM
Nous rencontrons encore des défis en ce qui concerne le scénario suivant. Notez que cela n’est vrai que lorsque vous avez des utilisateurs externes qui accèdent au déploiement.
Nom externe : RDWEB.RENDER.com
Nom interne : RDWEB.RENDRE.local
Ici, si vous obtenez un certificat avec RDWEB.RENDER.COM dans le nom, les erreurs de certificat apparaissent toujours. En effet, le certificat est censé valider un serveur avec le nom de domaine complet : ‘RDWEB.RENDER.COM ‘. Cependant, votre serveur est ‘RDWEB.RENDRE.LOCAL ‘ et le ‘.com’ à ‘.la magie locale se produit uniquement sur votre pare-feu / routeur public à l’aide de la redirection de port (scénario le plus courant).
Dans de tels scénarios, nous avions précédemment recommandé que le nom du certificat contienne le nom ‘.com’ et que le SAN contienne le ‘.nom local.
Récemment, tous les fournisseurs de certificats publics cessent d’émettre des certificats avec ‘.LOCAL » en eux. À partir de Windows 8 et Windows Server 2012, nous n’avons plus besoin que les noms externes et internes soient contenus dans le certificat.
Dans les scénarios où vous avez des clients externes qui se connectent et vous avez un suffixe de domaine interne privé (DOMAINE.LOCAL), vous pouvez obtenir un certificat d’une autorité de certification publiqueRDWEB.DOMAIN.COM ) nommez-le et liez-le aux rôles d’accès Web bureau à distance et de passerelle bureau à distance, car ce sont les seuls rôles exposés à Internet. Pour la publication du Courtier de connexion Bureau à distance et l’activation de l’authentification unique du Courtier de connexion Bureau à distance, vous pouvez utiliser un certificat interne avec le DOMAINE ‘.Nom LOCAL dessus. Cependant, comme mentionné précédemment, cela ne fonctionnera qu’avec les clients se connectant via RDC 8.0 ou supérieur.
La passerelle bureau à distance et le client de bureau à distance version 8.0 (et supérieure) fournissent aux utilisateurs externes une connexion sécurisée au déploiement. Une fois connecté au déploiement, le certificat interne avec le ‘.le nom local prendra en charge la signature d’applications à distance (publication) et l’authentification unique.
Maintenant, regardons où nous configurons le certificat que nous avons:
Ouvrez le Gestionnaire de serveur sur le serveur de courtier de connexion et cliquez sur Services Bureau à distance dans le volet le plus à gauche.
Une fois ici, vous verrez votre déploiement illustré comme dans l’illustration ci-dessous. Cliquez sur Tâches et sélectionnez » Modifier les propriétés du déploiement »
Cela fera apparaître la feuille de propriétés du déploiement. Sélectionnez l’option Certificats dans le volet de gauche:
Maintenant, comme indiqué précédemment, vous pouvez sélectionner le certificat créé à l’aide du bouton « Sélectionner un certificat existant » en bas de l’écran.
Pointez-le simplement sur le ‘.fichier pfx et lui permettre d’importer le certificat pour le rôle.
Vous pouvez utiliser un certificat unique pour tous les rôles, si vos clients sont internes au domaine uniquement, en générant un certificat générique simple (*.RENDRE.LOCAL) et le liant à tous les rôles.
Notez que même si plusieurs serveurs font partie de ce déploiement, le gestionnaire de serveur importera le certificat sur tous les serveurs du déploiement, les placera à la racine de confiance des machines et les liera aux rôles respectifs.
– Kiran Kadaba
