现象:
    意外发现一个很奇异的现象,用户在改掉自己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的老大。。开大会的时候特地提出来,这要没有个说法,我可没法交代啊。。