Skip to main content

Windows needs your credentials

Getting issue with one of my Windows Pro 7 user prompting to enter the network credentials. Here's the message.

"Please lock this computer, then unlock it using your most recent password or smart card."

When I lock this computer, enter the new password. The user account is immediately lockout. 
I also tried to logoff, and login back same issue - lockout. I need to unlock the account from the Active Directory, but the account will be lock out again later.

This post is the continuation of "Frequent Account Lockout in Active Directory", still no luck resolving this issue.

I found this post in Microsoft Technet (

"Run gpedit.msc
Expand “Local Computer Policy” > “Computer Configuration” > “Windows Settings” > “Security Settings” > “Local Policies” > “Security Options” > “Network security: Configure encryption types allowed for Kerberos”
Double click “Network security: Configure encryption types allowed for Kerberos”
Select “DES_CBC_MDC” and “RC4_HMAC_MD5”
Press “OK”
File menu

I can't find the Network security: Configure encryption types allowed for Kerberos”. It is not available, and there is no instruction on how to add this information. Dead end for me.

Troubleshooting steps: (found in Microsoft Technet community)

1. Click Start, click Run, type "control userpasswords2" (without the quotation marks), and then click OK. <-- Did not work for me, so I used the command prompt to run "rundll32.exe keymgr.dll,KRShowKeyMgr" to do this task.
2. Click the Advanced tab.
3. Click the "Manage Password" button.
4. Check to see if these domain account's passwords are cached. If so, remove them.
5. Check if the problem has been resolved now.

If there is any application or service is running as the problematic user account, please disable it and then check whether the problem occurs.

For your convenience, I'd like to list the common troubleshooting steps and resolutions for account lockouts as the following:

Common Causes for Account Lockouts

To avoid false lockouts, please check each computer on which a lockout occurred for the following behaviors:

Many programs cache credentials or keep active threads that retain the credentials after a user changes their password.

Service accounts:
Service account passwords are cached by the service control manager on member computers that use the account as well as domain controllers. If you reset the password for a service account and you do not reset the password in the service control manager, account lockouts for the service account occur. This is because the computers that use this account typically retry logon authentication by using the previous password. To determine whether this is occurring, look for a pattern in the Netlogon log files and in the event log files on member computers. You can then configure the service control manager to use the new password and avoid future account lockouts.

Bad Password Threshold is set too low:
This is one of the most common misconfiguration issues. Many companies set the Bad Password Threshold registry value to a value lower than the default value of 10. If you set this value too low, false lockouts occur when programs automatically retry passwords that are not valid. Microsoft recommends that you leave this value at its default value of 10. For more information, see "Choosing Account Lockout Settings for Your Deployment" in this document.

User logging on to multiple computers:
A user may log onto multiple computers at one time. Programs that are running on those computers may access network resources with the user credentials of that user who is currently logged on. If the user changes their password on one of the computers, programs that are running on the other computers may continue to use the original password. Because those programs authenticate when they request access to network resources, the old password continues to be used and the users account becomes locked out. To ensure that this behavior does not occur, users should log off of all computers, change the password from a single location, and then log off and back on.

Stored user names and passwords retain redundant credentials:
If any of the saved credentials are the same as the logon credential, you should delete those credentials. The credentials are redundant because Windows tries the logon credentials when explicit credentials are not found. To delete logon credentials, use the Stored User Names and Passwords tool. For more information about Stored User Names and Passwords, see online help in Windows XP and the Windows Server 2003 family.

Scheduled tasks:
Scheduled processes may be configured to using credentials that have expired.

Persistent drive mappings:
Persistent drives may have been established with credentials that subsequently expired. If the user types explicit credentials when they try to connect to a share, the credential is not persistent unless it is explicitly saved by Stored User Names and Passwords. Every time that the user logs off the network, logs on to the network, or restarts the computer, the authentication attempt fails when Windows attempts to restore the connection because there are no stored credentials. To avoid this behavior, configure net use so that is does not make persistent connections. To do this, at a command prompt, please type net use /persistent:no. Alternately, to ensure current credentials are used for persistent drives, disconnect and reconnect the persistent drive.

Active Directory replication:
User properties must replicate between domain controllers to ensure that account lockout information is processed properly. You should verify that proper Active Directory replication is occurring.

Disconnected Terminal Server sessions:
Disconnected Terminal Server sessions may be running a process that accesses network resources with outdated authentication information. A disconnected session can have the same effect as a user with multiple interactive logons and cause account lockout by using the outdated credentials. The only difference between a disconnected session and a user who is logged onto multiple computers is that the source of the lockout comes from a single computer that is running Terminal Services.

Service accounts:
By default, most computer services are configured to start in the security context of the Local System account. However, you can manually configure a service to use a specific user account and password. If you configure a service to start with a specific user account and that accounts password is changed, the service logon property must be updated with the new password or that service may lock out the account.

Just in case you need the Account Lockout and Management Tools from Microsoft, here's the link:


My research will continue tomorrow, hopefully to find a solution.


  1. If you have Windows 7 or Vista, you should look into the Credential Manager (Control Panel). It stores old account password and does not update them even if you choose to "store the new passwd" that you're asked for.

    Best regards,

  2. This is what I hate about Windows 7 Pro, it doesn't update. Just like other organization, we have a 90 days reset password for all employees. When they change password, I have to reset them manually due to this inconsistent "storing of new password" in Windows 7.

    Now, I missed Windows XP.

  3. Active directory replication failure was the culprit for me. Directory services log had this:

    Active Directory Domain Services could not update the following object with changes received from the directory service at the following network address because Active Directory Domain Services was busy processing information.

  4. Start troubleshooting from the local DNS service, most known issue.


Post a Comment

Popular posts from this blog

Alternative Social Networks

If you are planning to create your social network e.g. similar to Facebook. Here's a short list of alternative software's:

Open Source and Free​ - Wordpress (Open Source and Free) - (Open Source and Free)Commercial Social Networks software ($299 Stand Alone, $29/mo Cloud) (run with Joomla, need to know CMS) (very expensive, $399 for Standard) (from free to Commercial, I left my networks and they are selling it (I used this before, it's hard to maintain. I moved to NING but left too after it was sold to another company) (I don't recommend using this service, it's hard to export your data when it's time to move)Something to check when selecting your next soc…

Example of Out of Office Reply for Terminated Employee

This is a sample message that I used for terminated employees, unless HR staff specified a different message.
=== Example for KING.NET Employee === John Doe (employee or consultant) is no longer with KING.NET effective June 1, 2008 (termination date). For matters relating to "Project Name here" please direct your concerns to John Smith at [email protected] (Manager or Supervisor). For all other matters, please direct your email to Mary Smith HR at [email protected]
Please call our main office 703-345-6789 if you have other concerns.
Thank you.
=== end of message ===

Frequent Account Lockout in Active Directory

I have a user in Windows Pro 7, and Windows Server 2003 environment that is frequently account locked out. I tried many different scenarios to resolve this account lockout issue, from resetting his password, changing a new password, remove and re-join the domain, rebooting the workstation and active directory servers.

I tried to use the command prompt utility to run "rundll32.exe keymgrdll, KRShowKeyMgr" (case sensitive) to delete the account in Windows 7 password cache, and still no luck.

Still searching for answer ... Let me know if you encounter a similar issue in Windows Pro 7 and Windows Server 2003.

Continue reading updated post here: