如何查找Windows AD域中用户帐户被锁定的原因

Question

在最近发生 Outlook 事件后，我想知道如何最有效地解决以下问题：

假设一个相当典型的中小型 AD 基础设施：多个 DC、多个内部服务器和 Windows 客户端、多个使用 AD 和 LDAP 从 DMZ（SMTP 中继、VPN、Citrix 等）内进行用户身份验证的服务和几个内部所有依赖 AD 进行身份验证的服务（Exchange、SQL 服务器、文件和打印服务器、终端服务服务器）。您可以完全访问所有系统，但它们数量太多（包括客户端在内）而无法单独检查。

现在假设，由于某种未知原因，每隔几分钟就有一个（或多个）用户帐户因密码锁定策略而被锁定。

• 找到对此负责的服务/机器的最佳方法是什么？
• 假设基础结构是纯粹的标准 Windows，没有额外的管理工具，并且默认情况下几乎没有变化，有没有办法可以加速或改进查找此类锁定原因的过程？
• 可以做些什么来提高系统对这种帐户锁定 DOS 的弹性？禁用帐户锁定是一个显而易见的答案，但随后您会遇到用户可以轻松利用密码的问题，即使强制执行复杂性也是如此。

Answer 1

添加我在给出的答案中没有看到的内容。

找到对此负责的服务/机器的最佳方法是什么？

You can't just look at the Security log on the PDCe, because, while the PDCe does have the most up-to-date information regarding account lockouts for the entire domain, it does not have the information about from which client (IP or hostname) the failed logon attempts came from, assuming that the failed logon attempts occurred on another DC besides the PDCe. The PDCe will say that "Account xyz was locked out," but it won't say from where, if the failed logons were occurring on another DC in the domain. Only the DC that actually validated the logon will record the logon failure, including the client's address. (Also not bringing RODCs into this discussion.)

There are two good ways to find out where failed logon attempts are coming from when you have several domain controllers. Event forwarding, and Microsoft's Account Lockout Tools.

I prefer event forwarding to a central location. Forward failed logon attempts from all your domain controllers to a central logging server. Then you only have one place to go look for failed logons in your entire domain. In fact I personally don't really love Microsoft's Account Lockout tools, so now there's one good way.

Event forwarding. You'll love it.

Assuming the infrastructure is pure, standard Windows with no additional management tool and few changes from default is there any way the process of finding the cause of such lockout could be accelerated or improved?

See above. You can then have your monitoring system, such as SCOM or Nagios or whatever you use, comb that single event log and blow up your cell phone with text messages or whatever. It doesn't get more accelerated than that.

What could be done to improve the resilient of the system against such an account lockout DOS?

1. User education. Tell them to stop setting up Windows services to run under their domain user accounts, log off of RDP sessions when they're done, teach them how to clear the Windows Credential Vault of cached passwords for Outlook, etc.
2. Use Managed Service Accounts where you can so users no longer have to manage passwords for those user accounts. Users muck up everything. If you give a user a choice, he or she will always make the wrong choice. So don't give them a choice.
3. Enforcing remote session timeouts via GPO. If a user is idle in an RDP session for 6 hours, kick them off.