我们有一个域帐户已通过2台服务器中的1台被锁定。内置审核仅告诉我们很多信息（已从SERVER1，SERVER2锁定）。

该帐户在5分钟内被锁定，似乎每分钟大约有1个请求。

最初，我尝试从sysinternals运行procmon，以查看在解锁帐户后是否产生了任何新的PROCESS START。没有可疑的东西出现。我的工作站上运行procmon中并提升到一个UAC外壳（conscent.exe）之后，它似乎是从堆栈中ntdll.dll和rpct4.dll当您试图权威性针对AD（不知道）被调用。

无论如何，是否可以缩小导致DC进行身份验证请求的过程？它始终是相同的DC，因此我们知道它必须是该站点中的服务器。我可以尝试在Wireshark中查找呼叫，但是我不确定这是否会缩小实际触发它的进程。

没有服务，驱动器映射或计划的任务都在使用该域帐户-因此它必须是存储了域凭据的内容。在任何服务器上（我们选中），都没有与该域帐户打开的RDP会话。

进一步说明

是的，有问题的DC启用了“成功/失败”登录审核-直到帐户被实际锁定之前，不会记录任何失败事件。

进一步的挖掘表明，一旦帐户解锁，LSASS.exe就会KERBEROS呼叫有问题的DC。它（通常）以java开头（似乎被称为vpxd.exevCenter进程）。但是，当我查看另一个（也可能是）帐户锁定的“ server2”时，我再也看不到调用，lsass.exe并且仅生成了apache进程。两者之间的唯一关系是SERVER2是SERVER1的vSphere群集的一部分（server1是vSphere OS）。

DC错误

因此，AD似乎只能告诉我这是预身份验证Kerberos错误。我检查了一下，没有票，klist反正还是为了防万一而冲洗了一下。仍然不知道是什么导致此kerberos错误。

Index              : 202500597
EntryType          : FailureAudit
InstanceId         : 4771
Message            : Kerberos pre-authentication failed.

                     Account Information:
                         Security ID:        S-1-5-21-3381590919-2827822839-3002869273-5848
                         Account Name:        USER

                     Service Information:
                         Service Name:        krbtgt/DOMAIN

                     Network Information:
                         Client Address:        ::ffff:x.x.x.x
                         Client Port:        61450

                     Additional Information:
                         Ticket Options:        0x40810010
                         Failure Code:        0x18
                         Pre-Authentication Type:    2

                     Certificate Information:
                         Certificate Issuer Name:
                         Certificate Serial Number:
                         Certificate Thumbprint:

                     Certificate information is only provided if a certificate was used for pre-authentication.

                     Pre-authentication types, ticket options and failure codes are defined in RFC 4120.

                     If the ticket was malformed or damaged during transit and could not be decrypted, then many fields
                      in this event might not be present.

登录事件记录尝试登录的过程。在本地安全策略（secpol.msc）中启用失败的登录审核（安全设置>本地策略>审核策略>审核登录事件），然后在安全事件日志中查找事件。如果可以的话，您也可以通过组策略启用它。

将有一个“过程信息”部分，其中记录了可执行路径和过程ID。

例：

Process Information:
    Process ID:         0x2a4
    Process Name:       C:\Windows\System32\services.exe

我在研究其他问题时发现了这个老问题，但对于有类似问题的任何人：

失败代码0x18表示该帐户在客户端尝试进行身份验证时已被禁用或锁定。

您需要找到相同的事件ID，其失败代码为0x24，这将识别导致帐户锁定的失败登录尝试。（这假定它是由于某个地方的高速缓存密码错误而发生的。）

然后，您可以在这些事件上查看“客户端地址”，以查看哪个系统正在传递错误的凭据。从那里，您必须确定它是否是带有旧密码，映射的网络驱动器等的服务。

失败代码多种多样，因此，如果没有0x24代码的事件，您应该寻找0x18以外的任何内容，以确定导致帐户锁定的原因。我相信唯一会导致锁定的失败类型是0x24（密码错误），但我可能是错的。

Kerberos 0x18确实是错误的密码尝试。

Kerberos 0x12已被帐户禁用，过期，锁定或登录时间限制。

https://www.ultimatewindowssecurity.com/securitylog/encyclopedia/event.aspx?eventID=4771

我今天花了很多时间来找出根本原因。我走错了路-从使用网络嗅探器捕获的信息中（kerberos错误进程ID为566 = lsass.exe）。让我总结一下信息。

1. 登录到有问题的PC，以提升的权限运行Powershell

2. 启用审核登录

   auditpol /set /subcategory:"logon" /failure:enable

3. 检查来源

   Get-WinEvent -Logname 'Security' -FilterXPath "*[System[EventID=4625]]" -MaxEvents 2 | fl

如果你看到：

处理信息：

呼叫者进程ID：0x140

调用方进程名称：C：\ Windows \ System32 \ services.exe

这意味着您使用旧密码从问题帐户中运行了一些服务

这是从上面的笔记。看起来这篇帖子的发起人在他的最后评论中说过。Java调用vpxd.exe进程。

附加说明是的，正在讨论的DC上启用了“成功/失败”登录审核-在帐户被实际锁定之前，不会记录任何失败事件。

进一步的挖掘表明，一旦帐户解锁，LSASS.exe就会对有问题的DC进行KERBEROS调用。它（通常）以java开头（似乎由vCenter进程vpxd.exe调用）。但是，当我看到另一个（也可能是）帐户锁定的“ server2”时，我再也没有看到对lsass.exe的调用，并且仅生成了Apache进程。两者之间的唯一关系是SERVER2是SERVER1的vSphere群集的一部分（server1是vSphere OS）。