简而言之：是否有可能确定锁定 A/D 帐户的具体进程/exe？
我们定期收到 Windows 应用程序服务器上正在使用的服务帐户的帐户锁定信息。域控制器会报告失败的登录尝试导致锁定的时间，但不提供任何其他可帮助我们追溯锁定帐户的进程的信息。该帐户不能用于本地登录，只能用于在该服务器上执行进程。话虽如此，该服务器是由内部开发人员和外部顾问设置的自动化 shell 脚本、计划任务和服务的大杂烩。
我知道以下内容：
- 帐户名称
- 发起服务器
- 闭锁时间
这整件事让人非常沮丧，因为它几乎是随机发生的（即有时一天一次，有时一天几次，而且很少在同一时间发生）。更糟糕的是，如果我知道在哪里查找，这似乎很容易就能被捕获。
我是一名应用程序开发人员，并且在我们的域上没有扩展权限，因此任何可以在没有域管理员权限的情况下执行的解决方案/建议都是有利的。
谢谢！
答案1
不，你运气不好。
即使在最好的情况下，跟踪也是一件非常痛苦的事情，而且如果没有能力提高日志记录级别或以管理权限运行应用程序（我procmon马上perfmon想到了），除了逐个尝试和挖掘脚本之外，你几乎无能为力。我能想到的唯一建议（确保没有使用旧密码映射的打印机或驱动器）是在服务器上的文件内容中搜索相关帐户的用户名，希望你能走运。
答案2
喜欢HopelessN00b说，你已经进入了一个痛苦的世界。微软已经意识到，我们许多服务器管理员不得不向奇怪的审计员/经理解释，我们无法将某件事确定到这个水平，并且尝试过通过编写账户锁定工具来改善现状（参见此链接)。这些工具在检查 netlogon 日志文件方面做得不错。我还编写了一个脚本，用于监控帐户实际锁定的时间，然后解锁。这在过去被证明是有用的，因为它为您提供了历史视图，从而有可能确定某项特定工作等。
答案3
您（或具有权限的人）需要启用登录失败事件的审核。对于经典审核（2008 年之前），设置是Audit logon events。高级审核（2008 年之后）设置是Logon/Logoff | Audit logon。无论您使用哪一个，您都需要审核失败事件。然后查找事件 529（2008 年之前）或 4625（2008 年之后）。这些事件将指向有问题的进程。
顺便说一句，529 事件不包含进程名称，只包含进程 ID。为了查找更多信息，请启用进程跟踪审核并查找事件 592。