最近三个午夜,我在日志中收到了事件 ID 539...关于我自己的帐户:
Event Type: Failure Audit
Event Source: Security
Event Category: Logon/Logoff
Event ID: 539
Date: 2010-04-26
Time: 12:00:20 AM
User: NT AUTHORITY\SYSTEM
Computer: SERVERNAME
Description:
Logon Failure:
Reason: Account locked out
User Name: MyUser
Domain: MYDOMAIN
Logon Type: 3
Logon Process: NtLmSsp
Authentication Package: NTLM
Workstation Name: SERVERNAME
Caller User Name: -
Caller Domain: -
Caller Logon ID: -
Caller Process ID: -
Transited Services: -
Source Network Address: -
Source Port: -
它总是在午夜前半分钟内。在此之前没有登录尝试。紧接着(在同一秒内)有一个成功审计条目:
Logon attempt using explicit credentials:
Logged on user:
User Name: SERVERNAME$
Domain: MYDOMAIN
Logon ID: (0x0,0x3E7)
Logon GUID: -
User whose credentials were used:
Target User Name: MyUser
Target Domain: MYDOMAIN
Target Logon GUID: -
Target Server Name: servername.mydomain.lan
Target Server Info: servername.mydomain.lan
Caller Process ID: 2724
Source Network Address: -
Source Port: -
这三个进程的进程 ID 是相同的,因此我查了一下,现在至少它映射到 TCP/IP 服务(Microsoft)。
我不认为我周五改变了任何政策或任何事情。我该如何解释这一点?
答案1
您是否有一个在您的帐户下运行的计划任务,该任务在午夜连接到共享?事件 ID 552(第二个事件)通常在用户(在本例中为系统)使用 runas 以另一个帐户身份运行进程时生成。
但是,仔细查看后,登录 ID:(0x0,0x3E7) 表明,执行模拟的是服务。仔细查看机器上的服务。如果另一台机器正在使用您的凭据映射驱动器,并且保存的凭据已过期,您也可能会得到此信息。由于服务是 tcpip,所以我现在就押注于此。
答案2
帐户锁定可能很难解决。我的第一个建议是获取帐户锁定工具来自微软。
使用这些工具,您可以确定哪些 DC 确实锁定了帐户。然后,您需要在安全日志中进行一些侦查,以找出导致锁定的服务器,然后您就可以确定该服务器上的哪些内容锁定了您的帐户。
答案3
这可能是自动事件,例如使用您的凭据运行的服务。跳转到服务器并按services.msc
“登录身份”字段排序,看看您是否在其中。
答案4
您可能已使用您的用户 ID 安装了程序或服务。这些很可能是备份软件或任何类似的服务/任务。您无法从“计划任务”中找到所有计划任务,请查看您的自动服务、IIS、Backup Exec 等。