Windows活动目录系列---AD站点(2)

gfdxy3322

　　什么是站点之间的拓扑生成器(Intersite topology generator ISTG)？
　　在配置多站点的时候，KCC会指定每个站点中的一台DC作为站点间拓扑生成器。无论站点有多少个域或者目录分区，每个站点只能有一个ISTG。ISTG负责计算出跨站点链接时最理想的站点复制拓扑，当你在林中新增一个站点，每个站点的ITSG会去确认新站点出现在哪个目录分区，然后ISTG计算出有多少个新的链接对象是新站点复制信息时必须用到的。
　　在有些网络中，你可能希望指定某一个DC来进行站点间的复制，我们可以通过配置桥头服务器来满足这个要求。桥头服务器负责站点的所有进站复制和出站复制。ISTG会在它的目录中建立一个连接协议，并且稍后会把这个协议复制到桥头服务器，然后桥头服务器会与远程站点的桥头服务器建立一个复制连接并通过这个复制连接开始复制信息。如果有一个复制伙伴不可用了，ISTG会自动的选择另外一个DC作为该站点中的ISTG，但是如果你手动指定了桥头服务器，并且桥头服务器不可用了，那么ISTG是不会自动选择其他的DC作为该站点的ISTG的。
　　默认情况下，ISTG会自动选择桥头服务器，然后创建站点间的复制拓扑，来保证那些共享一个站点链接的桥头服务器之间能够正常的复制变更数据。每个目录分区都会有桥头服务器，所以站点内的某个DC可能是架构分区的桥头服务器，而另外一台DC可能是配置分区的桥头服务器，但是通常是一台DC作为所有目录分区的桥头服务器，除非站点中有其他域的应用程序分区或者域分区，如果出现这种情况，就会有多个桥头服务器了。当你在站点之间有防火墙，并且防火墙只允许指定的DC之间进行复制的时候，手动配置桥头服务器就非常适合这种情况。
　　在多站点的环境中优化DC的覆盖
　　当你在域中新增一台DC的时候，这台新DC会通过在DNS中建立一个SRV记录来发布它的服务。它和主机的A记录不同，主机的A记录是将主机名与IP地址做映射，而SRV记录是将服务和主机名做映射。例如想要发布提供验证和目录访问功能的服务，就需要一台DC注册Kerberos V5协议和LDAP的SRV记录，这些SRV记录会被写入到林DNS区域的几个文件夹中。
　　在DNS的域区域中，名称为_tcp的文件夹中保存了域中所有DC的SRV记录，域区域中还有一个_site的文件夹，这个文件夹中保存了为域中每个站点创建的子文件夹，每个站点的文件中都保存了此站点可用服务的SRV记录，比如在一个站点中装了一台DC，那么在_site\站点名\_tcp中就会有一条对应这台DC的SRV记录。
　　SRV记录中一般包含以下的信息：

• 　　服务名称和端口。SRV记录会表明它所代表的服务和服务所用的固定端口，这个端口不一定要是熟知的端口。在Windows 2012中SRV记录中包含 LDAP的端口389，Kerberos的端口88,Kerberos密码协议的端口464，以及GC服务的端口3268.
  
• 　　协议。TCP和UDP是服务的两种传输协议，同一个服务可以通过两个不同的SRV记录分别使用这两种传输协议，例如Kerberos记录就用这两种协议注册了SRV记录。Windows的客户端只会用TCP的协议，但是UNIX的客户端可以使用TCP和UDP两种协议。
  
• 　　主机名。主机名对应了承载服务的服务器A记录，当客户端查询服务的时候，DNS服务器会返回SRV记录和关联的A记录给客户端，所以客户端不需要单独的提交一个查询去解析服务的IP地址。
  

　　SRV记录中的服务器名遵循标准的DNS组件层次，通过"."来划分组件。比如一台DC的Kerberos服务注册记录为Kerberos._tcp.站点名._sites.域名。域名指的是域或者DNS区域，例如contoso.com，_site是所有DNS中注册的站点，站点名是承载服务的DC所隶属的站点，_tcp是站点内所有基于TCP协议的服务，Kerberos是使用TCP作为创术协议的Kerberos秘钥颁发中心。
　　在某些特定的场合，某些分公司地区有计算机设备但是没有DC，或者不需要安装一台DC给它，这种情况我们可以建立一个没有DC的站点，但是这样的话在这个站点的_sites\站点名\_tcp的目录下面是不会列出对应DC的SRV记录的。有几种方式可以解决这个问题，例如你比较关注的是DC和AD域数据库的安全性维护，那么可以部署RODC，或者使用自动站点覆盖功能，在一个空的站点中(指没有DC的站点)，离此空站点最近的站点中的DC会自动的处理两个站点的信息(自身站点和空站点)，并且将自己的SVR记录写入到空站点中，这个操作可以通过组策略来配置。或者如果站点只是有较少的电脑，并且网络状况良好，为了节省部署服务器的费用，你可以将本地站点的子网添加到有多台DC的中心站点中，此时客户端计算机是位于远程站点的，无DC的站点位置会被认为是隶属于中心站点，只有在中心站点中的DC都不可用的情况下无DC的站点才会出现问题。在这种情况下，客户端使用缓存凭证进行本地验证，但是因为站点链接自动桥接默认是开启的，那么域验证始终还是经过桥接多个站点的站点链接进行。
　　客户端计算机是如何发现DC的？
　　当你将一台windows操作系统的计算机加入域并重启后，客户端就完成了DC的发现和客户端注册过程。注册过程的目的是为了根据IP子网的信息，最快的发现离客户端最近的DC。
　　客户端发现DC的过程如下：

• 　　新的客户端会去查询域中所有的DC。当新加域的客户端重新启动的时候，它会从DHCP接收一个IP地址，并为域的验证做好准备，但是客户端不知道DC在哪里，因此客户端会去查找_tcp文件夹来查询DC，_tcp文件夹中保存有域中所有DC的SRV记录。
  
• 　　客户端尝试一个LDAP的Ping命令，去按顺序的Ping所有的DC。客户端向DNS查询_tcp文件夹后，DNS返回给客户端一个清单，里面包含了所有满足的DC，然后客户端在第一次启动的时候会尝试连接清单中所有的DC。
  
• 　　第一台DC响应Ping命令。第一台响应Ping命令的DC会检查客户端的IP地址，并且将客户端的IP地址和站点中的子网对象相互参照，接着将客户端所隶属的站点信息发回给客户端，客户端收到信息后将站点名保存在本机的注册表中，然后到指定站点的_tcp文件夹中查询DC信息。
  
• 　　客户端查询所属站点中的所有DC。第3步中的查询动作发生后，DNS会返回客户端一个所属站点中的DC列表。
  
• 　　客户端顺序的对站点中所有的DC进行LDAP的Ping操作。DC发出响应首次验证客户端。
  
• 　　客户端生成一个亲密度。客户端会与最先响应的DC形成一个亲密度，并且以后的验证都会最先尝试与这台DC联系，如果这台DC不可用了，客户端会再次查询站点内的_tcp文件夹，然后再与最先响应的DC进行绑定。
  

　　如果客户端移动到了另外一个站点，像移动客户端，手提电脑之类的设备，客户端会尝试连接到它的首选DC去验证，首选DC会通知客户端，它的IP地址不是本站点的，然后引用一个新站点给客户端，客户端通过DNS查询IP所属的站点中的DC。
　　自动的站点覆盖：
　　像之前提到的，你可以配置站点引导用户找到复制资源的本地副本，比如DFS命名空间中的共享文件夹。有时候你可能不需要DC，只要求让服务本地化，那么非本站点的最近DC将会把它的SVR记录在本站点中，这个过程就称为站点覆盖。
　　没有DC的站点应用站点覆盖时，一般是被与此站点的站点链接花费最低的站点中的DC，当然你也可以手动的去配置站点覆盖和SRV记录的优先级，来指定你想要使用的站点中的DC来为没有DC的站点提供验证服务。
　　关于如何评估站点覆盖的资料可以参考一下链接：
http://go.microsoft.com/fwlink/?LinkId=168550