上周五寫了一篇名為《深度剖析修改ad使用者密碼的資料同步機制》的文章，其中發現在修改了ad使用者密碼以後，5分鐘之內，新舊密碼同時可用的狀況。
今天微軟gtsc的工程師換了兩撥人做技術支援，在不斷的嘗試過程當中，找到了答案。
在他們不斷的給出解決辦法的時候，其中提供了一篇kb號為906305的文章。鏈結如下：
根據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當中。
值得我們思考的是，任何問題都不是表象的，如果希望避免問題再次出現，甚至希望能夠控制問題的發生，我們就應該深究。
當然，這次如果不是被逼，我也懶得去研究這些。人老了，鑽不動了。。哎。。。
批量建立AD賬戶
第一步，寫入記事本 dn，objectclass，samaccountname，userprincipalname，displayname，useraccountcontrol cn 市經，ou 市場部，dc zyliday，dc com user，shijing，shiing abc.com，市經...
Powershell批量建立AD賬戶
它是乙個單獨的命令列，即匯入乙個 csv 檔案並使用其中的資訊建立數十甚至數百個新的 active directory 使用者 import csv c provision1.csv foreach object 它確實是個很長的命令，但功能卻強大得令人驚訝。首先是 import csv 本機外殼 ...
MOSS同步AD賬戶 三
假如您的公司新入職了員工，部門經理或管理員向 ad中加入了新員工的資訊，那麼怎麼把新員工的賬戶同步到 moss 中呢？方法有 2種，第一種方法是直接用 開發實現，這種方法對於了解 moss sdk 的程式設計師來說，實現起來比較容易。第二種方法便是利用 moss 自帶的功能，直接同步 ad賬戶資訊到...