方案 1:使用 AD Connector 将身份验证代理到本地部署 Active Directory 服务 - 部署 Amazon WorkSpaces 的最佳实践

方案 1:使用 AD Connector 将身份验证代理到本地部署 Active Directory 服务

此方案适用于不希望将本地部署 Active Directory 服务扩展到 AWS 的客户,或者 AD DS 的新部署不是选项的情况。图 4 概括地描述了每个组件,并显示了用户身份验证流程。

显示连接到本地部署 Active Directory 的 AD Connector 的示意图。

图 4 – AD Connector 到本地部署 Active Directory

在此方案中,AWS Directory Service(AD Connector)用于通过 AD Connector 代理到客户本地部署 AD DS 的所有用户或 MFA 身份验证(图 5)。有关用于身份验证过程的协议或加密的详细信息,请参阅本文档的安全部分。

显示通过身份验证网关进行用户身份验证的示意图。

图 5 – 通过身份验证网关进行用户身份验证

方案 1 显示了一种混合架构,其中客户可能已经具有 AWS 中的资源,以及可通过 Amazon WorkSpaces 访问的本地部署数据中心中的资源。客户可以利用其现有的本地部署 AD DS 和 RADIUS 服务器进行用户和 MFA 身份验证。

此架构使用以下组件或构造。

AWS

  • Amazon VPC – 创建一个 Amazon VPC,其中至少有两个跨两个可用区的私有子网。

  • DHCP 选项集 – 创建一个 Amazon VPC DHCP 选项集。这允许定义客户指定的域名和域名服务器(DNS)(本地部署服务)。有关更多信息,请参阅 DHCP 选项集

  • Amazon 虚拟私有网关 – 能够通过 IPsec VPN 隧道或 AWS Direct Connect 连接与您自己的网络进行通信。

  • AWS Directory Service – AD Connector 部署到一对 Amazon VPC 私有子网中。

  • Amazon WorkSpaces – WorkSpaces 与 AD Connector 部署在相同的私有子网中(请参阅本文档的设计注意事项部分)。

客户

  • 网络连接 – 企业 VPN 或 Direct Connect 终端节点。

  • AD DS – 企业 AD DS。

  • MFA(可选)– 企业 RADIUS 服务器。

  • 终端用户设备 – 用于访问 Amazon WorkSpaces 服务的企业或 BYOL 终端用户设备(例如 Windows、Mac、iPad、安卓平板电脑、零客户端和 Chromebook)。请参阅此适用于受支持的设备和 Web 浏览器的客户端应用程序列表

尽管此解决方案非常适合不想将 AD DS 部署到云中的客户,但它确实有一些注意事项:

  • 依赖连接 – 如果与数据中心的连接丢失,用户将无法登录各自的 WorkSpaces,而现有连接将在 Kerberos/票证授予票证(TGT)生命周期内保持活动状态。

  • 延迟 – 如果连接时存在延迟(VPN 比 Direct Connect 更易出现此问题),则 WorkSpaces 身份验证和任何与 AD DS 相关的活动(例如组策略(GPO)实施)将花费更多时间。

  • 流量成本 – 所有身份验证都必须遍历 VPN 或 Direct Connect 链路,因此流量成本取决于连接类型。这可以是数据自 Amazon EC2 传出至 Internet,也可以是数据传出 (Direct Connect)。

注意

AD Connector 是一种代理服务。它不存储或缓存用户凭证。所有身份验证、查找和管理请求都由您的 Active Directory 处理。有权读取所有用户信息并将计算机加入域的目录服务中需要具有委派权限的账户。

通常,WorkSpaces 体验高度依赖于图 4 中所示的项目 5。对于此方案,WorkSpaces 身份验证体验高度依赖于客户 AD 和 WorkSpaces VPC 之间的网络链路。客户应确保该链路高度可用。