Powershell – Change different domain account without being admin Windows

Unfortunately there are numerous circumstances where the security event log will event id 680 that look like this and the workstation name will be blank.

680,AUDIT FAILURE,Security,Fri Feb 25 14:29:37 2011,NT AUTHORITY\SYSTEM,Logon attempt by: MICROSOFT_AUTHENTICATION_PACKAGE_V1_0    Logon account:  jdoe    Source Workstation:     Error Code: 0xC0000064    

One way to expose more information is to enable netlogon verbose logging. On a domain controller(s) where the events are recorded, create the following registry value:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters]
"DBFlag"=dword:24401F04

Restart the netlogon service for this to take effect. The verbose information will be recorded in: %systemroot%\debug\netlogon.log and netlogon.bak. The log file rolls over and is renamed to .bak at around 19 MB. After one of the events, make a copy of the two files from the dc where the event occurred, and open them in a text editor and search for the user's name.

If you're lucky, it will have something like this:

02/12 10:54:39 [LOGON] ACMI: SamLogon: Transitive Network logon of (null)\jdoe from  (via EXCHANGE2) Entered
02/12 10:54:39 [LOGON] ACMI: NlPickDomainWithAccount: jdoe: Algorithm entered. UPN:0 Sam:1 Exp:0 Cross: 0 Root:0 DC:0
02/12 10:54:39 [LOGON] ACMI: NlPickDomainWithAccount: Username jdoe is hq.acme.com\jdoe (found On GC)

Note that if you have multiple domain controllers, when you restart the netlogon service on one, the machine that is making the logon attempts may switch to another dc, so be prepared to enable this on more than one dc. If you have a multi-domain environment with child domains, you may have to track this from a child domain to the root domain and another child domain before the offending machine is located. The offending machine could be anything, it doesn't necessarily have to be a windows workstation. It could be a multifunction network printer/copier, or an email client that is attempting an authenticated SMTP connection with your Exchange server.

I have not encountered any scenario where an account is listed as unlocked and the user is getting account locked issues. However, this could potentially occur if the DCs are not up to date.

Are the users who are getting this problem all within one AD site? Generally your intrasite DC replication will occur fast enough to avoid these issues. If your intersite replication schedule is too long and a user somehow gets locked in a separate AD site you could have the scenario you encounter.

Have you tried looking for the root cause of the account lockouts? You could use the Lockout Tool to find where the bad logon attempts are coming from.