|
A travers cet article, je vais tenter d’expliquer comment mettre en place le SSO (Single Sign On) pour l’utilisation de RemoteApp publiées sous RDS 2008 R2. Pour les besoins de l’explication, je vais partir du principe que l’infrastructure en place est la suivante : - 1 domaine : core.lab - 1 ferme de 2 serveurs RDSH o RDSH1.core.lab o RDSH2.core.lab Le nom de la ferme est RDFARM.core.lab - 1 RD Connection Broker : RDCB.core.lab - 1 RD Web Access : RDWA.core.lab - 1 RD Gateway : RDGW : RDGW.core.lab La mise en place du SSO peut se décomposer en plusieurs phases : 1) Choix des certificats 2) Génération des certificats 3) Installation des certificats sur les différentes machines 4) Paramétrage des RD Session Hosts 5) Paramétrage du RD Connection Broker 6) Paramétrage du RD Web Access 7) Paramétrage du RD Gateway 8) Créations des GPOs 1. Choix des certificats Un ou plusieurs certificats devront être générés. Il y a besoin de certificat pour les éléments suivants : - Chaque serveur RD Session Host - Le serveur RD Connection Broker - Le serveur RD Web Access - Le serveur RD Gateway. Les serveurs RD Session Hosts et le serveur RD Connection Broker devront partager le même certificat. Les serveurs RD Web Access et RD Gateway peuvent chacun avoir un certificat différent. En conclusion, il nous faut au maximum 3 certificats différents. Le certificat des serveurs RD Session Host et du RD Connection Broker devra comporter les indications suivantes : CN=RDFARM.core.lab Le certificat du serveur RD Web Access devra comporter les indications suivantes : CN=RDWA.core.lab Le certificat du serveur RD Gateway devra comporter les indications suivantes : CN=RDGW.core.lab Il est possible de n’utiliser qu’un seul certificat pour tous ces serveurs. Il faudrait alors soit utiliser un wildcard de type *.core.lab dans le Subject Name, soit référencer les différents noms utiles, dans les champs SAN (Subject Alternative Name) du certificat. Il est à noter toutefois que seuls les clients RDC 6.1 et au-delà peuvent faire usage de ces possibilités. Pour l’utilisation de Subject Alternative Name dans notre exemple, il faudrait renseigner : Subject Name : CN=RDFARM.core.lab Subject Alternative Name : DNS= RDFARM.core.lab DNS= RDWA.core.lab DNS= RDGW.core.lab On retrouve le nom RDFARM.core.lab, aussi bien dans le Subject Name que dans le Subject Alternative Name. Cette répétition est volontaire. Pour la suite de cet article, je vais considérer que nous allons utiliser 3 certificats différents. 2. Génération des certificats Pour générer nos certificats, il existe 2 possibilités : - Utiliser une autorité de certification au sein du domaine Active Directory - Acheter vos certificats auprès de société telles que VeriSign ™, Thawte ™, et autres… Si l’ensemble des postes clients accédant à l’infrastructure visée sont sous contrôle de votre service informatique, vous pouvez vous contenter d’utiliser votre propre autorité de certification. En effet, si ces postes sont dans la même forêt que l’autorité de certification, il y aura une approbation automatique de celle-ci. Dans le cas contraire, ils devront être paramétrés pour approuver cette autorité de certification, et devront avoir un accès à la CRL (Certificate Revocation List) de celle-ci. Pour créer vos propres certificats, je vous invite à consulter cet article. 3. Installation des certificats sur les différentes machines Une fois les certificats créés, il faut les installer sur les différents serveurs concernés. Dans notre exemple, il s’agit des serveurs et certificats suivants : | Serveur | Certificat | | RDSH1.core.lab | RDFARM.core.lab | | RDSH2.core.lab | RDFARM.core.lab | | RDCB.core.lab | RDFARM.core.lab | | RDWA.core.lab | RDWA.core.lab | | RDGW.core.lab | RDGW.core.lab | Cela se fait de la manière suivante : Depuis l’un des serveurs en question, lancer une MMC en élévation de privilège, faire« Add or Remove Snap-ins ». Choisir le snap-in « certificate »  Sélectionner« Computer Account », puis « Local Computer »  Depuis le magasin « Personal », faire « All Tasks » puis« Import… »  Sélectionner le fichier en .pfx préalablement créé, saisir le mot de passe communiqué lors de l’export de la clé privée,  Sélectionner l’emplacement du certificat dans le magasin « Personal » et faire l’import. A la fin de l’opération, vous devez voir le certificat dans la console.  Cette opération est à refaire pour chacun des serveurs précédemment cités, avec leur certificat respectif. 4. Paramétrage des RD Session Hosts Sur les serveurs RD Session Hosts, il y a 2 choses à configurer : - Le protocole RDP - Les RemoteApp Pour le protocole RDP, cela se passe au niveau de la MMC : « Remote Desktop Session Host Configuration ». Ouvrir les propriétés de la connexion RDP-TCP, et dans l’onglet général, cliquer sur le bouton « Select » afin de sélectionner le certificat. 
Mettre le certificat choisi en surbrillance, et cliquer sur « OK »  Le certificat sélectionné sera alors affiché.  Faire OK, pour appliquer les modifications. Concernant les RemoteApp, ouvrir la MMC « RemoteApp Manager ». Choisir le lien « Change » à coté de « Digital Signature Settings » 
Cocher la case « Sign with a digital certificate » et cliquer sur le bouton « Change». 
Choisir le certificat, et valider par « Ok »  Le certificat choisi doit alors s’afficher dans l’interface, comme ceci : 
Faire la même opération avec l’autre serveur RD Session Host de la ferme. 5. Paramétrage du RD Connection Broker Sur le serveur RD Connection Broker, il y a 2 choses à configurer : - Le protocole RDP - Le certificat utilisé par le RD Connection Broker lui-même. Pour le protocole RDP, procéder exactement de la même façon que pour les serveurs RD Sessions Hosts, à l’aide de la MMC « Remote Desktop Session Host Configuration ». Pour le RD connection Broker, lancer la MMC « Remote Desktop Connection Manager ». Puis, sélectionner l’option pour mettre à jour le certificat.  Cocher la case « Sign with a digital certificate » et cliquer sur le bouton «Select ». Choisir le certificat, et valider par « Ok » Le certificat choisi doit alors s’afficher dans l’interface, comme ceci :  6. Paramétrage du RD Web Access Sur le serveur RD Web Access, il y a 2 choses à configurer : - Le protocole RDP - Le certificat utilisé par le protocole HTTPS. Pour le protocole RDP, procéder exactement de la même façon que pour les serveurs RD Sessions Hosts, à l’aide de la MMC « Remote Desktop Session Host Configuration ». Pour le protocole HTTPS, lancer la MMC « Internet Information Services (IIS) Manager ». Se positionner sur le « Default Web Site », puis sélectionner l’option de « Binding… ».  Sélectionner ensuite le protocole HTTPS, puis le bouton « Edit… » 
Il ne reste plus qu’à sélectionner le certificat à employer, et à valider.  Un redémarrage du site Web est à prévoir. 
7. Paramétrage du RD Gateway Sur le serveur RD Gateway, il y a 2 choses à configurer : - Le protocole RDP - Le certificat utilisé par le protocole HTTPS. Pour le protocole RDP, procéder exactement de la même façon que pour les serveurs RD Sessions Hosts, à l’aide de la MMC « Remote Desktop Session Host Configuration ». Pour le protocole HTTPS, cette fois ci, on va passer par le « RD Connection Manager » Lancer la MMC « RD Gateway Manager ». Puis, sélectionner l’option pour mettre à jour le certificat.  Choisir ensuite l’import de certificat.  Sélectionner ensuite le bon certificat, puis cliquer sur le bouton « Import », puis valider par « OK ». 8. Créations des GPOs Les GPOs à créer sont à mettre en place pour tous les postes clients qui souhaiteront exécuter des RemoteApp en faisant du SSO. Dans notre exemple, j’ai créé une OU « Desktop » dans laquelle j’ai déplacé tous les postes utilisateurs. Ensuite, depuis la MMC « Group Policy Management », il faut sélectionner l’OU en question, puis sélectionner « Create a GPO in this domain, and Link it here ».  Dans notre exemple, je l’ai nommée SSO for RDS. 
Faire ensuite Edit  La MMC« Group Policy Management Editor » s’ouvre alors. Aller dans« Computer Configuration\Policies\Administrative Templates\System\Credentials Delegation » Modifier le paramètre « Allow Delegating Default Credentials » Selectionner« Enabled », puis cliquer sur le bouton « Show… » 
Saisir ensuite le SPN pour les serveurs concernés. Dans notre exemple , il faut saisir le nom de notre ferme. Valider ensuite deux fois par « OK ».  Aller ensuite dans « Computer Configuration\Policies\Administrative Templates\Windows Components\Remote Desktop Connection Client » Le paramètre à modifier est « Specify SHA1 thumbprints of certificates representing trusted .rdp publishers » 
Le « thumbprint »ou « empreinte » est à récupérer sur le certificat de la ferme. Pour cela, depuis la console certificat, choisir le certificat RDFARM.core.lab, puis dans l’onglet « Details », récupérer les données du champ« Thumbprint »  Ces données sont à recopier, de préférence sans les espaces, pour éviter les« copier/coller » malheureux. En effet, selon ce qui est sélectionné, des caractères non affichables peuvent être inclus dans le presse-papier, et ainsi corrompre les données.  Une fois ceci fait et validé, la configuration du SSO est terminée. Pour que la GPO soit prise en compte, ne pas oublier de fermer la MMC « Group Policy Management Editor ». Philippe Windows Core Support Escalation Engineer  |
