Serveur d'impression

Vue d'ensemble de la multi-location dans l'infrastructure moderne Remote Desktop (RDmi) – Serveur d’impression

Par Titanfall , le 19 octobre 2019 - 16 minutes de lecture

Par Kristin L. Griffin et Benny Tritsch, avec l'aide de Freek Berson

En juin, nous avons publié un article sur l’infrastructure moderne Remote Desktop (RDmi). Dans cet article, nous avons expliqué le concept à la base de RDmi et évoqué certains des principaux avantages qu’il apporte. Une caractéristique, la multi-location, est un gros problème. Aujourd’hui, nous allons vous dire pourquoi et vous montrer comment cela fonctionne.

Le défi de la multi-location

L'infrastructure RDS d'origine n'a pas été créée dans l'optique de la multi-location, et son utilisation pour fournir des applications Win32 de manière sécurisée à plusieurs clients pose des problèmes.

Pour réduire les coûts, les fournisseurs d'hébergement essaient de partager des composants d'infrastructure RDS (passerelle RD, accès Web RD, courtier de connexion RD) entre plusieurs clients. Cependant, ils n'étaient pas vraiment destinés à être partagés.

La sécurité est également un défi, car les fournisseurs d’hébergement doivent garder les données des clients (locataires) complètement séparées les unes des autres, et les rôles RDS faisant face à Internet (passerelle RD et accès Web RD) doivent être liés au domaine afin expérience de connexion unique.

En raison de ces obstacles, certains CSP et MSP choisissent de déployer des environnements RDS complètement distincts pour chaque client. Cela résout les problèmes de sécurité, mais vous avez maintenant une surcharge administrative beaucoup plus importante et vous ne pouvez pas payer pour les ressources supplémentaires nécessaires à la prise en charge de tous les rôles RDS de chaque client.

Ainsi, comme nous l'avons mentionné, certains fournisseurs tentent de partager certains des rôles entre plusieurs clients. Ils utilisent un seul Active Directory, puis partagent les rôles d'accès Web RD, de passerelle et de courtier. Toutefois, cela représente un défi: du côté de la gestion, le fournisseur d’hébergement doit être très strict sur la sécurisation de l’accès aux données propres au client; et du côté des clients, les entreprises pourraient ne pas être en mesure d'utiliser leur propre marque ou avoir une expérience de connexion unique en douceur.

Parmi les autres problèmes liés aux déploiements multi-locataires, citons le contrôle d'accès basé sur les rôles (RBAC) pour les administrateurs, ainsi que l'intégration de l'authentification multi-facteurs (MFA), qui reposent tous deux sur Active Directory. RBAC exige que tous les locataires fassent partie du même AD (ou de plusieurs AD connectés) et MFA utilise également l’AD ou le AD Azure d’un client.

En un mot, il s’agit de conformité, de confiance et de contrôle. Les clients veulent leur propre AD isolé et ne veulent pas que les MSP créent des relations de confiance avec d’autres AD (les politiques de sécurité de certains clients peuvent même ne pas autoriser de relations de confiance).

L’équipe RDS a reconnu toutes ces difficultés et a décidé de remédier à la situation lors de la prochaine itération de RDS, l’infrastructure moderne Remote Desktop (RDmi).

Avantages de RDmi

L'une des plus grandes différences avec RDmi réside dans le fait qu'il utilise Azure AD au lieu d'Active Directory classique. Cela est formidable, car vous pouvez exploiter instantanément les identités basées sur le cloud, MFA et RBAC sans avoir à effectuer de configuration complexe. (Par exemple, dans RDS 2016, vous pouvez également utiliser Azure MFA, mais cela nécessite un serveur de stratégie réseau distinct et une configuration compliquée pour la passerelle RD.)

Le passage à Azure AD signifie également que les composants d'infrastructure de bureau à distance (bureau à distance, passerelle de bureau à distance et accès Web au bureau à distance) ne sont plus liés à un domaine. Pour les rôles RD Gateway et RD Web Access, il s'agit d'un énorme pas en avant en termes de sécurité.

Vous avez peut-être entendu ou participé à de longues discussions sur le fait de ne pas exposer les machines appartenant à un domaine à Internet, car cela augmenterait la surface d’attaque. Avant RDmi, les utilisateurs essayaient de limiter leur exposition aux passerelles RD / Accès Web RD en:

  • Création d'une passerelle DMZ pour RD avec des contrôleurs de domaine en lecture seule;
  • Utilisation de dispositifs de proxy inverse tiers; ou
  • Exécution du serveur de passerelle RD en mode groupe de travail.

Certaines de ces solutions fixes certains des enjeux de certains cas d'utilisation, mais aucun d'entre eux n'était une solution à l'épreuve des balles à 100%, et ils ont généralement sacrifié une expérience simple SSO. Avec RDmi, cette difficulté est de l'histoire.

Et encore une fois, la multi-location est l’une des meilleures fonctionnalités de RDmi, ce qui tient en partie au fait que les composants d’infrastructure ne sont pas liés à un domaine. L’infrastructure est déployée et gérée dans l’abonnement du fournisseur à l’aide de Azure AD du fournisseur, tandis que les hôtes de session sont déployés dans l’abonnement du locataire (ou du centre de données) à l’aide de Azure AD du locataire pour l’authentification. En raison de cette scission architecturale, RBAC permet également aux administrateurs de client de gérer leurs propres ressources tout en donnant aux MSP / CSP un accès aux ordinateurs virtuels spécifiques que le client souhaite gérer.

Enfin, un autre avantage important de RDmi est que les rôles d'infrastructure de RD sont des services .NET, exécutés en tant que services Azure Web App. L’avantage évident ici est que les administrateurs n’ont plus à gérer de machines virtuelles pour ces machines. Un avantage moins évident (mais très important) est qu'Azure Web Apps est automatiquement mis à l'échelle. Vous pouvez définir deux règles d'échelle (haut et bas) et, en quelques minutes, vous disposez d'une infrastructure à mise à l'échelle automatique.

Exigences RDmi

Pour configurer RDmi, vous avez besoin de:

  • Un abonnement Azure et un fournisseur d'hébergement d'infrastructure Azure AD pour RDmi.
  • Un abonnement Azure et Azure AD pour chaque locataire. Cela peut être créé par le fournisseur d'hébergement ou le locataire peut apporter son abonnement Azure existant et Azure AD.
  • Chaque Azure AD de chaque locataire doit être synchronisé avec les services de domaine Active Directory (dans le cloud ou sur site). (Cela est dû au fait que les hôtes de session sont liés à un domaine.)

Notre exemple de construction

Nous allons maintenant examiner la configuration de l'infrastructure multi-locataire dans RDmi, sur la base de la dernière version de Private Preview disponible. Nous vous montrerons également l'expérience utilisateur du point de vue du client.

Pour cet article, nous avons construit un environnement multi-locataire composé de:

  • Un «fournisseur de services cloud» (rdsgurus.com) hébergeant les rôles d’infrastructure RDmi dans Azure.
  • Deux locataires distincts (rdsgurus.cloud et rdmi.cloud).
  • Rdsgurus.com a également ses hôtes de session installés dans son centre de données local, de sorte qu’il fonctionne également en tant que locataire.

Chaque client hébergé a son propre abonnement, Azure AD et les services de domaine Active Directory.

Notre exemple de construction RDmi. (Cliquez pour agrandir.)

Pour le fournisseur de services hébergeur / cloud, nous avons configuré un abonnement Azure avec Azure Active Directory et nous l'avons synchronisé avec les services de domaine Active Directory s'exécutant sur site afin de pouvoir afficher un exemple de conception hybride.

Azure AD doit être associé aux abonnements des locataires pour pouvoir les connecter au déploiement RDmi (ce service fait partie de l'abonnement par défaut). Vous devez synchroniser Azure AD sur AD pour pouvoir utiliser des hôtes de session joints à un domaine et utiliser des comptes AD pour accéder au déploiement.

Voici quelques liens utiles si vous le faites vous-même:

Déploiement de l'infrastructure RDmi

RDmi est actuellement en aperçu technique. Nous ne décrirons pas chaque détail car les commandes et étapes exactes sont sujettes à modification. Cependant, nous allons décrire le processus au niveau fonctionnel.

Pour déployer l'infrastructure Rdmi, vous devez avoir les bits. Pour l'instant, les bits ne sont pas disponibles publiquement, mais ils se composent de plusieurs fichiers JSON et PS1. Lorsqu'ils sont disponibles, vous y accédez à partir de la galerie PowerShell. Ensuite, vous choisissez un emplacement dans l'abonnement pour héberger le déploiement. Vous créez un groupe de ressources dans lequel déployer l'infrastructure RDmi. Ensuite, vous êtes prêt à importer les modules PowerShell nécessaires et à exécuter les commandes PowerShell requises.

Importer des modules et se connecter
Importer les modules nécessaires (AzureRM et AzureAD) et connectez-vous à l'abonnement Azure de l'hébergeur à l'aide de Login-AzureRmAccount. Vous obtiendrez des écrans pour votre nom d'utilisateur et votre mot de passe.

La sortie PowerShell ressemblera à ceci:

Compte: MyAccount@rdsgurus.com
SubscriptionName: MySubsciptionName
SubscriptionId: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxxx
LocataireId: aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
Environnement: AzureCloud

Créer l'infrastructure RDmi
Vous êtes maintenant prêt à créer l'infrastructure RDmi. Vous exécutez une série de commandes PowerShell qui:

  1. Créez un coffre-fort de clés Azure avec des certificats initialisés et des applications client / Web dans Azure AD.
  2. Créez les rôles RDmi Infrastructure en tant que Azure Application Services. Il utilise un modèle ARM et référence les packages compressés pour chaque rôle. Étant donné que RD Broker utilise SQL, vous spécifiez également les informations d'identification SQL ici (SA, pas AD).

Lorsque le script s'exécute correctement, les URL du RD Web, du courtier RD, de la passerelle du RD et des diagnostics du RD sont générées. Il vous donne également le UPN admin et l'initializeDBSecret. Cela ressemble à ceci:

RDWeb: https://rdweb-some-random-digits.azurewebsites.net
RDBroker: https://rdbroker-same-random-digits.azurewebsites.net
RDGateway: https://rdgateway-same-random-digits.azurewebsites.net
RDDiagnostics: https://rddiagnostics-same-random-digits.azurewebsites.net
RDWebClient: https://rdweb-same-random-digits.azurewebsites.net:443/webclient/index.html
AdminUPN: MyAccount@rdsgurus.com
InitializeDBSecret: zzzzzzzz-zzzz-zzzz-zzzz-zzzzzzzzzzzzzz

Mapper un nom de domaine personnalisé
Le mappage d'un nom de domaine personnalisé sur les rôles d'infrastructure RDmi est facultatif, mais vivement recommandé pour les environnements de production, car cela intègre l'image de marque de votre entreprise. Pour le moment, cela ne fonctionne que pour le rôle d'accès Web RD, mais nous nous attendons à ce que cela fonctionne pour tous les rôles une fois que RDmi est défini sur GA. En gros, vous:

  1. Créez un enregistrement DNS pour associer votre nom de domaine personnalisé à l'adresse Web du bureau à distance que vous avez obtenue à la suite du déploiement de l'infrastructure. Nous avons utilisé un CNAME pour cartographier rdweb-some-random-digits.azurewebsites.net à rdmi.rdsgurus.com.
  2. Ajoutez ce mappage à l'application Web dans Azure et liez un certificat SSL pour ce nom de domaine personnalisé à l'application Web. Nous avons lié un certificat générique pour rdsgurus.com.

Suivez cet article pour voir comment nous l'avons fait pour l'application Web Accès Web RD.

Déploiement locataire

Maintenant que l’infrastructure RDmi est déployée, il est temps de configurer vos locataires. Pour ce faire, vous devez comprendre ce que vous construisez. Le déploiement du locataire comprend:

  • Le locataire: un «locataire» est l’espace désigné par le client dans le déploiement de RDmi. Il est relié aux abonnements Azure et Azure AD du client, mais est complètement distinct des autres clients. Dans le déploiement du client hébergé, vous créez «HostPools».
  • HostPools: un HostPool est un ensemble d’hôtes de session (résidant dans l’abonnement Azure du locataire ou dans le centre de données) ayant le même environnement applicatif.
  • Groupes d'applications: un HostPool héberge des «groupes d'applications» (AppGroups) décrivant quelles applications seront publiées et comment elles seront publiées (accès au bureau complet ou RemoteApp). Chaque hôte de session ne peut appartenir qu'à un seul HostPool, et tous les hôtes de session affectés à HostPool hébergent toutes les connexions à tous les groupes d'applications créés dans cet HostPool.
  • Utilisateurs du groupe d'applications: Ensuite, vous affectez des «utilisateurs d'AppGroup» qui auront accès à chaque groupe App. Les utilisateurs ne peuvent être attribués qu'à un seul groupe App dans le même HostPool, mais ils peuvent l'être également à des groupes App résidant dans plusieurs HostPools.
Cliquez pour agrandir

Nous allons maintenant expliquer comment vous créez le déploiement du client hébergé.

Autoriser l'accès RDmi à Azure AD du locataire
Pour permettre à l'infrastructure RDmi côté fournisseur d'hébergement de fonctionner avec les locataires, chaque locataire doit donner son accord pour autoriser l'application Web principale et l'application Web cliente RDmi à lire leur Azure AD. Vous faites cela deux fois, une fois pour l'option de consentement de l'application serveur, puis pour l'option de consentement de l'application client. Pour ce faire, connectez-vous au site Web de RDmi RD Web Access, sélectionnez chaque option de consentement et accordez les autorisations appropriées.

Il vous demandera de vous connecter, en utilisant un compte utilisateur de Azure AD du locataire, qui est autorisé à accorder le consentement. Il vous montre ensuite les autorisations que vous accordez à l'infrastructure RDmi.

Créer le locataire
Ensuite, l'hébergeur crée le locataire dans l'infrastructure RDmi et désigne les comptes d'utilisateurs locataires en tant qu'administrateurs.

À ce stade, le locataire peut créer son déploiement ou autoriser l'accès hébergeur à effectuer les étapes suivantes en son nom:

Connecté à l'infrastructure RDmi, dans PowerShell, vous:

  1. Ajoutez d'autres administrateurs de locataires et attribuez des rôles spécifiques en fonction des besoins. (Les administrateurs de locataires existants peuvent le faire.)
  2. Créez un HostPool et indiquez-lui d'utiliser «Connexion inversée». À l'aide de la connexion inversée (facultative mais fortement recommandée), les hôtes de session utilisent uniquement un port 443 sortant pour communiquer avec l'infrastructure RDmi. Aucun autre trou n'a besoin d'être percé dans le pare-feu!
  3. Créez les informations d'enregistrement (un hachage, au format texte, lié au HostPool) dont vous aurez besoin pour ajouter des hôtes de session à un HostPool particulier.

Dans l’abonnement du client, vous:

  1. Créer des hôtes de session.
  2. Ajoutez un serveur de licences et dites aux hôtes de la session de l’utiliser.
  3. Enregistrez les hôtes de session avec un HostPool et configurez-les pour utiliser la connexion inversée.
  4. Configurez un partage de fichiers pour les UPD. (Ceci est facultatif, mais nous le faisons dans tous nos exemples de locataires.)

Connecté à l'infrastructure RDmi, dans PowerShell, vous:

  1. Créez les AppGroups pour chaque HostPool.
  2. Attribuer des utilisateurs aux AppGroups.
  3. Créez des RemoteApps pour les AppGroups qui publient des RemoteApps.
  4. Configurez le (s) HostPool (s) pour utiliser les UPD.

Passons maintenant à la partie importante: l'expérience de l'utilisateur final.

Expérience utilisateur final pour le client RD

Lorsque vous démarrez le client RD, celui-ci est vide et vous devez donc ajouter un abonnement.

Entrez l’adresse du service de courtier RD (par exemple, https://rdmi.rdsgurus.com), vous serez ensuite invité à saisir les informations d'identification de l'utilisateur. Une fois que l'utilisateur s'est connecté, le flux est entré dans le registre à HKEY_CURRENT_USER Logiciel Microsoft Client Terminal Server Default FeedURLs.

Les applications attribuées à l'utilisateur apparaissent dans la fenêtre:

Cliquez sur l'icône de l'application pour démarrer RemoteApp (ou le bureau complet, le cas échéant). L'authentification unique ne fonctionne pas encore. Par conséquent, les noms d'hôte personnalisés ne sont pas appliqués. cependant, cela devrait être disponible dans GA. Pour l'instant, vous recevez l'avertissement «éditeur inconnu». Cochez l'option «Ne plus me demander de connexions à cet ordinateur» pour une meilleure expérience utilisateur.

(Remarque: pour annuler la case à cocher, supprimez la clé de registre sur: HKEY_CURRENT_USER Software Microsoft Client Terminal Server LocalDevices.)

Vous êtes invité à saisir à nouveau vos informations d'identification (cette étape sera éliminée avec SSO) et l'application se lancera (en tant qu'application RemoteApp dans ce cas). Voici notre exemple d'application:

Expérience utilisateur final pour le client Web

L'expérience utilisateur final du client Web est légèrement différente, car tout le travail est effectué dans le navigateur Web.

Ouvrez un navigateur et accédez au site Web d'accès Web RD Web pour le client Web. Dans cet exemple, l'URL est la suivante: https://rdmi.rdsgurus.com/webclient.

Cela vous redirige pour vous connecter à login.microsoftonline.com. Azure AD détermine ensuite le fournisseur d'identité utilisé pour l'authentification (c'est-à-dire Azure AD, ADFS, etc.).

Une fois que vous vous êtes connecté à votre fournisseur d'identité réel, Azure AD renvoie votre navigateur au site d'origine (le client Web RD) avec un jeton. Le site Web analyse le jeton et vous obtenez votre flux. Les applications que vous avez attribuées apparaissent dans la fenêtre du navigateur.

Cliquez sur une icône d'application pour démarrer l'application. Dans ce cas, vous êtes invité à autoriser la redirection du Presse-papiers et de l’imprimante.

Ensuite, l'application démarre dans la fenêtre du navigateur.

Et cela fonctionne dans la fenêtre du navigateur:

Démos vidéo

Vous pouvez voir le client Web RD au travail sur nos démonstrations vidéo. Nous en avons créé un pour l'expérience RemoteApp et l'un des postes de travail complets.

Sommaire

RDmi n’est pas simplement une mise à niveau d’une plate-forme existante. Comme elle est conçue pour franchir l’obstacle de la location multiple, il s’agit vraiment d’un nouveau produit. L'infrastructure fonctionne avec Azure AD, il n'est plus nécessaire de faire partie d'un domaine, nécessite moins de gestion des ressources et évolue automatiquement. Les locataires sécurisent leurs ressources AD et contrôlent également leur propre déploiement au sein de l'infrastructure RDmi.

Nous vous avons montré l'expérience utilisateur final utilisant à la fois le nouveau client RD et le client Web RD (et nous nous attendons à ce que cette expérience utilisateur devienne beaucoup plus fluide une fois que l'authentification unique est activée). Restez à l'écoute pour notre prochain article, dans lequel nous ajouterons MFA au déploiement multi-locataire de RDmi et montrerons à nouveau l'expérience de l'utilisateur final!

Click to rate this post!
[Total: 0 Average: 0]

Commentaires

Laisser un commentaire

Votre commentaire sera révisé par les administrateurs si besoin.