Account Lockouts - NOT from bad password

[OregonSteve]

Greetings-

Single Site, Single Domain; 3 DCs; Windows 2003 Server; XP pro workstations w/ SP2. A user reported not being able to log in; checking their account revealed it was locked out. This problem has been happening to apparently random users on our network starting about two months ago. Looking at the Security logs on the DCs reveals entries like the one below, indicating the account is locked out, but I can never find ones indicating a bad password attempt.
We had all our users change passwords about 4 months ago with a maximum password age of 180 days.

Event Type: Failure Audit
Event Source: Security
Event Category: Account Logon
Event ID: 675
Date: 12/18/2005
Time: 9:30:45 AM
User: NT AUTHORITY\SYSTEM
Computer: DC1
Description:
Pre-authentication failed:
User Name: AtkinsJ
User ID: MyDomain\AtkinsJ
Service Name: krbtgt/MyDomain
Pre-Authentication Type: 0x2
Failure Code: 0x18
Client Address: 10.35.27.23


In this case, this entry appears anywhere from 2 to 12 times A SECOND. They stop abruptly at 09:34:00 We've seen this on other accounts over the past couple of months, but never to this extent. What could be generating this message in such mass quantities??? If I can find this out, I'm sure I'll be able to resolve the main problem that's affecting other users.

I've found several posts in this forum presenting user lockout problems, but have never seen a post that contains a solution... Let's be the first to crack this nut!!!

Thanx
OregonSteve

"..You should never, never doubt what nobody is sure about." -Willy Wonka

 

[trusted]

Here a link that might help you.

http://www.eventid.net/display.asp?eventid=675&eventno=62&source=Security&phase=1

 

[OregonSteve]

Greetings-

Thank you, but most of these scenarios do not describe our circumtstances.
-We moved from Novell to Microsoft several years ago, so we've been AD since day one.
-Our clients run XP sp2
-Security logs don't show bad password attempts
-This specific case shows over 1300 security log entries in less than four minutes
-No time errors have been recorded
-Users not logged into another machine
-Users not logged onto a terminal session
-Computer not being re-added to Domain


Thanx
OregonSteve

"..You should never, never doubt what nobody is sure about." -Willy Wonka

 

[porkchopexpress]

The faliure code suggests a bad password.

0x18 Username exists, but password is wrong

 

[porkchopexpress]

Have you looked at this page it very informative.

http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/security/bpactlck.mspx

Do you get any other info from the event log?

This type of error is often caused by an automated process e.g. a scheduled task, or a dictionary attack on you directory service.

 

[markdmac]

How many DCs do you have? Have you verified that they are syncing OK?



I hope you find this post helpful.

Regards,

Mark

 

[OregonSteve]

Greetings-

YES! My mistake as to the error code. This one (0x18) shows up the first 6 times, but then the next 1280+ entries are the 0x12 (account locked out). Thanks, PorkChop.

And I did find out that this user was connected through our VPN, which uses pass-through authentication, i.e. it passes credentials on to AD for authentication. Seems like symptoms to a more fundamental problem...

Thanx
OregonSteve

"..You should never, never doubt what nobody is sure about." -Willy Wonka

 

[xmsre]

0x18 is a KDC_ERR_PREAUTH_FAILED. As part of ther kerberos ticket granting process, preauthentication data is encrypted with the credentials for the krbtgt account. It could be an issue with the SPN, or with the krbtgt account missing RC4 or MD5 keys.

 

[lkd]

OregonSteve, did you ever come up with a source of this problem? I don't think I am having the same problem, but I am having a similar problem with my account. The campus and district admins are not able to determine what is going on...and it is REALLY causing me grief. I am going to post a new thread since the details of the problem are a little different...if you have any suggestions, let me know.

Thanks!

 

[djtech2k]

I suggest turning on auditing and then comb thru your event logs for this user. The event logs will tell you what computer is requesting authentication for that user. YOu can then trace down the computer.

I have found that mapped drives, service accounts, and Terminal Servers are famous for this.

Alot of times, a user uses their credentials to map a drive or uses it as a service account that stays running. When the password changes, the mapped drive or service account is not updated, hence the lockout. The other thing is TS. Since most users will NOT logoff TS sessions correctly (they click the X in the corner or choose disconnect instead of logoff), often times sessions get hung or left in disconnected state on Terminal Servers. Again, the sessions stays alove and the password gets changed, so it starts failing authentication and locking out.

Those are a few things I have seen many times.

 

[NickFerrar]

Make sure you use the account lockout tools from MS:

http://www.microsoft.com/downloads/...9C-91F3-4E63-8629-B999ADDE0B9E&displaylang=en

Makes it much easier to narrow down what's going on.

This guy's blog has some useful info on using them:

http://www.markwilson.co.uk/blog/2005/05/troubleshooting-windows-authentication.htm

 

[Chris1980]

We have the same problem on our network, my account has been locking out for months now and I was just clearing it myself. As it has started happening to a more users now I'm looking into it properly.

The account lockout tools that NickFerrar has pointed out are very helpful, especially the EventCombMT tool that has a built in search for Account Lockouts (aswell as some other searches that will probably be helpful for other issues). Has pointed out a number of machines that aren't mine that are involved in locking my account so I'll be trawling through them soon to figure whats going on.

Most likely issue is a service or a mapped drive as others have mentioned but I think everyone should be aware of the potential that their problem may be related to external malicious attacks or even internal ones.