在最近出现 Outlook 故障后，我想知道如何最有效地解决以下问题：
假设一个相当典型的中小型 AD 基础设施：多个 DC、多个内部服务器和 Windows 客户端、多个使用 AD 和 LDAP 从 DMZ 内部进行用户身份验证的服务（SMTP 中继、VPN、Citrix 等）以及多个内部服务都依赖 AD 进行身份验证（Exchange、SQL 服务器、文件和打印服务器、终端服务服务器）。您拥有所有系统的完全访问权限，但它们数量有点太多（包括客户端），无法单独检查。
现在假设，由于某些未知原因，每隔几分钟就会有一个（或多个）用户帐户根据密码锁定策略被锁定。
- 找到负责此问题的服务/机器的最佳方法是什么？
- 假设基础设施是纯粹的、标准的 Windows，没有额外的管理工具，并且与默认情况下几乎没有变化，有没有什么方法可以加速或改进查找此类锁定原因的过程？
- 怎样才能提高系统对这种账户锁定 DOS 的适应能力？禁用账户锁定是一个显而易见的答案，但随后您就会遇到用户可以轻松利用密码的问题，即使强制执行了复杂性。
答案1
添加一些我在给出的答案中没有看到的内容。
找到负责此问题的服务/机器的最佳方法是什么？
你不能只是查看 PDCe 上的安全日志，因为虽然 PDCe 确实具有有关整个域的帐户锁定的最新信息，但它没有有关失败登录尝试来自哪个客户端（IP 或主机名）的信息，假设失败的登录尝试发生在 PDCe 之外的另一个 DC 上。PDCe 会说“帐户 xyz 已被锁定”，但如果失败的登录发生在域中的另一个 DC 上，它不会说从哪里锁定。只有实际验证登录的 DC 才会记录登录失败，包括客户端的地址。（同样不将 RODC 纳入讨论。）
当您拥有多个域控制器时，有两种好方法可以找出失败的登录尝试来自何处。事件转发以及微软的帐户锁定工具。
我更喜欢将事件转发到中央位置。将所有域控制器的失败登录尝试转发到中央日志服务器。然后，您只有一个地方可以查找整个域中的失败登录。事实上，我个人并不喜欢微软的帐户锁定工具，所以现在有了一好办法。
事件转发。您一定会喜欢它。
假设基础设施是纯粹的标准 Windows，没有额外的管理工具，并且与默认值相比几乎没有变化，有没有什么方法可以加速或改善查找此类锁定原因的过程？
参见上文。然后，您可以让您的监控系统（例如 SCOM 或 Nagios 或您使用的任何系统）梳理该单个事件日志，并用短信或其他方式轰炸您的手机。没有比这更快的了。
怎样才能提高系统抵御此类帐户锁定 DOS 的能力？
- 用户教育。告诉他们停止设置 Windows 服务以在其域用户帐户下运行，完成后注销 RDP 会话，教他们如何清除 Outlook 缓存密码的 Windows Credential Vault 等。
- 尽可能使用托管服务帐户，这样用户就不必再管理这些用户帐户的密码。用户把一切都搞砸了。如果你给用户一个选择，他或她总是会做出错误的选择。所以不要给他们选择。
- 通过 GPO 强制执行远程会话超时。如果用户在 RDP 会话中闲置了 6 个小时，则将其踢出。
答案2
不久前，我们在清理大型环境中的管理员帐户时遇到了同样的问题。尽管 DC 审计日志在技术上提供了所需的信息，但我们决定实施 ManageEngine 的 ADAudit Plus 产品，该产品会扫描这些日志并查找登录尝试以及 AD 中的任何更改。使用内置报告功能和一些 Excel 工作，我们能够（非常容易地）追踪登录的来源。在我们的案例中，这主要与管理员在实施各种应用程序时使用管理员帐户而不是服务帐户有关。
答案3
怎样才能提高系统抵御此类帐户锁定 DOS 的能力？
你不能。
有很多东西可能会烧毁您的房屋。例如，简单的代码会反复请求 IP 地址，直到 DHCP 范围耗尽。或者简单的代码会创建目录，直到 MFT 已满，您必须重新格式化分区才能恢复。您无法防范一切。
更常见的锁定情况是，人们在比几年前更多种设备中输入凭证。例如打印机（用于通过电子邮件发送扫描件）、智能手机或平板电脑。如果他们忘记了输入凭证的位置，或者他们不再有权访问该设备，则该设备可能会一直尝试身份验证。电子邮件身份验证很难追踪这些设备，即使你这样做了，用户也可能无法访问它或不知道它在哪里。IP 10.4.5.27？我知道有一个用户每天都必须打电话给服务台来解锁他们的帐户，然后他们会立即登录，然后他们的帐户会再次被锁定。他们这样持续了几个月。我告诉他们重命名他们的帐户。
生活中存在着各种阻碍，我们不可能将它们全部消除。