Avoiding account lockout policy (pre Windows 2008)

Over the last year or so a few instances have come up with service accounts getting locked out and the owners being unhappy. Usually everyone wants to know if it is possible to set their account so it can't be locked out. Prior to Windows 2008 AD fine grained password policies and managed service accounts, the answer typically is No. The security guy in me says No way should this be done even if it is possible. But to be fair, lets look at technical feasibility.

Lockout policy/Password policy is a domain wide setting, for domain accounts it follows what policy is applying to the domain controllers. For domain member local accounts it follows whatever policy is pushed to the client system. But, there is in fact a way to avoid lockouts, though it is a bit unorthodox. Let me give some background then I will mention the how-to.

A few weeks ago, one morning I had this idea pop into my head that it would be interesting to explorer the security implications of computer accounts in the enterprise (This means computer objects...people like to mix "computer accounts" to mean user accounts). Since computer accounts have passwords and can access remote resources, I thought there may be some interesting things to find.

So on this mission, I first looked at what can you do with computer accounts. Normal tools, like ADUC, dsmod, etc don't let you set a computer account password manually. NET USER and admod will allow this however. So I created my object, reset the password and started messing around. I first found that you can't log in interactively with computer accounts and it gives you an error saying that a policy is blocking this. I granted all possible user rights to the account, and added to administrators group, but no help there. If you look at the UserAccountControl attribute, there are flags that indicate the type of account. There is also a SamAccountType attribute on users and computers. The value of this is slightly different, but you can't edit this attribute as it is controlled by the SAM. UserAccountControl however can be edited. There is some security implications with this related to computers that I will get into some other time.

Anyways, if you look at the values in the linked article above you can see these flags. You can't have both set at the same time, but you can change the computer object's useraccesscontrol level to that of a normal user. Coincidentally, this causes the SamAccountType value to be updated to match a user object as well.

Values:
0x1000 workstation trust account
0x0200 normal account

So I changed my test object's UAC to 0x0200, I retried local login and it worked fine. Also using it for scheduled tasks, services, etc were all working now as well. Previously I could only use the account to map network drives.

So this was an interesting discovery, but I took this a little further on login attempts. I noticed with repeat failed passwords my bad password count kept going up, well over the lockout threshold set in my test domain. When my normal user objects were getting locked, my computer account kept taking attempts over and over. Providing the correct password after multiple failures that should have resulted in lockout showed that I could still log in. So apparently the mechanism used to lock accounts ignores computer objects, doesn't look at UAC for them, and doesn't look at the SamAccountType. Given this, we can create an unlockable "user" by creating a computer object.

For those who may worry now about brute force password attempts on computer objects, given that most forms of logins are blocked for a standard account, and the auto generated password length is significantly high, the risk is low. For those that have pretty loose computer object creation policies, it may be time to start thinking in a different way. In the near future, I hope to provide some better details on the overall security implications of computer objects.