Bot-PC Being Locked Out
Connecting to our Windows 2008 R2 terminal server, we have a Bot-PC dedicated to running scheduled tasks.
Every hour it boots itself and starts its one-hour cycle of tasks.
I tweaked the PC registry for its auto-login to the domain.
It then has a shortcut in the Startup folder than triggers an RDP session.
It seems that ever since I changed our admin password that it keeps being locked out by the system.
Of course, that could be a coincidence.
I have to go to AD and Unlock the account a few times per day.
Maybe it's every hour, I've only just today started checking hourly.
I’m not sure what logs to look at or where to check first?
All tasks seem to be working, so I don't think I missed any credentials (as soon as I unlock the account all tasks work, including the RDP shortcut).
S.
Every hour it boots itself and starts its one-hour cycle of tasks.
I tweaked the PC registry for its auto-login to the domain.
It then has a shortcut in the Startup folder than triggers an RDP session.
It seems that ever since I changed our admin password that it keeps being locked out by the system.
Of course, that could be a coincidence.
I have to go to AD and Unlock the account a few times per day.
Maybe it's every hour, I've only just today started checking hourly.
I’m not sure what logs to look at or where to check first?
All tasks seem to be working, so I don't think I missed any credentials (as soon as I unlock the account all tasks work, including the RDP shortcut).
S.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Michael Pfister
Check all the scheduled tasks and scripts it starts via auto start if it contains username/password. Sysinternals Autoruns is a good tool to check all possibilities an autostart script/program could have been hidden.
Check for hardcoded admin password as such manual changes can cause unintentional lockout. I am thinking if you referring to local or domain admin but should be domain admin since you saw that lockout from concerned machine.
Suggest looking at the event log to verify the details of the machine and user. The eventid 644 or 4740 will indicated user account was locked out after repeated logon failures due to a bad password.
The following tools are useful to help you to isolate and troubleshoot lockout issues from AD and client end.
http://www.microsoft.com/en-us/download/details.aspx?id=18465
Suggest looking at the event log to verify the details of the machine and user. The eventid 644 or 4740 will indicated user account was locked out after repeated logon failures due to a bad password.
The following tools are useful to help you to isolate and troubleshoot lockout issues from AD and client end.
http://www.microsoft.com/en-us/download/details.aspx?id=18465
ASKER
To mpfister, I installed and ran EventCombMT with your document link's settings. I selected a limited time range of about an hour during which a new lockout occurred at least once.
I couldn't decipher anything from reading the logs so I attached them.
EventCombMT.txt
BORDENSRV-Security_LOG.txt
I couldn't decipher anything from reading the logs so I attached them.
EventCombMT.txt
BORDENSRV-Security_LOG.txt
Looks like from the Logon Type 4, it is a batch job that executes a scheduled task. Possibilities to generate a logon failure event includes
- attempts for guess the password of an account through scheduled tasks. This task may also be using accounts on a (or to map to a) file share serve that failed.
- administrator entering the wrong password for the account at the time of task creation or from the password of an account being changed without modifying the scheduled task to use the new password.
Disable all scheduled task to see if any error and may be some other program running too. Other shared
- attempts for guess the password of an account through scheduled tasks. This task may also be using accounts on a (or to map to a) file share serve that failed.
- administrator entering the wrong password for the account at the time of task creation or from the password of an account being changed without modifying the scheduled task to use the new password.
Disable all scheduled task to see if any error and may be some other program running too. Other shared
This Event is usually caused by a stale hidden credential. Try this from the system giving the error:
From a command prompt run: psexec -i -s -d cmd.exe
From the new DOS window run: rundll32 keymgr.dll,KRShowKeyMgr
Remove any items that appear in the list of Stored User Names and Passwords. Restart the computer.
ASKER
btan,
Assuming you wanted this run on the terminal server, I'm getting "psexec is not a recognized command".
S.
Assuming you wanted this run on the terminal server, I'm getting "psexec is not a recognized command".
S.
ASKER
I also installed alockout.dll and ran appinit.reg on both the BOT-PC and the terminal server and boot both last night. Today, after multiple locks, there is still not Alockout.log file being created. Notable, no winnt\debug directory exists on either machine, so I assumed to look in windows\debug but found no log files. I'm now wondering if I was supposed to install this tool on the server where Active Directory is running?
Psexec is a standalone exe which you can find in sysinternal..for the lockout tool you need to have it in the AD.
https://technet.microsoft.com/en-us/library/cc738772(v=ws.10).aspx
https://technet.microsoft.com/en-us/library/cc738772(v=ws.10).aspx
ASKER
I just went through every task on every server and then remembered that our old mail server is still online. I found a group of tasks being run by user Robot. I deleted them all. They had likely been running with valid credentials before the recent password change but were not executing anything since the target files had been moved. I won't be sure of this being the fix until we cycle through several hours without any locking. I'll be back.
ASKER
That was the fix. Now to award points. The last time I tried to spread the wealth the moderator gave me crap for arbitrarily, in their opinion, awarding points, even though I clearly stated the fix was mine but with guidance. To avoid the crap, I'm going back and awarding all points to the first person to mention old tasks/bad passwords. Thanks to all.
S.
S.
ASKER
In the end, I reentered every password on all tasks being executed by the user being locked out. Ultimately the offending tasks were on an old mail server that I had forgotten was still online.