我们有一个域帐户被 2 个服务器中的 1 个锁定。内置审核仅告诉我们这么多(从 SERVER1、SERVER2 锁定)。
该帐户在 5 分钟内被锁定,大约每分钟 1 个请求。
我最初尝试运行 procmon(来自 sysinternals)以查看在我解锁帐户后是否产生了任何新的 PROCESS START。没有出现任何可疑情况。在我的工作站上运行 procmon 并提升到 UAC shell(conscent.exe)后,似乎从堆栈中可以看到,当您尝试针对 AD 进行身份验证时ntdll.dll
会rpct4.dll
调用该进程(不确定)。
有没有办法缩小导致向我们的 DC 发出身份验证请求的进程的范围?它始终是同一个 DC,所以我们知道它一定是该站点中的服务器。我可以尝试在 wireshark 中查找调用,但我不确定这是否会缩小实际触发它的进程的范围。
没有任何服务、驱动器映射或计划任务使用该域帐户 - 因此它一定是存储了域凭据的某个东西。任何服务器上都没有与该域帐户打开的 RDP 会话(我们已检查)。
进一步说明
是的,在相关 DC 上启用了“成功/失败”登录审核 - 在帐户实际被锁定之前不会记录任何失败事件。
进一步挖掘表明,一旦帐户解锁,LSASS.exe
就会调用相关 DC。它前面(通常)是 java,它似乎被 vCenter 进程调用。但是,当我查看帐户锁定(也)可能发生的其他“server2”时,我从未看到调用,并且只生成了 apache 进程。两者唯一的关系是 SERVER2 是 SERVER1 的 vSphere 集群的一部分(server1 是 vSphere OS)。KERBEROS
vpxd.exe
lsass.exe
直流错误
因此,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.
答案1
登录事件记录尝试登录的过程。在本地安全策略 (secpol.msc) 中启用失败登录审核(安全设置 > 本地策略 > 审核策略 > 审核登录事件),然后在安全事件日志中查找事件。如果更愿意,您也可以通过组策略启用它。
将有一个进程信息部分,其中记录可执行文件路径和进程 ID。
例子:
Process Information:
Process ID: 0x2a4
Process Name: C:\Windows\System32\services.exe
答案2
我今天花了很多时间才找到根本原因。我走错了路——从用网络嗅探器捕获的信息(kerberos 错误进程 ID 为 566 = lsass.exe)。让我总结一下信息。
登录有问题的电脑,以提升的权限运行 powershell
启用审核登录
auditpol /set /subcategory:"logon" /failure:enable
检查来源
Get-WinEvent -Logname 'Security' -FilterXPath "*[System[EventID=4625]]" -MaxEvents 2 | fl
如果你看到:
处理信息:
调用方进程 ID:0x140
调用者进程名称:C:\Windows\System32\services.exe
这意味着你正在使用有问题的账户和旧密码运行某些服务
答案3
我在研究另一个问题时发现了这个老问题,但对于任何有类似问题的人来说:
失败代码 0x18 表示当客户端尝试进行身份验证时,该帐户已被禁用或锁定。
您需要找到失败代码为 0x24 的相同事件 ID,它将识别导致帐户锁定的失败登录尝试。(这假设这是由于某个地方的缓存密码错误而发生的。)
然后,您可以查看这些事件的客户端地址查看哪个系统传递了错误凭据。然后,您必须确定它是否是使用旧密码的服务、映射的网络驱动器等。
故障代码有多种,因此如果没有 0x24 代码的事件,您应该查找 0x18 以外的任何代码来确定导致帐户锁定的原因。我相信唯一会导致锁定的故障类型是 0x24(密码错误),但我可能错了。
答案4
这是上面的注释。看起来这篇文章的发起者在他的最后一条评论中说道。Java 调用 vpxd.exe 进程。
进一步说明是的,“成功/失败”登录审核在相关 DC 上启用 - 在帐户实际被锁定之前不会记录任何失败事件。
进一步挖掘表明,一旦帐户解锁,LSASS.exe 就会对相关 DC 进行 KERBEROS 调用。它之前(通常)是 java,它似乎由 vCenter 进程 vpxd.exe 调用。但是,当我查看帐户锁定(也)可能发生的另一个“server2”时,我从未看到对 lsass.exe 的调用,并且只生成了 apache 进程。两者唯一的关系是 SERVER2 是 SERVER1 的 vSphere 集群的一部分(server1 是 vSphere OS)。