如何监视活动目录复制和解决相关问题

在Windows的活动目录服务中，域控制器的活动目录数据库里包含着所有目录对象，比如用户帐号，机器帐号和其它各种类型的对象。而“目录复制”组件则负责把发生在该域控制器上的目录对象更改复制到其它域控制器上去，以保证所有域控制器的数据库内容相对一致。如果域控制之间的目录复制发生了问题，则会引起非常严重的问题。比如你在北京的域控制器上创建了一个帐号，如果北京和广州的域控制器复制发生问题，导致广州的域控制器无法得到你刚才创建的用户帐号，那么你在广州的客户就可能无法使用该帐号进行相关的操作了。可想而知，活动目录的复制在企业的应用中是何等的重要。

由于活动目录的复制服务是一项非常高端的应用，它的正常执行非常依赖于相对底层的服务和组件的执行状态。让我们来回顾一下整个复制过程：当一台域控制器上某个目录对象发生了的变更后，该域控制器对这个新的变改赋予一个值，我们称之为USN（unique sequence number）。然后，该域控制器检测哪些域控制器是其复制伙伴，并通过DNS服务器来得到他们的IP地址。随后，该服务器和他的复制伙伴进行基于kerberos协议的双向验证。通过验证后，该两个域控制器建立了RPC（Remote Procedure Call）连接。基于RPC连接，，目标域控制器向源域控制器发出获取最新的更新的请求，当目标服务器得到来自源域控制器的变更后，通过ESENT（Extensible Storage Engine）的引擎把这些内容写到AD的数据库里，复制到此结束。从这一段过程中可以看出，目录复制的成功执行与复制的拓扑结构，网络名字解析（DNS），安全（Kerberos），RPC以及AD的数据库有着紧密的联系。由于目录复制问题的差错覆盖面非常广泛，我们这里就其相依赖的组件这一部分做一下讨论，枚举一些方法来检测这些内容是否正确执行。

目录复制的拓扑结构和复制状态：

通常，你可以使用“repadmin.exe”这个工具可以用来检测该服务器从哪些源域控制器复制AD的内容，同时检测该项复制是否正确。比如：
C:>repadmin /showreps

Default-First-Site-NameDC01
DSA Options : (none)
objectGuid : a0d6dbaf-4297-47b3-92b8-2d604d290bb5
invocationID: e805158b-f7e1-4d23-a797-5121262c0fa2

==== INBOUND NEIGHBORS ======================================
CN=Schema,CN=Configuration,DC=domain,DC=com
Default-First-Site-NameDC02 via RPC
objectGuid: 035046f0-5de5-4adb-b1fc-259614a8de64
Last attempt @ 2007-01-01 05:58.19 failed, result 8453:
Replication access was denied.
Last success @ 2007-01-01 04:12.01. 14 consecutive failure(s).
CN=Configuration,DC=Domain,DC=com
Default-First-Site-NameDC02 via RPC
objectGuid: 035046f0-5de5-4adb-b1fc-259614a8de64
Last attempt @ 2007-01-01 05:58.19 failed, result 8453:
Replication access was denied.
Last success @ 2007-01-01 12:12.01. 14 consecutive failure(s).
DC=RESKIT,DC=com
Default-First-Site-NameDC02 via RPC
objectGuid: 035046f0-5de5-4adb-b1fc-259614a8de64
Last attempt @ 2007-01-01 05:58.19 failed, result 8453:
Replication access was denied.
Last success @ 2007-01-01 12:12.01. 14 consecutive failure(s).

以上列表表明DC01尝试从DC02复制AD内容，但是由于“Access is denied”的错误，复制失败在3个区域全部失败。你从该列表里得到错误的原因是“Access is denied”，那么你的下一步方向就是从安全方面入手查看为什么会有“Access Denied”错误。同时你还可以从刚才的报告中得到附加的信息，比如服务器的GUID。DC02 的ID是035046f0-5de5-4adb-b1fc-259614a8de64。 这个ID非常重要，它是DC01用来寻找DC02IP地址的唯一依据。

网络名字解析：

由于复制的机制是建立在TCP/IP通讯协议，那么域控制器是使用DNS来完成寻找对方的任务的。通常，你可以使用nslookup.exe来验证当前DNS服务器是否能提供正确的名字解析。在复制中，域服务器需要提供复制伙伴的GUID。比如说，如果对方的GUID是035046f0-5de5-4adb-b1fc-259614a8de64，那么域控制器就需要向DNS查询：035046f0-5de5-4adb-b1fc-259614a8de64._msdcs.domain.com 所对应的IP地址。你可以通过下列步骤来检测DNS是否工作正常：
第一步：使用 ipconfig 把当前在DNS缓存里的内容枚举出来
C:>ipconfig /displaydns
Windows IP Configuration
1.0.0.127.in-addr.arpa
----------------------------------------
Record Name . . . . . : 1.0.0.127.in-addr.arpa.
Record Type . . . . . : 12
Time To Live . . . . : 0
Data Length . . . . . : 4 Section . . . . . . . :
Answer PTR Record . . . . . : localhost

RESKIT-DC2
----------------------------------------
Record Name . . . . . : RESKIT-DC2.reskit.com
Record Type . . . . . : 1
Time To Live . . . . : 1506
Data Length . . . . . : 4
Section . . . . . . . :
Answer A (Host) Record . . . : 54.34.192.30

第二步：尝试用nslookup来解析主机名称。Nslookup直接查询DNS服务器的内容，不会使用自己DNS缓存里的内容，这样，你就可以比较nslookup和DNS缓存的结果来验证内容是否一致。
C:>nslookup reskit-dc2.reskit.com

Server: ns.reskit.com
Address: 61.53.4.32

Name: reskit-dc2.reskit.com
Address: 54.34.192.30

第三步：如果上述两步都无法得到正确结果，那么问题可能会是

1． 服务器名字不对
    2． 域后缀名不对
    3． DNS服务失效
    4． 多台DNS服务器的内容不一致
    5． 网络原因导致无法和DNS服务器通讯

第四步：检测刚才dns缓存或nslookup里得到IP是否为复制伙伴的IP

第五步：如果dns缓存里的ip有误，使用ipconfig把缓存清空
C:>ipconfig /flushdns
Windows IP Configuration
Successfully flushed the DNS Resolver Cache.

第六步：尝试用nslookup来解析由GUID组成的复制伙伴的DNS名字。这个名字的结构是._msdcs.
C:>NSLOOKUP 035046f0-5de5-4adb-b1fc-259614a8de64._msdcs.reskit.com
Server: ns.reskit.com
Address: 65.53.4.32
Name: RESKIT-DC2.reskit.com
Address: 54.34.192.30
Aliases: 035046f0-5de5-4adb-b1fc-259614a8de64._msdcs.reskit.com

第七步：如果nslookup能够成功把以上名字转换成IP地址，那么这就证明DNS的服务工作是正常的，如果不能得到正确IP，则有可能是客户端联系了一台错误的DNS服务器，或者该服务器数据库没有得到及时更新。

RPC连接：

在RPC通讯中，Endpoint Mapper 是一个用来存储RPC服务信息的数据库。RPC服务侦听TCP135端口来获知哪个客户端尝试调用相关的RPC请求。当得到相关的客户请求，RPC服务则动态分配一个端口供客户端的服务器通讯使用。由此可见在检测RPC连接时我们需要检测一下一些内容：

1. 检测域控制器的TCP 135端口没有被封闭。
    2. 检测目录服务在侦听该端口。
    3. 检测被分配的动态端口没有被封闭。

为了进行上述检测，你可以使用portqry.exe 和rpcdump.exe两个工具。比如下面这个案例是用来检测TCP端口135是否打开，并且DRS RPC endpoint的通讯是否正常：

1. 用rpcdump来查询DRS endpoint 是否已经在RPC的endpoint mapper 数据库里进行了注册

C:>Rpcdump /s /v /i > endpoint.txt

2. 打开endpoint.txt 文件，查看ncacn_ip_tcp 一段里是否有e3514235-4b06-11d1-ab04-00c04fc2dcd2 的UUID。比如：
ProtSeq:ncacn_ip_tcp
Endpoint:1025
NetOpt:
Annotation:MS NT Directory DRS Interface
IsListening:YES
StringBinding:ncacn_ip_tcp:65.53.63.15[1025]
UUID:e3514235-4b06-11d1-ab04-00c04fc2dcd2
ComTimeOutValue:RPC_C_BINDING_DEFAULT_TIMEOUT
VersMajor 4 VersMinor 0

3. 如果IsListening栏里显示的是“YES”，则TCP 135端口和DRS接口的通讯是畅通无阻的。从上面的报告，你还可以知道DRS接口使用1025动态端口。

4. 如果IsListening栏里显示“NO”，或者报告第一行就显示查寻错误，或者没有任何注册的endpoint，那么则问题可能和端口被封有关，你需要和您的网络供应商联系察看一下哪个网络设备阻断了该端口。比如：
Querying Endpoint Mapper Database...
137 registered endpoints found.

安全：

活动目录复制使用Kerberos来进行双方的身份验证，同时服务器上的安全策略配置也直接影响目录复制的正常进行。在您进行安全方面的检测时，你需要察看是否双方的服务器时间相一致，否则kerberos认证会返回相关错误。并且，您需要检测服务器是否注册相应的SPN 名字 （e3514235-4b06-11d1-ab04-00c04fc2dcd2/ntdsa_objectGUID/domainname），保证双方的计算机密码在双方的数据库里是同步的。这里枚举了一些你在安全方面必须要进行检查的内容和步骤：

检测“Access this computer from network user right”

在MPS报告里，找到　＜computername＞_userrights.txt 文件，确认everyone，authenticated users，以及enterprise domain controllers 组拥有该权限。

检测域控制器时间是否同步：

你可以使用“net time PDC /set /y”来同步该台域控制器和PDC的时间。

检测域控制器userAccountControl属性以及Kerberos信任：
    1． 确认双方的KDC服务都是在启动的状态。
    2． 确认该计算机帐号的“Trust computer for delegation”的选项已经激活。
    3． 如果用adsiedit或ldp工具察看该计算机的userAccountControl属性，它的值为532480 （0x82000）
    4． 如果两台域控制器在不同的域里，那么使用“Active Directory Domains and Trusts 来验证两个域的信任连接是否正常。

更改KDC相关的设置：

当目录复制服务已经由于安全检测没有通过而中断，你需要更改KDC的相关配置来使两台机器的验证得以通过。

1． 如果计算机在不同的域，你在源域控制器上添加如下注册表键值：
HKEY_LOCAL_MACHINESystemCurrentControlSetServicesNTDSParameters
Value name: Replicator Allow SPN Fallback
Value type: REG_DWORD
Value data: 1

2. 在源控制器上运行：

C:>repadmin /add cn=configuration,dc=,dc=com

3. 当你完成上述指令后，删除“Replicator Allow SPN FallBack”键值。

重新设置计算机密码和更新kerberos的缓存内容：

在得到“Access is denied”错误时，您可能需要重设计算机密码：
    1． 停止当前KDC服务。“C:>net stop kdc”
    2． 清除用户的kerberos缓存内容。“c:>Klist purgeall”
    3． 通过计划任务服务启动一个由LocalSystem帐号启动的CMD窗口
    C:>at system_time /interactive cmd.exe
    4. 当系统弹出CMD窗口后，在该窗口里运行“c:>klist purgeall”.这样系统的kerberos缓存内容也被清空了。
    5. 在CMD窗口里执行以下指令来重设计算机密码：
    C:>netdom resetpwd /server:PDC /userD:domainadmin_account /PasswordD:*
    您需要在按回车符后提供该帐号的密码。当您收到成功的消息后，尝试通过访问PDC的FQDN名字来使自己的更新kerberos 票证。
    C:>net use PDC.domain.comIPC$
    6. 用AD Site and Service 来重新检测复制的拓扑逻辑，或者用命令行方式检测KCC。 “C:>repadmin /KCC”
    7. 随后用repadmin /syncall /d /e 来强制进行复制。

检测SPN的注册情况：

1． 首先，运行“SETSPN DC1”，您会得到如下类似输出：
Registered ServicePrincipalNames for CN=dc1,OU=Domain
Controllers,DC=mydomain,DC=com:
HOST/dc1
HOST/dc1.mydomain.com
HOST/dc1.mydomain.com/mydomain.com
GC/dc1.mydomain.com/mydomain.com
LDAP/3cb25b0f-3809-48fb-8571-59f4a2253846._msdcs.mydomain.com
LDAP/dc1.mydomain.com/mydomain
LDAP/dc1
LDAP/dc1.mydomain.com
LDAP/dc1.mydomain.com/mydomain.com
HOST/dc1.mydomain.com/mydomain
E3514235-4B06-11D1-AB04-00C04FC2DCD2/3cb25b0f-3809-48fb-8571-59f4a2253846/mydomain.com

最后一项名字是目录复制注册所用的SPN名字，如果你没有找的该名字，则目录复制无法正常进行，你必须为该服务器重新注册该名字“setspn -a E3514235-4B06-11D1-AB04-00C04FC2DCD2/3cb25b0f-3809-48fb-8571-59f4a2253846/mydomain.com”

需要注意的是“E3514235-4B06-11D1-AB04-00C04FC2DCD2”是一个固定值，你不需要更改他。而后面一个值“3cb25b0f-3809-48fb-8571-59f4a2253846”是该服务器的GUID，你可以通过DNS的_msdcs 区域得到该服务器的值。

2． 用如下命令来检测该域控制器是否拥有两个或两个以上相同的SPN。理论上来讲，一个域控制器只能有一个对应的DRS SPN。

“LDIFDE –f output.txt –d dc=domain,dc=com –r “(&(objectclass=user)(serviceprincipalname= E3514235-4B06-11D1-AB04-00C04FC2DCD2/3cb25b0f-3809-48fb-8571-59f4a2253846/mydomain.com))” –l “dn,ServicePrincipalName,ObjectClass,saMAccountName””

检测复制区域的权限：

域控制器必须对需要复制的区域有“复制”的权限。如果该域控制器有3个复制区域，domain，configuration和schema。那么必须检测域控制器的机器帐号有对该3个区域的复制权限。

i. 运行adsiedit

ii. 右键点击每一个区域的根结点，选择“内容”

iii. 在安全页里的名字栏里点击“Enterprise Domain Controllers”，确认该组有 “manage replication topology”“Replication Directory Changes”“Replication Synchronization”权限，同时必须确认该计算机帐号在“Enterprise domain controller”组里。

安全策略检测：

使用“secedit /export /mergedpolicy /cfg sec.txt”导出双方服务器的安全策略配置，检测双方的SMB协议配置是否恰当，这包括如下内容：
Digitally Sign Client Communication (Always).
Digitally Sign Client Communication (When Possible).
Digitally Sign Server Communication (Always).
Digitally Sign Server Communication (When Possible).
LAN Manager Authentication Level.
Crash on Audit Fail.

AD数据库：

常见的导致目录复制失败的数据库方面原因有三个：
    1． 数据库的数据损坏
    2． 磁盘空间不够，导致数据无法更新到数据库日志文件里。
    3． 防病毒软件锁住了数据库日志文件，导致AD无法正常打开日志文件。

通常如果是数据库发生问题，你能在目录事件日志里收到相关的错误提示。这样您需要把服务器重新启动至目录服务恢复模式，然后用ntdsutil.exe来修复损坏的数据库。需要注意的是如果您使用的是WIndows2000域控制器，千万不要使用“repair”模式进行修复。因为如果使用了repair模式来进行修复的话，AD的数据库部分内容会丢失，如果丢失的内容涉及到schema,则后果不堪设想，很有可能还会导致其他域控制器的数据库损坏。

总结：

最后，我们来谈一下一种比较特殊的情况。很多时候当前域控制器无法及时得到发生在另一台服务器的对象变更。如果你在AD Site and Service强制进行复制，则该窗口会停止响应。如果您运行“repadmin /showreps”，你会发现在尝试复制相关区域的时候，该服务器得到如下返回信息“The replication job is preemptied”。

其实这个现象并不是一个错误，他只是提示当前的复制任务被其他任务给抢占了，需要延后执行。这个现象的原因主要是因为目录服务的引擎是一个单线程任务，每一个和目录复制相关的任务都有他固定的优先级。比如KCC检测拓扑逻辑的优先级较高，站台内部复制的任务比跨站台复制的优先级高，域内的复制比全局编录区域的复制优先级高，同步复制比异步复制的优先级高。当有复制相关任务产生时，系统把该任务放入一个队列里，然后按照其优先级从高到低依次执行在该队列里的所有任务，如果系统在执行一个任务时有一个较高优先级的任务进入队列里，则系统中断当前任务，而去执行刚进入队列的高优先级任务。对于这个被中断的任务，系统提示“The replication job is preemptied”。所以遇到这种情况，您不必着急，只要等待一会儿，问题就自然而然的消失了。

最后，你可以参考“Troubleshooting Active Directory Replication Problems”文档，该文档里列举了常见的问题和相应的解决放案，既实用又便捷，非常值得参考。

http://www.microsoft.com/technet/prodtechnol/windows2000serv/technologies/-

activedirectory/ maintain/opsguide/part1/adogd12.mspx

参考信息：

RPC相关知识：http://msdn2.microsoft.com/en-us/library/aa374172.aspx