隨著微軟基礎架構的深入普及和各個企業對資訊化建設的重視，在微軟產品日益成熟的今天，域環境的應用也越來越廣泛。都會接觸到很多應用產品。無論是微軟系列的產品本身，或者是現在的很多第三方應用，我們都希望能基於員工的域賬號做一個統一的身份驗證，從而嚴格控制微軟平臺上各個應用的訪問許可權的安全。因此，域賬號的驗證機制就體現得格外重要。

     無論是在甲方公司日常的運維中，還是在乙方公司大大小小的專案中，會有企業的員工反映，自己唯一的域賬號時常被鎖，或者時常彈出對話方塊，請求使用者輸入密碼確認。這樣就會導致使用者無法開啟工作應用，工作軟體，甚至工作電腦。這樣勢必對員工的工作產生了極大的影響。員工很想知道為什麼自己在沒有輸錯密碼的同時，會有這些驗證失敗的提示。

本文主要講述是如何通過微軟工具和相關操作，查詢定位到驗證失敗的原因。

藉助工具：

LockoutStatus

接下來，我們就實際演示一遍如何查詢到AD賬號被鎖的原因

1. 首先將LockoutStatus放到域環境中的任一一臺DC上。

2. 使用管理員許可權將LockoutStatus開啟

3. 點選檔案選項File，選擇目標Select Target

4. 在目標使用者名稱列寫出需要查詢的域賬號（被鎖賬號），點選OK

5. 現在開始掃描該賬號在所有DC上的被鎖記錄

6. 掃描完成後，你可以找到很多賬號鎖定資訊，包括DC名，站點，賬號狀態，錯誤密碼計數器，和最後一次錯誤密碼時間。

7. 找尋到最後一條錯誤時間記錄，找到相應的DC名，遠端登入這臺域控。

8. 找到這個時間點的日誌

9. 用具有許可權的管理員賬號開啟日誌檔案

10. 選擇篩選當前日誌來減小日誌範圍。

11. 在關鍵詞欄中，勾選“稽核失敗”來作為篩選題目。

12. 篩選完成後，找到該時間點事件日誌。我們可以很清晰的看到“源工作站”一欄，意思是該錯誤密碼申請，來自這臺客戶端 CN1D8DKC。

到這裡，我們就已經知道了導致賬號被鎖的錯誤密碼的傳送源是來自這臺客戶機，但是這樣並沒有完。如果企業內部資產記錄和資訊保安做的比較好比較嚴格的企業，可能通過機器名已經能夠查到這臺客戶端屬於哪一個員工在使用，就可以拿著以上的證據去找他“擺聊齋”了。但是在很多企業，客戶機名是一個無法定位到員工頭上的隨機數字或者是編號，更或者是惡作劇或者是“栽贓嫁禍”這個時候怎麼辦呢？不要著急，我們採用Windows Power Shell來“找出凶手”，接下來我們繼續看。

13. 用管理員許可權開啟Power Shell,然後輸入一下命令來查詢是哪個賬戶在登入當前這臺終端機。

get-wmiobject -computername CN1D8DKC win32_computersystem | format-list username

系統最終查詢出的賬號是 cn001\cn1wh0u0

也就是說，目前這臺名為CN1D8DKC的客戶機是域使用者cn1wh0u0正在使用。

14. 用dsa.msc命令開啟AD與使用者管理控制檯。

15. 找到該使用者的詳細資訊。

到此，我們終於找到了“罪魁禍首”！當然了，密碼被鎖的具體原因還要通過我們查出來的這臺源客戶端電腦的本機日誌才能更準確的查出來，原因也有很多，從我們日常的經驗來看，大部分原因是因為A使用者曾經使用過B使用者的電腦，然後在訪問某內部網頁或者應用時記住了密碼。結果過段時間A使用者修改了自己的域賬號密碼，結果B使用者這臺電腦還是一直在傳送老的密碼，悲劇就發生了。對待這樣的事情，大家還是心平氣和的對待這個問題，也可能是各種各樣的原因造成的，相信真正使壞的人也確實是極少數。

--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

下面在給大家share幾個查詢使用者資訊的命令

1. net user /domain username

2. 查詢使用者帳號的位置

dsquery user –samid username

3. 將第2步查出的全路徑通過命令，查出賬號更詳細資訊

repadmin /showobjmeta 域控名 "CN=馬駿一,OU=Chengdu,DC=corp,DC=jbhydro,DC=com"

標籤：賬號鎖定   賬號解鎖   密碼錯誤   

原文：http://horse87.blog.51cto.com/2633686/1617607