本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
# AD DS 部署方案
支持 Amazon WorkSpaces 的是 AWS 目录服务，正确设计和部署目录服务至关重要。以下六个场景以* AWS 快速入门指南*中的 A [ctive Directory 域服务](https://docs.aws.amazon.com/quickstart/latest/active-directory-ds/architecture.html)为基础，描述了与 Amazon 一起使用时 AD DS 的最佳实践部署选项 WorkSpaces。本文档的[设计注意事项](using-multi-region-aws-managed-active-directory-with-amazon-workspaces.md)部分详细介绍了使用 AD Connector 的具体要求和最佳实践 WorkSpaces，这是整体 WorkSpaces设计概念不可或缺的一部分。
+ **场景 1：使用 AD Connector 代理对本地 AD DS 的身份验证** — 在这种情况下，客户已建立网络连接（VPN/Direct Connect），所有身份验证都通过 AWS 目录服务（AD Connector）代理到客户的本地 AD DS。
+ **场景 2：将本地 AD DS 扩展到 AWS （副本）**— 此场景与场景 1 类似，但此处将客户 AD DS 的副本与 AD Connector 结合部署，从而减少了向 AD DS 和 AD DS 全局目录发送身份验证/查询请求的延迟。 AWS
+ **场景 3：使用 AWS 云端的 AWS Directory Service 进行独立隔离部署** — 这是一个孤立的场景，不包括与客户进行身份验证的连接。这种方法使用 AWS 目录服务（微软 AD）和 AD Connector。尽管这种情况不依赖于与客户的连接进行身份验证，但它确实在需要时通过VPN或Direct Connect为应用程序流量提供了预配置。
+ **场景 4： AWS Microsoft AD 和到本地的双向传递信任** — 此场景包括 AWS 托管微软 AD 服务 (MAD)，该服务与本地 Microsoft AD Forest 具有双向传递信任。
+ **场景 5：使用共享服务 VPC 的 AWS Micro** soft AD — 此场景使用共享服务 VPC 中的 AWS 托管 Microsoft AD 用作多个 AWS 服务（亚马逊 EC2 WorkSpaces、Amazon 等）的身份域，同时使用 AD Connector 将轻型目录访问协议 (LDAP) 用户身份验证请求代理到 AD 域控制器。
+ **场景 6： AWS Microsoft AD、共享服务 VPC 和对本地 AD 的单向信任** — 此场景与场景 5 类似，但它包括使用对本地的单向信任的不同身份和资源域。
在选择 Active Directory 域服务 (ADDS) 的部署方案时，您需要考虑几个因素。本节介绍了 AD Connector 在 Amazon 中的作用 WorkSpaces，并介绍了选择 ADDS 部署方案时的一些重要注意事项。有关 ADDS 设计和规划的更多指导 AWS，请查阅 A [ctive Directory 域服务 AWS 设计和规划指南](https://d1.awsstatic.com/whitepapers/adds-on-aws.pdf)。
# AWS AD Connector 在亚马逊的角色 WorkSpaces
[AWS AD Connec](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/directory_ad_connector.html) tor 是一种 AWS 目录服务，充当 Active Directory 的代理服务。它不存储或缓存任何用户凭据，而是将身份验证或查找请求转发到您的 Active Directory（本地或本地）。 AWS除非您正在使用 AWS Managed Microsoft AD，否则它也是注册您的 Active Directory（本地或扩展到 AWS）以便在 Amazon WorkSpaces (WorkSpaces) 中使用的唯一方法。
AD Connector 可以指向您的本地 Active Directory、扩展到 AWS （Amazon EC2 上的 AD 域控制器）的活动目录，或者指向 AWS Managed Microsoft AD。
AD Connector 在以下各节中介绍的大多数部署场景中起着重要作用。将 AD Connec WorkSpaces tor 与配合使用具有许多好处：
+ 当指向您的公司 Active Directory 时，它允许您的用户使用他们现有的公司凭证登录 WorkSpaces 和其他服务，例如[亚马逊 WorkDocs](https://aws.amazon.com/workdocs/)。
+ 无论您的用户访问的是本地基础设施中的资源还是诸如中的资源，您都可以始终如 WorkSpaces一地应用现有的安全策略（密码过期 AWS 云、帐户锁定等）。
+ AD Connector 可与您现有的基于 RADIUS 的 MFA 基础设施轻松集成，从而提供额外的安全保护。
+ 它可以隔离您的用户。例如，它允许为每个业务部门或角色配置多个 WorkSpaces 选项，因为多个 AD 连接器可以指向 Active Directory 的相同域控制器（DNS 服务器）进行用户身份验证：
+ 目标域或组织单位，用于有针对性地应用 Active Directory 组策略对象 (GPO)
+ 使用不同的安全组来控制往返流量 WorkSpaces
+ 不同的访问控制选项（允许的客户端设备）和 IP 访问控制组（限制对 IP 范围的访问）
+ 选择性启用本地管理员权限
+ 不同的自助服务权限
+ 选择性地强制执行多因素身份验证 (MFA) Authentication
+ 将您的 WorkSpaces 弹性网络接口 (ENI) 放置到不同的 VPC 或子网中进行隔离
如果您达到单个小型或大型 AD 连接器的性能极限，则多个 AD 连接器还允许支持更多用户。有关更多详细信息，请参阅该[的大小 AWS Managed Microsoft AD](#sizing-aws-managed-microsoft-ad)部分。
只要小型 AD Connec WorkSpaces tor 中至少有一个活跃 WorkSpaces 用户，大型 AD Connector 中至少有 100 个活跃 WorkSpaces 用户，就可以免费使用 AD Connector。有关更多信息，请参阅[AWS 目录服务定价](https://aws.amazon.com/directoryservice/pricing/)页面。
## 网络 AWS 与本地 Active Directory 关联的重要性
WorkSpaces 依赖于与您的活动目录的连接。因此，指向 Active Directory 的网络链接的可用性至关重要。例如，如果[场景 1](scenario-1-using-ad-connector-to-proxy-authentication-to-on-premises-active-directory-service.md) 中的网络链接已关闭，则您的用户将无法进行身份验证，因此也将无法使用他们的 WorkSpaces。
如果要将本地 Active Directory 用作场景的一部分，则需要考虑网络链接的弹性、延迟和流量成本。 AWS在多区域 WorkSpaces 部署中，这可能涉及不同 AWS 区域的多个网络链接，或者在它们之间建立对等连接的多个 AWS Transit Gateway网络链接，将您的 AD 流量路由到与本地 AD 相连的 VPC。这些网络链接注意事项适用于以下各节中概述的大多数场景，但对于那些来自 AD Connectors 的广告流量 WorkSpaces 需要穿过网络链接才能到达本地 Active Directory 的场景尤其重要。 [场景 1](scenario-1-using-ad-connector-to-proxy-authentication-to-on-premises-active-directory-service.md) 重点介绍了一些注意事项。
## 将多因素身份验证与 WorkSpaces
如果您计划将多因素身份验证 (MFA) Authentication WorkSpaces 与一起使用，则必须使用 AD Conn AWS ector 或 AWS Managed Microsoft AD，因为只有这些服务允许注册目录以与 RADIUS 一起使用 WorkSpaces 和配置。对于您的 RADIUS 服务器的放置，本[网络 AWS 与本地 Active Directory 关联的重要性](#network-link-to-aws-with-on-premises-ad)节中介绍的网络链路注意事项适用。
## 将账户和资源域分开
出于安全原因或为了提高可管理性，可能需要将账户域与资源域分开。例如，将 WorkSpaces 计算机对象放在单独的资源域中，而用户则是帐户域的一部分。这样的实现可用于允许合作伙伴组织在资源域中 WorkSpaces使用 AD 组策略进行管理，同时不放弃对账户域的控制权或授予访问权限。这可以通过使用两个带有已配置活动目录信任的活动目录来实现。以下各节对此进行了更详细的介绍：
+ [场景 4： AWS Microsoft AD 和到本地的双向传递信任](scenario-4-aws-microsoft-ad-and-a-two-way-transitive-trust-to-on-premises.md)
+ [场景 6： AWS Microsoft AD、共享服务 VPC 和对本地的单向信任](scenario-6-aws-microsoft-ad-shared-services-vpc-and-a-one-way-trust-to-on-premises.md)
## 大型活动目录部署
您必须确保相应地配置 Active Directory 网站和服务。如果您的 Active Directory 由位于不同地理位置的大量域控制器组成，则这一点尤其重要。你的 Windows WorkSpaces 使用[标准的 Microsoft 机制](https://social.technet.microsoft.com/wiki/contents/articles/24457.how-domain-controllers-are-located-in-windows.aspx)来发现他们被分配到的 Active Directory 站点的域控制器。此 DC 定位器流程依赖于 DNS，如果在 DC Locator 流程的早期阶段返回一长串优先级和权重不明确的域控制器，则可能会显著延长。更重要的是，如果您 WorkSpaces 被 “固定” 到次优域控制器，则在穿越广域网链路时，与该域控制器的所有后续通信都可能会增加网络延迟并降低带宽。这将减慢与域控制器的任何通信，包括处理可能大量的组策略对象 (GPO)，以及从域控制器传输文件。根据网络拓扑的不同，它还可能增加您的网络成本，因为 WorkSpaces 和域控制器之间交换的数据可能会不必要地通过更昂贵的网络路径。有关您的 [VPC 设计](design-considerations.md) VPC 设计的 DHCP 和 DNS 以及 Active Directory 网站和服务的指导，请参阅和[设计注意事项](design-considerations.md)部分。
## 将 Microsoft Azure 活动目录或活动目录域服务与 WorkSpaces
如果你打算将 Microsoft Azure 活动目录与一起使用 WorkSpaces，你可以使用 Azure AD Connect 将你的身份与本地活动目录或开启的活动目录同步 AWS （亚马逊 EC2 上的域控制器或 AWS Managed Microsoft AD）。但是，这将不允许你加 WorkSpaces 入 Azure 活动目录。有关更多信息，请参阅[微软 Azure 文档中的微软混合身份](https://docs.microsoft.com/en-us/azure/active-directory/hybrid/)*文档*。
如果你想加入 Azure Active Directory，你需要部署微软 Azure Active Directory 域服务 (Azure AD DS)，在 AWS 和 Azure 之间建立连接，然后使用指向 Azure A AWS D DS 域控制器的 AD Connector。 WorkSpaces 有关如何设置的更多信息，请参阅[使用 Azure Active Directory 域服务将你的添加 WorkSpaces 到 Azure AD](https://aws.amazon.com/blogs/desktop-and-application-streaming/add-your-workspaces-to-azure-ad-using-azure-active-directory-domain-services/) 博客文章。
将 AWS Directory Service s 与 s 配合使用时 WorkSpaces，必须考虑 WorkSpaces部署规模及其预期增长，才能 AWS Directory Service 适当地调整部署规模。本节提供有关调整大小以 AWS Directory Service 供使用的指导 WorkSpaces。我们还建议您查看 [AD Connector](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ad_connector_best_practices.html) [的最佳做法和《*AWS Directory Service 管理指南*》中 AWS Managed Microsoft AD各节的最佳实践](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_best_practices.html)。
## AD Connector 的大小调整为 WorkSpaces
Active Directory 连接器（AD Connector）有两种尺寸可供选择，小号和大号。虽然没有强制性的用户或连接限制，但我们建议对最多 500 个授权用户使用小型 AD Connector，为最多 5000 个 WorkSpaces 授权用户使用大型 AD Connector。 WorkSpaces 您可以将应用程序负载分布在多个 AD Connector 上，以根据您的性能需求进行扩展。例如，如果您需要支持 1500 个 WorkSpaces 用户，则可以 WorkSpaces 平均分配到三个小型 AD Connector，每个都支持 500 个用户。如果您的所有用户都居住在同一个域中，则 AD Connector 可以全部指向同一组 DNS 服务器来解析您的 Active Directory 域。
请注意，如果您从小型 AD Connector 开始，并且 WorkSpaces 部署会随着时间的推移而增长，则可以提出支持请求，将 AD Connector 的大小从小改为大，以便处理更多的 WorkSpaces 授权用户。
## 的大小 AWS Managed Microsoft AD
[AWS Managed Microsoft AD](https://aws.amazon.com/directoryservice/active-directory/)允许你将 Microsoft 活动目录作为托管服务运行。启动服务时，您可以在标准版和企业版之间进行选择。标准版建议用户数不超过 5,000 的中小型企业使用，并且最多支持大约 30,000 个目录对象，例如用户、群组和计算机。企业版旨在支持多达 500,000 个目录对象，还提供一项附加功能，例如[多区域复制](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_configure_multi_region_replication.html)。
如果你需要支持超过 500,000 个目录对象，可以考虑在 Amazon EC2 上部署 Microsoft Active Directory 域控制器。有关这些域控制器的大小，请参阅微软的 Act [ive Directory 域服务容量规划](https://docs.microsoft.com/en-us/windows-server/administration/performance-tuning/role/active-directory-server/capacity-planning-for-active-directory-domain-services)文档。
# 场景 1：使用 AD 连接器对本地 Active Directory Service 进行代理身份验证
此场景适用于不想将其本地 AD 服务扩展到 AWS内部 AD 服务或无法选择新部署 AD DS 的客户。下图概述了每个组件和用户身份验证流程。
![\[示例架构概述了每个组件和用户身份验证流程。\]](http://docs.aws.amazon.com/zh_cn/whitepapers/latest/best-practices-deploying-amazon-workspaces/images/ad-connector-to-onprem.png)
在这种情况下， AWS 目录服务（AD Connector）用于通过 AD 连接器代理到客户本地 AD DS 的所有用户或 MFA 身份验证（详见下图）。有关用于身份验证过程的协议或加密的详细信息，请参阅本文档的[安全性](security.md)部分。
![\[示例架构显示了如何使用 AD Connector 进行所有用户或通过 AD 连接器代理到客户本地 AD DS 的 MFA 身份验证。\]](http://docs.aws.amazon.com/zh_cn/whitepapers/latest/best-practices-deploying-amazon-workspaces/images/user-authentication-auth-gateway.png)
场景 1 显示了一种混合架构，在该架构中 AWS，客户可能已经拥有资源，而本地数据中心中也有可以通过 Amazon 访问的资源 WorkSpaces。客户可以利用其现有的本地 AD DS 和 RADIUS 服务器进行用户和 MFA 身份验证。
此架构使用以下组件或结构：
## AWS
+ **Amazon VPC** — 创建跨两个可用区至少有两个私有子网的亚马逊 VPC。
+ **DHCP 选项集** — 创建亚马逊 VPC DHCP 选项集。这允许定义客户指定的域名和域名服务器 (DNS)（本地服务）。有关更多信息，请参阅 [DHCP 选项集](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_DHCP_Options.html)。
+ **Amazon 虚拟专用网关**-允许通过 IPsec VPN 隧道或 AWS Direct Connect 连接与您自己的网络进行通信。
+ **AWS Directory Service** — AD Connector 部署到一对 Amazon VPC 私有子网中。
+ **亚马逊 WorkSpaces** — 部署 WorkSpaces 在与 AD Connector 相同的私有子网中。有关更多信息，请参阅本文档的 “[活动目录：网站和服务](design-considerations.md#active-directory-sites-and-services)” 部分。
## 客户
+ **网络连接**-企业 VPN 或 Direct Connect 端点。
+ **广告 DS** — 公司广告 DS。
+ **MFA（可选）**-企业 RADIUS 服务器。
+ **最终用户设备** — 用于访问亚马逊服务的企业或自带许可 (BYOL) 的最终用户设备（例如 Windows、Mac、iPad、安卓平板电脑、零客户端和 Chromebook）。 WorkSpaces 有关[支持的设备和 Web 浏览器，请参阅此客户端应用程序列表](https://docs.aws.amazon.com/workspaces/latest/userguide/workspaces-user-getting-started.html#choose-client)。
尽管此解决方案非常适合不想将 AD DS 部署到云端的客户，但它确实有一些注意事项：
+ **依赖连接** — 如果与数据中心的连接中断，用户将无法登录各自 WorkSpaces的数据中心，并且现有连接将在 Kerberos/Ticket-Agranting Ticket Ticket (TGT) 的生命周期内保持活动状态。
+ **延迟** — 如果通过连接存在延迟（VPN 比 Direct Connect 更是如此），则 WorkSpaces 身份验证和任何与 AD DS 相关的活动（例如组策略 (GPO) 强制执行）将花费更多时间。
+ **流量成本**-所有身份验证都必须通过 VPN 或 Direct Connect 链路，因此这取决于连接类型。这要么是从 Amazon EC2 向互联网传输数据，要么是数据传出（Direct Connect）。
**注意**
AD Connector 是一种代理服务。它不存储或缓存用户凭据。相反，所有身份验证、查询和管理请求都由您的 AD 处理。您的目录服务中需要一个具有委托权限的帐户，该帐户具有读取所有用户信息以及将计算机加入域的权限。
通常， WorkSpaces 体验在很大程度上取决于上图所示的 Active Directory 身份验证过程。在这种情况下， WorkSpaces 身份验证体验在很大程度上取决于客户 AD 和 WorkSpaces VPC 之间的网络链接。客户应确保链接高度可用。
# 场景 2：将本地 AD DS 扩展到 AWS （副本）
此场景与场景 1 类似。但是，在这种情况下，将客户 AD DS 的副本与 AD Connec AWS tor 结合部署。这减少了向在亚马逊弹性计算云 (Amazon EC2) 上运行的 AD DS 发出的身份验证或查询请求的延迟。下图显示了每个组件和用户身份验证流程的高级视图。
![\[示例架构显示了与 AD Connector 结合部署 AWS 的客户 AD DS 的副本。\]](http://docs.aws.amazon.com/zh_cn/whitepapers/latest/best-practices-deploying-amazon-workspaces/images/extend-customer-ad-cloud.png)
与场景 1 一样，AD Connector 用于所有用户或 MFA 身份验证，这反过来又被代理给客户 AD DS（参见[上](scenario-1-using-ad-connector-to-proxy-authentication-to-on-premises-active-directory-service.md#fig5)图）。在这种情况下，客户 AD DS 跨可用区部署在 Amazon EC2 实例上，这些实例被提升为客户本地 A [D 林](https://ipwithease.com/what-is-a-forest-in-active-directory/)中的域控制器，在 AWS 云中运行。每个域控制器都部署到 VPC 私有子网中，以使 AD DS 在 AWS 云中具有高可用性。有关在上部署 AD DS 的最佳实践 AWS，请参阅本文档的[设计注意事项](using-multi-region-aws-managed-active-directory-with-amazon-workspaces.md)部分。
部署 WorkSpaces 实例后，它们可以访问基于云的域控制器，以获得安全、低延迟的目录服务和 DNS。所有网络流量，包括 AD DS 通信、身份验证请求和 AD 复制，均在私有子网内或通过客户 VPN 隧道或 Direct Connect 进行保护。
此架构使用以下组件或结构：
## AWS
+ **亚马逊 VPC** — 创建一个亚马逊 VPC，在两个可用区中至少有四个私有子网，两个用于客户 AD DS，两个用于 AD Connector 或亚马逊。 WorkSpaces
+ **DHCP 选项集** — 创建亚马逊 VPC DHCP 选项集。这允许客户定义指定的域名和 DNS（本地 AD DS）。有关更多信息，请参阅 [DHCP 选项集](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_DHCP_Options.html)。
+ **Amazon 虚拟专用网关**-允许通过 IPsec VPN 隧道或 AWS Direct Connect 连接与客户拥有的网络进行通信。
+ **Amazon EC2**
+ 客户企业 AD DS 域控制器部署在 Amazon EC2 实例上的专用私有 VPC 子网中。
+ 用于专用私有 VPC 子网中的 Amazon EC2 实例上的 MFA 的客户（可选）RADIUS 服务器。
+ **AWS 目录服务** — AD Connector 部署到一对 Amazon VPC 私有子网中。
+ **亚马逊 WorkSpaces** — 部署 WorkSpaces 在与 AD Connector 相同的私有子网中。有关更多信息，请参阅本文档的 “[活动目录：网站和服务](design-considerations.md#active-directory-sites-and-services)” 部分。
## 客户
+ **网络连接**-企业 VPN 或 AWS Direct Connect 端点。
+ **AD DS** — 企业 AD DS（复制所必需的）。
+ **MFA（可选）**-企业 RADIUS 服务器。
+ **最终用户设备** — 用于访问亚马逊服务的企业或自带终端用户设备（例如 Windows、Mac、iPad、安卓平板电脑、零客户端和 Chromebook）。 WorkSpaces 请参阅[支持的设备和 Web 浏览器的客户端应用程序列表](https://docs.aws.amazon.com/workspaces/latest/userguide/workspaces-user-getting-started.html#choose-client)。此解决方案与场景 1 没有相同的注意事项。Amazon WorkSpaces 和 AWS Directory Service 不依赖现有的连接。
+ 对@@ **连接的依赖** — 如果与客户数据中心的连接中断，最终用户可以继续工作，因为身份验证和*可选*的 MFA 是在本地处理的。
+ **延迟**-除复制流量外，所有身份验证均为本地身份验证且延迟较低。请参阅本文档的 “[活动目录：网站和服务](design-considerations.md#active-directory-sites-and-services)” 部分。
+ **流量成本** — 在这种情况下，身份验证是本地的，只有 AD DS 复制必须通过 VPN 或 Direct Connect 链路，从而减少了数据传输。
总的来说， WorkSpaces 体验会得到增强，并且不会高度依赖与本地域控制器的连接，如上图所示。当客户想要扩展 WorkSpaces 到数千台台式机时，情况也是如此，尤其是在与 AD DS 全球目录查询相关的情况下，因为这种流量仍然是 WorkSpaces 环境本地的。
# 场景 3：使用 AWS 云端的 AWS Directory Service 进行独立隔离部署
如下图所示，该场景将 AD DS 部署在 AWS 云端的独立隔离环境中。 AWS Directory Service 仅用于这种情况。客户无需完全管理 AD DS，而是可以依靠 Directory Servic AWS e 来完成诸如构建高可用性目录拓扑、监控域控制器以及配置备份和快照之类的任务。
![\[示例架构显示 AD DS 部署在 AWS 云端的独立隔离环境中。\]](http://docs.aws.amazon.com/zh_cn/whitepapers/latest/best-practices-deploying-amazon-workspaces/images/cloud-only-ad-microsoft.png)
与场景 2 一样，AD DS（Microsoft AD）部署到跨越两个可用区的专用子网中，这使得 AD DS 在云中具有很高的可用性。 AWS 除了 Microsoft AD 之外，还部署了 AD Connector（在所有三个场景中），用于 WorkSpaces 身份验证或 MFA。这可确保在 Amazon VPC 内实现角色或职能的分离，这是一种标准的最佳实践。有关更多信息，请参阅本文档的[设计注意事项](using-multi-region-aws-managed-active-directory-with-amazon-workspaces.md)部分。
场景 3 是一种标准的全方位配置，非常适合想要 AWS 管理 Di AWS rectory Service 的部署、修补、高可用性和监控的客户。由于其隔离模式，该场景还适用于概念验证、实验室和生产环境。
除了 AWS Directory Service 的位置外，此图还显示了从用户到工作空间的流量以及工作空间与 AD 服务器和 MFA 服务器的交互方式。
此架构使用以下组件或结构。
## AWS
+ **亚马逊 VPC** — 创建一个亚马逊 VPC，在两个可用区中至少有四个私有子网——两个用于 AD DS M [icrosoft AD，两个用于 AD](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/directory_microsoft_ad.html) Connector 或。 WorkSpaces
+ **DHCP 选项集** — 创建亚马逊 VPC DHCP 选项集。这允许客户定义指定的域名和 DNS（Microsoft AD）。有关更多信息，请参阅 [DHCP 选项集](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_DHCP_Options.html)。
+ **可选：Amazon 虚拟专用网关**-允许通过 IPsec VPN 隧道 (VPN) 或 AWS Direct Connect 连接与客户拥有的网络进行通信。用于访问本地后端系统。
+ **AWS Directory Ser** vice — 部署到一对专用 VPC 子网中的 Microsoft AD（AD DS 托管服务）。
+ **亚马逊 EC2** — 适用于 MFA 的客户 “可选” RADIUS 服务器。
+ **AWS 目录服务** — AD Connector 部署到一对 Amazon VPC 私有子网中。
+ **亚马逊 WorkSpaces** — 部署 WorkSpaces 在与 AD Connector 相同的私有子网中。有关更多信息，请参阅本文档的 “[活动目录：网站和服务](design-considerations.md#active-directory-sites-and-services)” 部分。
## 客户
+ **可选：网络连接**-企业 VPN 或 AWS Direct Connect 终端。
+ **最终用户设备** — 用于访问亚马逊服务的企业或自带终端用户设备（例如 Windows、Mac、iPad、安卓平板电脑、零客户端和 Chromebook）。 WorkSpaces 有关[支持的设备和 Web 浏览器，请参阅此客户端应用程序列表](https://docs.aws.amazon.com/workspaces/latest/userguide/workspaces-user-getting-started.html#choose-client)。
与场景 2 一样，此场景在依赖客户本地数据中心的连接、延迟或数据输出传输成本（VPC WorkSpaces 内启用互联网访问的除外）方面没有问题，因为从设计上讲，这是一个隔离或仅限云的场景。
# 场景 4： AWS Microsoft AD 和到本地的双向传递信任
如下图所示，该场景将 AWS 托管 AD 部署在云中， AWS 云端与客户的本地 AD 具有双向传递信任。用户和 WorkSpaces 是在托管 AD 中创建的，AD 信任允许在本地环境中访问资源。
![\[示例架构显示了部署在云中的 AWS 托管 AD， AWS 云端与客户本地 AD 具有双向传递信任。\]](http://docs.aws.amazon.com/zh_cn/whitepapers/latest/best-practices-deploying-amazon-workspaces/images/cloud-only-transitive-trust.png)
与场景 3 一样，AD DS（Microsoft AD）部署到跨越两个可用区的专用子网中，这使得 AD DS 在云中具有很高的可用性。 AWS
此方案非常适合想要拥有完全托管的 AWS Directory Service（包括部署、修补、高可用性和 AWS 云监控）的客户。此场景还允许 WorkSpaces 用户在其现有网络上访问已加入广告的资源。这种情况需要建立域信任。安全组和防火墙规则需要允许两个活动目录之间的通信。
除了 AWS Directory Service 的位置外，上图还概述了从用户到工作空间的流量以及工作空间与 AD 服务器和 MFA 服务器的交互方式。
此架构使用以下组件或结构。
## AWS
+ **亚马逊 VPC** — 创建一个亚马逊 VPC，在两个可用区中至少有四个私有子网——两个用于 AD DS M [icrosoft AD，两个用于 AD](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/directory_microsoft_ad.html) Connector 或。 WorkSpaces
+ **DHCP 选项集** — 创建亚马逊 VPC DHCP 选项集。这使客户能够定义指定的域名和 DNS（Microsoft AD）。有关更多信息，请参阅 [DHCP 选项集](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_DHCP_Options.html)。
+ **可选：Amazon 虚拟专用网关**-允许通过 IPsec VPN 隧道 (VPN) 或 AWS Direct Connect 连接与客户拥有的网络进行通信。用于访问本地后端系统。
+ **AWS Directory Ser** vice — 部署到一对专用 VPC 子网中的 Microsoft AD（AD DS 托管服务）。
+ **亚马逊 EC2** — 客户*可选* RADIUS 服务器，适用于 MFA。
+ **亚马逊 WorkSpaces** — 部署 WorkSpaces 在与 AD Connector 相同的私有子网中。有关更多信息，请参阅本文档的 “[活动目录：网站和服务](design-considerations.md#active-directory-sites-and-services)” 部分。
## 客户
+ **网络连接**-企业 VPN 或 AWS Direct Connect 端点。
+ **最终用户设备** — 用于访问亚马逊服务的企业或自带终端用户设备（例如 Windows、Mac、iPad、安卓平板电脑、零客户端和 Chromebook）。 WorkSpaces 请参阅[支持的设备和 Web 浏览器的客户端应用程序列表](https://docs.aws.amazon.com/workspaces/latest/userguide/workspaces-user-getting-started.html#choose-client)。
此解决方案需要连接到客户的本地数据中心，才能使信任流程正常运行。如果 WorkSpaces用户使用本地网络上的资源，则需要考虑延迟和出站数据传输成本。
# 场景 5： AWS 微软 AD 使用共享服务虚拟私有云 (VPC) Private Cloud
如下图所示，该场景在 AWS 云中部署了 AWS 托管 AD，为已经托管在更广泛的迁移中 AWS 或计划作为更广泛迁移的一部分的工作负载提供身份验证服务。最佳实践建议是将 Amazon 置 WorkSpaces 于专用 VPC 中。客户还应创建特定的 AD OU 来整理 WorkSpaces 计算机对象。
要 WorkSpaces 使用托管托管 AD 的共享服务 VPC 进行部署，请使用在托管 AD 中创建的 ADC 服务账户部署 AD Connector (ADC)。服务帐户需要权限才能在共享服务 Managed AD 的 WorkSpaces指定 OU 中创建计算机对象。
![\[示例架构显示， WorkSpaces 使用共享服务 VPC 托管托管 AD，部署 AD Connector。\]](http://docs.aws.amazon.com/zh_cn/whitepapers/latest/best-practices-deploying-amazon-workspaces/images/microsoft-ad-shared-services-vpc.png)
此架构使用以下组件或结构。
## AWS
+ **亚马逊 VPC** — 创建在两个可用区中至少有两个私有子网的亚马逊 VPC（两个用于 AD Connector 和 WorkSpaces）。
+ **DHCP 选项集** — 创建亚马逊 VPC DHCP 选项集。这允许客户定义指定的域名和 DNS（Microsoft AD）。有关更多信息，请参阅 [DHCP 选项集](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_DHCP_Options.html)。
+ **可选：Amazon 虚拟专用网关**-允许通过 IPsec VPN 隧道 (VPN) 或 AWS Direct Connect 连接与客户拥有的网络进行通信。用于访问本地后端系统。
+ **AWS Directory Ser** vice — 部署到一对专用的 VPC 子网（AD DS 托管服务）、AD Connector 中的微软 AD
+ **AWS Transit Gateway/VPC 对等互连** — 启用工作空间 VPC 和共享服务 VPC 之间的连接
+ **亚马逊 EC2** — 客户*可选* RADIUS 服务器，适用于 MFA。
+ **亚马逊 WorkSpaces** — 部署 WorkSpaces 在与 AD Connector 相同的私有子网中。有关更多信息，请参阅本文档的 “[活动目录：网站和服务](design-considerations.md#active-directory-sites-and-services)” 部分。
## 客户
+ **网络连接**-企业 VPN 或 AWS Direct Connect 端点。
+ **最终用户设备** — 用于访问亚马逊服务的企业或自带终端用户设备（例如 Windows、Mac、iPad、安卓平板电脑、零客户端和 Chromebook）。 WorkSpaces 请参阅[支持的设备和 Web 浏览器的客户端应用程序列表](https://docs.aws.amazon.com/workspaces/latest/userguide/workspaces-user-getting-started.html#choose-client)。
# 场景 6： AWS Microsoft AD、共享服务 VPC 和对本地的单向信任
如下图所示，此场景使用现有的本地 Active Directory 供用户使用，并在 AWS 云中引入了一个单独的托管 Active Directory 来托管与关联的计算机对象 WorkSpaces。此方案允许计算机对象和 Active Directory 组策略独立于公司 Active Directory 进行管理。
当第三方想要代表客户管理 Windows WorkSpaces 时，此场景非常有用，因为它允许第三方定义和控制与其关联的 WorkSpaces 和策略，而无需向第三方授予对客户 AD 的访问权限。在这种情况下，将创建一个特定的 Active Directory 组织单位 (OU) 来组织共享服务 AD 中的 WorkSpaces 计算机对象。
**注意**
Amazon Linux WorkSpaces 需要建立双向信任才能创建它们。
要使用客户身份域中的用户在托管 Active Directory 的共享服务 VPC 中创建的计算机对象部署 Windows WorkSpaces ，请部署引用公司 AD 的 Active Directory 连接器 (ADC)。使用在企业 AD（身份域）中创建的 ADC 服务帐户，该帐户具有在共享服务托管 AD 中为 Windows 配置的组织单位 (OU) WorkSpaces 中创建计算机对象的委托权限，并且具有企业 Active Directory（身份域）的读取权限。
为确保域定位器功能能够对身份域所需 AD 站点中的 WorkSpaces 用户进行身份验证，请按照 [Microsoft 的文档为两个域名的 Amazon WorkSpaces 子网的 Amazon Subnets 的](https://techcommunity.microsoft.com/t5/ask-the-directory-services-team/domain-locator-across-a-forest-trust/ba-p/395689)广告站点命名。最佳做法是将身份域和共享服务域 AD 域控制器与 Amazon 位于同一 AWS 区域 WorkSpaces。
有关配置此场景的详细说明，请查看[ WorkSpaces 使用 AWS 目录服务为 Amazon 设置单向信任的](https://d1.awsstatic.com/Projects/deploy-amazon-workspaces-one-way-trust-with-aws-directory-service.pdf)实施指南
在此场景中，我们在共享服务 VPC 和本 AWS Managed Microsoft AD 地 AD 之间建立单向传递信任。图 11 显示了信任和访问的方向，以及 AWS AD Connector 如何使用 AD Connector 服务帐户在资源域中创建计算机对象。
按照 Microsoft 的建议使用森林信任来确保尽可能使用 Kerberos 身份验证。您 WorkSpaces 将在中接收来自资源域的组策略对象 (GPO)。 AWS Managed Microsoft AD此外，您还可以使用您的身份域 WorkSpaces 执行 Kerberos 身份验证。为了使其可靠地运行，最佳做法是将您的身份域扩展到 AWS 如上所述。我们建议查看《[ WorkSpaces 使用单向信任资源域部署 Amazon Directory Service》以及](https://aws.amazon.com/getting-started/hands-on/deploy-workspaces-one-way-trust/)实施指南，了解更多详情。
AD Connector 和您的 WorkSpaces，都必须能够与您的身份域和资源域的域控制器通信。有关更多信息，请参阅《*Amazon WorkSpaces 管理指南》 WorkSpaces*中的 [IP 地址和端口要求](https://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html)。
如果您使用多个 AD 连接器，则最好让每个 AD 连接器使用自己的 AD 连接器服务帐户。
![\[aSample 架构显示了一个 Windows，其中 WorkSpaces 包含使用客户身份域中的用户在托管 Active Directory 的共享服务 VPC 中创建的计算机对象。\]](http://docs.aws.amazon.com/zh_cn/whitepapers/latest/best-practices-deploying-amazon-workspaces/images/one-way-trust-ad-onprem.png)
此架构使用以下组件或结构：
## AWS
+ **亚马逊 VPC** — 创建一个亚马逊 VPC，其中至少有两个私有子网横跨两个可用区，其中两个用于 AD Connector 和。 WorkSpaces
+ **DHCP 选项集** — 创建亚马逊 VPC DHCP 选项集。这允许客户定义指定的域名和 DNS（Microsoft AD）。有关更多信息，请参阅 [DHCP 选项集](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_DHCP_Options.html)。
+ **可选：Amazon 虚拟专用网关**-允许通过 IPsec VPN 隧道 (VPN) 或 AWS Direct Connect 连接与客户拥有的网络进行通信。用于访问本地后端系统。
+ **AWS Directory Ser** vice — 微软 AD 部署到一对专用的 VPC 子网（AD DS 托管服务），即 AD Connector。
+ **传输网关/VPC 对等互连** — 启用工作空间 VPC 和共享服务 VPC 之间的连接。
+ **亚马逊 EC2** — 适用于 MFA 的客户 “可选” RADIUS 服务器。
+ **亚马逊 WorkSpaces** — 部署 WorkSpaces 在与 AD Connector 相同的私有子网中。有关更多信息，请参阅本文档的 “[活动目录：网站和服务](design-considerations.md#active-directory-sites-and-services)” 部分。
## 客户
+ **网络连接**-企业 VPN 或 AWS Direct Connect 端点。
+ **最终用户设备** — 用于访问亚马逊服务的企业或自带终端用户设备（例如 Windows、Mac、iPad、安卓平板电脑、零客户端和 Chromebook）。 WorkSpaces 有关[支持的设备和 Web 浏览器，请参阅此客户端应用程序列表](https://docs.aws.amazon.com/workspaces/latest/userguide/workspaces-user-getting-started.html#choose-client)。
# 在 Amazon 上使用多区域 AWS 托管活动目录 WorkSpaces
[AWS 微软目录服务 Active Directory](https://aws.amazon.com/directoryservice/active-directory/) (MAD) 是一个完全托管的微软 Active Directory (AD)，可以与亚马逊配对 WorkSpaces。客户之所以选择 AWS 托管 Microsoft AD，是因为它具有内置的高可用性、监控和备份功能。 AWS Microsoft AD Enterprise 托管版增加了配置[多区域复制](https://aws.amazon.com/blogs/aws/multi-region-replication-now-enabled-for-aws-managed-microsoft-active-directory/)的功能。此功能可自动配置区域间网络连接、部署域控制器并在多个区域之间复制所有 Active Directory 数据，从而确保驻留在这些区域的 Windows 和 Linux 工作负载能够以低延迟和高性能连接和使用 AWS MAD。无法[直接向注册](https://docs.aws.amazon.com/workspaces/latest/adminguide/register-deregister-directory.html)复制的 MAD 区域 WorkSpaces，但是可以通过将 AD Connector (ADC) 配置为指向复制的域控制器来注册复制的 MAD 目录。 WorkSpaces
使用 MAD 部署 AD 连接器的最佳做法是为 WorkSpaces 环境中的每个业务部门创建一个 AD 连接器。这将允许您将每个业务部门与 Active Directory 中的特定组织单位保持一致。然后，您可以在组织单位级别分配与相关业务部门直接对应的 AD 组策略对象。
## 架构
![\[展示带有 MAD 的 AD 连接器的示例架构是为 WorkSpaces 环境中的每个业务部门创建一个 AD 连接器。\]](http://docs.aws.amazon.com/zh_cn/whitepapers/latest/best-practices-deploying-amazon-workspaces/images/registering-replicated-mad-region.png)
## 实施
要将复制的 MAD 区域注册到 WorkSpaces，你需要创建一个指向你的 MAD 域控制器 IP 的 AD Connector。您可以前往 Directory S [ervic AWS e 控制台导航窗格，选择 “目录](https://console.aws.amazon.com/directoryservicev2/)”，然后选择正确的目录 ID，找到您的 MAD 域控制器 IP 地址。要创建这些 AD 连接器，请遵循本[指南](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ad_connector_getting_started.html)。创建它们后，您可以[注册它们 WorkSpaces](https://docs.aws.amazon.com/workspaces/latest/adminguide/register-deregister-directory.html)。在新区域部署 WorkSpaces 之前，请确保已更新您的 VPC [DHCP 选项集](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/dhcp_options_set.html)。