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énarios de déploiement d'AD DS
Amazon WorkSpaces est soutenu par le service d' AWS annuaire, et la conception et le déploiement appropriés du service d'annuaire sont essentiels. Les six scénarios suivants s'appuient sur les [services de domaine Active Directory présentés](https://docs.aws.amazon.com/quickstart/latest/active-directory-ds/architecture.html) *dans le guide de démarrage AWS rapide* et décrivent les meilleures pratiques en matière d'options de déploiement pour AD DS lorsqu'ils sont utilisés avec Amazon WorkSpaces. La section [Considérations relatives à la conception](using-multi-region-aws-managed-active-directory-with-amazon-workspaces.md) de ce document détaille les exigences spécifiques et les meilleures pratiques relatives à l'utilisation d'AD Connector pour WorkSpaces, ce qui fait partie intégrante du concept de WorkSpaces conception global.
+ **Scénario 1 : utilisation d'AD Connector pour l'authentification par proxy auprès d'AD DS sur site** — Dans ce scénario, la connectivité réseau (VPN/Direct Connect) est en place avec le client, toutes les authentifications étant transmises par proxy via AWS Directory Service (AD Connector) à l'AD DS local du client.
+ **Scénario 2 : extension d'AD DS sur site à AWS (Replica)** : ce scénario est similaire au scénario 1, mais ici, une réplique de l'AD DS du client est déployée AWS en combinaison avec AD Connector, réduisant ainsi le temps de latence des demandes d'authentification/de requête adressées à AD DS et au catalogue global AD DS.
+ **Scénario 3 : déploiement isolé autonome à l'aide du AWS Directory Service dans le AWS cloud** — Il s'agit d'un scénario isolé qui n'inclut pas la connectivité vers le client pour l'authentification. Cette approche utilise AWS Directory Service (Microsoft AD) et AD Connector. Bien que ce scénario ne repose pas sur la connectivité avec le client pour l'authentification, il prévoit le trafic des applications lorsque cela est nécessaire via un VPN ou Direct Connect.
+ **Scénario 4 : AWS Microsoft AD et confiance transitive bidirectionnelle vers le service local** — Ce scénario inclut le service géré AWS Microsoft AD (MAD) avec une confiance transitive bidirectionnelle vers la forêt Microsoft AD sur site.
+ **Scénario 5 : AWS Microsoft AD utilisant un VPC Shared Services** — Ce scénario utilise Managed AWS Microsoft AD dans un VPC Shared Services pour être utilisé comme domaine d'identité pour plusieurs services ( AWS Amazon EC2, Amazon WorkSpaces, etc.) tout en utilisant le connecteur AD pour transmettre par proxy les demandes d'authentification utilisateur LDAP (Lightweight Directory Access Protocol) aux contrôleurs de domaine AD.
+ **Scénario 6 : AWS Microsoft AD, Shared Services VPC et confiance unidirectionnelle avec AD sur site — Ce scénario est similaire au** scénario 5, mais il inclut des domaines d'identité et de ressources disparates utilisant une approbation unidirectionnelle sur site.
Vous devez prendre en compte plusieurs points lors de la sélection de votre scénario de déploiement pour les services de domaine Active Directory (ADDS). Cette section explique le rôle de l'AD Connector auprès d'Amazon WorkSpaces et aborde certaines considérations importantes lors de la sélection d'un scénario de déploiement ADDS. Pour plus d'informations sur la conception et la planification d' AWSADDS, consultez le [guide de AWS conception et de planification des services de domaine Active Directory](https://d1.awsstatic.com/whitepapers/adds-on-aws.pdf).
# Le rôle de l' AWS AD Connector auprès d'Amazon WorkSpaces
L'[AWS AD Connector](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/directory_ad_connector.html) est un service d' AWS annuaire qui agit comme un service proxy pour un Active Directory. Il ne stocke ni ne met en cache les informations d'identification utilisateur, mais transmet les demandes d'authentification ou de recherche à votre Active Directory, sur site ou sur site. AWS À moins que vous ne l'utilisiez AWS Managed Microsoft AD, c'est également le seul moyen d'enregistrer votre Active Directory (sur site ou étendu à AWS) pour une utilisation avec Amazon WorkSpaces (WorkSpaces).
Un AD Connector peut pointer vers votre Active Directory local, vers un Active Directory étendu à AWS (contrôleurs de domaine AD sur Amazon EC2) ou vers un. AWS Managed Microsoft AD
L'AD Connector joue un rôle important dans la plupart des scénarios de déploiement décrits dans les sections suivantes. L'utilisation de l'AD Connector WorkSpaces offre de nombreux avantages :
+ Lorsqu'ils sont dirigés vers l'Active Directory de votre entreprise, il permet à vos utilisateurs d'utiliser leurs informations d'identification professionnelles existantes pour se connecter à WorkSpaces d'autres services, tels qu'[Amazon WorkDocs](https://aws.amazon.com/workdocs/).
+ Vous pouvez appliquer de manière cohérente les politiques de sécurité existantes (expiration des mots de passe, verrouillage des comptes, etc.), que vos utilisateurs accèdent aux ressources de votre infrastructure sur site ou dans une infrastructure telle que. AWS Cloud WorkSpaces
+ L'AD Connector permet une intégration simple à votre infrastructure MFA existante basée sur Radius afin de fournir un niveau de sécurité supplémentaire.
+ Il permet de séparer vos utilisateurs. Par exemple, il permet de configurer un certain nombre d' WorkSpaces options par unité commerciale ou par personne, étant donné que plusieurs connecteurs AD peuvent pointer vers les mêmes contrôleurs de domaine (serveurs DNS) d'Active Directory pour l'authentification des utilisateurs :
+ Domaine cible ou unité organisationnelle pour une application ciblée des objets de stratégie de groupe (GPO) Active Directory
+ Différents groupes de sécurité pour contrôler le flux de trafic vers/depuis WorkSpaces
+ Différentes options de contrôle d'accès (appareils clients autorisés) et groupes de contrôle d'accès IP (limite d'accès aux plages d'adresses IP)
+ Activation sélective des autorisations d'administrateur local
+ Différentes autorisations en libre-service
+ Application sélective de l'authentification multifactorielle (MFA)
+ Placement de vos interfaces réseau WorkSpaces élastiques (ENI) dans différents VPC ou sous-réseaux à des fins d'isolation
Les connecteurs AD multiples permettent également de prendre en charge un plus grand nombre d'utilisateurs, si vous atteignez la limite de performance d'un seul connecteur AD, petit ou grand. Reportez-vous à la [Dimensionnement de AWS Managed Microsoft AD](#sizing-aws-managed-microsoft-ad) section pour plus de détails.
L'utilisation d'AD Connector WorkSpaces est gratuite, à condition que vous ayez au moins un WorkSpaces utilisateur actif dans un petit AD Connector et au moins 100 WorkSpaces utilisateurs actifs dans un grand AD Connector. Pour plus d'informations, consultez la page de [tarification des services d'AWS annuaire](https://aws.amazon.com/directoryservice/pricing/).
## L'importance de votre lien réseau AWS avec un Active Directory sur site
WorkSpaces repose sur la connectivité à votre Active Directory. Par conséquent, la disponibilité du lien réseau vers votre Active Directory est de la plus haute importance. Par exemple, si votre liaison réseau dans le [scénario 1](scenario-1-using-ad-connector-to-proxy-authentication-to-on-premises-active-directory-service.md) est en panne, vos utilisateurs ne pourront pas s'authentifier et ne pourront donc pas utiliser leur WorkSpaces.
Si un Active Directory sur site doit être utilisé dans le cadre du scénario, vous devez tenir compte de la résilience, de la latence et du coût du trafic de votre liaison réseau. AWS Dans un WorkSpaces déploiement multirégional, cela peut impliquer plusieurs liaisons réseau dans différentes AWS régions, ou plusieurs liaisons réseau avec AWS Transit Gateway un peering établi entre elles pour acheminer votre trafic AD vers le VPC connecté à votre AD sur site. Ces considérations relatives aux liens réseau s'appliquent à la plupart des scénarios décrits dans les sections suivantes, mais elles sont particulièrement importantes pour les scénarios dans lesquels votre trafic AD en provenance des connecteurs AD WorkSpaces doit traverser le lien réseau pour atteindre votre Active Directory sur site. [ Le scénario 1](scenario-1-using-ad-connector-to-proxy-authentication-to-on-premises-active-directory-service.md) met en évidence certaines des mises en garde.
## Utilisation de l'authentification multifactorielle avec WorkSpaces
Si vous envisagez d'utiliser la Multi-Factor Authentication (MFA) WorkSpaces avec, vous devez utiliser un AD AWS Connector ou AWS Managed Microsoft AD un AD Connector, car seuls ces services autorisent l'enregistrement de l'annuaire à utiliser WorkSpaces et à configurer RADIUS. Pour le placement de vos serveurs RADIUS, les considérations relatives aux liaisons réseau abordées dans la [L'importance de votre lien réseau AWS avec un Active Directory sur site](#network-link-to-aws-with-on-premises-ad) section s'appliquent.
## Séparer le compte du domaine de ressources
Pour des raisons de sécurité ou pour une meilleure gestion, il peut être souhaitable de séparer le domaine du compte du domaine des ressources. Par exemple, placez les objets WorkSpaces informatiques dans un domaine de ressources distinct, tandis que les utilisateurs font partie du domaine du compte. Une telle implémentation peut être utilisée pour permettre à une organisation partenaire de gérer l' WorkSpacesutilisation des politiques de groupe AD dans le domaine des ressources, sans pour autant renoncer au contrôle ni accorder l'accès au domaine du compte. Cela peut être accompli en utilisant deux Active Directory avec un Active Directory Trust configuré. Les sections suivantes traitent de cette question plus en détail :
+ [Scénario 4 : AWS Microsoft AD et une confiance transitive bidirectionnelle vers les environnements locaux](scenario-4-aws-microsoft-ad-and-a-two-way-transitive-trust-to-on-premises.md)
+ [Scénario 6 : AWS Microsoft AD, VPC à services partagés et confiance unidirectionnelle sur site](scenario-6-aws-microsoft-ad-shared-services-vpc-and-a-one-way-trust-to-on-premises.md)
## Déploiements Active Directory de grande envergure
Vous devez vous assurer qu'Active Directory Sites & Services est configuré en conséquence. Cela est particulièrement important si votre Active Directory est composé d'un grand nombre de contrôleurs de domaine situés dans différentes zones géographiques. Votre Windows WorkSpaces utilise le [mécanisme standard de Microsoft](https://social.technet.microsoft.com/wiki/contents/articles/24457.how-domain-controllers-are-located-in-windows.aspx) pour découvrir son contrôleur de domaine pour le site Active Directory auquel il est affecté. Ce processus DC Locator repose sur le DNS et peut être considérablement prolongé si une longue liste de contrôleurs de domaine dont la priorité et le poids ne sont pas spécifiques est renvoyée au début du processus DC Locator. Plus important encore, si WorkSpaces vous êtes « épinglé » sur un contrôleur de domaine sous-optimal, toutes les communications ultérieures avec ce contrôleur de domaine peuvent être affectées par une latence réseau accrue et une réduction de la bande passante lorsque vous traversez des liaisons réseau étendues. Cela ralentira toute communication avec le contrôleur de domaine, y compris le traitement d'un nombre potentiellement important d'objets de stratégie de groupe (GPO) et les transferts de fichiers depuis le contrôleur de domaine. En fonction de la topologie du réseau, cela peut également augmenter vos coûts de mise en réseau, car les données échangées entre WorkSpaces les contrôleurs de domaine peuvent emprunter inutilement un chemin réseau plus coûteux. Reportez-vous aux [Considérations relatives à la conception](design-considerations.md) sections [Conception en VPC](design-considerations.md) et pour obtenir des conseils sur le DHCP et le DNS dans le cadre de la conception de votre VPC, ainsi que sur les sites et services Active Directory.
## Utilisation de Microsoft Azure Active Directory ou des services de domaine Active Directory avec WorkSpaces
Si vous avez l'intention d'utiliser Microsoft Azure Active Directory avec WorkSpaces, vous pouvez utiliser Azure AD Connect pour synchroniser votre identité avec votre Active Directory local ou avec votre Active Directory sur AWS (contrôleur de domaine sur Amazon EC2 AWS Managed Microsoft AD ou). Toutefois, cela ne vous permettra pas de WorkSpaces rejoindre votre Azure Active Directory. Pour plus d'informations, consultez la [documentation Microsoft Hybrid Identity](https://docs.microsoft.com/en-us/azure/active-directory/hybrid/) dans la *documentation Microsoft Azure*.
Si vous souhaitez vous connecter WorkSpaces à Azure Active Directory, vous devez déployer les services de domaine Microsoft Azure Active Directory (Azure AD DS), établir une connectivité entre Azure AWS et Azure et utiliser un connecteur AWS AD pointant vers vos contrôleurs de domaine Azure AD DS. Pour plus d'informations sur la façon de configurer cela, consultez le billet de blog [Ajouter votre WorkSpaces compte à Azure AD à l'aide des services de domaine Azure Active Directory](https://aws.amazon.com/blogs/desktop-and-application-streaming/add-your-workspaces-to-azure-ad-using-azure-active-directory-domain-services/).
Lorsque vous utilisez AWS Directory Service s with WorkSpaces, vous devez tenir compte de la taille de votre WorkSpaces déploiement et de sa croissance attendue afin de déterminer la taille AWS Directory Service appropriée. Cette section fournit des conseils sur le dimensionnement AWS Directory Service à utiliser avec WorkSpaces. Nous vous recommandons également de consulter les [meilleures pratiques pour AD Connector](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ad_connector_best_practices.html) et les [meilleures pratiques pour les AWS Managed Microsoft AD](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_best_practices.html) sections du *Guide d'AWS Directory Service administration*.
## Dimensionnement de l'AD Connector avec WorkSpaces
Le connecteur Active Directory (AD Connector) est disponible en deux tailles, petite et grande. Bien qu'aucune limite d'utilisateur ou de connexion ne soit imposée, nous recommandons d'utiliser un petit AD Connector pour un maximum de 500 utilisateurs WorkSpaces autorisés, et un AD Connector de grande taille pour un maximum de 5 000 utilisateurs WorkSpaces autorisés. Vous pouvez répartir la charge des applications sur plusieurs AD Connector afin de répondre à vos besoins en termes de performances. Par exemple, si vous devez prendre en charge 1 500 WorkSpaces utilisateurs, vous pouvez répartir le vôtre de WorkSpaces manière égale sur trois petits AD Connector, chacun prenant en charge 500 utilisateurs. Si tous vos utilisateurs résident dans le même domaine, l'AD Connector peut tous pointer vers le même ensemble de serveurs DNS résolvant votre domaine Active Directory.
Remarque : si vous avez commencé avec un petit AD Connector et que votre WorkSpaces déploiement s'étoffe au fil du temps, vous pouvez créer un ticket d'assistance pour faire passer la taille de votre AD Connector de petite taille à grande afin de prendre en charge le plus grand nombre d'utilisateurs WorkSpaces autorisés.
## Dimensionnement de AWS Managed Microsoft AD
[AWS Managed Microsoft AD](https://aws.amazon.com/directoryservice/active-directory/)vous permet d'exécuter Microsoft Active Directory en tant que service géré. Vous pouvez choisir entre l'édition Standard et l'édition Enterprise lorsque vous lancez le service. L'édition Standard est recommandée pour les petites et moyennes entreprises comptant jusqu'à 5 000 utilisateurs et prend en charge environ 30 000 objets de répertoire, tels que des utilisateurs, des groupes et des ordinateurs. L'édition Enterprise est conçue pour prendre en charge jusqu'à 500 000 objets de répertoire et propose également une fonctionnalité supplémentaire, telle que [la réplication multirégionale](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_configure_multi_region_replication.html).
Si vous devez prendre en charge plus de 500 000 objets d'annuaire, envisagez de déployer des contrôleurs de domaine Microsoft Active Directory sur Amazon EC2. Pour le dimensionnement de ces contrôleurs de domaine, reportez-vous au document de [planification des capacités pour les services de domaine Active Directory](https://docs.microsoft.com/en-us/windows-server/administration/performance-tuning/role/active-directory-server/capacity-planning-for-active-directory-domain-services) de Microsoft.
# Scénario 1 : utilisation du connecteur AD pour l'authentification par proxy auprès du service Active Directory local
Ce scénario s'adresse aux clients qui ne souhaitent pas étendre leur service AD sur site à ou pour lesquels un nouveau déploiement d'AD DS n'est pas une option. AWS La figure suivante montre, à un niveau élevé, chacun des composants et le flux d'authentification utilisateur.
![\[Exemple d'architecture présentant à un haut niveau chaque composant et chaque flux d'authentification utilisateur.\]](http://docs.aws.amazon.com/fr_fr/whitepapers/latest/best-practices-deploying-amazon-workspaces/images/ad-connector-to-onprem.png)
Dans ce scénario, le AWS Directory Service (AD Connector) est utilisé pour toutes les authentifications utilisateur ou MFA transmises par proxy via l'AD Connector à l'AD DS sur site du client (détaillé dans la figure suivante). Pour plus de détails sur les protocoles ou le cryptage utilisés pour le processus d'authentification, reportez-vous à la [Sécurité](security.md) section de ce document.
![\[Exemple d'architecture montrant comment AD Connector est utilisé pour toutes les authentifications utilisateur ou MFA transmises par proxy à l'AD DS sur site du client.\]](http://docs.aws.amazon.com/fr_fr/whitepapers/latest/best-practices-deploying-amazon-workspaces/images/user-authentication-auth-gateway.png)
Le scénario 1 montre une architecture hybride dans laquelle le client possède peut-être déjà des ressources AWS, ainsi que des ressources dans un centre de données sur site accessible via Amazon WorkSpaces. Le client peut tirer parti de ses serveurs AD DS et RADIUS sur site existants pour l'authentification des utilisateurs et l'authentification MFA.
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.
+ **Ensemble d'options DHCP** : création d'un ensemble d'options DHCP Amazon VPC. Cela permet de définir des noms de domaine et des serveurs de noms de domaine (DNS) (services sur site) spécifiés par le client. Pour plus d'informations, reportez-vous aux [ensembles d'options DHCP](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_DHCP_Options.html).
+ **Amazon Virtual Private Gateway** — Activez la communication avec votre propre réseau via un tunnel VPN IPSec ou une AWS Direct Connect connexion.
+ **AWS Directory Service** — AD Connector est déployé dans une paire de sous-réseaux privés Amazon VPC.
+ **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](design-considerations.md#active-directory-sites-and-services) de ce document.
## Client
+ **Connectivité réseau** : points de terminaison VPN d'entreprise ou Direct Connect.
+ **AD DS** — AD DS d'entreprise.
+ **MFA (facultatif)** : serveur RADIUS d'entreprise.
+ Appareils destinés aux **utilisateurs finaux : appareils** destinés aux utilisateurs finaux destinés aux entreprises ou aux appareils BYOL (tels que Windows, Mac, iPad, tablettes Android, clients zéro et Chromebooks) utilisés pour accéder au service Amazon. WorkSpaces Consultez [cette liste d'applications clientes pour les appareils et les navigateurs Web pris en charge](https://docs.aws.amazon.com/workspaces/latest/userguide/workspaces-user-getting-started.html#choose-client).
Bien que cette solution soit idéale pour les clients qui ne souhaitent pas déployer AD DS dans le cloud, elle comporte certaines réserves :
+ **Dépendance accordée à la connectivité** : en cas de perte de connectivité au centre de données, les utilisateurs ne peuvent pas se connecter à leurs serveurs respectifs WorkSpaces, et les connexions existantes resteront actives pendant toute la durée de vie du ticket Kerberos/Ticket Grant Ticket (TGT).
+ **Latence** — Si la latence existe via la connexion (c'est davantage le cas avec un VPN qu'avec Direct Connect), l' WorkSpaces authentification et toute activité liée à AD DS, telle que l'application de la politique de groupe (GPO), prendront plus de temps.
+ **Coûts liés au trafic** — Toutes les authentifications doivent passer par le VPN ou le lien Direct Connect, et cela dépend donc du type de connexion. Il s'agit soit d'un transfert de données sortant d'Amazon EC2 vers Internet, soit d'un transfert de données sortant (Direct Connect).
**Note**
AD Connector est un service proxy. Il ne stocke ni ne met en cache les informations d'identification des utilisateurs. Au lieu de cela, toutes les demandes d'authentification, de recherche et de gestion sont gérées par votre AD. Un compte doté de privilèges de délégation est requis dans votre service d'annuaire et autorisé à lire toutes les informations utilisateur et à associer un ordinateur au domaine.
En général, l' WorkSpaces expérience dépend fortement du processus d'authentification Active Directory illustré dans la figure précédente. Dans ce scénario, l'expérience WorkSpaces d'authentification dépend fortement de la liaison réseau entre l'AD du client et le WorkSpaces VPC. Le client doit s'assurer que le lien est hautement disponible.
# Scénario 2 : extension des services AD DS locaux à AWS (réplique)
Ce scénario est similaire au scénario 1. Toutefois, dans ce scénario, une réplique de l'AD DS du client est déployée AWS en combinaison avec AD Connector. Cela réduit la latence des demandes d'authentification ou de requête adressées à AD DS s'exécutant sur Amazon Elastic Compute Cloud (Amazon EC2). La figure suivante montre une vue globale de chacun des composants et du flux d'authentification utilisateur.
![\[Exemple d'architecture montrant une réplique de l'AD DS du client sur laquelle est déployée AWS en combinaison avec AD Connector.\]](http://docs.aws.amazon.com/fr_fr/whitepapers/latest/best-practices-deploying-amazon-workspaces/images/extend-customer-ad-cloud.png)
Comme dans le scénario 1, AD Connector est utilisé pour toutes les authentifications utilisateur ou MFA, qui sont à leur tour transmises par proxy aux services de domaine Active Directory du client (voir [la](scenario-1-using-ad-connector-to-proxy-authentication-to-on-premises-active-directory-service.md#fig5) figure précédente). Dans ce scénario, les services de domaine Active Directory du client sont déployés sur des instances Amazon EC2 qui sont promues en tant que contrôleurs de domaine dans la [forêt AD](https://ipwithease.com/what-is-a-forest-in-active-directory/) locale du client, s'exécutant dans le cloud. AWS Chaque contrôleur de domaine est déployé dans des sous-réseaux privés VPC afin de rendre AD DS hautement disponible dans le cloud. AWS Pour connaître les meilleures pratiques relatives au déploiement d'AD DS sur AWS, reportez-vous à la section [Considérations relatives à la conception](using-multi-region-aws-managed-active-directory-with-amazon-workspaces.md) de ce document.
Une fois les WorkSpaces instances déployées, elles ont accès aux contrôleurs de domaine basés sur le cloud pour des services d'annuaire et un DNS sécurisés à faible latence. Tout le trafic réseau, y compris les communications AD DS, les demandes d'authentification et la réplication AD, est sécurisé soit au sein des sous-réseaux privés, soit via le tunnel VPN du client ou Direct Connect.
Cette architecture utilise les composants ou constructions suivants :
## AWS
+ **Amazon VPC** — Création d'un Amazon VPC avec au moins quatre sous-réseaux privés répartis sur deux AZ : deux pour les services de domaine Active Directory du client, deux pour AD Connector ou Amazon. 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 des DNS (AD DS local) spécifiés. Pour plus d'informations, reportez-vous à la section [Ensembles d'options DHCP](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_DHCP_Options.html).
+ **Amazon Virtual Private Gateway** — Activez la communication avec un réseau appartenant au client via un tunnel ou une connexion VPN IPSec. AWS Direct Connect
+ **Amazon EC2**
+ Contrôleurs de domaine AD DS d'entreprise cliente déployés sur des instances Amazon EC2 dans des sous-réseaux VPC privés dédiés.
+ Serveurs RADIUS client (facultatif) pour le MFA sur des instances Amazon EC2 dans des sous-réseaux VPC privés dédiés.
+ **AWS Services d'annuaire** — AD Connector est déployé dans une paire de sous-réseaux privés Amazon VPC.
+ **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](design-considerations.md#active-directory-sites-and-services) de ce document.
## Client
+ **Connectivité réseau** : VPN ou AWS Direct Connect terminaux d'entreprise.
+ **AD DS** : AD DS d'entreprise (requis pour la réplication).
+ **MFA (facultatif)** : serveur RADIUS d'entreprise.
+ **Appareils utilisateur final : appareils** destinés aux utilisateurs finaux professionnels ou BYOL (tels que Windows, Mac, iPad, tablettes Android, clients zéro et Chromebooks) utilisés pour accéder au service Amazon. WorkSpaces Consultez la [liste des applications clientes pour les appareils et navigateurs Web pris en charge](https://docs.aws.amazon.com/workspaces/latest/userguide/workspaces-user-getting-started.html#choose-client). Cette solution ne présente pas les mêmes inconvénients que le scénario 1. Amazon WorkSpaces et AWS Directory Service ne comptent pas sur la connectivité en place.
+ **Recours à la connectivité** — En cas de perte de connectivité avec le centre de données du client, les utilisateurs finaux peuvent continuer à travailler car l'authentification et le MFA *optionnel* sont traités localement.
+ **Latence** — À l'exception du trafic de réplication, toutes les authentifications sont locales et à faible latence. Reportez-vous à la section [Active Directory : Sites et services](design-considerations.md#active-directory-sites-and-services) de ce document.
+ **Coûts liés au trafic** — Dans ce scénario, l'authentification est locale, seule la réplication AD DS devant passer par le VPN ou le lien Direct Connect, ce qui réduit le transfert de données.
En général, l' WorkSpaces expérience est améliorée et ne dépend pas fortement de la connectivité aux contrôleurs de domaine locaux, comme le montre la figure précédente. C'est également le cas lorsqu'un client souhaite s'adapter WorkSpaces à des milliers de postes de travail, en particulier en ce qui concerne les requêtes du catalogue global AD DS, car ce trafic reste local dans l' WorkSpaces environnement.
# Scénario 3 : déploiement isolé autonome à l'aide du AWS Directory Service dans le cloud AWS
Dans ce scénario, illustré dans la figure suivante, AD DS est déployé dans le AWS cloud dans un environnement isolé autonome. AWS Directory Service est utilisé exclusivement dans ce scénario. Au lieu de gérer entièrement les services AD DS, les clients peuvent compter sur AWS Directory Service pour des tâches telles que la création d'une topologie d'annuaire hautement disponible, la surveillance des contrôleurs de domaine et la configuration des sauvegardes et des instantanés.
![\[Exemple d'architecture illustrant le déploiement d'AD DS dans le AWS cloud dans un environnement isolé autonome.\]](http://docs.aws.amazon.com/fr_fr/whitepapers/latest/best-practices-deploying-amazon-workspaces/images/cloud-only-ad-microsoft.png)
Comme dans le scénario 2, l'AD DS (Microsoft AD) est déployé dans des sous-réseaux dédiés qui s'étendent sur deux AZ, ce qui rend AD DS hautement disponible dans le AWS cloud. Outre Microsoft AD, AD Connector (dans les trois scénarios) est déployé pour WorkSpaces l'authentification ou le MFA. Cela garantit la séparation des rôles ou des fonctions au sein d'Amazon VPC, ce qui est une bonne pratique standard. Pour plus d'informations, reportez-vous à la section [Considérations relatives à la conception](using-multi-region-aws-managed-active-directory-with-amazon-workspaces.md) de ce document.
Le scénario 3 est une configuration standard complète qui convient aux clients qui souhaitent AWS gérer le déploiement, les correctifs, la haute disponibilité et la surveillance du AWS Directory Service. Le scénario fonctionne également bien pour les validations de concepts, les laboratoires et les environnements de production en raison de son mode d'isolation.
Outre le placement de AWS Directory Service, cette figure montre le flux de trafic d'un utilisateur vers un espace de travail et la manière dont l'espace de travail interagit avec le serveur AD et le serveur MFA.
Cette architecture utilise les composants ou constructions suivants.
## AWS
+ **Amazon VPC** — Création d'un Amazon VPC avec au moins quatre sous-réseaux privés répartis sur deux AZ : deux pour AD DS, [Microsoft AD, deux pour AD Connector](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/directory_microsoft_ad.html) ou. 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](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_DHCP_Options.html).
+ **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 (service géré AD DS).
+ **Amazon EC2** — Serveurs RADIUS « facultatifs » du client pour le MFA.
+ **AWS Services d'annuaire** — AD Connector est déployé dans une paire de sous-réseaux privés Amazon VPC.
+ **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](design-considerations.md#active-directory-sites-and-services) de ce document.
## Client
+ **Facultatif : connectivité réseau** — VPN d'entreprise ou AWS Direct Connect terminaux.
+ **Appareils utilisateur final : appareils** destinés aux utilisateurs finaux professionnels ou BYOL (tels que Windows, Mac, iPad, tablettes Android, clients zéro et Chromebooks) utilisés pour accéder au service Amazon. WorkSpaces Consultez [cette liste d'applications clientes pour les appareils et les navigateurs Web pris en charge](https://docs.aws.amazon.com/workspaces/latest/userguide/workspaces-user-getting-started.html#choose-client).
Tout comme le scénario 2, ce scénario ne pose aucun problème en termes de dépendance à la connectivité au centre de données sur site du client, de latence ou de coûts de transfert de données sortantes (sauf lorsque l'accès à Internet est activé WorkSpaces au sein du VPC) car, de par sa conception, il s'agit d'un scénario isolé ou uniquement basé sur le cloud.
# Scénario 4 : AWS Microsoft AD et une confiance transitive bidirectionnelle vers les environnements locaux
Dans ce scénario, illustré dans la figure suivante, AWS Managed AD est déployé dans le AWS cloud, avec une confiance transitive bidirectionnelle envers l'AD sur site du client. Les utilisateurs WorkSpaces sont créés dans Managed AD, l'AD Trust permettant d'accéder aux ressources dans l'environnement local.
![\[Exemple d'architecture illustrant le déploiement de AWS Managed AD dans le AWS cloud, avec une confiance transitive bidirectionnelle avec l'AD sur site du client.\]](http://docs.aws.amazon.com/fr_fr/whitepapers/latest/best-practices-deploying-amazon-workspaces/images/cloud-only-transitive-trust.png)
Comme dans le scénario 3, l'AD DS (Microsoft AD) est déployé dans des sous-réseaux dédiés qui s'étendent sur deux AZ, ce qui rend AD DS hautement disponible dans le AWS cloud.
Ce scénario convient parfaitement aux clients qui souhaitent disposer d'un AWS Directory Service entièrement géré, y compris le déploiement, l'application de correctifs, la haute disponibilité et la surveillance de leur AWS cloud. Ce scénario permet également aux WorkSpaces utilisateurs d'accéder à des ressources associées à AD sur leurs réseaux existants. Ce scénario nécessite la mise en place d'une approbation de domaine. Les groupes de sécurité et les règles de pare-feu doivent autoriser la communication entre les deux annuaires actifs.
Outre le placement de AWS Directory Service, la figure précédente décrit le flux de trafic d'un utilisateur vers un espace de travail, ainsi que la manière dont l'espace de travail interagit avec le serveur AD et le serveur MFA.
Cette architecture utilise les composants ou constructions suivants.
## AWS
+ **Amazon VPC** — Création d'un Amazon VPC avec au moins quatre sous-réseaux privés répartis sur deux AZ : deux pour AD DS, [Microsoft AD, deux pour AD Connector](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/directory_microsoft_ad.html) ou. 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](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_DHCP_Options.html).
+ **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 (service géré AD DS).
+ **Amazon EC2** — Serveurs RADIUS *optionnels* pour le 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](design-considerations.md#active-directory-sites-and-services) de ce document.
## Client
+ **Connectivité réseau** : VPN ou AWS Direct Connect terminaux d'entreprise.
+ **Appareils utilisateur final : appareils** destinés aux utilisateurs finaux professionnels ou BYOL (tels que Windows, Mac, iPad, tablettes Android, clients zéro et Chromebooks) utilisés pour accéder au service Amazon. WorkSpaces Consultez la [liste des applications clientes pour les appareils et navigateurs Web pris en charge](https://docs.aws.amazon.com/workspaces/latest/userguide/workspaces-user-getting-started.html#choose-client).
Cette solution nécessite une connectivité au centre de données sur site du client pour permettre au processus de confiance de fonctionner. Si WorkSpaces les utilisateurs utilisent des ressources sur le réseau local, les coûts de latence et de transfert des données sortantes doivent être pris en compte.
# Scénario 5 : AWS Microsoft AD utilisant un Virtual Private Cloud (VPC) à services partagés
Ce scénario, illustré dans la figure suivante, implique le déploiement d'un AD AWS géré dans le AWS cloud, fournissant des services d'authentification pour les charges de travail déjà hébergées AWS ou prévues dans le cadre d'une migration plus large. La meilleure pratique recommandée est d'installer Amazon WorkSpaces dans un VPC dédié. Les clients doivent également créer une unité AD OU spécifique pour organiser les objets WorkSpaces informatiques.
Pour effectuer un déploiement WorkSpaces avec un VPC à services partagés hébergeant Managed AD, déployez un AD Connector (ADC) avec un compte de service ADC créé dans Managed AD. Le compte de service nécessite des autorisations pour créer des objets informatiques dans l' WorkSpacesunité d'organisation désignée dans les services partagés Managed AD.
![\[Exemple d'architecture WorkSpaces illustrant un VPC à services partagés hébergeant Managed AD, déployez un AD Connector.\]](http://docs.aws.amazon.com/fr_fr/whitepapers/latest/best-practices-deploying-amazon-workspaces/images/microsoft-ad-shared-services-vpc.png)
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](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_DHCP_Options.html).
+ **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 déployé dans une paire dédiée de sous-réseaux VPC (AD DS Managed Service), AD Connector
+ **AWS Transit Gateway/VPC Peering** : activez la connectivité entre le VPC Workspaces et le VPC Shared Services
+ **Amazon EC2** — Serveurs RADIUS *optionnels* pour le 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](design-considerations.md#active-directory-sites-and-services) de ce document.
## Client
+ **Connectivité réseau** : VPN ou AWS Direct Connect terminaux d'entreprise.
+ **Appareils utilisateur final : appareils** destinés aux utilisateurs finaux professionnels ou BYOL (tels que Windows, Mac, iPad, tablettes Android, clients zéro et Chromebooks) utilisés pour accéder au service Amazon. WorkSpaces Consultez la [liste des applications clientes pour les appareils et navigateurs Web pris en charge](https://docs.aws.amazon.com/workspaces/latest/userguide/workspaces-user-getting-started.html#choose-client).
# 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.](https://techcommunity.microsoft.com/t5/ask-the-directory-services-team/domain-locator-across-a-forest-trust/ba-p/395689) 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](https://d1.awsstatic.com/Projects/deploy-amazon-workspaces-one-way-trust-with-aws-directory-service.pdf)
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 Directory Service œuvre [Deploy Amazon WorkSpaces using a One-Way Trust Resource Domain with](https://aws.amazon.com/getting-started/hands-on/deploy-workspaces-one-way-trust/) 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](https://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) 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.\]](http://docs.aws.amazon.com/fr_fr/whitepapers/latest/best-practices-deploying-amazon-workspaces/images/one-way-trust-ad-onprem.png)
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](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_DHCP_Options.html).
+ **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](design-considerations.md#active-directory-sites-and-services) de ce document.
## Client
+ **Connectivité réseau** : VPN ou AWS Direct Connect terminaux d'entreprise.
+ **Appareils utilisateur final : appareils** destinés aux utilisateurs finaux professionnels ou BYOL (tels que Windows, Mac, iPad, tablettes Android, clients zéro et Chromebooks) utilisés pour accéder au service Amazon. WorkSpaces Consultez [cette liste d'applications clientes pour les appareils et les navigateurs Web pris en charge](https://docs.aws.amazon.com/workspaces/latest/userguide/workspaces-user-getting-started.html#choose-client).
# Utilisation d'Active Directory AWS géré par plusieurs régions avec Amazon WorkSpaces
[AWS Directory Service for Microsoft Active Directory](https://aws.amazon.com/directoryservice/active-directory/) (MAD) est un service Microsoft Active Directory (AD) entièrement géré qui peut être associé à Amazon WorkSpaces. Les clients choisissent AWS Managed Microsoft AD car il intègre une haute disponibilité, une surveillance et des sauvegardes. AWS L'édition Managed Microsoft AD Enterprise ajoute la possibilité de configurer [la réplication multirégionale](https://aws.amazon.com/blogs/aws/multi-region-replication-now-enabled-for-aws-managed-microsoft-active-directory/). Cette fonctionnalité configure automatiquement la connectivité réseau interrégionale, déploie des contrôleurs de domaine et réplique toutes les données Active Directory dans plusieurs régions, garantissant ainsi que les charges de travail Windows et Linux résidant dans ces régions peuvent se connecter à AWS MAD et l'utiliser avec une faible latence et des performances élevées. Les régions MAD répliquées ne peuvent pas être [enregistrées directement auprès](https://docs.aws.amazon.com/workspaces/latest/adminguide/register-deregister-directory.html) de celles-ci WorkSpaces, mais un répertoire MAD répliqué peut être enregistré WorkSpaces en configurant un AD Connector (ADC) pour qu'il pointe vers vos contrôleurs de domaine répliqués.
La meilleure pratique lors du déploiement de connecteurs AD avec MAD consiste à créer un connecteur AD pour chaque unité commerciale de votre WorkSpaces environnement. Cela vous permettra d'aligner chaque unité commerciale sur une unité organisationnelle spécifique au sein d'Active Directory. Vous pouvez ensuite attribuer des objets de stratégie de groupe AD au niveau de l'unité organisationnelle qui correspondent directement à l'unité commerciale en question.
## Architecture
![\[Un exemple d'architecture illustrant les connecteurs AD avec MAD consiste à créer un connecteur AD pour chaque unité commerciale de votre WorkSpaces environnement.\]](http://docs.aws.amazon.com/fr_fr/whitepapers/latest/best-practices-deploying-amazon-workspaces/images/registering-replicated-mad-region.png)
## Mise en œuvre
Pour enregistrer votre région MAD répliquée dans WorkSpaces, vous devez créer un connecteur AD pointé vers les adresses IP de votre contrôleur de domaine MAD. Vous pouvez trouver les adresses IP de vos contrôleurs de domaine MAD en accédant au volet de navigation de la [console AWS Directory Service](https://console.aws.amazon.com/directoryservicev2/), en sélectionnant Directories, puis en choisissant le bon ID de répertoire. Pour créer ces connecteurs AD, suivez ce [guide](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ad_connector_getting_started.html). Une fois qu'ils sont créés, vous pouvez [les enregistrer pour WorkSpaces](https://docs.aws.amazon.com/workspaces/latest/adminguide/register-deregister-directory.html). Avant de procéder WorkSpaces au déploiement dans votre nouvelle région, assurez-vous d'avoir mis à jour le jeu d'[options DHCP](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/dhcp_options_set.html) de votre VPC.