RemoteApp- comment faire du SSO avec Remote DesktopService 2008 R2
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 leSubject 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 ».
9. Utilisation du site web RD Web Access
Une dernière chose est nécessaire pour que le SSO fonctionne correctement : il faut impérativement cocher la case “J’utilise un ordinateur privé” depuis le site RD Web Access.
Philippe
Windows Core Support Escalation Engineer
Comments
Anonymous
April 23, 2012
Bonjour, Comment faire du SSO dans un cas multi fermes ?Anonymous
November 26, 2014
Merci pour article, il est très bien. Il m'a beaucoup aidé à mettre en place le SSo sur RDP malgré quelques difficultés