深度剖析修改AD用户密码的数据同步机制 推荐

该问题已解决，详见《再度剖析AD账户新旧密码同时可用的问题》

现象：
意外发现一个很奇异的现象，用户在改掉自己AD账号的密码之后，新密码立即可用，但旧密码也同样可用。

测试：
为了了解这个问题的本质，我做了很多的测试，发现这个问题确实普遍存在，而且新旧密码都可以使用的时间，精确的控制在整整5分钟，一秒不多，一秒不少。
为尽可能排除其他因素的干扰，每次密码修改过程都在DC上进行。总共测试的DC有3台，DC01、DC02为同一站点，其中DC01为PDC仿真器，另外一台为外地站点的DC03。为提高效率，用WS-*写了一个查询界面，用于返回“OK”，或者“Incorrect”值，来表示密码正确或者错误。旁边开启Windows自带的始终，精确到秒进行观察。

先来说说站点内测试的情况。
测试账户原始密码为“11”，输入密码“11”返回结果“OK”，输入密码“22”返回结果“Incorrect”。
在DC02上修改密码为“22”，输入密码“22”返回结果“OK”，输入密码“11”同样返回结果“OK”。
不断尝试密码“11”，均返回“OK”结果。在5分钟之后，返回结果变为“Incorrect”。
在DC01上修改密码为“33”，输入密码“33”返回结果“OK”，输入密码“22”仍然返回结果“OK”。
与之前一样，不断尝试密码“22”，均返回“OK”结果。5分钟之后，返回结果变为“Incorrect”。
值得注意的是，如果同时在DC01、DC02上修改掉密码，那么旧密码会立刻失效。

站点间的情况大体相当，我连接本地AD站点进行查询，DC随机，修改密码操作在外地的DC03上进行。
为更清楚的说明问题，下图是ADSI信息的截图，从左到右分别是DC01、DC02、DC03三台的ADSI属性选项。



测试结果，和站点内进行测试基本一致，但有两点不同。
第一点，在DC03上进行密码修改以后，大约要30-40秒左右，新密码才能返回“OK”结果，这期间旧密码是可用的。从上图可以看出，在DC03修改的密码，同步到DC01时，用去了40秒时间，然后10秒之后，被同步到了DC02。我感觉我当时的WS-*是连到DC02进行的查询，因为我当时看到开始返回“OK”值的时间是26分27秒。
第二点，旧密码仍然可用的时间还是5分钟整，不过这次更能发现问题，因为从时间计算上表明，这个5分钟的时间，不是从密码被同步到那个与客户端连接到的DC02开始算起。而是从修改密码的DC03的25分36秒开始算起。整整5分钟，一秒不多，一秒不少。这一点，在站点内测试时，是没有表现出来的。因为两台DC处于同一网络，带宽很高，网络效率很高。所以在我修改用户密码是，两台DC的ADSI所显示出来的时间是相同的。

深度分析
经过测试，我们可以得知，虽然AD密码修改会立即触发数据同步。但是由于网络问题，会造成一定延时。（虽然是废话，但至少还不是屁话）
并且经过很多次的测试，我们可以分析出这样一条有关密码修改后的AD同步数据流向。
首先，用户密码发生修改以后，无论是直接在DC上操作，还是通过客户端进行。修改的密码，收到密码修改的DC会立即触发更新，但并不是与所有的DC，而只是域内的PDC仿真器。
然后，用户登陆时会使用新密码，如果该请求提交到的那个DC，即不是PDC仿真器也不是提交密码修改的那台DC的情况下，这台DC肯定没有得到最新的修改后的密码，所以它会发现该用户提交的密码不正确。
但此刻该DC并没有立刻拒绝用户的验证请求，而是去请示AD中的PDC仿真器。这时PDC仿真器已经收到了来自与另一DC所提交的经过修改的最新密码，PDC发现，用户此刻提交的请求，与最新的密码是一致的。于是通知之前那台DC放行。
而为什么会存在一个5分钟的时间，新旧密码同样可用的的情况。在进行站点内测试时，我曾想过应该是缓存。不过现在看来，应该不能算是缓存。准确来讲，应该是由发起密码更改的那台DC，为旧密码开启了一个最后生存时间，而这个时间，就是5分钟整。不过这点也只是我自己的猜测，因为生存时间的概念，与之前同时修改两台DC后，旧密码立刻失效的情况，相违背。

疑惑
分析到这里，对于密码修改后，各个DC之间是如何进行同步的机制，也算比较清晰的了解了。 但是这里还是有最后一个疑问。。
这个“5分钟”到底为什么，它从何而来，能否修改，能否去掉。。
为此已经向微软GTSC申请了技术支持。其实这也不是什么大问题，主要是讨个说法。

有人会问，说法很重要么？我说，当然重要。。因为最初意外发现这个问题的人，不是别人，正是我们IT的老大。。开大会的时候特地提出来，这要没有个说法，我可没法交代啊。。