Lors de ma série Windows Azure Pack – IaaS : Introduction, j’avais fait l’impasse sur un sujet, la configuration de la Remote Desktop Gateway.
Â
Â
Â
J’avais laissé le sujet de côté car, il impliquait un peu plus de travail et surtout l’introduction d’un nouveau composant dans ma maquette : Remote Desktop Gateway. Fournir un accès directe aux machines virtuelles des locataires n’étant pas envisageable d’un point de vue sécurité, il était nécessaire de fournir un intermédiaire qui puisse s’assurer que le locataire ne puisse accéder qu’à ses machines virtuelles. A la différence de Microsoft Azure, Windows Azure Pack propose deux types d’accès :
- Remote Desktop
- Console
Â
Â
L’accès console est une nouveauté de Windows Server 2012 R2 aussi nommée « Enhanced session mode« . La fonctionnalité est intéressante car elle propose un accès RDS à la machine virtuelle via l’hôte Hyper-V. Cela signifie que même si la machine virtuelle ne dispose pas de connectivité Internet, on peut quand même y accéder.
Â
Â
Pour mettre en Å“uvre cela implique une authentification basée sur un certificat client. On va donc beaucoup parler de certificats dans ce billet et accessoirement de Remote Desktop Gateway interfacé avec notre SCVMM favoris. C’est une histoire de confiance car ce certificat permettra à notre Remote Desktop Gateway de s’authentifier auprès des hôtes Hyper-V, le tout piloté par SCSM. La mise en place se déroule en quatre étapes :
- La mise en place du gabarit de certificat
- Configuration de l’infrastructure SCVMM
- Mise en place de la Remote Desktop Gateway
- Reconfiguration de Windows Azure Pack
- Expérience utilisateur
Â
Â
La mise en place du gabarit de certificat
La partie fun, c’est par quel tour de magie la Remote Desktop Gateway va être ne mesure de savoir sur quel hôte Hyper-V est hébergé la machine virtuelle demandée et comment elle va s’authentifier. Tout commence avec le portail des locataires qui présente aux utilisateurs uniquement la ou les machines virtuelles auxquelles ils ont accès. Lorsque l’utilisateur demande l’accès à un de ses machines virtuelles, il faut générer un fichier RDS qui sera mis à disposition de l’utilisateur. C’est la Remote Desktop Gateway qui va s’occuper de cela.
Â
Â
Â
Â
Â
Â
Pour éviter que tout le monde de puisse demander à générer un fichier RDS, Microsoft utilise un certificat délivré par une autorité de certification interne. Il sera propagé à tous les hôtes Hyper-V grâce à SCVMM et consommé sur la Remote Desktop Gateway pour son usage « Client-Authentication ». On va donc commencer par générer ce gabarit de certificat un peu particulier car :
- L’usage du certificat est limité à l’infrastructure Windows Azure Pack, il n’a pas besoin d’être reconnu à l’extérieur
- Le certificat doit être exportable (avec sa clé privé)
- Il doit impérativement supporter SHA256
- Il doit référencer « Client Authentication » comme Extended Key Usage
Â
Â
Parmi nos gabarits de certificats, celui qui se rapproche le plus de cela, c’est le « Workstation authentication », il dispose déjà de l’Extended Key Usage dont nous avons besoin.
Â
Â
Â
Â
Parce que ce certificat ne sera utilisé que par des systèmes reposant sur Windows Server 2012 R2 (RDS, SCVMM, Hyper-V), on peut se permettre d’utiliser les options les plus avancées.
Â
Â
Â
Â
On va nommer le gabarit « RDS Console » et être généreux avec une durée de vie de deux ans.
Â
Â
Â
Â
Ensuite, on va s’assurer que ce certificat puisse être exportable avec sa clé privée. C’est essentiel car le certificat sera mis en place sur le ou les serveurs SCVMM ainsi que sur tous les serveurs Hyper-V.
Â
Â
Â
Â
Ici, l’essentiel, c’est que les demandes de certificats utilisent le fournisseur « Microsoft Enhanced RSA and AES Cryptographic Provider ». C’est une exigence de Windows Azure Pack.
Â
Â
Â
Â
Le nom indiqué dans le certificat étant un nom dépendant du DNS public, il est nécessaire de reconfigurer le gabarit de certificat pour qu’il utilise les informations contenues dans la demande de certificat et non pas le FQDN déclaré dans l’annuaire Active Directory.
Â
Â
Â
Â
Après, y a plus qu’à s’assurer que l’on puisse soumettre une demande de certificat.
Â
Â
Â
Â
Reste plus qu’Ã publier ce gabarit de certificat pour que nous puissions soumettre notre demande de certificat.
Â
Â
Â
Â
Configuration de l’infrastructure SCVMM
L’infrastructure SCVMM sera chargée de propager le certificat vers tous les hôtes Hyper-V. Ce sera donc sur ce serveur que nous allons réaliser la demande de certificat. Par contre, la demande est un peu particulière car sans notre intervention, le système d’exploitation n’est pas en mesure de la compléter. Il a besoin de notre aide.
Â
Â
Â
Â
On va commencer par compléter le subject Name. C’est un Common Name qui référence le nom public de ma RDS Gateway, donc CN=rdg.windowsazurepack.fr.
Â
Â
Â
Â
Ais-je besoin de Subject Alernative Name? Oui, si je suis en haute disponibilité. Dans ce cas, on ajoute aussi les FQDN de chaque serveur RDS Gateway impliqué dans la fermez ainsi que le nom associé à la VIP qui est utilisé pour la haute disponibilité (NLB/HLB). Ce n’est pas obligatoire mais pour d’y retrouver, le Friendly Name, c’est toujours bien.
Â
Â
Â
Â
La demande est maintenant complète, on peut la soumettre à notre autorité de certification interne.
Â
Â
Â
Â
Maintenant la subtilité. Ce certificat sera utilisé par SCVMM mais aussi par les hôtes Hyper-V. Il faudra donc le mettre à disposition de SCVMM au format PFX (avec la clé privée). Ce même certificat sera aussi utilisé par notre RDS Gateway (ou ferme RDS en cas de haute disponibilité). Pour cet usage, pas besoin de clé privée.
Â
Â
Pour la mise en place dans SCVMM, ça passe par un peu de Powershell. On indique à VMM que nous allons utiliser le même certificat sur SCVMM et sur les hôtes Hyper-V et que ce certificat est disponible dans un fichier PFX sécurisé par un mot de passe.
$Password = ReadHost -AsSecureString
$VMMServer = « SCVMM.WINDOWSAZUREPACK.LAN »
$PFX = « C:\TEMP\RDSConsole.PFX »
Set-SCVMMServer -VMMServer $VMMServer -VMConnectionHostIdentificationMode FQDN -VMConnectionGatewayCertificatePath $PFX -VMConnectGatewayCertificatePassword $Password -VMConnectHyperVCertificatePath $PFX -VMHyperVCertificatePassword $Password -VMConnectTimeToLiveInMinutes 1
Â
Â
Â
Â
Qu’est-ce que cela change sur nos Hyper-V? Déjà , il est présent dans le magasin personnel de tous les Hyper-V dépendant de mon infrastructure SCVMM
Get-ChildItem Cert:\LocalMachine\My -EKU « Client Authentication »
Â
Â
Â
Puis nos Hyper-V ont été configurés pour ne reconnaître que l’empreinte numérique du certificat que nous allons utiliser. Seul lui sera utilisable pour l’Enhanced session mode.
Get-WMIObject -ComputerName $Env:ComputerName -Namespace « Root\Virtualization\V2″ -Class MSVM_TerminalServiceSettingData »
Â
Â
Â
Au passage, petit rappel, ce ne sera pas le protocole RDS qui sera utilisé mais VMConnect (port 2179).
Â
Â
Â
Â
Mise en place de la Remote Desktop Gateway
Commençons avec le plus facile, avec la mise en place du rôle « Remote Desktop Gateway » sur un serveur dédié, membre de notre domaine. Il sera présenté sur Internet sous le nom de rdg.WindowsAzurePack.Fr, avec uniquement el flux HTTPS exposé. Qui dit HTTPS, dit certificat SSL mis en place sur le serveur avant de commencer. Coté mise en Å“uvre, c’est un sous-rôle du Remote Desktop Services (Nous sommes bien dans l’installation d’un rôle et non pas dans un déploiement RDS).
Â
Â
Â
Â
Lorsqu’on sélectionne le sous-rôle « Remote Desktop Gateway », il va automatiquement installer les composants dépendants (NPS, RPC over HTTP Proxy et le Web Server pour porter le tout). Nos locataires vont arriver en SSL, c’est la Gateway qui se chargera d’établir la connexion RDS pour leur compte vers les hôtes Hyper-V hébergeant la machine virtuelle demandée.
Â
Â
Â
Â
Une fois l’installation terminée, on lance la console RD Gateway. Elle nous indique tout de suite ce qui manque.
Â
Â
Â
Â
Plus précisément, le certificat utilisé par la Gateway pour sécuriser les connexions SSL. On va donc sélectionner le certificat que nous avons préalablement importé.
Â
Â
Â
Â
Vu que nous avons respectés les prérequis, le certificat avec le rôle attendu est déjà présent dans le magasin personnel du serveur. A noter que dans une mise en œuvre en haute disponibilité, le certificat devra être présent sur tous les serveurs de la ferme.
Â
Â
Â
Â
A ce stade, notre Remote Desktop Gateway est opérationnelle pour un usage RDS standard.
Â
Â
Â
Â
Je dis bien standard car le mode « Enhanced session » est un peu particulier. Nous avons besoin d’un composant additionnel présent sur le média d’installation de SCVMM 2012 R2, le System Center Virtual Machine Manager Console Gateway. Ce package est disponible sur le média d’installation du SCVMM 2012 R2 dans le répertoire AMD64\Setup\Msi\RDGateWayFedAuth.
Â
Â
Â
Â
Normalement, le rôle de la RDS Gateway est d’authentifier les utilisateurs avant qu’ils n’accèdent aux sessions RDS. Problème, dans le contexte de Windows Azure Pack, notre RDS Gateway n’a aucune idée du fournisseur d’identité à solliciter. Le package va donc modifier le mode de fonctionnement de la RDS Gateway pour réaliser une authentification à base de certificat.
Â
Â
Maintenant, on va commencer à transpirer un peu. Pour commencer, on va importer le certificat que nous avons obtenu sur le serveur SCVMM. Par contre, on n’a pas besoin de la clé privée qui va avec cette fois. Le certificat (livré au format CER) devra être importé dans le magasin « Local machine » du serveur Remote Desktop Gateway. La commande PowerShell Import-Certificate fera tout aussi bien l’affaire.
Â
Â
Â
Â
Note : Si plusieurs RDS Gateway (ferme RDS) alors, il faudra le faire sur tous.
Â
Â
C’est là que cela se complique. Il faut configurer la RDS Gateway pour utiliser notre certificat nouvellement importé. Il a une caractéristique bien précise : un EKU bien particulier. C’est ce que nous allons rechercher :
Get-ChildItem Cert:\LocalMachine\My -EKU « Client Authentication »
Â
Â
Â
Â
On va conserver cette information, elle va resservir immédiatement. Nous allons reconfigurer la RDS Gateway pour utiliser ce certificat. Pour la méthode, je ne l’invente pas, c’est repris du Technet : « Remote Console in System Center 2012 R2 »
$Thumbprint = « 43C301991A44386C08A8D2998AFD2CCDE74FB777 »
$TSData = Get-WmiObject -computername $Env:ComputerName -NameSpace « root\TSGatewayFedAuth2 » -Class « FedAuthSettings »
$TSData.TrustedIssuerCertificates = $Thumbprint
$TSData.Put()
Â
Â
Â
Â
Note : Attention, dans le contexte d’une ferme RDS, c’est sur chaque nÅ“ud qu’il faudra exécuter le script.
Â
Â
Reconfiguration de Windows Azure Pack
La reconfiguration dans Windows Azure Pack se déroule à deux niveaux. Au niveau du VM Clouds, on va renseigner notre nouvelle Remote Desktop Gateway.
Â
Â
Ou plutôt on devrait car il y a un petit bug à ce niveau. Lors de la rédaction de ce billet, je suis tombé sur un problème à ce niveau. Une fois la Remote Desktop Gateway déclarée depuis le portail d’administration de Windows Azure Pack, j’ai rapidement constaté que le Resource Provider VM Clouds ne répondait plus, que ce soit dans le portail d’administration ou celui des locataires. Après de nombreuses recherches, le problème se situait au niveau des informations enregistrées dans Service Provider Foundation (doublons). Mes recherches m’ont menées vers un excellent billet VM Cloud is missing in Windows Azure Pack. C’est une situation qui survient lorsqu’on déclare la RDS Gateway ultérieurement (comme c’est le cas de ce billet) ou lorsqu’on modifie la configuration existante à ce niveau. Donc dans notre cas on va suivre la démarche proposée par Kristian Nese, en PowerShell, depuis le serveur sur lequel est installé Service Provider Foundation :
Import-Module SPFAdmin
Get-SCSPFServer
$Stamp = Get-SCSpfStamp
$rdgw = « rdg.Windowsazurepack.Fr »
New-SCSPFServer -Name $rdgw -ServerType RDGateway -Stamps $Stamp
Get-SCSPFServer
Â
Â
De cette manière, on évite de se retrouver avec des doublons. Après cet interlude, c’est au niveau des souscriptions qu’il faut intervenir. Pour chaque souscription proposant le fournisseur « VM Clouds », il faut s’assurer que la case d’option « Connect to the console of virtual machines » est bien activée.
Â
Â
Â
Â
Expérience utilisateur
Coté locataire, c’est Client RDS 8.1 (Donc Windows 8.1) ou l’installation de la KB2830477 pour les clients Windows 7 obligatoire. Voilà pour les prérequis. Après le changement, c’est dans le portail des locataires qu’on le verra avec une option « Connect » qui est maintenant disponible pour ses machines virtuelles.
Â
Â
Â
Â
Lorsqu’il utilise l’option Console, il faut noter une information importante. C’est le fichier RDS qui donne accès réseau à l’hôte Hyper-V hébergeant la machine virtuelle du locataire. Donc ne pas laisser trainer ce fichier.
Â
Â
Â
Â
Un fichier RDS nous sera proposé. On voit bien qu’on passe par la Gateway RDS pour accéder à un hôte Hyper-V en particulier dans ma plateforme Windows Azure Pack.
Â
Â
Â
Â
Lorsque nos locataires vont se connecter, la Gateway n’est pas en capacité de traiter l’authentification. C’est là qu’invertirent le package System Center Virtual Machine Manager Console Gateway que nous avons installé. L’authentification est réalisée avec le certificat que nous avons mis à disposition sur la Remote Desktop Gateway.
Â
Â
Â
Â
L’hôte Hyper-V reconnaissant aussi ce certificat l’authentification est acceptée. On notera que la connexion initiée est bien en RDS mais pas sur le port attendu. C’est normal car c’est une session VMConnect.
Â
Â
L’option « Desktop » est un peu moins intéressante car elle propose un accès direct sans passer par la Remote Desktop Gateway. C’est donc beaucoup moins intéressant, sauf si une Gateway NVGRE est en place.
Â
Â
Â
Â
Conclusion
D’un point de vue sécurité, l’option console est bien plus intéressante puisque tous les connexions doivent nécessairement passer par la Remote Desktop Gateway. Elle assure aussi une rupture protocolaire car les clients se connectent à la Remote Desktop Gateway en HTTPS, pas en RDS. Subtilité supplémentaire, ce n’est pas une connexion RDS (port TCP/UDP 3389) qui est initiée mais une session VMConnect (port 2179). Enfin, parce qu’on se connecte à l’hôte Hyper-V pour accéder à la VM et non à la VM directement, on est en mesure d’accéder à la VM même si celle-ci n’est pas sur un réseau routable ou n’a pas de carte réseau.
Â
Â
Â
Â
BenoîtS – Simple and secure by design but Business compliant (with disruptive flag enabled)
Â
Â
Â
Â
Â
Â
Â
Â
Â
Â
Â
Â
Â
Â
Â
Â
Â
Â
Â
Â
Â
Â