偶爾都會遇到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.