Asked by:

Multiple accounts getting locked out.

Question

We are running Active Directory 2008 R2 in a mixed domain because we still have 1 2003 DC.
Several of our AD accounts constantly get locked out, especially mine which gets locked out about 2-3 times a day.
I've used the altools and from the DC's security logs i have traced it down to my laptop. I've checked all the usuals on my laptop, network drives, scheduled tasks, services, scripts etc. Please dont suggest the obvious.
Ive enabled kerberos client logging on my PC but the system event logs dont tell me much, just these:

A Kerberos Error Message was received:

on logon session

Client Time:

Server Time: 5:14:18.0000 7/16/2013 Z

Error Code: 0xe KDC_ERR_ETYPE_NOTSUPP

I've followed this article to enable NETLOGON logs on the domain controller.

The 'etype' error message makes me suspect this is related to your mixed mode domain, try enabling Netlogon debug logging on all DC's and check if it's only the W2k3 or W2K8 R2 DC's that generate the inital lockout. A possible scenario is if an etype has
been used in the encryption of the users password that a W2k3 DC doesn't support (or vice versa).

i could recreate my windows profile and reimage my PC and it will probably fix the issue but i'd rather find the root cause of this issue as its happening intermittently everywhere.

Ingolfur, thats an interesting point about the mixed domain. I have enabled netlogon debug mode on the W2K8 DC's but not on the W2K3 DC. Also the initial lockouts come from the w2k8 DC's and not usually from the w2k3 DC. Whats strange is that the bad password
goes over the WAN to remote site DC's that im not working on as well. Ill enable logging on the w2k3 DC and see if that gives me any clues.

But those logs only seem to tell me the codes for bad username and password and what PC is failing the authentication. I need to somehow trouble shoot it from the PC's and look at what is causing it to authenticate. I suspect it could be some residual
affects of the conficker virus as i have learned that we used to be infected with this 3 years ago before my time. But i have scanned my PC and used the Microsoft articles and tools to detect if im infected and it comes up clean.

Here, the client has requested a ticket from the domain controller with a specific algorithm of which the domain controller does not have a hash. In the request, the client will list all the algorithms it supports. The domain controller will pick the highest
one that it supports and returns the ticket encrypted with that algorithm. If there are no matches, the domain controller returns KDC_ERR_ETYPE_NOTSUPP.

Another common cause of this is when a device requests an AES encrypted tickets before you raise the functional level of the domain to
2008 or higher. This does not typically occur on Windows clients as they request the legacy algorithms in addition to AES. This scenario is more likely to occur
on Unix/Linux systems where an administrator specifies a single algorithm in the krb5.conf file. In this case, raise the functional level of the domain or configure the client to utilize another algorithm, like RC4-HMAC.

If the client is requesting an algorithm that the domain controller should support, but is still returning the error, try resetting the password on the account and wait for replication to converge. Resetting the password regenerates the hashes stored
in the directory.

Note: Domain controllers do not store the password of the user. Instead, they store various hashes of the password using various algorithms. }

Microsoft is conducting an online survey to understand your opinion of the Technet Web site. If you choose to participate, the online survey will be presented to you when you leave the Technet Web site.