AWS Directory Service

在这里插入图片描述

Hello大家好，我们接下来讨论AWS Directory Service，AWS目录服务的内容。

什么是微软活动目录（AD）

在这里插入图片描述

在认证考试中有很多的考点是关于微软AD部分的，也就是微软活动目录以及AWS活动目录服务—AWS Directory Service的内容。

微软活动目录知识面比较复杂，如果您完全不了解微软活动目录，那么学习本课时可能会有些吃力，建议先去看一些微软活动目录的基础知识。

那什么是微软活动目录呢？AD在Windows 2000 Server开始内置于Windows Server产品中。它是微软Windows Server中，负责架构中大型网络环境的集中式目录管理服务（Directory Services）。

负责处理以及存储在组织中的网络对象。对象可以是用户、组群、电脑、邮件、配置文件、打印机等等。

它是一种WINDOWS环境中集中管理方式，用于安全管理，创建账户，分配权限等等。

前面提到的这些对象，如用户、群组、电脑、打印机等等他们将被组织在一起，并组织成”树”，然后一组“树”被称为“森林”。

那么，我们为什么需要AD呢？我举个简单例子：

例如，我们有一个域控制器存储和管理着张三的用户名和密码，然后还有一些其他的Microsoft电脑连接到此域控制器。我们就可以在这些任何一台电脑上使用张三的登陆凭证登陆WINDOWS。AD负责登陆验证并对用户进行管理。

当然这只是AD的一个非常简单的一个功能举例，AD还有客户端计算机管理，组策略，资源管理等等功能在这里就不在展开了。

什么是ADFS?（微软活动目录联合服务）

在这里插入图片描述

那什么是ADFS呢？ADFS翻译过来是微软活动目录联合服务。它主要功能是提供了跨应用程序的单点登录。

所以这意味着可为任何支持ADFS提供如跨AWS控制台、Dropbox、Office365单点登录。

我们之前的课时介绍过这个流程：

用户连接到ADFS进行验证，ADFS 将使用您的 Microsoft AD 对用户进行身份验证，然后 ADFS 将返回一个响应，该响应将被传递到AWS 并与 STS 交换令牌，最终用户可以使用该临时凭证访问AWS管理控制台。在之后我们会讨论SSO，SSO使我们能够更轻松地做到这一点。

AWS Directory Services

在这里插入图片描述

好的，接下来我们讨论AWS Directory Services，AWS目录服务。这是由AWS管理的服务，有三种目录类型。

**第一个叫做 AWS Managed Microsoft AD,**正如其名，它是搭建在AWS云端的Microsoft AD。

您可以使用它在AWS 中创建您自己的 AD**，**在AWS本地管理用户，并支持MFA。如果您想使其和本地 AD 之间建立连接，必须将AWS 托管的Microsoft AD与本地 AD 建立信任关系。我们看下这种信任是什么样的：

位于右侧的AWS托管 AD 连接到本地 AD，并建立了信任关系，它支持 MFA，用户可以在本地，或者在AWS托管的AD任意端进行身份验证。

**AWS目录服务的第二个叫做AD Connector，**它是一个代理服务，能够从云端重定向请求到您的本地AD。

注意在使用AD Connector场景时，管理用户只能够在本地端进行，我们来看一下：

所以在这种场景下，在AD Connector端的身份验证，因为AD Connector它是一个代理服务，这里的请求会被代理发送到本地的AD获取响应。

所以，在前面讲的使用Microsoft 托管AD的情况下，我们可以在本地和云端两个地方管理用户，需要建立信任关系。

而使用 AD Connector，用户只能在本地管理，来自云端的请求会通过这个代理来访问本地的AD。

**最后一个服务叫做Simple AD，**是由Samba 4 提供支持的独立托管目录。现在使用的很多需要微软AD支持的应用程序和工具都可以与 Simple AD 一起使用。

注意它不能与本地 AD 连接。

使用 Simple AD 是一种更低成本的解决方案，它不支持太多的功能，例如，不支持 MFA。Simple AD与一些AWS的服务也不兼容，如RDS SQL Server等。

但它会更简单，更低的成本，如果您的场景是需要一个简单的目录服务，用于支持基本AD功能的Windows 工作负载，那么Simple AD就会是一个更合适的方案。

好的，我们讨论了以上三种目录服务，也简单探讨了他们之间的区别，接下来我们将更加深入的探讨这三种目录服务，让大家非常清楚的了解他们之间的区别和使用场景。

AWS Directory Service - AWS Managed Microsoft AD

在这里插入图片描述

首先，AWS Managed Microsoft AD，我们后面就称其为AWS托管微软AD。

选择使用AWS托管微软AD，它会部署到您的VPC中，大致是这样：

两个可用区，就会创建两个连接到 Virtual Private Cloud (VPC) 的域控制器，分别部署在两个不同的可用区中以实现高可用性。

然后我们就可以创建 EC2 Windows 实例，并加入域。我们可以在这些实例上部署传统AD应用程序，例如，sharepoint。

还支持将多个AWS账户和VPC中的Windows EC2 实例无缝加入到域中。

它和很多AWS资源无缝集成，比如我们在云中部署托管微软AD，可以将其与 RDS for SQL Server，WorkSpaces, Quicksight 等无缝集成使用。

可以创建AWS SSO，提供对第三方应用程序的访问。

AWS托管微软AD支持在AWS作为一个独立的存储库，或者可以加入到您的本地 AD。

多可用区部署将至少是两个可用区，支持增加更多的域控制器以提供更高的可用性，所以在这个例子中，我可以在添加两个域控制器，一共四个域控制器，提高了可用性。

另外，AWS托管微软AD的数据复制、快照和软件更新是自动为您配置和管理的。

最后总结下，使用AWS托管微软AD，可以与其他服务无缝集成，支持无缝加入EC2 实例，多可用区部署。

AWS Managed Microsoft AD - 集成

在这里插入图片描述

前面我们提到了AWS托管微软AD与很多资源和服务很好的集成，接下来让我们深入了解一下集成。

如：这是我们部署的AWS托管微软AD的域控，它可以和本地AD配置一个双向森林信任，就可以从云端扩展到使用您的本地的AD，后面我们会介绍这部分。

它还与一系列 AWS 服务集成，如最常用和重要的是：RDS for SQL Server，WorkSpaces，Quicksight，AWS Connect，WorkDocs，和AWS SSO单点登陆，

并且通过单点登录，我们可以访问更多 SAML 业务的应用程序，例如 GitHub、Box、Dropbox、Office365 等，我们将在后面的课时看到这部分内容。

最后，您的传统 Active Directory 应用程序，例如您的 .NET 应用程序、SharePoint、以及您部署在 EC2 实例上的 SQL Server，显然都可以和AWS托管微软AD很好的集成。

所以大家可以看到，这将是与AWS产品集成度最高的目录服务。

连接到本地AD

在这里插入图片描述

好的，接下来我们来讨论如何将AWS托管微软AD连接扩展到您的本地 Active Directory ,注意这部分在考试中有很多考点。

您可以将本地部署的AD连接扩展到AWS托管的微软AD。两者之间需要设置一个 Direct Connect，DX，或者是通过VPN连接。

我们来看一下：

左边是您本地部署的AD，右侧是您部署VPC的AWS托管的微软AD，我们已经在两者之间建立了连接。在本地部署的微软AD，它负责管理本地的用户；在AWS托管的微软AD，负责管理在AWS上的用户。

AWS托管微软 AD 支持所有三个信任关系方向：传入、传出和双向，分别表示本地到AWS单向信任，AWS到本地单向信任，以及双向森林信任。

这块有一个重要的知识点要注意，上面说到的信任关系，和同步不是一个概念，不要混淆。

AWS托管的微软AD是不支持复制的，这就意味着在这两个不同的微软AD上的用户是相互独立的，这一点大家要了解。

但如果本地AD和AWS托管微软 AD建立了信任关系后，如果在其中一个AD中找不到某个用户，也会询问这个用户在另一个AD是否存在，因为两个AD建立了信任关系。但这并不到等于数据复制，所以理解这一点非常重要。我们来看一下：

您的传统AD应用程序可以连接到本地的AD，您的 EC2 实例可以进行无缝域加入到您的AWS托管微软 AD。然后因为我们建立了双向森林信任，您传统的 Active Directory 应用程序，如果它试图请求一个属于 AWS的上的域，因为配置了信任关系，它就有权限和能力访问到右侧AWS的AD并检查其中的用户。这是双向森林信任的一个场景。

解决方案-AD复制

在这里插入图片描述

好的，接下来我们看一个相关的解决方案架构，可能稍微有点复杂，大家要掌握这部分内容。

这个架构的场景是您想要部署在您本地的微软AD在AWS中建立一个副本，当本地和AWS之间的DX或者VPN出现故障时，仍然希望用户能够正常连接和访问。

这需要在AWS和本地AD之间建立信任关系，我们来看一下：

左边是我们的本地的微软AD,包括一个域；右侧是AWS VPC下有一个AWS托管的AD DC包括另一个域，他们之间没办法直接设置复制，设置复制的唯一方法，是启动一个EC2实例，在一个EC2 Windows实例上部署一个AD，并设置它与本地AD的复制。

通过配置这些复制，我们将在VPC上拥有一个本地微软AD的副本，这样将有助于最大程度的减少延迟，并且也有助于灾备恢复。

最后，我们可以在我们这个VPC中的EC2实例，和这个AWS托管的微软AD DC之间建立一个双向信任。从而达到我们上面提到的需求。

好的，这是一种解决方案架构，考试的时候可以会出现这个考点，希望大家能够掌握。

以上就是所有aws托管的微软AD的全部内容。

AWS Directory Service - AD Connector

在这里插入图片描述

接下里我们讨论 AD Connector ，这部分就简单的多了。

AD Connector是一个网关，一个代理，它可以重定向您的请求到您本地的微软AD。

不支持缓存功能，不支持MFA，用户仅在本地进行管理，无法配置信任关系，需要VPN或者DX连接。

没有和 SQL Server做集成，也不能进行无缝连接，不能共享目录。

所以AD Connector是一个比较基础的组件，所以在考试中如果遇到需要目录服务代理的场景，就需要使用AD Connector。

使用AD Connector如果连接断开了基本上就废了。

那么它是如何工作的呢？我们来看一下：

左边是本地网路，右边是AWS，然后在两者之间通过一个DX或者VPN连接，我们已经配置了AD Connector，因此，如果我们的用户通过 AD Connector连接，AD Connector 收到用户的请求，然后访问本地的AD，代理身份验证并取回登陆信息回给用户，所以这就是它的工作方式，在这种场景下可能会有一些延迟。