上周五写了一篇名为《深度剖析修改AD用户密码的数据同步机制》的文章，其中发现在修改了AD用户密码以后，5分钟之内，新旧密码同时可用的状况。
    今天微软GTSC的工程师换了两拨人做技术支持，在不断的尝试过程当中，找到了答案。
    在他们不断的给出解决办法的时候，其中提供了一篇KB号为906305的文章。链接如下：
    http://support.microsoft.com/kb/906305/en-us
    根据KB中大致描述了问题的状况和原因，虽然这篇KB是适用于WinSrv03的，但是现在证明，在WinSrv08上同样适用。
    详细情况，大家可以看KB文章（建议看英文原版，中文自动翻译简直就不是人话，机器就是机器），下面谈谈我个人的想法。
    同上篇文章后面jrfly331兄所提到的一样。这个5分钟就是为了防止AD同步延时问题，防止DC数量比较多时，用户登录所在的站点内还没有成功的更新到密码的修改的情况。。这样，即使新密码没有生效，旧密码依然可用。其实上篇文章里的那个截图也显示出来了，我在一台海外的DC上修改密码，花了40秒钟才复制到中国的DC。所以，有些网络效率不高的情况下，是会发生密码同步需要一定时间的情况的。鉴于这样的考虑，我们的旧密码，就有启用了一种生存时间的概念，而这个生存时间，就是从密码修改一刻算起，5分钟整。而在WinSrv03中，这个时间为60分钟。
    那么这个问题的关键在哪里呢？？就在NTLM。。
    NTLM是什么？NTLM是NT LAN Manager的缩写，它是 Windows NT 早期版本的标准安全协议之一，也是Windows Server系统三大安全验证协议之一，至今保留。它主要用于多种网络身份验证，包括AD验证，Exchange的POP3,IMAP,SMTP等等。此外，NTLM 还为没有加入到域中的计算机提供的身份验证协议，这也是为什么我们是用WS-*去调它的原因，因为第三方很多应用，跟AD是没有关系的。具体的身份验证机制和流程，如果大家有兴趣的话，可以google一下，或者在微软的知识库里找到，这里我就不多说。
    但需要提到的就一点，也是与这次碰到的问题紧密相关的一点。就是，在NTLM的验证过程中，一旦发生密码更改，它会将用户的dspswvalidate属性修改为ture，使得在一个生存时间内，旧密码依然可以通过NTLM的验证。而这个生存时间的值，在WinSrv03中，是60分钟。在WinSrv08中则变为5分钟，虽然5分钟这个，我现在还没有找到任何官方的明确说法，但至少从我的测试当中，能够确认这一点。
    值得注意的是，这个缓存，在LDAP验证方式中同样存在，但却不存在于kerberos验证方式中。换句话说，也就是我们最常见的使用Ctrl-Alt-Del的交互式方式登录到桌面系统是不会存在旧密码可用的情况的。今天测了一下，的确如此。
    这里，我也需要做一个检讨。我们在发现这个问题的时候，确实是使用的WS-*的方式进行登录的。因为我们用WS-*做了一个SSO的接口，用于其它的第三方系统能够统一使用AD作为唯一的身份验证机制。另外，我做测试的时候也为了方便，直接在WS-*上面加了一个查询。所以我就我没有使用交互式登陆来进行测试，因为那样还需要找个客户端，然后每次还得登进登出的，很麻烦。这也导致了在之前测试的时候没有能够及时发现两种方式验证在效果上存在的区别。
    不过现在，问题的原因总算是找到了，而且解决问题的办法也就在KB当中。
    值得我们思考的是，任何问题都不是表象的，如果希望避免问题再次出现，甚至希望能够控制问题的发生，我们就应该深究。
    当然，这次如果不是被逼，我也懒得去研究这些。人老了，钻不动了。。哎。。。