Windows活动目录系列---分布式活动目录部署概述(下)

   本地ADDS部署与云服务集成：

   目前可以通过两种方法来将ADDS扩展到云上。一种是通过Windows Azure AD,另一种是在Windows Azure虚拟机上安装Windows 2012R2的服务器，然后将服务器提升为DC。

   什么是Windows Azure AD?

   Windows Azure AD是一个基于Windows Azure的服务，它被用来给云上的应用程序提供ID管理和访问控制。通常在订阅了office365,Exchange Online,SharePoint Online,Lync Online中的某些服务的时候会用到Windows Azure AD,另外你可以将要求有验证动作的Windows Azure Apps或者互联网连接的Apps与Windows Azure AD集成。你可以让本地部署的ADDS与Windows Azure AD同步，以便你公司的用户能够使用相同的ID去访问内部和云上的资源。

   Windows Azure AD不会包含本地部署的ADDS中所有的服务功能，Windows Server 2012 AD支持5个不同的服务： AD域服务，AD轻型目录服务，AD联盟服务，AD证书服务和AD权限管理服务。除了提供Windows Azure AD服务，目前Windows Azure也支持Windows Azure访问控制服务，这个服务支持第三方ID管理工具的集成和本地部署AD域服务的联合。

   在Windows Azure上安装活动目录

   Windows Azure提供基础架构即服务(IaaS)的功能,这个功能的本质其实就是云中的虚拟机。所有本地的虚拟化应用程序和服务器都可以考虑部署在Windows Azure上。当你在Windows Azure上部署活动目录的时候，你可以将一台虚拟机提升为域控制器，所有的部署规则和你在本地部署活动目录是完全一样的。

   你可以在Windows Azure上部署AD域服务，用来支持用户验证和作为灾难恢复的保护机制。假如你本地所有的域控制器都故障了，那么Windwos Azure上的AD域服务会保留一份你的AD数据库的完整副本，这样能够让你快速的恢复和还原网络功能性。

   当你想在Windows Azure上部署AD域服务的时候，需要考虑以下两个方面：

   1. 服务恢复。Windows Azure服务器可以按照日常的维护计划进行回滚，但是它不会为客户提供回滚服务。域控制器复制是依赖与更新序列号(USN),当一个AD域服务系统被回滚到之前的状态，会有重复的USN被创建，为了避免这种情况，Windows Server 2012 AD引入了一个新的标示符"虚拟机生成ID"，虚拟机生成ID可以检测一个回滚状态，它能够防止虚拟DC的变更数据对外复制，直到虚拟的AD域服务和域中的其他域控制器的数据聚合在一起。

   2. 虚拟机的限制。Windows Azure的虚拟机的内存上限是14G而且只有一块网卡，另外它不支持虚拟机的快照功能。

  在Windows Azure上运行AD服务的时候需要特别考虑的地方：

  因为在Windows Azure虚拟机上有几个方面是你无法控制管理的，所以在把AD安装到Windows Azure之前你需要有几个特别的地方需要考虑到：

  1.IP地址。所有的Windows Azure虚拟机都是通过DHCP来分配IP的，你的Windows Azure虚拟网络一定是要在你第一次安装域控制之前被提供的。

  2.DNS。Windows Azure内置的DNS是不符合AD的要求的，例如动态DNS和SRV记录。你可以在你的DC上安装DNS角色，但是DC不可以被设置成静态IP地址，为了避免这些潜在的问题，Windows Azure的DHCP租约是永不过期的。

 注意：不要把Windows Azure上的DC的动态IP改成静态IP，否则你在Windows Azure上的网络ID会因为变更而受到影响，如果你给DC设置了静态IP，他们最后可能会丢失连接。

  3.硬盘。Window Azure虚拟机的操作系统虚拟硬盘使用的是主机缓存读写，它能够提升虚拟机的性能，但是如果AD组件被安装在操作系统盘，数据可能会因为硬盘的故障而丢失。使用其他的Windows Azure硬盘连接到虚拟机上则不会使用缓存功能。当你在Windows Azure上安装AD时，ntds.dit和SYSVOL文件夹会放置在Windows Azure虚拟机的一个附加硬盘上，而不是放在系统盘中。

复杂的AD域环境中对DNS的要求：

AD域要求DNS能够正常的工作，所以在一个多域或者多林的环境中部署DNS则需要一些额外的规划设计。当你想部署一个DNS的架构来支持复杂的AD域环境的时候，你需要关注下面几个重要的配置区域：

1. 验证DNS客户端配置。最好给AD域中的所有计算都配置至少两个可用的DNS服务器，所有的计算机必须能够DNS保持一个良好的网络通信。

2. 验证和监视DNS的名称解析。验证所有的计算机包括DC，都能够成功的解析到林中的所有DC。DC之间必须能够成功的复制AD域的变更数据。客户端计算机必须能够通过SRV记录找到DC服务器，并且能够根据DC的名称解析到对应的IP地址。在一个多域或多林的环境中，客户端计算机可能需要定位多个跨林的服务，比如KMS服务器，TS授权服务器，特殊应用程序的授权服务器以及各个域的DC服务器，所以必须确保DNS名称的正确解析，才能保证服务的正常应用。

3. 在多个命名空间之间优化DNS的名称解析。当企业在AD林中部署了多个树，或者部署了多个林的时候，名称解析就会因为多个域命名空间的存在而变得更加复杂，使用DNS的条件转发，存根区域以及委派功能会让跨命名空间的名称解析变得更加简单和高效。

4. 使用AD域与DNS集成。当你将DNS区域与AD域集成在一起，DNS的信息将保持在AD域中，并且通过AD域的复制进程同步复制DNS的信息。这样大大的优化了DNS在林中的复制过程，另外你还可以自己定义DNS区域的复制范围，默认情况下，特定域的DNS记录将会复制到域内的其他安装了DNS角色的DC中。允许跨域解析的DNS记录存放在_msdcs.forestrootdomainname(如果你的域是contoso.com，那么这个区域的名称就是_msdcs.contoso.com)区域，这个区域的记录会被复制到整个林中装有DNS的DC上，这个默认的配置最好不要去修改。

5. 部署一个GlobalNames区域。GlobalNames区域允许你在林中配置DNS名称的单名称解析。在以前会在域中部署一台WINS服务器来支持单名称解析，GlobalNames区域可以替换WINS的存在，特别是当你部署了IPV6协议的时候，因为WINS是不支持IPV6寻址的。

6. 当你把AD域扩展到Windows Azure，你需要做一些额外的配置。Windows Azure内置的DNS是不支持AD域服务的，如果要支持云上的域功能组件，你需要做以下的配置：

   a.为Windows Azure的子网配置一个AD域站点

   b.将本地部署的DNS在Windows Azure上注册，以便能够从Windows Azure上访问DNS记录。

   c.在Windows Azure上注册基于云的DNS