# 如何分析 AD 帳號被鎖定的原因與解決問題的方法 在我公司裡有幾個帳號非常奇怪，經常會發生帳號被鎖定的情況，也因此我經常都要替這些被鎖定的帳號進行解鎖動作，我也好長一段時間都苦於不知如何查出該帳號被鎖定的原因，但最近因為上過 **Windows Server 2008 / R2 Active Directory 疑難雜症專班** 課程學到如何對帳號鎖定進行問題分析，如果之前沒遇到這問題，就算去上課可能也不會感受深刻吧，實在是難得的經驗。 首先，先分析有幾個可能會造成帳號鎖定的原因： **1\. 螢幕保護程式 ( 密碼保護 )** 這種狀況是上課時老師分享的一種情況，我個人是沒這樣遇過，但想想還真的有可能。 一般來說，進入螢幕保護模式後如果要讓電腦繼續執行只要滑動滑鼠就好了，如果按鍵盤的話我都會按 Ctrl 鍵，不過卻有人習慣按下 Enter 鍵，好笑的事還有人習慣一直連續按下 Enter 鍵 (可能認為這樣電腦會醒的比較快吧^^)，如果電腦正處於輸入密碼的視窗，那不就等於不輸入密碼連續登入嗎？當超過連續登入錯誤的「鎖定閥值」後就會導致帳號鎖定了！ ![alt](https://stwillblogassets.blob.core.windows.net/files/images/external/stwillblogassets.blob.core.windows.net/d176223c69aa74702e59-image_373.png) **2\. 使用 Windows Vista / Windows 7 試圖登入不支援 NTLMv2 驗證方法的電腦或 NAS** 這問題我之前有寫過一篇文章分享【[Windows Vista / Windows 7 無法登入 NAS 或 Samba 的解法](/post/2010/09/13/Windows-Vita-7-can-not-access-NAS-or-SAMBA.aspx)】講的就是這種狀況，這會讓你永遠無法登入成功，即便你打對密碼。 **3\. 網路密碼記憶在 Windows 裡，但該使用者的密碼已經變更了** 如果你習慣連接遠端電腦時將密碼記憶在電腦裡，尤其是登入 NAS 的時候或其他不是使用 Windows 驗證的情況，若當帳號密碼從 AD 裡變更了，當你下次登入 NAS 時就會發生登入失敗的狀況，不過由於密碼是記憶在 Windows 理的，當開完機後第一次連線時如果發生帳號驗證失敗， 則 Windows 會自動幫你重試登入 5 次，所以如果你的群組原則設定的「鎖定閥值」只有 5 次的話，那麼你只要連接一次帳號就等於登入失敗了 6 次，也就代表你的帳號就被鎖定了，連反悔的機會都沒有！ 所以基本上在設定 GPO 的「帳號鎖定原則」的「帳號鎖定閥值」時不建議小於 10 次，參考圖示如下： ![alt](https://stwillblogassets.blob.core.windows.net/files/images/external/stwillblogassets.blob.core.windows.net/2ec10b3b9c5e354914db-image_374.png) **4\. 電腦中毒 ( 或被植入木馬 )** 由於一些木馬會嘗試登入網路上的芳鄰，登入的過程會試圖嘗試各種密碼，如果遇到這種罕見的狀況也有可能導致帳號經常被鎖定！ \--- 除此之外，要分析那些「不知道為何帳號被鎖定」的狀況就真的有點困難了，以下就是分析的方法。 **分析帳號鎖定 (Account Lockout) 的原因有以下三個主要步驟** 一、啟用相關記錄檔 二、分析造成鎖定帳號的來源 IP 三、處理造成問題的電腦 以下就是這三個階段分別的說明： **一、 啟用相關記錄檔** 這裡有 2 個相關記錄必須被開啟： **1\. 在擁有 PDC 模擬器 (PDC Emulator) 角色的 DC 啟動 NETLOGON 紀錄** - 要進行 NETLOGON 紀錄時，請用以下指令啟動 NETLOGON 紀錄 - **nltest /dbflag:0x2080ffff** - 當偵錯完畢後，請用以下指令關閉 NETLOGON 紀錄 (避免 Log 過大塞爆硬碟) - **nltest /dbflag:0x0** - 啟動 NETLOGON 紀錄後，相關記錄會存放在以下路徑： - **C:\\Windows\\Debug\\netlogon.log** **2\. 在 Default *Domain Controller* Policy 啟動與帳號相關的稽核記錄 \[**非必要**\]** ![alt](https://stwillblogassets.blob.core.windows.net/files/images/external/stwillblogassets.blob.core.windows.net/f9e3689bb293a4338f5b-image_375.png)  設定三個與帳戶鎖定相關的稽核記錄： 1. 稽核帳戶登入事件 (Account Logon Events) -- 稽核「**失敗**」事件 2. 稽核帳戶管理 (Account Management) -- 稽核「**成功**」事件 3. 稽核登入事件 (Logon Events) -- 稽核「**失敗**」事件 ![alt](https://stwillblogassets.blob.core.windows.net/files/images/external/stwillblogassets.blob.core.windows.net/bc3a00e0e9da37b00b40-SNAGHTMLdbbb67a.png) **備註說明** - 由於帳號登入稽核事件非常多，也因此若僅啟用稽核失敗的紀錄很難查出帳號到底是在哪一次登入失敗時被鎖定的，也因此除了紀錄【稽核帳戶登入事件 – 失敗】外，還要特別紀錄【稽核帳戶管理 – 成功】事件，因為當 DC 鎖定該帳戶時就會產生一筆「帳號鎖定成功」的事件，你透過找出這個事件的記錄往回找尋相關的登入失敗事件即可查出發生問題的時間，這樣就能進一步分析其他記錄。 - 如果要查詢此原則是否已經套用，可使用 **RSoP.msc** 工具查看。如果沒有即時套用，可利用 **GPUpdate /force** 立即套用。 - 相關安全性稽核記錄會放在「安全性」事件中： ![alt](https://stwillblogassets.blob.core.windows.net/files/images/external/stwillblogassets.blob.core.windows.net/4083acbe26ef62928663-image_376.png) **二、分析造成鎖定帳號的來源 IP** 先利用 **net accounts** 命令檢查目前的群組原則是如何定義帳號鎖定的規則： ![alt](https://stwillblogassets.blob.core.windows.net/files/images/external/stwillblogassets.blob.core.windows.net/1e2eafbc7fdfd958ee8c-image_377.png) 接著我們可以去下載一個 [Account Lockout and Management Tools](https://web.archive.org/web/20110513111206/http://www.microsoft.com/downloads/en/details.aspx?FamilyId=7AF2E69C-91F3-4E63-8629-B999ADDE0B9E&displaylang=en) 工具組，此工具從 2003 年之後至今都沒有更新過了，不過依然可以在 Windows Server 2008 R2 上使用 (需要一些調整才能用)，此工具組中有好幾個工具程式，其中有一個 **nlparse.exe** 可以幫我們從 **C:\\Windows\\Debug\\netlogon.log** 記錄檔中篩選出必要的紀錄，以便於分析帳號鎖定的狀況。 不過若在 Windows Server 2008 上執行時會出現以下錯誤，說是缺了一個 **comdlg32.ocx** 檔案： ![alt](https://stwillblogassets.blob.core.windows.net/files/images/external/stwillblogassets.blob.core.windows.net/b6ec7f08f511d6173e35-image_378.png) 此檔案你只要從任何一台 Windows Client 主機都可以找的到，只要複製到 Windows Server 2008 相對應的目錄即可執行，該檔案的路徑如下： - 32 位元作業系統：C:\\Windows\\System32\\COMDLG32.OCX - 64 位元作業系統：C:\\Windows\\SysWOW64\\COMDLG32.OCX 另一個更簡單的作法是將 **netlogon.log** 複製到你的電腦，在你的電腦執行 **nlparse.exe** 即可。 執行時畫面如下，請點選 Open 按鈕選取 **netlogon.log** 開啟此記錄檔： ![alt](https://stwillblogassets.blob.core.windows.net/files/images/external/stwillblogassets.blob.core.windows.net/9050b04668073215fb7a-SNAGHTMLdf875a5.png) 由於我們要分析帳號被鎖定的原因，因此你可以僅篩選出以下兩種狀態碼的資料即可，分別是： - 0xC000006A  輸入密碼錯誤 (注意：若該帳號使用 Kerberos 驗證將查不到此記錄) - 0xC0000234  帳號已被鎖定 ![alt](https://stwillblogassets.blob.core.windows.net/files/images/external/stwillblogassets.blob.core.windows.net/2ad8d1e5d5d19e4ae061-SNAGHTMLdf977d7.png) 當按下 Extract 按鈕後，會在 **netlogon.log** 所在目錄另外產生兩個篩選過後的檔案： ![alt](https://stwillblogassets.blob.core.windows.net/files/images/external/stwillblogassets.blob.core.windows.net/e6882221e5fcdbed384c-image_379.png) 若我們用 Excel 開啟 **netlogon.log -Out.csv** 檔案，像我剛剛測試了一個帳號，連續登入失敗 10 次，即可發現有 11 筆資料被篩選出來，透過這種方式你可以非常清楚的知道這個帳號到底是何時被鎖定的、最後一次登入失敗是在何時、透過什麼管道與驗證方式登入、登入的來源電腦是哪壹台主機或IP，如此詳盡的資訊相信可以很快的找到讓帳號鎖定的兇手！ ![alt](https://stwillblogassets.blob.core.windows.net/files/images/external/stwillblogassets.blob.core.windows.net/3d631f80e37cd3409df4-image_380.png) 這裡的資料中，倒數第二個欄位可以特別解釋一下，由於記錄的內容是 **Y530A (via DC2)**，我們在本文章稍早有提到「**在擁有 PDC 模擬器 (PDC Emulator) 角色的 DC 啟動 NETLOGON 紀錄**」，意思就是在擁有 PDC 模擬器 (PDC Emulator) 角色的 DC 取得 **netlogon.log** 紀錄，不過在網域環境下可能不止壹台 DC，換句話說，這代表登入的主機 (Y530A) 是從 DC2 進行驗證的，而 DC2 代替 Y530A 往 PDC 模擬器 (PDC Emulator) 角色的 DC 進行密碼驗證的。 所以透過這筆記錄我們可以得知使用者一定是登入 DC2 網域主控站，不然就是該電腦是透過 DC2 網域主控站進行 NTLM 驗證，而且不管如何只要使用者是透過 NTLM 驗證方法進行登入，最後一定會轉到 PDC 模擬器 (PDC Emulator) 角色的 DC 進行密碼驗證，這也是我們為什麼一定要從「**在擁有 PDC 模擬器 (PDC Emulator) 角色的 DC 啟動 NETLOGON 紀錄**」的主要原因。 在 [Account Lockout and Management Tools](https://web.archive.org/web/20110513111206/http://www.microsoft.com/downloads/en/details.aspx?FamilyId=7AF2E69C-91F3-4E63-8629-B999ADDE0B9E&displaylang=en) 工具組中還有另一個 **eventcombMT.exe** 工具更為方便，他會自動搜尋所有 DC 的「安全性」事件記錄，並直接篩選出與帳號鎖定相關的事件出來，如果要使用這個工具的話，在先前提到的「**在 Default *Domain Controller* Policy 啟動與帳號相關的稽核記錄**」就必須進行設定，否則會抓不到必要的安全性事件紀錄。 剛開啟 後的畫面如下，若你的電腦本身就有登入網域，那麼預設 Domain 就會被填入： ![alt](https://stwillblogassets.blob.core.windows.net/files/images/external/stwillblogassets.blob.core.windows.net/da2baeb61f2bf27f2186-SNAGHTMLe2d745e.png) 由於 EventCombMT 是一個事件檢視器的搜尋工具，所以已經內建了一些搜尋的條件，其中帳戶鎖定就是一個內建的選項，請選擇 **Account Lockouts** 預設搜尋項目： ![alt](https://stwillblogassets.blob.core.windows.net/files/images/external/stwillblogassets.blob.core.windows.net/571b6892e6865cc09ee7-SNAGHTMLe2ed3cc.png) 選完後會自動幫你搜尋到要查詢的網域主控站有哪些，但重點在於他幫你預設好的 **Event IDs** 編號： ![alt](https://stwillblogassets.blob.core.windows.net/files/images/external/stwillblogassets.blob.core.windows.net/a02d2e217494b23a9af6-SNAGHTMLe313a4c.png) 不過這套工具實在太舊了，因為從 Windows Server 2008 之後所有 **Event IDs** 都與之前的版本不一樣了，因此如果你的 DC 是 Windows Server 2008 以後的版本就必須手動修改 **Event IDs** 的內容如下： - 4625 4740 4771 4772 4777 修改完成後按下 **Search** 按鈕即可開始搜尋所有 DC 上的事件記錄，並將搜尋到的結果儲存在 c:\\temp 預設輸出目錄下，如下圖示： ![alt](https://stwillblogassets.blob.core.windows.net/files/images/external/stwillblogassets.blob.core.windows.net/b5161cbf602c0b5b8599-SNAGHTMLe355357.png) 而剩下的就是分析這些篩選出來的資料並進一步分析，雖然輸出的檔案是 \*.txt 檔，不過你還是可以將副檔名改成 \*.csv 後用 Excel 開啟會比較方便篩選或檢視。 ![alt](https://stwillblogassets.blob.core.windows.net/files/images/external/stwillblogassets.blob.core.windows.net/ae2881b1ee53e8c1409a-image_381.png) **備註**：若要搜尋與帳號鎖定相關的事件記錄，以下是 Windows Server 2003 與 Windows Server 2008 的相關事件編號與相關描述。 | Event ID (Win2k3) | Event ID (Win2k8) | 描述 | | :---: | :---: | --- | | 644 | 4740 | 已自動鎖定使用者帳戶。 | | 529 | 4625 | 登入失敗。嘗試以不明的使用者名稱，或已知使用者名稱與錯誤密碼登入。 | | 675 | 4771 | 預先驗證失敗。此事件是在使用者鍵入不正確的密碼時，於金鑰發佈中心(KDC)上所產生。 | | 676 | 4772 | 驗證票證要求失敗。在 Windows XP 或 Windows Server 2003 系列中不會產生此事件。 | | 681 | 4777 | 登入失敗。嘗試網域帳號登入。在 Windows XP 或 Windows Server 2003 系列中不會產生此事件。 |   當然，如果你直接使用**事件檢視器**進行事件篩選一樣也是可以的，重點是你自己要知道有哪些 **Event IDs** 需要被篩選出來即可，如下圖示是 **Windows Server 2008 R2** 的事件檢視器篩選出多個特定 ID 的方式：  ![alt](https://stwillblogassets.blob.core.windows.net/files/images/external/stwillblogassets.blob.core.windows.net/b15b6d3ef830eb25a5c4-image_382.png) ![alt](https://stwillblogassets.blob.core.windows.net/files/images/external/stwillblogassets.blob.core.windows.net/f3635cd5feb2978f9003-image_383.png) **備註**：很不幸的，在寫這篇文章的同時剛好發現 **Windows Server 2008 繁體中文版** 無法使用逗號分隔多個 Event ID 進行篩選，而且我在 Windows Server 2008 英文版 並未發現此問題，之後的 R2 版本也沒有問題，不知道微軟何時才會推出 Hotfix 更新這個 Bug！？  **三、處理造成問題的電腦** 找出導致鎖定帳號的來源 IP 與電腦還算簡單，有了上述步驟應該就能輕易找到，不過要能找出到底是哪個 **程序** (Process) 就沒那麼容易了，而這一段就不是三言兩語可以講得清楚，也是最需要經驗支持… 首先，要先把造成問題的電腦離線（將網路線拔掉），以免帳號再次被鎖定，然後再進行帳號鎖定的相關分析，以下提供一些追蹤的方向與工具供各位參考： - 事件檢視器 - 檢視 **問題電腦** (導致帳號鎖定的電腦) 的「安全性」紀錄 - 分析本機的 netlogon.log 紀錄 - 啟用記錄  **nltest /dbflag:0x2080ffff** - 關閉紀錄  **nltest /dbflag:0x0** - 利用 acctinfo.dll 產生 alockout.log 並分析所有相關活動的 Process - 請參考[這篇文章](http://www.markwilson.co.uk/blog/2005/05/troubleshooting-windows-authentication.htm) - 利用 [Process Monitor](http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx) 分析嫌犯程序的各種行為 - File 存取記錄 - 機碼存取記錄 - 程序所在位置 - 利用 [Microsoft Network Monitor](https://web.archive.org/web/20110607213958/http://www.microsoft.com/downloads/en/details.aspx?FamilyID=983b941d-06cb-4658-b7f6-3088333d062f) 分析有問題的程序所發出的封包 - 檢視及驗證封包內容與連線埠號(Ports) **相關連結** - [Taiwan CSS Platform Team](http://blogs.technet.com/b/csstwplatform/) - [Account Lockout and Management Tools](https://web.archive.org/web/20110513111206/http://www.microsoft.com/downloads/en/details.aspx?FamilyId=7AF2E69C-91F3-4E63-8629-B999ADDE0B9E&displaylang=en) - [啟用 Net Logon 服務的偵錯記錄](http://support.microsoft.com/kb/109626/zh-tw) - [Using the checked Netlogon.dll to track account lockouts](https://web.archive.org/web/20140826151031/http://support.microsoft.com:80/kb/189541) - [How Domain Controllers Are Located in Windows](http://support.microsoft.com/kb/247811/en-us) - [Troubleshooting Windows authentication with the Microsoft account lockout and management tools](http://www.markwilson.co.uk/blog/2005/05/troubleshooting-windows-authentication.htm) - [Audit Policy Settings Under Local Policies\\Audit Policy](http://technet.microsoft.com/zh-tw/library/dd941595\(WS.10\).aspx) - [用於匿名存取的帳戶在 IIS 6.0 或 IIS 5.0 中可能意外地被鎖定](https://web.archive.org/web/20140117063552/http://support.microsoft.com:80/kb/922730) - [DS-Account lockout 問題處理概觀](http://blogs.technet.com/b/csstwplatform/archive/2009/03/16/ds-account-lockout.aspx) - [如何使用 EventcombMT 公用程式，在事件記錄檔中搜尋帳戶鎖定 (Account Lockout)](http://support.microsoft.com/kb/824209/zh-tw) - [啟用 Net Logon 服務的偵錯記錄](http://support.microsoft.com/kb/109626/zh-tw) - [如何使用 UserAccountControl 旗標操作使用者帳戶的內容](http://support.microsoft.com/kb/305144/zh-tw)