We’ve been having some interesting issues at work recently with the account lockout that has been enforced upon us by our auditors. Like most places, we use an account for services that run on the servers. Now, on one of our servers somewhere in the galaxy, the password is wrong. This causes the account to lockout after a while, meaning most of the others fall over. I’ve managed to find out which server it is – I think – yet I can’t see anything actually logging on as the account other than the evidence in the eventlog. Strange.

Another problem related to the above, is that our proxy (a “BLOXX” ) uses the service account to authenticate users. This caused huge problems. It give no indication that the account is locked, the proxy instead repeatedly asks the user for their password. Obvisouly the service desk assume the user is rtyping their password incorrectly, which –  lets face it – is probably quite likely… Eventually we discovered that the proxy must use the service account to query AD in some way, and if that account was locked, it would reject any authentication.

To add yet more fun to the problem with implementing the lockout is that I can’t get rid of it. Nope. It won’t go.  I’ve unset everythign in the policy, confirmed it in RSOP, yet if I look in adsiedit.msc I can clearly see that the information is still set there. If i set the lockout information again, I can see it change in adsieit. Removing it again, means that it stays there. I’ve no idea how to set it to “not configured”, so I’ve set it to a high value. Ultimately, the lockout isn’t there to punish users, it’s there to stop the domain admin accounts from being brute forced.

The resolution we’ve found is to use a different account for the bloxx and to manually edit LockoutThreshold in adsi edit to keep things nice and happy