Windows Server 2003 AD应用程序目录分区深入了解.doc

Windows Server 2003 AD应用程序目录分区深入了解 -江小帅 2010-02-03 16:31:56标签：Windows Server 应用程序 分区 江小帅推送到技术圈 江小帅的作品我很喜欢，大家可以读一下，很有名气！他目前在WINITPRO工作，之前有幸跟他本人通过电话！希望他会继续出更好的文章，这是文章是他N年前发的不过还是不会过时！Windows Server 2003 AD应用程序目录分区深入了解作者：江小帅微软的技术知识库实在是太庞大了，以至一些新的功能我们在彻底熟悉的时候会花费太多的时间，没办法，这是由于产品的复杂性决定的。面对OS或服务组件及AD我们应该经常问的是：默认为什么会出现这个？为什么要有这样的功能？这个功能如何实现？这个功能有什么限制？拿此文做例子，可能一些人认为不去了解活动目录的应用程序目录分区或DNS区域中随DC增加而带来的新记录的变化，网络环境也一样运行。呵呵！那就大可不必看了。 一、Windows Server 2003 AD应用程序目录分区 1) 什么是应用程序目录分区？ 应用程序目录分区是仅复制到特定域控制器的目录分区。参与特定应用程序目录分区复制的域控制器寄存该分区的副本。只有运行 Windows Server 2003 的域控制器可以寄存应用程序目录分区的副本。应用程序目录分区可包含任何类型的对象（除了安全主体）。在Windows 2000的DC时代默认DC上会存留三个常规的目录分区：Schema目录分区，Configuration目录分区，Domain目录分区（如果是GC的话，那么还存在GC的目录）。Schema目录分区全森林复制，一般也很少对其做修改设置，除非当安装像Exchange这样的应用程序或需要添加雇员的ID和Number到AD的时候这个分区的内容才会需要更改。Configuration目录分区也是全森林复制的，对于域配置的变化，DC的增加减少，站点的变化等而随之变化。所以对于一个成熟的企业域环境，这个变化也会很少。Domain目录分区为全域复制的分区，这个分区微软当初定义的时候是用来容纳一些user、computer、OU、GPO等对象。基本上一个公司的这些对象在使用Domain目录分区存储的时候变化是客观的，用户或计算机、策略的变化必然要使维持这个目录分区的宿主DC之间同步。那为什么Windows 2003还要提供应用程序目录分区的功能呢？ 2) 为什么Windows 2003 AD要支持应用程序目录分区？ AD的对象一般都是相对静态的，这样对提高DC的性能、提高KCC之间的平衡有很大的帮助。所以在“向AD中发布对象”的时候对于经常，频繁性变化的对象不适合使用AD这样的分布数据库来进行存储。在Windows 2000 DC时代，DNS的区域是可以集成到AD的，这是因为AD的数据库为了优化客户程序定位DC必须需要DNS来实现底层的定位，而将DNS的区域文件保存在AD的数据库里可以实现客户程序以任意形式来定位任意DC，那么DNS的区域保存在哪里？答案是保存在Domain目录分区里（图5指出了DNS区域文件如果存储在Domain目录分区时它的位置），它将在域的范围内复制，这就让一些不提供DNS服务但身份是DC的计算机干了“狗拿耗子”的事情（也有备份的考虑在内）。DNS的区域记录对于一些网络也是经常变化的，比如客户计算机名字频繁变化的环境，所有的同域DC都在跟着复制变化的DNS区域记录，不管你到底提不提供DNS服务（类比一下电影大腕里王小柱说的话：直播要覆盖到全球每个角落，允许你不看，但不允许说你收不到）。所以活动目录应用程序分区才在Windows 2003中出现了。 3) 目录应用程序的命名 提前理解这个有利于帮助我们理解2003AD默认的DNS应用程序目录分区。应用程序目录分区是整个林名称空间的一部分，就像域目录分区一样。它与域目录分区遵循相同的域名系统 (DNS) 和可分辨名称命名约定。应用程序目录分区可出现在林名称空间中可出现域目录分区的任何地方。在林名称空间中，应用程序目录分区可能出现在三处：域目录分区的子项、应用程序目录分区的子项、林中的新树。 二、Windows Server 2003 DNS应用程序目录分区（创建的AD环境，所有计算机全部为2003SP1的操作系统） 1) 默认的DNS应用程序分区 默认全新装Windows Server 2003 DC的时候AD会自动创建两个应用程序目录分区：ForestDnsZones目录分区、DomainDnsZones目录分区。这两个目录分区都可以存储DNS的区域记录。但复制的范围（复制作用域）是不一样的，一个是整个森林范围内的DC间复制，一个域范围内的DC间复制。 2) DNS区域的创建向导 DNS区域的创建向导会出现一个特殊的选项如图1，理解这些选项的区别将帮助我们理解区域的复制，更涉及到DC上KCC的运行性能。 “至Active Directory林中的所有DNS服务器”-将创建的DNS区域存储在默认的ForestDnsZ应用程序目录分区，所以将导致创建的DNS区域被复制到森林中所有运行2003DC并提供DNS服务的服务器上。 “至Active Directory域中的所有DNS服务器”-将创建的DNS区域存储在默认的DomainDnsZ应用程序目录分区，所以将导致创建的DNS区域被复制到域中所有运行2003DC并提供DNS服务的服务器上。 “至Active Directory域中的所有域控制器”-将创建的DNS区域存储在Domain目录分区，所以将导致创建的DNS区域被复制到域中所有的域控制器上。因为2000不支持应用程序目录分区，所以当域中包含2000操作系统的DC时推荐选择此项。 “到在以下应用程序目录分区的范围内指定的所有域控制器”（默认灰色）-只有当使用应用程序目录分区创建命令创建一个新的应用程序目录分区的时候才可以使用，小帅在后面的部分中将创建一个应用程序目录分区之后，这个部分就可以选择了。 3) 建立森林中的第一台域控制器： 默认建立林中第一台DC的时候都会让Dcpromo向导自动安装DNS服务，安装过程小帅在这里忽略了。建立好的该DC之后，我们来仔仔细细看看DNS区域及DNS特殊记录。如图2DNS区域：默认Dcpromo创建了两个DNS区域：_、，小帅自己手工创建了一个DNS反向搜索区域：10.0.0.x subnet，下面小帅一个个的说明这些区域。 DNS区域_的“复制作用域”为“至Active Directory林中的所有DNS服务器”，所以该DNS区域实际上是存储在ForestDnsZ这个默认创建的DNS应用程序分区中了。注意该区域是被默认委派的，因为在的区域里面有一个委派记录。图3是利用ADSI显示该应用程序分区的情况。提示：Dcpromo默认创建的名为_的DNS区域是主持 Active Directory 林中所有域控制器的域控制器定位器 DNS 资源记录。它还可用于在 Active Directory 域或 Active Directory 林中定位具有特定角色的域控制器（PDC、GC），如果域已重命名，则可通过搜索域控制器的 GUID 来定位它（那个长长数字）。另外/kb/817470/zh-cn中详细说明了Windows 2000及Windows 2003在创建默认的DNS区域时的不同、升级到Windows 2003的DNS做配置全林性应用程序目录分区的修改、理解_msdcs区域在windows 2003域控制器中的任一的两中存储方式。另外注意在Windows Server 2003 SP1 中，当创建一个已位于现有区域下的新的正向查找区域时，向导会在该现有区域下自动创建一个新的委派。DNS区域的复制作用域为“至Active Directory域中的所有DNS服务器”，所以该DNS区域实际上是存储在DomainDnsZ这个默认创建的DNS应用程序分区中了。图4是利用ADSI显示该应用程序分区的情况。DC=RootDNSServers容器中保存的是根提示 特殊的DNS记录： 回到图2上，在区域下有两个“域”：ForestDnsZones和DomainDnsZones。这两个位置是用来说明：在哪台DC宿主ForestDnsZ应用程序目录分区（所以该记录的格式只有tcp.sitename._.或形式，别忘了该目录分区是林复制性的，所以没域什么事儿），哪台DC是宿主DomainDnsZ应用程序目录分区的，此时的SRV记录都应该时， 图6是利用Replmon.exe显示的上的目录分区情况（由于是第一台DC，所以没有任何复制链接）利用LDP.exe也显示了上存在5个NamingContexts（目录分区），如图7高亮显示的部分（注意他们的DN格式）4) 建立域中的第二台域控制器： 在建立域的第二台域控制器的时候，默认都是将要成为的计算机的DNS服务器地址指向。Dcpromo向导不会有是否选择安装DNS服务的提示。安装步骤小帅这里省略。安装完重启后并没有安装DNS服务，所以上不应该宿主ForestDnsZ和DomainDnsZ这两个应用程序目录分区。图8是利用LDP.exe显示的名称上下文下面的图9是利用Replmon.exe查看的复制情况（两台DC都属于一个站点，形成的是站点内部的复制）大家也可以在c:windowsdebug下找到Dcpromo.txt。该文件内详细说明了，当dc02被提升为DC的时候从dc01上复制了哪些目录分区。（只有3个） 在DNS控制台中区域下面的两个特殊“域”中仍然只有dc01的SRV记录，因为此时dc02上根本就没有任何应用程序目录分区。 接下来在上安装DNS服务，安装步骤小帅省略，这样经过一定的复制周期，站点链接建立完成，同步完成之后，将与一样拥有5个名称上下文。如图10所示在DNS的控制台中我们也可以看到区域下面的两个特殊的“域”内包含了两个DC提供LDAP服务的SRV记录。如图11我们以“DomainDnsZones”域为例证明目前应用程序分区DomainDnsZ存在两个副本。应用程序目录分区ForestDnsZ也是一样的。其他识别应用程序目录分区的工具和办法： Configuration目录分区中的Partition容易下包含了所有的应用程序目录分区，这样每个域的DC在复制这个名称上下文的时候都可以查看到森林中有哪些应用程序目录分区。在每一个应用程序目录分区的属性中有一个属性叫msDS-NC-Replica-Locations，这个属性的值决定着该目录分区的副本有几个，也就是都由哪几台DC来宿主的。如图12图12中ForestDnsZones应用程序目录分区的msDS-NC-Replica-Locations属性值有两个： CN=NTDS Settings,CN=DC01,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configureation,DC=jzlld,DC=org CN=NTDS Settings,CN=DC02,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configureation,DC=jzlld,DC=org msDS-NC-Replica-Locations属性值请参考以下链接： /librar . ctive_directory.asp 应用程序目录分区的对象类型是crossRef，请参考以下链接： /librar . hema/c_crossref.asp 你也可以使用dnscmd的一个子命令来查询某个DNS应用程序目录分区的情况。比如在dc01上查看DNS应用程序目录分区ForestDnsZ的信息可以使用如下命令： “dnscmd.exe /DirectoryPartitionInfo ForestDnsZ” 5) 建立子域并建立该域的第一台域控制器： 在建立子域的第一台域控制器的时候，将dc03的DNS服务器的地址指向dc01，这样可以使其联系到域命名FSMO（），以便对新域命名及对新DC的添加给予允许操作。Dcpromo同样也不会出现安装DNS服务的提示。建立的步骤小帅省略（3台DC都在一个站点内部）。这样的3台DC的KCC同步是需要时间的，所以等“AD站点和服务”中出现了环状链接说明KCC服务已经达到平衡了。dc03会在dc01的区域创建一个“子域”sub，并将自己的一些SRV记录登记在下面，当然也会在dc01的_区域注册一些记录，别忘了上面我们提到的这个DNS区域的作用。 利用replmon.exe查看的目录分区及应用程序分区复制情况如图13，（请看仔细，略微有点儿长）为什么有一个“DC=sub,DC=jzlld,DC=org”的名称上下文，而且是单向的？因为是GC（注意dc01上的特殊标记），需要从sub域内的基础机构主控（）抄写该域对象的属性子集。如果也是GC的话，那么它也会有这样一个名称上下文。 此时，应用程序目录分区的msDS-NC-Replica-Locations属性仍然是两个值，因为dc03目前还不是DNS服务器。而且dc01和dc02的DNS控制台中的两个特殊的“域”（ForestDnsZones和DomainDnsZones）也不会有什么变化，依然是两个LDAP服务的SRV记录，分别是dc01和dc02的。 接下来对区域做区域分割，将目前的DNS区域名称空间分割成两个区域：和，然后做授权给来维护DNS区域的操作并在上安装DNS服务并建立相应的区域，修改网卡上的DNS服务器地址的指向，配置对区域的所有查询转发到（一定要注意配置转发）。建立的步骤小帅省略。此时dc03应该有默认的ForestDnsZ的应用程序目录分区（DNS区域_能够自动复制到dc03就说明了这点），还应该有自己本域的一个默认应用程序目录分区：DomainDnsZ（这个应用程序目录分区与DomainDnsZ是不同的，可以查看两个应用程序目录分区的GUID及他们的宿主来区别）如图14的DNS区域的两个“域”（ForestDnsZones和DomainDnsZones）的变化如图15、如图16ForestDnsZ应用程序目录分区的3个宿主分别在该“域”内注册了LDAP的SRV记录。DomainDnsZ应用程序目录分区的2个宿主分别在该“域”内注册了LDAP的SRV记录，因为这个应用程序目录分区是在域内的DC兼DNS的计算机上宿主的。所以没有dc03的LDAP服务的SRV记录，只有dc01和dc02的。 当小帅在的自己的DNS控制台上创建一个DNS区域，并且复制作用域设置为“至Active Directory域中的所有DNS服务器”的时候，在该DNS区域下将出现DomainDnsZones“域”，其内的记录为DomainDnsZ应用程序目录分区宿主dc03上的LDAP服务注册的SRV记录，如图17为什么反向查找区域没有区域？ 因为小帅在dc01上创建10.0.0.x subnet区域的时候设置该区域是在域内的全域复制的，所以它包含在域的Domain目录分区内，当然不会被复制过来。 为什么的DNS区域下面没有名为ForestDnsZones“域”？ 因为宿主ForestDnsZ应用程序目录分区的宿主SRV记录保存在dc01和dc02的DNS区域下面，是不会复制到该位置的。_区域能够出现（不是小帅手工创建的，是复制出来的）能够出现本身也意味着计算机是ForestDnsZ应用程序目录分区的宿主。 既然这样，那如果子域sub中的一些应用程序目录分区的客户端应用程序需要定位企业中的某些应用程序目录分区那怎么办？ 别忘了，小帅说过Configuration目录分区中包含了企业中的所有名称上下文，也就是包含了所有AD林中的目录分区（目录分区和应用程序分区），并且该目录分区是全林性复制的。另外从一个应用程序分区的命名上客户端程序就知道应该上哪台DNS上去定位记录了。如图18企业森林中到目前为止有7种不同的名称上下文（目录分区），至于它们各自的复制作用域，各位自己分析吧。 6) 命令行工具dnscmd 这个工具可以用来管理DNS应用程序目录分区，大家可以参看如下链接 /technet . a5cc2.mspx?mfr=true /technet . a5cc2.mspx?mfr=true /technet . a5cc2.mspx?mfr=true /technet . a5cc2.mspx?mfr=true 默认情况下，DNS 服务器服务将尝试在 Active Directory 中定位和创建默认的 DNS 应用程序目录分区。如果 DNS 服务器服务无法做到这一点，那么管理员可以使用该过程手动创建应用程序目录分区。如果当前在 Active Directory 中默认的 DNS 应用程序目录分区可用，在 DNS 控制台中创建默认应用程序目录分区的选项将不可用。可以使用DNS控制台，也可以使用命令行工具dnscmd.exe来完成该操作。 默认情况下，只有 Enterprise Admins 组的成员才可以创建 DNS 应用程序目录分区。 利用dnscmd.exe命令来创建一个DNS应用程序分区。 小帅在上利用dnscmd.exe命令行工具来创建一个DNS应用程序分区，FQDN名字为TestDnsZ。如图19此时，在dc01上的DNS控制台中创建一个DNS区域并将其存储在小帅刚建立好的DNS应用程序目录分区TestDnsZ中，此时在选择上有区别了。如图20注意，由于此时DNS应用程序目录分区TestDnsZ只登记了这台计算机，所以只能在dc01上建立区域的时候有这个特殊的选项，在dc02、dc03上的DNS控制台上创建区域的时候都不会出现该选项。 图21是在dc01上建立好名为的DNS区域之后出现的一个特殊的“域”TestDnsZones及dc01上LDAP服务注册的SRV记录注意，由于此时DNS应用程序目录分区TestDnsZ只登记了这台计算机，所以只能在dc01上建立区域的时候有这个特殊的选项，在dc02、dc03上的DNS控制台上创建区域的时候都不会出现该选项。 图21是在dc01上建立好名为的DNS区域之后出现的一个特殊的“域”TestDnsZones及dc01上LDAP服务注册的SRV记录接下来小帅将 dc02、dc03登记到该目录分区，让dc01、dc02和dc03这三台DC兼DNS的计算机来宿主这个DNS应用程序目录分区TestDnsZ。要执行此过程，必须是 Active Directory 中 DnsAdmins组（默认域管理员不是这个组的成员，另外注意DnsAdmins是本地组） 或域管理员组的成员，或者被委派了适当的权限。如图22、图23下面是DNS控制台中和DNS应用程序目录分区TestDnsZ的msDS-NC-Replica-Locations属性的截图及DNS控制台中该应用程序目录分区的注册记录。如图24当然你也可以利用“dnscmd.exe servername /UnenlistDirectoryPartition FQDN”命令来删除某个服务器在某个应用程序分区的登记。 注意：因为DNS应用程序目录分区也是应用程序目录分区的一种，所以使用dnscmd命令是无法删除该应用程序目录分区的，只能使用ntdsutil命令来删除应用程序目录服务分区，下面的部分小帅会介绍利用ntdsutil命令对应用程序目录分区的操作。三、 自定义应用程序目录分区 应用程序目录分区不一定就是为了DNS这个应用程序使用，以上AD默认创建的ForestD、DomainDnsZ和小帅手工创建的TestDnsZ几个DNS应用程序目录分区是专为DNS这个应用程序设置的目录分区，当然我们也可以根据企业的相关需要来为可行的应用程序定义应用程序目录分区，并设置他们的复制范围。比如很多企业使用的TAPI就是一个很好的例子，TAPI的详细内容请参考：/librar . ming_interfaces.asp /technet . 1f6ae.mspx?mfr=true 在使用ntdsutil命令来管理应用程序目录分区的之前需要先理解一些概念 1) 应用程序分区的命名（在第一部分中我们已经解释了） 2) 应用程序目录分区复制 信息一致性检查器 (KCC) 自动生成和维护企业中所有应用程序目录分区的复制拓扑。当应用程序目录分区在多个站点拥有副本时，那些副本和域目录分区有着相同的站点间复制日程安排。 3) 安全描述符参考域 网络的每个容器和对象都有一组附加于其中的访问控制信息。此信息称为安全描述符，可控制用户、组和计算机所允许的访问类型。如果对象或容器未被创建它的应用程序或服务分配安全描述符，那么它将被分配架构中定义的该对象类的默认安全描述符。这种默认的安全描述符是不明确的，它向 Domain Admins 组的成员分配对对象的读取权限，但不指定域管理员属于哪个域。当在某个域命名分区中创建该对象时，此域命名分区就用来指定读取权限实际上分配给了哪个 Domain Admins 组。 在应用程序目录分区中创建对象时，默认安全描述符的定义是不同的，因为应用程序目录分区可以在属于不同域的不同域控制器上拥有副本。因为存在这种潜在的不确定性，所以在创建应用程序目录分区时会分配一个默认的安全描述符参考域。 默认的安全描述符参考域定义了当该应用程序目录分区中的对象需要为默认安全描述符定义域值时应使用什么域名。默认的安全描述符参考域是在创建时分配的。如果该应用程序目录分区是某个域目录分区的子项，那么在默认情况下，父域目录分区将变成安全描述符参考域。如果该应用程序目录分区是另一个应用程序目录分区的子对象，则父应用程序目录分区的安全描述符参考域将变成新的子应用程序目录分区的参考域。如果新的应用程序目录分区创建为新树的根，那么此林根域将用作默认的安全描述符参考域。 4) 应用程序分区和DC的升、降级 如果域控制器拥有某个应用程序目录分区的副本，则必须从该应用程序目录分区的副本集中删除此域控制器，或者删除该应用程序目录分区，然后才能降级此域控制器。 如果域控制器拥有某个应用程序目录分区的“最新”副本，则必须删除该应用程序目录分区，然后才能降级此域控制器。 理解以上的应该差不多了，其他的相关资源请参考Windows Server 2003帮助或 /technet . 949f2.mspx?mfr=true 5) 小帅先利用ntdsutil将在上面建立的TestDnsZ的应用程序目录分区的3个副本删除，然后将该应用程序目录分区删除，如图25，在此小帅使用的命令全部为缩写并且没有显示帮助。此时存储在该DNS应用程序目录分区TestDnsZ内的DNS区域中的数据也将被删除，从整个AD中消失，你也可以使用上面小帅介绍的各种方法来检验该DNS目录分区的存在。如图26小帅然后建立一个新的应用程序目录分区名为AppDS.（注意命名和默认参考域），并将dc01,dc03作为该应用程序目录分区的副本集。如图27因为在运行ntdsutil的时候connect的就是dc01，所以当创建该应用程序目录分区的时候dc01就已经是该目录分区的副本了，所以只添加dc03就可以了。 该应用程序分区当你在创建DNS区域并选择“复制作用域”的时候也是可见的，就跟图20选择的位置类似。 图28显示的是使用LDP查看dc01上存储的目录分区及查看AppDS.应用程序分区属性msDS-NC-Replica-Locations值的情况。到此其他操作应该非常简单了。请参考ntdsutil.exe帮助信息或Windows Server 2003 AD帮助或 /technet . 949f2.mspx?mfr=true 四、 从媒体安装域控制器的应用程序目录相关 2003SP1提供了一个功能就是从媒体来安装新的域控制器，如果想实现从媒体的无应答安装，并复制相应的应用程序目录分区需要提升林功能，并安装2003SP1。下面小帅将林提升功能（要求森林中的每个域都为2003模式才可以提升整个森林的模式），并将dc04利用媒体的安装形式将其提升为域的第三台DC，还要将我们在上面刚刚建立的应用程序目录分区AppDS.及默认的DNS应用程序目录分区之一ForestDnsZ复制到dc04，注意dc04上没有安装DNS服务（小帅省略所有操作步骤，只将应答文件及最终结果呈现）。如图29、图30注意：其中c:Ntdsretore为小帅将备份好的dc01的系统状态SystemState.bkf恢复到dc04上的“备用位置”生成的临时文件夹。 验证AppDS.应用程序分区如图31具体步骤请参考 /kb/311078/zh-cn 五、注意事项及相关资源 /def . appliesto#appliesto “Event ID 4515 is logged in the DNS Server log in Windows Server 2003”。理解完应用程序目录分区就知道为什么会出现4515的错误了。 http:/windowssdk.msdn.microsoft . a_dnstombstoned.asp 应用程序目录分区的限制 /librar . ctive_directory.asp 该链接从目录架构的方面描述了应用程序目录分区 /Wi . 43a403b4361033.mspx DNS与AD应用程序之间的关系（包扩GC） /kb/817470/zh-cn 在从 Windows 2000 升级到 Windows Server 2003 时，如何将 _msdcs 子域重新配置为全林性 DNS 应用程序目录分区 /technet . 81ff7.mspx?mfr=true Active Directory 的新功能概述六、总结 其实本文小帅很早就想写了，不过进度却一直拖拖拉拉，可能是由于不是每天都很快乐的原因吧，郁闷和烦恼就象家常便饭一样，快乐的时光越来越少，如果某一天出现了快乐的事儿，那小帅会觉得算很幸运捡了个便宜，不快乐和郁闷的时候就纯属是正常状态了。转念又一想谁又能每天都快乐呢？傻子也许可以。谁也不愿意永远做傻子，就像不能永远快乐一样深入理解全局编录服务器GC 版权声明：原创作品，如需转载，请与作者联系。否则将追究法律责任。概述： 在Win2003AD域环境中，除了FSMO操作主机角色外，全局编录服务器(GC)也是有着特殊含义的域控制器。通过GC，可以提高在活动目录中搜索对象的速度，可以加快用户登录验证等。 简单的说，GC是森林中所有对象的只读调整缓冲存储器( Read Only Cache),目录只用于搜索。GC服务器存储本域中所有对象的所有属性，同时会存储林中其它域中所有对象的部分属性。一般来说，属性是否存储在GC中，取决于该属性在搜索中使用的频率,由系统自动进行决定。但AD架构管理员也可以定义对象的哪些属性保存的GC中，同时决定该属性是否可以进行索引。 本文拟就与GC相关的内容一一阐述，希望能起抛砖引玉作用，与有兴趣的朋友一起更好的了解和熟悉全局编录服务器。 GC出现的原因 GC的作用 查看当前环境中GC服务器 提升DC为全局编录服务器 验证全局编录服务器的提升 验证全局编录服务器是否工作正常 删除全局编录服务器 使用AdsiEdit工具查看全局编录服务器中的数据一：GC出现的原因 在Win2003活动目录中有两种目录服务，分别是DNS以及LDAP，两个目录服务互为补充。DNS的目的比较简单，用于简单快速的定位域控制器，但定位到具体的域控制器后，对活动目录信息的更细致访问，如活动目录中关于用户，计算机，打印机等对象信息搜索，DNS就无能为力。此时就需要通过LDAP服务来访问。 如果用户知道某个对象处于哪个域，也知道对象的标识名，那么用LDAP搜索对象就非常容易。但如果用户只知道某个对象的某个属性，根本不知道对象所处的域，也不知道该对象的标识名，那么使用LDAP来搜索对象是一件非常困难的事，AD不得不对当前环境中每一个域的每个对象都搜索一遍。为了解决这个问题，活动目录提供了全局编录服务器(GC，到Global Catalog)。GC中包含了当前林中每个域中所有对象的副本，如果在一次LDAP搜索中，涉及到搜索中多个域的名称上下文时，AD会选择搜索GC服务器，从而实现加快搜索速度，减少网络通信量的目的。二：GC的作用 1：存储对象信息副本，提高搜索性能 全局编录服务器中除了保存本域中所有对象的所有属性外，还保存林中其它域所有对象的部分属性，这样就允许用户通过全局编录信息搜索林中所有域中对象的信息，而不用考虑数据存储的位置。通过GC执行林中搜索时可获得最大的速度并产生最小的网络通信量。 2：存储通用组成员身份信息，帮助用户构建访问令牌 全局组成员身份存储在每个域中，但通用组成员身份只存储在全局编录服务器中。 我们知道，用户在登陆过程中需要由登录的DC构建一个安全的访问令牌，而要构建成功一个安全的访问令牌由三方面信息组成：用户SID，组SID，权力。其中用户SID和用户权力可以由登录DC获得，但对于获取组SID信息时，需要确定该用户属不属于通用组，而通用组信息只保存在GC中。所以当GC故障，负责构建安全访问令牌的DC就无法联系GC来确认该用户组的SID，也就无法构建一个安全的访问令牌。 注：在Win2003中，可以通过通用组缓存功能解决GC不在线无法登录情况，具体操作本文略过。 3：提供用户UPN名称登录身份验证。 当执行身份验证的域控制器没有用户UPN帐号信息时，将由GC解析用户主机名称(UPN)进行身份验证，以完成登录过程 4：验证林中其他域对象的参考 当域控制器的某个对象的属性包含有另一个域某个对象的参考时，将由全局编录服务器来完成验证。三：查看当前环境中GC服务器 1：通过“Active Directory 站点和服务”查看 步骤： 点击“开始-设置-控制面板-管理工具-Active Directory站点和服务”: 选中具体的“NTDS Setting。选中NTDS Setting,右键选择“属性”在弹出的“NTDS Setting 属性”对话框中，有“全局编录”复选框,如果选中，表示是一台全局编录服务器， 如果没有选中，则表示当前的服务器不是全局编录服务器。 2：利用复制监视器Replmon查看 复制监视器Replication Monitor(ReplMon)是针对Windows Server的故障查找工具,不但是定位活动目录 复制故障强有利的工具，同时也可以使用该工具查看和检查操作主机角色状态。 详细Replmon工具使用方法本文不做过多说明，这里只列出如何使用Replmon工具GC角色。 步骤：选中当前DC，右键单击，选择“Show Global Catalog Servers in Enterprise” 在弹出窗口中，清楚列出当前林中所有的全局编录服务器 3：通过命令行方式查看全局编录服务器 在Supprot Tools和Resource Tools工具中，有多个命令行工具可以查看全局编录服务器，这里只列出两个最常见的命令行工具 使用dsquery命令查看当前域中的GC dsquery server -domain -isgc使用nltest命令查看当前域中的GC nltest /dsgetdc:四：提升DC为全局编录服务器 将一台域控制器提升为全局编录服务器操作很简单，方法见通过“Active Directory 站点和服务”管理单元查看全局编录服务器， 将“全局编录”复选框选中即可。 注意：设置完成后，并不代表当前的全局编录服务器已经提升完成，因为全局编录服务器中包含有多个域的所有对象，需要时间来进行全局编录数据库同步。五：验证全局编录服务器的提升 通过提升DC为全局编录服务器操作，需要时间同步全局编录服务器，同步完成后，全局编录服务器才开始真正运行。 下面介绍如何查看全局编录服务器是否已经开始工作。 1：使用LDP工具查看当前DC的IsGlobalCatalogReady属性 LDP(LDAP浏览器工具)是一个轻量目录访问协议 (LDAP) 客户端实用工具,可以用来查询和浏览 LDAP目录服务，详细用法本文不做具体介绍， 可以搜索相关的说明文档或后期的Blog文章介绍。这里只给出简单的使用说明 步骤： 与LDAP目录绑定 “运行”，输入“LDP”，打开LDP窗口后，选择“Connection|Bind,打开Bind对话框，输入身份凭证。单击”OK“按钮，LDP连接到”Superlan.Com域控制器，显示检测结果，从下图可以看出“IsGlobalCatalogReady属性为True 2：查看DNS管理工具查看GC记录是否已更新到DNS中。 从下图可以看出当前哪个域控制器是GC，且使用的端口是多少，默认的GC使用端口是3268。六：验证全局编录服务器是否工作正常 全局编录服务器正确提升后，可以通过查看注册表信息和端口状态来查看 全局编录服务器是否工作正常。 1：查看注册表信息(HKLMSystemCurrentControlSetServicesNTDSParameters) 健值：Global Catalog Promotion Complete，值为1，表示GC工作正常 2：全局服务编录器默认使用3268/3269端口，通过查看端口是否处于监听状态可以判断GC是否工作正常 使用netstat -an命令查看当前正在运行的端口,可以看到3268/3269端口已经处于正常监听状态七：删除全局编录服务器 删除全局编录服务器方法请参见”四：提升全局编录服务器“，将”全局编录“复选框取消即可，此处略过。八：使用AdsiEdit工具查看全局编录服务器中的数据 因篇辐较长，拟定以独立的文章介绍，见后续文章!/36993/101261使用AdsiEdit工具查看GC数据 2008-09-23 12:02:51标签：GC 活动目录 架构 AdsiEdit 全局编录 推送到技术圈 版权声明：原创作品，如需转载，请与作者联系。否则将追究法律责任。阅读前请参考：深入理解全局编录服务器(/36993/101190)全局编录服务器并不是一个独立的实体，域控制器也没有单独为GC准备一个独立的DIT文件，GC服务器与当前的域公用同一个NTDS.DIT文件，两者的区别只是使用的端口号不同，前者使用3268端口，后者使用389端口。理解了这一点，也就理解了如何来查看GC数据。 AdsiEdit工具是一个超级强大的AD查看与编辑工具，我们可以使用这个工具做一些其它工具无法实现的功能。 比如本文准备阐述的查看全局编录服务器中的数据等。为了更好的说明如何使用AdsiEdit工具查看GC数据，先介绍一下当前的演示环境： 两个域，父域为Superlan.Com,子域为Sub.Superlan.Com,其中Superlan.Com域中有一台DC(PriDomDemo.Superlan.Com), 同时担任GC角色，子域中有一台DC(SubDomDemo.Sub.Superlan.Com),非GC。 域结构如下：因PriDomDemo.Superlan.Com为父域DC，同时又为GC，所以在PriDomDemo AD数据库中，应该包含有子域Sub.Superlan.Com数据。 那么如何在PriDomDemo中查看子域数据，同时验证GC相关的概念，比如 GC是森林中所有对象的只读调整缓冲存储器 包含有子域所有对象的部分属性。 自定义对象的哪些属性保存的GC中，同时决定该属性是否可以进行索引等等。 本文利用AdsiEdit工具，分别连接GC以及Sub.Superlan.Com域，通过比较标准的Sub域数据与保存在GC中Sub域数据，就上述问题做深入阐述!具体操作如下一：使用AdsiEdit查看AD数据 1：连接到GC服务器 在AdsiEdit中,连接到GC服务器很简单，唯一需要注意的是，需要在“高级”中指定使用Global Catalog协议 具体如下： 在“运行”窗口输入“AdsiEdit.msc,打开AdsiEdit编辑器。 选中AdsiEdit,右键选择”Connect to“ 在Connection Setting弹出框，输入相应的名称上下文输入名称上下文后，打开Advanced 按钮，选择”Global Catalog协议选择两次