I built a Windows 2008 R2 server last year, and ever since my elevated account locks 10-12 times a day. After much research and testing I found that the server is locking my account at each failed attempt to update Group Policy (about every 90 minutes). I found no information on the web indicating any one else has seen this, and I find it unbelievable myself.

Each time 3 System events are logged on the server:

Event ID 14: The password stored in Credential Manager is invalid. This might be caused by the user changing the password from this computer or a different computer. To resolve this error, open Credential Manager in Control Panel, and reenter the password for the credential contoso\me.

There are no entries in Credential Manager. This happens whether or not I disable the Credential Manager service, whether or not I am logged on, whether or not I log out and use a local admin account to delete my profile.

Event ID 40960: The Security System detected an authentication error for the server cifs/ContosoDC.contoso.com. The failure code from authentication protocol Kerberos was "The user account has been automatically locked because too many invalid logon attempts or password change attempts have been requested. (0xc0000234)".


Event ID 1058:

The processing of Group Policy failed. Windows attempted to read the file \contoso.com\SysVol\contoso.com\Policies{78719F0C-3091-4B5C-9BC3-6498F729531E}\gpt.ini from a domain controller and was not successful. Group Policy settings may not be applied until this event is resolved. This issue may be transient and could be caused by one or more of the following: a) Name Resolution/Network Connectivity to the current domain controller. b) File Replication Service Latency (a file created on another domain controller has not replicated to the current domain controller). c) The Distributed File System (DFS) client has been disabled.

I checked the items a-c, none seem to be the case.

I've tested this thoroughly by checking that the user account is not locked, running gpupdate on the server, and then re-checking the user account, which immediately locks. I've used lockout tools to reveal that all lockouts are originating from this particular server. The user account has no associated email address, and I've extensively researched the usual array of known lockout issues.

Any clues for me ? I'm getting ready to take down this production server and reset its computer object in AD, but I don't know that it will help.

  • 2
    Do you have a service setup with your user name? What about a disconnected RDP session? What order are you getting these in? I would guess 40960 is the locking process and the rest are a result of that.
    – Nixphoe
    Commented Mar 5, 2014 at 19:35

2 Answers 2


Apparently, there can be passwords in credential manager that don't show up. Or, to quote this link:

There are passwords that can be stored in the SYSTEM context that can't be seen in the normal Credential Manager view.

Download PsExec.exe from http://technet.microsoft.com/en-us/sysinternals/bb897553.aspx and copy it to C:\Windows\System32 .

From a command prompt run: psexec -i -s -d cmd.exe

From the new DOS window run: rundll32 keymgr.dll,KRShowKeyMgr

Remove any items that appear in the list of Stored User Names and Passwords. Restart the computer.

Hopefully, that'll solve your problem.

  • 1
    I wish I could give you more than one upvote. I never would have thought of looking in the SYSTEM account's context for saved credentials like this.
    – bshacklett
    Commented Mar 10, 2015 at 20:51

If the credential manager doesn't help, I would try putting the system in an OU without any GPOs to test.

If the issue still occurs it is related to the default domain GPO, a GPO that applies to the entire domain or is not GPO related. Either way this can help to limit the scope to search.

From a cmd prompt use gpupdate to test the changes without having to wait and gpresult /R to see what GPOs applied to the system.

If you think that a GPO is still involved use the WMI filter to prevent GPOs from applying.

Also note there could be GPOs applied at the site level, but you will see those in the gpresult output.

If you are able to limit the lockouts with reducing the GPOs, then add them to the OU one at time to find the one that is part of the cause. Then research that GPO to find the resolution.

Also here is a list of thing I check when account is getting locked and I already know the system that it is coming from. Services Scheduled Tasks Mapped drives Web apps VM console KVM console RDP sessions Scripts PW helper apps VPN connect Other devices that connect to email Remote Desktop tools Applications that run Credential Manager

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .