We help IT Professionals succeed at work.

Account Lockout - Find App/Process on account

Paul Walsh
Paul Walsh asked
on
Hi All,

I have an account that is constantly being locked within AD after a password change. On our secondary DC Iooking at the event logs it tells me the first DC is the computer that is causing the lockout. I have looked everywhere on this first DC for where this account is used, but cannot find it. On the first DC within about 30 seconds of unlocking this account I can see an event that states that the particular credentials have been explicitly used. Any idea how I can what app/process is using this account.

I have tried resetting the password back to what it used to be, however the account still gets locked out.

Thanks for your help.

Cheers,
Paul
Comment
Watch Question

Zaheer IqbalTechnical Assurance & Implementation
Commented:
Hi Paul

Try and use the MS Lockout Status tool and see if you can capture the details.
The link below gives you it in more details

https://community.spiceworks.com/how_to/48758-trace-the-source-of-a-bad-password-and-account-lockout-in-ad
Paul WalshSystem Administrator

Author

Commented:
Hi,

Thanks for this, I have followed the steps provided. On the DC in question with the account in question I can only see event fith failure code 0x12 and not the 0x18 stated in the guide?

Cheers,
Paul
Paul WalshSystem Administrator

Author

Commented:
Hi,

What is strange is that it states the secondary domain controller is locked. There is no log of this domain controller locking my account. What I can find on my first domain controller is an event ID 4648 that states that the administrator account tried to log onto the second domain controller using this accounts credentials.

Any help would be more than grateful.

Cheers,
Paul
Zaheer IqbalTechnical Assurance & Implementation

Commented:
Is a account used for a user / support user or is it a service account ?
Do you have any tasks running against that account or any services running as that account ?
Paul WalshSystem Administrator

Author

Commented:
Hi,

That's the strange thing, the account in question isn't a service account. I have checked under services and scheduled tasks and it isn't listed there either.
Paul WalshSystem Administrator

Author

Commented:
What I can see periodically on the first controller is an event id 4648, with the account in question. Looks like the administrator is trying to log on using the problem account. In the process Id I get 0x4?

Cheers,
Paul
Infrastructure Architect
Commented:

Hello Paul,


If you are still struggling to isolate from where the bad password is getting triggered - I would suggest the following.


1) Enable Netlogon debug logging on all domain controllers.

https://support.microsoft.com/en-in/help/109626/enabling-debug-logging-for-the-netlogon-service

Once done, All activities related with netlogon will get logged into the log file -   %windir%\debug\netlogon.log


2) On the DC which is holding PDC Emulator role, Look for event - 4740. You can use a filter on security events and filter 4740 to make sure that you get the recent events quickly. To identify PDC Emulator role holder, use netdom query fsmo from a command prompt from any of the DC.


3) Wait for the next lockout event . Identify the caller computer name. If its something which you can track further and the user who is using - You are safe.


4) There could be scenarios where the caller computer may come as blank. In that scenario - you need to dig further on each domain controller on the netlogon.log which will give you the entire sequence from where a request came and what was the response from DC. You can search using the username on netlogon.log. The good part here is that this log will include the IP address and even the MAC (I believe so - but need to doublecheck).


Event ID 4648 refers to an explicit login. Can be an administrator trying to authenticate by using "RUN AS" or a drive mapping using a different credentials.


Goodluck !


Shaba


Paul WalshSystem Administrator

Author

Commented:
Hi,

Ok finally cracked it. For some reason it wasn't logging that account lock out on the target controller. It did however log event 4625 which listed the first DC. I checked the logs on the corresponding DC and the time stamps matched the 4648 error, confirming the first DC as the culprit. Account wasn't assigned to any services or scheduled task. Came across this: https://www.morgantechspace.com/2013/07/how-to-clear-windows-cached-credentials.html

and low and behold the problem account had a cached credential. Removed the defunct entry, ensured everything was still running as expected, and hey presto, strange problem fixed.

Thanks for all your help, I will split the points.

Paul
Zaheer IqbalTechnical Assurance & Implementation

Commented:
Ah ok yes I remember this. Apologies maybe I miss-read your question I didnt state that you were logging in as the account and then after a while it was getting locked out.

Thanks for the points.