Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

My admin-account in our Datacenter get's permanently locked and I have to unlock it again and again with our general Datacenter-Administrator. I want it to stop, but I don't know who locks my account and on which machine that happens.

We have several Server 2003, 2008 and 2008 R2 Servers in our Datacenter. Our 3 Domain Controllers are running 2 x Server 2008 and 1 x Server 2008 R2.

How can I track down from which client, on which Server my user get's permanently locked out?

Update: With LockOutStatus.exe I found out that last lockout time was 13:19. At this time, I have EventID 4771 logged on our DC. It tells me the Client-Address of one of our Terminal-Servers with Servicename "krbtgt/domain" Failure Code 0x18 and Pre-Authentication Type 2.

I looked for errors on that terminalserver but didn't found some Kerberos related. I did found GPO-related Errors on Systemlog of that terminalserver: EventID 1006 with ErrorCode 49. In fact I was logged on at this Terminalserver this time. But not tomorrow. This won't be the "root-error". Any thouhts what to do to find the problem?

Update / solved: There were 4 Sessions on a few servers where my user was logged on (but disconnected) using old-credentials. I used LockOutStatus.exe to find the time when my user was last locked. Then I looked at security logs and found an Event with ID 4771 which holds the client's IP that caused my user to lock out. I logged out the session, unlocked my user-account and waited for the next session/server to lock my user. I repeated that until my user didn't get locked out again.

Thanks to you for your good answers and tips :)

share|improve this question
2  
Do you have any services or scheduled tasks running as this account? –  jscott May 17 '11 at 10:27
2  
Turn on auditing of login failures, then you should be able to track what is happening via the event viewer. The most common causes of this problem that I've seen, by the way, is when people install software which adds itself to a computer as a service using their account as the service account; and smartphones that don't get an updated password for email push but keep trying anyway (we've had a lot of trouble with nokia E71s doing this). –  RobM May 17 '11 at 10:28
    
possible duplicate of Finding why a user is locked out in Active Directory –  RobM May 17 '11 at 10:35
    
Thanks for your comments @jscott and @Robert. I didn't install anything with my account and didn't specify it as user for a service to logon. Because it's an pure admin-account, it isn't used for mail too. I would like to do some auditing. I'm currently reading about auditing, but it seems, that the logs are written on the server where the logon-attempt is happening. Is it possible to log that on a domain-controller or other central server? –  wullxz May 17 '11 at 10:35

3 Answers 3

up vote 2 down vote accepted

Is it possible that you have a disconnected session with your user account on that server? If you recently changed your password, then any disconnected but active sessions on a server/workstation could result in something like that.

If not:

I would try and enable process tracking in addition to logon tracking. This will enable you to see which process was started at the time the logon failure and ultimately the lock-out occurred.

On Win2k8 those event ids are 4688 when a process starts, and 4689 when the process exits. Deciphering that can a bit tricky though.

You could try and install an evaluation version of EventSentry (I am affiliated with), which normalizes logon and process data and stores it in a database for easy searching. E.g., you can see which processes were running at the time, search through logon events across multiple servers and so forth. However, setting up EventSentry just for this purpose might be overkill.

Did you check your scheduled tasks to make sure no tasks are configured under your user account?

share|improve this answer
    
Yes, there were disconnected but active sessions! I logged off of our terminalservers (there are 3) this morning, but maybe there was still a session I used yesterday or last week. As my user was locked out, I created a new password and unlocked my account. I think that was the problem. With our general domain-admin I locked my sessions out... Now I'm looking if this error occurs again. It'll be tracked with EventID 4771 and the client's IP on the DC. I'll edit my question if the problem is solved. Thanks –  wullxz May 17 '11 at 15:03

Assuming you're working in an AD domain, you can enable account logon auditing in the Default Domain GPO. This will enable auditing on all computers and should allow you to track down what's going on. Once you've found the relevant log entries you can look at the logon type to try and determine what's happening.

http://www.windowsecurity.com/articles/Logon-Types.html

share|improve this answer
    
Thanks for your answer. With LockOutStatus I was able to find the server that caused the error this time. I edited my Question. I hope you have additional ideas to solve that problem. –  wullxz May 17 '11 at 14:16

i wrote a blog entry about this a while ago, might give you some pointers - http://www.beakersoft.co.uk/2008/02/07/where-has-that-account-been-locked-out/

share|improve this answer
    
Thanks, LockOutStatus helped me to find the Server causing the error and lockout this time. But this can't be the underlying problem because I logged onto that server around 12.00 o'clock and got locked out last night or so. Maybe you have some other hints for me? –  wullxz May 17 '11 at 14:15
    
Check for stale drive mappings, best way is a net use command to see them all, then net use /d to remove the connections. Also might be worth looking at any scheduled tasks and services that are running as you –  beakersoft May 17 '11 at 15:21
    
My user is just for administration. I never installed Software in our Datacenter except Updates for existing applications. I never created scheduled tasks. I think the problem were the existing sessions on our terminalservers. I'll check that and edit my question (and of course choose an answer as my answer for this problem) –  wullxz May 17 '11 at 20:17

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.