最后三个中午，我在日志中得到了事件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: - 总是在午夜半分钟之内。 在它之前没有login尝试。 紧随其后（在同一秒），有一个成功的审计条目：
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是相同的，所以我查了一下，现在至less映射到TCP / IP服务（Microsoft）。
我不相信我周五改变了任何政策或任何事情。 我应该如何解释呢？
您是否有计划任务在您的帐户下运行，并在午夜时段连接到共享？ 事件ID 552（第二个事件）通常是在用户（在本例中为系统）使用runas作为另一个帐户运行进程时生成的。
然而，仔细一看，loginID：（0x0,0x3E7） – 显示服务是模拟的人。 仔细看看机器上的服务。 如果另一台计算机使用您的凭据映射驱动器，并且已保存的凭据已过期，您也可以获取此信息。 由于该服务是tcpip这就是我现在正在赌我的镍。
帐户locking可能是一个难以解决的问题。 我的第一个build议是从微软获得帐户locking工具 。
使用这些工具，你可以找出你的DC实际上locking了账户。 从那里你需要在安全日志中进行一些窥探来确定哪个服务器正在导致locking，然后你可以找出那个服务器上的locking你的账户的东西。
这可能是一个自动化事件，就像在您的凭据下运行的服务一样。 跳到服务器上，并通过Logon As字段对services.msc进行sorting，看看你是否在那里。
您可能已经使用您的用户标识安装了一个程序或服务。 很可能这些是备份软件或任何类似的服务/任务。 您无法从“计划任务”中查找所有已完成的任务，请查看您的自动化服务，IIS，Backup Exec等。