The Case of the Locked Domain Account
Posted by William Diaz on November 1, 2011
Account locks normally are not a big deal to troubleshoot. Often times it is a user typing in an incorrect password to the account they are trying to logon to too many times. Other times, it is being caused by expired or incorrect cached credentials being used to authenticate to some network resource. In the latter case, this is a simple matter of going onto the workstation that has been identified as one locking the account and removing the cached credentials.
In Windows XP, this can be done by going to Start > Settings > Control Panel > User Accounts > Advanced (or Manage Passwords for non-admins) > Advanced > Manage Passwords. Alternatively, you can just use the control userpasswords2 command.
From Stored user Names and Passwords window select the network location or url and delete it, or update with the correct logon info:
In this case, though, it wasn’t that simple. The account that was getting locked was a shared domain account that was used to logon to multiple workstations throughout the day. As a result, we were seeing this account getting locked from these various workstations. The account was specifically used by contract employees within the company in a remote office and I began to suspect that someone was inputting the incorrect password. I was reassured that that wasn’t the case but I needed to verify anyway. You can determine account logon types by reviewing the Security logs in the Windows Event Viewer of the system that locked the account. I reviewed all the workstations by looking at the last account lock in the Account Lockout Status Tools and comparing that with the workstation security log.
Here is an example starting with the lockout tool showing a couple bad password attempts:
This is cross-referenced with the workstation’s security logs, also showing bad username or password from the same time:
The Logon Type tell you what kind of logon method was used:
Type 2 – Interactive. This is akin to sitting at the workstation/terminal and typing in the credentials.
Type 3 – Network. You see this most often when connecting to shared folders, printers, or other network resources.
Type 4 – Batch. Usually scheduled tasks.
Type 5 – Service. Services can run in the context of any user account.
Type 7 – Unlock. You see this when a system is unlocked.
Type 8 – Network Clear Text. I don’t think you will see this too often (or ever these days). When passwords are sent across the network in clear text, you will see this.
Type 9 – New Credentials. You will see this when you use the RunAs command with the /netonly switch. Otherwise, it is recorded as a type 2 event.
Type 10 – Remote Interactive. Remote desktop, remote assistance, terminal services.
Type 11 – Cached Interactive. Cached logons, i.e. mobile/laptop users not connected to the network.
I remotely connected to the workstation that was most often locking the domain account. I started by looking for any obvious network shares, but none were mapped. I decided to look at the various network connections to and from the workstation and ran TCPView from SysInternals. Perhaps the culprit might reveal itself here, and interestingly enough, I saw an established connection to some server that did not follow our company’s server convention name (office-role.domainname.com):
Seeing things like this can be kind spooky. Who knows, this could be some rouge server doing something malicious. A ping returns a familiar subnet, though, for server-009271, which I recall seeing for all printers on the 39th floor where the group that uses this account is stationed. Looking at the printers the workstation is connected to confirms this is the IP of a printer:
I began to assume that print jobs to this specific printer were causing the domain account to become locked. To test this assumption, I printed a test page to this printer and notice two failed logon attempts. After 3 print jobs, 6 bad password attempts have failed. Our accounts lock after 5 failed attempts. No other printers the workstation/account is connected to exhibit this issue. To further isolate this as either an account issue or a printer issue, I connect to the printer from my own workstation and sent a test page, with the same two bad password attempts recorded in the Account Lockout Status utility.
Sure it was printer issue, I asked the local techs in that office to check the printer setup and confirm any authentication settings. After some back and forth, we find that printer preferences for this printer are not correctly authenticating print requests:
Checking the option Use Windows Login resolved the issue with the bad passwords being sent from the domain account.