偶爾都會遇到ad帳號一直被鎖的問題，就要去查明原因，下面就列出清查的方式。
事情準備 : dc主機上相關log功能一定要開。
1. 在gpo->domain controllers policy裡，要啟用下列三個稽核功能，這樣在事件檢視器裡的安全性事件裡，才能找到登入失敗的相關訊息。
2. 在gpo->domain controllers policy裡，NTLM的稽核也要開啟，這樣在事件檢視器裡的NTLM裡面，才能找到更準確的登入失敗訊息。
3. 要設定帳號鎖定的log產生時，發信通知相關人員，這樣才會知道是否有某帳號一直被鎖定的異狀發生。
清查流程 : 當發現某帳號一直被鎖定時
1. 先查安全性事件，找4625，4771，4776，如果能在這裡面找到來源的ip，那就趕快找到該電腦做處理。
2. 如果在安全性事件裡的log，找不到來源電腦，就要去NTLM的log裡，那邊也會顯示來源電腦。
最近遇到比較特別的狀況是a網域的帳號被鎖定，但從NTLM的log查到的安全通道名稱，是另一個信任網域b的dc主機，但上面顯示的工作站名稱，在b網域裡都查不到，而且會變來變去。
這時後就再去b網域的dc主機上，查詢NTLM log。結果log裡安全通道名稱，是顯示一台網域內的電腦。
後來發現是這台電腦有開放對外服務，有一些來自外部的異常連線，關閉服務後，帳號被鎖定的問題就解除了。
We occasionally encounter issues where an AD account keeps getting locked, and we need to investigate the cause. Below are the steps for troubleshooting.
Preparation:
Make sure the relevant logging features are enabled on the domain controller (DC).
-
In GPO -> Domain Controllers Policy, enable the following three audit policies. This will allow you to find failed login information under the Security events in Event Viewer.
-
Also in GPO -> Domain Controllers Policy, enable NTLM auditing. This helps you locate more accurate failed login details under the NTLM section in Event Viewer.
-
Configure alerts to notify relevant personnel via email when an account lockout log is generated. This ensures you're aware when an account is repeatedly getting locked.
Troubleshooting Process:
When you discover that a certain account keeps getting locked:
-
First, check the Security event logs for event IDs 4625, 4771, and 4776. If you can find the source IP there, locate the corresponding computer and take action.
-
If the source computer cannot be identified in the Security logs, check the NTLM logs. These also show the source machine involved in the failed login.
A recent unusual case:
An account from domain A was being locked, but the NTLM log showed that the secure channel name was a domain controller from trusted domain B. However, the workstation name shown could not be found in domain B and kept changing.
In this case, we checked the NTLM logs on the domain controller in domain B. The secure channel name in the logs pointed to a computer within the domain.
We later found that this computer was running a public-facing service, and there were some abnormal external connection attempts. After shutting down the service, the account lockout issue was resolved.
