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 »

 

image001

 

Sélectionner« Computer Account », puis « Local Computer »

 

image002

 

Depuis le magasin « Personal », faire « All Tasks » puis« Import… »

 

image003

 

Sélectionner le fichier en .pfx préalablement créé, saisir le mot de passe communiqué lors de l’export de la clé privée,

 

image004

 

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.

 

image005

 

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.

image006

 

Mettre le certificat choisi en surbrillance, et cliquer sur « OK »

 

image007

 

Le certificat sélectionné sera alors affiché.

 

image008

 

Faire OK, pour appliquer les modifications.

 

Concernant les RemoteApp, ouvrir la MMC « RemoteApp Manager ».

Choisir le lien « Change » à coté de « Digital Signature Settings »

image009

 

Cocher la case « Sign with a digital certificate » et cliquer sur le bouton « Change».

image010

 

Choisir le certificat, et valider par « Ok »

 

image007

 

Le certificat choisi doit alors s’afficher dans l’interface, comme ceci :

image011

 

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.

 

image012

 

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 :

 

image013

  

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… ».

 

image014

 Sélectionner ensuite le protocole HTTPS, puis le bouton « Edit… »

 

image015

 Il ne reste plus qu’à sélectionner le certificat à employer, et à valider.

 

image016

 Un redémarrage du site Web est à prévoir.

image017

  

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.

 

image018

 

Choisir ensuite l’import de certificat.

 

image019

 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 ».

 

image020

 

Dans notre exemple, je l’ai nommée SSO for RDS.

image021

 

Faire ensuite Edit

 

image022

 

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… »

image023

 

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 ».

 

image024

 

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 »

image025

 

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 »

 

image026

 

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.

 

image027

 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.

 

 

rdwa

 

Philippe

Windows Core Support Escalation Engineer