Scénario 6 : AWS Microsoft AD, VPC à services partagés et confiance unidirectionnelle sur site - Bonnes pratiques pour le déploiement WorkSpaces

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Scénario 6 : AWS Microsoft AD, VPC à services partagés et confiance unidirectionnelle sur site

Ce scénario, comme illustré dans la figure suivante, utilise un Active Directory local existant pour les utilisateurs et introduit un Active Directory géré distinct dans le AWS cloud pour héberger les objets informatiques associés au WorkSpaces. Ce scénario permet de gérer les objets informatiques et les politiques de groupe Active Directory indépendamment de l'Active Directory d'entreprise.

Ce scénario est utile lorsqu'un tiers souhaite gérer Windows pour WorkSpaces le compte d'un client, car il permet au tiers de définir et de contrôler les WorkSpaces politiques qui lui sont associées, sans qu'il soit nécessaire de lui accorder l'accès à l'AD du client. Dans ce scénario, une unité organisationnelle (UO) Active Directory spécifique est créée pour organiser les objets WorkSpaces informatiques dans Shared Services AD.

Note

Amazon Linux a WorkSpaces besoin d'une confiance bidirectionnelle pour pouvoir être créés.

Pour déployer Windows WorkSpaces avec les objets informatiques créés dans le VPC Shared Services hébergeant Managed Active Directory en utilisant des utilisateurs du domaine d'identité du client, déployez un connecteur Active Directory (ADC) référençant l'AD de l'entreprise. Utilisez un compte de service ADC créé dans l'AD d'entreprise (domaine d'identité) doté d'autorisations déléguées pour créer des objets informatiques dans l'unité organisationnelle (UO) configurée pour Windows WorkSpaces dans l'AD géré par Shared Services et disposant d'autorisations de lecture sur l'Active Directory d'entreprise (domaine d'identité).

Pour garantir que la fonction Domain Locator est en mesure d'authentifier WorkSpaces les utilisateurs sur le site AD souhaité pour le domaine d'identité, nommez les sites AD des deux domaines pour les WorkSpaces sous-réseaux Amazon de la même manière, conformément à la documentation de Microsoft. Il est recommandé d'avoir à la fois des contrôleurs de domaine AD de domaine d'identité et de domaine de services partagés dans la même AWS région qu'Amazon WorkSpaces.

Pour obtenir des instructions détaillées sur la configuration de ce scénario, consultez le guide de mise en œuvre pour configurer une confiance unidirectionnelle pour Amazon WorkSpaces avec AWS Directory Services

Dans ce scénario, nous établissons une confiance transitive unidirectionnelle entre le AWS Managed Microsoft AD VPC Shared Services et l'AD sur site. La figure 11 montre le sens de la confiance et de l'accès, ainsi que la manière dont l' AWS AD Connector utilise le compte de service AD Connector pour créer des objets informatiques dans le domaine des ressources.

Une approbation forestière est utilisée conformément aux recommandations de Microsoft pour garantir que l'authentification Kerberos est utilisée dans la mesure du possible. WorkSpaces Vous recevez des objets de stratégie de groupe (GPO) de votre domaine de ressources dans le AWS Managed Microsoft AD. De plus, vous WorkSpaces effectuez une authentification Kerberos avec votre domaine d'identité. Pour que cela fonctionne de manière fiable, il est recommandé d'étendre votre domaine d'identité AWS comme indiqué ci-dessus. Pour plus de détails, nous vous suggérons de consulter le guide de mise en AWS Directory Service œuvre Deploy Amazon WorkSpaces using a One-Way Trust Resource Domain with One-Way.

L'AD Connector et le vôtre WorkSpaces doivent tous deux être en mesure de communiquer avec les contrôleurs de domaine de votre domaine d'identité et de votre domaine de ressources. Pour plus d'informations, consultez les exigences en matière d'adresse IP et de port WorkSpaces dans le guide d' WorkSpaces administration Amazon.

Si vous utilisez plusieurs connecteurs AD, il est recommandé que chacun d'eux utilise son propre compte de service AD Connector.

Exemple d'architecture illustrant un Windows WorkSpaces avec les objets informatiques créés dans le VPC Shared Services hébergeant Managed Active Directory en utilisant des utilisateurs du domaine d'identité du client.

Figure 11 : AWS Microsoft, VPC à services partagés et confiance unidirectionnelle envers AD sur site

Cette architecture utilise les composants ou constructions suivants :

AWS

  • Amazon VPC — Création d'un Amazon VPC avec au moins deux sous-réseaux privés répartis sur deux AZ : deux pour AD Connector et. WorkSpaces

  • Ensemble d'options DHCP : création d'un ensemble d'options DHCP Amazon VPC. Cela permet au client de définir un nom de domaine et un DNS (Microsoft AD) spécifiques. Pour plus d'informations, reportez-vous aux ensembles d'options DHCP.

  • Facultatif : passerelle privée virtuelle Amazon — Activez la communication avec un réseau appartenant au client via un tunnel VPN (VPN) ou une connexion IPSec. AWS Direct Connect À utiliser pour accéder aux systèmes principaux sur site.

  • AWS Directory Service : Microsoft AD est déployé dans une paire dédiée de sous-réseaux VPC (AD DS Managed Service), AD Connector.

  • Transit Gateway/VPC Peering : activez la connectivité entre le VPC Workspaces et le VPC Shared Services.

  • Amazon EC2 — Serveurs RADIUS « facultatifs » du client pour le MFA.

  • Amazon WorkSpaces : WorkSpaces sont déployés dans les mêmes sous-réseaux privés que l'AD Connector. Pour plus d'informations, reportez-vous à la section Active Directory : Sites et services de ce document.

Client