Answered by:

Windows 7 - AD Account keeps locking

Question

We are starting to roll out Win7. We implemented 5 machines so far and 2 of them have a problem where the user's domain account is constantly getting locked (usually several times each day but at random intervals). The other 3 machines are Ok,
but we see errors in the domain controller event log for those also. The event log entry is at the end of the post (I've redacted some items). Note that we've tried the following: Removing/re-adding to the domain, running Sysprep to generate a
new SID, Disabling Java updater, removing all network drive and network printer mappings, turning off Kerberos pre-authenticaion for the user account in AD, and registry changes to including changing the
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters and HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa.
Any suggestions would be appreciated.

Answers

Usually account lockouts are caused by service accounts/mapped drives/scheduled tasks\disconnected sessions etc. Failure code 0x18 usually means bad password so talked to the users and ensure they dont use wrong password or Bad Password Threshold is not
set too low.

I was told by Microsoft that the hotfix would be released by the end of this month. For customers running with a hybrid of both on premise Exchange and cloud-based Exchange, that hotfix will be released in August.

All replies

Usually account lockouts are caused by service accounts/mapped drives/scheduled tasks\disconnected sessions etc. Failure code 0x18 usually means bad password so talked to the users and ensure they dont use wrong password or Bad Password Threshold is not
set too low.

Thanks for the reply. We have already looked at all of the scenarios in the "Common Causes for Account Lockouts" section, as I mentioned, we already looked at scheduled tasks, printer mappings, network drive mappings. The bad password threshold
is set to 5, not that it is relevant in this case since it happens to EVERY account logged into the Windows 7 machine. This must be some sort of Active Directory bug or something. Any other suggestions?

1.Check "logon Details" for all service, find the mwadmin account and update the password.
2.Check Schedule Tasks which run with mwadmin account
3.Restart Windows to Safe Mode or Clean Boot to check if any third party application is configured to use mwadmin account
4.Using Account Lockout and Management Toolsto troubleshoot account lockouts and to change a user's password

One more question, have you defined Kerberos Authentication related policy or have your modified Kerberos Authentication related registry before you get these errors?

Note Remove this registry value when it is no longer needed so that performance is not degraded on the computer. Also, you can remove this registry value to disable Kerberos event logging on a specific computer.

We looked at the Kerberos traffic, it is Outlook indeed casuing the issue. We are using the Windows 7 defaults (not blocking NTLM) except for the fact that we have a GPO set up that disables the use of LM Hash which is a different animal.

I would test without that GPO to be honest. From memory NTLM don't use any Kerberos call. (Or test with a older Outlook) (but it can use LM hash (http://support.microsoft.com/kb/820281 old kb, but
it show that NTLM use LM hash some way)

I did a program in the past that use libNTLM to send NTLM hash to a Exchange 2007/2010 and it's only a 3 phases negotiation on the SSL port, nothing Kerberos there... (link
there to show) Outlook fallback to the basic auth scheme for a odd reason.

I was told by Microsoft that the hotfix would be released by the end of this month. For customers running with a hybrid of both on premise Exchange and cloud-based Exchange, that hotfix will be released in August.

We had the same problem. Several users getting locked out. We used Office 365 (with Office 2010) and recenlty broke our federation because we changed our internal domain name. The end result was that after our local domain
name change a few users ended up with passwords for our network and Office 365. Only those users with different passwords were having the lockout problems. We had already applied the hotfix listed in this
article (KB2598374), but did not apply the reg fix at this time as I think it's the unmatched passwords causing the problem.

The patch alone doesn't solve the problem, you need to apply the reg fix too (the reg fix is profile specific - must be applied to the logged on user). Once you do that, users can have mismatched passwords and it won't matter.

Since the hotfix came out before Office 2013, I would assume (or hope) that a hotfix would not be needed, but rather they would have baked it directly into Outlook 2013. You may still need to implement the registry fix though.

i can say that also 2008 r2 terminal Server could cause this Problem with some locked ad accounts

if you use Outlook 2013 !.

:-)

So in one customer site there is only one account who is locked out every day.

I am sure that i can solve this Problem in recreating the ts user Profile where Outlook 2013 is used,
because no other user has similar effects. Maybe the Problem can also be solved in Clearing the credential store in user account control Panel.

in my case the terminal Servers sit in other Domain connecting/authenticating to another Domain (different forest!)and maybe the cached credentials are corrupt.