De nombreuses organisations souhaitent tirer parti d’Azure Virtual Desktop pour créer des environnements qui ont plusieurs forêts Active Directory locales.
Cet article explore plus en détail l’architecture décrite dans l’article Azure Virtual Desktop à l’échelle de l’entreprise. Il est destiné à vous aider à comprendre comment intégrer plusieurs domaines et Azure Virtual Desktop à l’aide de Microsoft Entra Connect pour synchroniser les utilisateurs depuis Active Directory Domain Services (AD DS) en local avec Microsoft Entra ID.
Architecture
Téléchargez un fichier Visio de cette architecture.
Dataflow
Dans cette architecture, le flux d’identité fonctionne comme suit :
- Microsoft Entra Connect synchronise les utilisateurs de CompanyA.com et CompanyB.com vers un locataire Microsoft Entra (NewCompanyAB.onmicrosoft.com).
- Les pools d’hôtes, les espaces de travail et les groupes d’applications sont créés dans des abonnements et des réseaux virtuels spoke distincts.
- Les utilisateurs sont affectés aux groupes d’applications.
- Les hôtes de session Azure Virtual Desktop dans les pools d’hôtes sont joints aux domaines CompanyA.com et CompanyB.com à l’aide des contrôleurs de domaine dans Azure.
- Les utilisateurs se connectent à l’aide de l’application Azure Virtual Desktop ou du client web avec un nom d’utilisateur principal (UPN) au format suivant : user@NewCompanyA.com, user@CompanyB.com ou user@NewCompanyAB.com, selon leur suffixe UPN configuré.
- Les applications ou bureaux virtuels sont présentés respectivement à leurs utilisateurs. Par exemple, une application ou un bureau virtuel du pool d’hôtes 1 ou 2 de l’Espace de travail A, sont présentés aux utilisateurs de CompanyA.
- Les profils utilisateurs FSLogix sont créés dans les partages Azure Files sur les comptes de stockage correspondants.
- Les objets de stratégie de groupe (GPO) synchronisés à partir d’un emplacement local sont appliqués aux utilisateurs et aux hôtes de session Azure Virtual Desktop.
Composants
Cette architecture utilise les mêmes composants que ceux listés dans l’architecture Azure Virtual Desktop à l’échelle de l’entreprise.
De plus, cette architecture utilise les composants suivants :
Microsoft Entra Connect en mode de préproduction : la rubrique Serveur de préproduction pour les topologies Microsoft Entra Connect fournit une redondance supplémentaire pour l’instance Microsoft Entra Connect.
Abonnements Azure, espaces de travail Azure Virtual Desktop et pools d’hôtes : vous pouvez utiliser plusieurs abonnements, espaces de travail Azure Virtual Desktop et pools d’hôtes pour les limites d’administration et les besoins de l’entreprise.
Détails du scénario
Ce diagramme d’architecture représente un scénario typique qui contient les éléments suivants :
- Le locataire Microsoft Entra est disponible pour une nouvelle société nommée NewCompanyAB.onmicrosoft.com.
- Microsoft Entra Connect synchronise des utilisateurs de AD DS local vers Microsoft Entra ID.
- La Société A et la Société B ont des abonnements Azure distincts. Elles disposent également d’un abonnement des services partagés appelé Abonnement 1 dans le diagramme.
- Une architecture hub-and-spoke Azure est implémentée avec un réseau virtuel hub de services partagés.
- Les environnements Active Directory locaux hybrides sont présents avec deux forêts Active Directory ou plus. Les domaines résident dans des forêts distinctes, chacune ayant son propre suffixe UPN. Par exemple, CompanyA.local avec le suffixe UPN CompanyA.com, CompanyB.local avec le suffixe UPN CompanyB.com et un suffixe UPN supplémentaire, NewCompanyAB.com.
- Les contrôleurs de domaine des deux forêts se trouvent en local et dans Azure.
- Les domaines vérifiés sont présents dans Azure pour CompanyA.com, CompanyB.com et NewCompanyAB.com.
- L’authentification d’objet de stratégie de groupe et héritée, comme Kerberos, NTLM (Windows New Technology LAN Manager) et LDAP (Lightweight Directory Access Protocol) est utilisée.
- Pour les environnements Azure qui ont toujours une infrastructure locale de dépendance, une connectivité privée (VPN de site à site ou Azure ExpressRoute) est définie entre l’environnement local et Azure.
- L’environnement Azure Virtual Desktop se compose d’un espace de travail Azure Virtual Desktop pour chaque unité commerciale et deux pools d’hôtes par espace de travail.
- Les hôtes de session Azure Virtual Desktop sont joints à des contrôleurs de domaine dans Azure. Autrement dit, les hôtes de session CompanyA rejoignent le domaine CompanyA.local et les hôtes de session CompanyB rejoignent le domaine CompanyB.local.
- Les comptes de stockage Azure peuvent utiliser Azure Files pour les profils FSLogix. Un compte est créé par domaine d’entreprise (ici, CompanyA.local et CompanyB.local) et le compte est joint au domaine correspondant.
Remarque
Active Directory Domain Services est un composant auto-géré local de nombreux environnements hybrides, et Microsoft Entra Domain Services (Microsoft Entra Domain Services) fournit des services de domaine managés avec un sous-ensemble de fonctionnalités AD DS traditionnelles entièrement compatibles, comme la jonction de domaine, la stratégie de groupe, le protocole LDAP et l’authentification Kerberos/NTLM. Pour obtenir une comparaison détaillée de ces composants, consultez Comparer AD DS autogéré, Microsoft Entra ID et Microsoft Entra Domain Services managé.
L’idée de solution Plusieurs forêts Azure Virtual Desktop utilisant Microsoft Entra Domain Services traite de l’architecture qui utilise Microsoft Entra Domain Services géré dans le cloud.
Cas d’usage potentiels
Voici quelques cas d’usage pertinents pour cette architecture :
- Fusions et acquisitions, changement d’image d’une organisation et identités locales multiples
- Environnements Active Directory locaux complexes (plusieurs forêts, plusieurs domaines, exigences de stratégie de groupe (ou d’objet de stratégie de groupe) et authentification héritée)
- Infrastructure d’objet de stratégie de groupe locale avec Azure Virtual Desktop
Considérations
Lorsque vous concevez votre charge de travail basée sur cette architecture, gardez à l’esprit les idées suivantes.
Objets de stratégie de groupe
Pour étendre l’infrastructure GPO pour Azure Virtual Desktop, les contrôleurs de domaine locaux doivent être synchronisés avec les contrôleurs de domaine IaaS (Infrastructure as a Service) Azure.
L’extension de l’infrastructure GPO vers des contrôleurs de domaine Azure IaaS nécessite une connectivité privée.
Réseau et connectivité
Les contrôleurs de domaine étant des composants partagés, ils doivent être déployés dans un réseau virtuel hub de services partagés dans cette architecture hub-and-spoke.
Des hôtes de session Azure Virtual Desktop sont joints au contrôleur de domaine dans Azure par le biais de leur peering de réseaux virtuels hub-and-spoke respectifs.
Stockage Azure
Les considérations de conception suivantes s’appliquent aux conteneurs de profils d’utilisateurs, aux conteneurs de cache cloud et aux packages MSIX :
Vous pouvez utiliser aussi bien Azure Files qu’Azure NetApp Files dans ce scénario. Vous choisissez la solution appropriée en fonction de facteurs tels que les performances attendues, le coût, etc.
Les comptes de stockage Azure et Azure NetApp Files ont pour limite de se joindre à un seul service AD DS à la fois. Dans ce cas, plusieurs comptes de stockage Azure ou plusieurs instances Azure NetApp Files sont nécessaires.
Microsoft Entra ID
Dans les scénarios comprenant des utilisateurs dans plusieurs forêts Active Directory locales, un seul serveur de synchronisation Microsoft Entra Connect est connecté au locataire Microsoft Entra. Seule exception, un serveur Microsoft Entra Connect qui est utilisé en mode de préproduction.
Les topologies d’identité suivantes sont prises en charge :
- Plusieurs forêts Active Directory locales.
- Une ou plusieurs forêts de ressources approuvent toutes les forêts du compte.
- Une topologie de maillage complet permet aux utilisateurs et aux ressources de se trouver dans n’importe quelle forêt. En général, il existe des approbations bidirectionnelles entre les forêts.
Pour en savoir plus, lisez la section Serveur de préproduction pour les topologies Microsoft Entra Connect.
Contributeurs
Cet article est géré par Microsoft. Il a été écrit à l’origine par les contributeurs suivants.
Auteur principal :
- Tom Maher | Ingénieur de sécurité et d’identité senior
Étapes suivantes
Pour plus d’informations, consultez les articles suivants :
- Topologie Microsoft Entra Connect
- Comparez les différentes offres d'identité : Active Directory Domain Services (AD DS) autogéré, Microsoft Entra ID et Microsoft Entra Domain Services (Microsoft Entra Domain Services)
- Documentation Azure Virtual Desktop