Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I want to setup basic authentication on a virtual directory (in IIS6). It looks as if a malicious user can use the dialog (uid/pwd challenge) to try and login with a domain account and lock this account through failed attempts (so you could lock user and service accounts, which is not good). Is there a way around this behavior? I tried setting the default domain to the local machine and use a non - AD account, but this didn't help.

Thanx in advance!

share|improve this question
If you disable the lockout then you will be giving an evil person a method to be able to brute-force your passwords. Perhaps you should be looking for some IDS type solution that will block the IP after excessive failures. – Zoredache Feb 25 '11 at 17:01
I thought maybe there would be a way to prevent IIS from accessing the AD at all, just have is validate against local users.. – Syg Feb 27 '11 at 8:55

You should try this addon: It will dynamically block IPs after x-number of failed logins.

share|improve this answer
will do, thanx! – Syg Mar 8 '11 at 14:20
This tarpit method rocks. It is also included in Windows Server 2012. I like this method much better than relying on account lockout. A public facing website with Windows Authentication enabled and domain Account Lockout gives a hacker the means to hold all your accounts in a locked state. – Brain2000 Aug 7 '12 at 22:26

This issue applies to any system, Windows or otherwise. I can create a simple program that will lockout every account on every AD domain in an organization, the impact would be huge, and it would be very difficult to recover from such an attack. The only thing required is a list of usernames/domains, which are available to anyone who logs on the network.

Simply put, if your passwords are so weak that they can be brute-forced, you're problem isn't account lockout.

Here are some perspectives from various sources at Microsoft:

"Bad Password Threshold is set too low: This is one of the most common misconfiguration issues. Many companies set the Bad Password Threshold registry value to a value lower than the default value of 10. If you set this value too low, false lockouts occur when programs automatically retry passwords that are not valid. Microsoft recommends that you leave this value at its default value of 10. "

Troubleshooting Account Lockout

What should I set account lockout to?

"You should turn it off. Account lockout is a feature that locks out an account after a certain number of attempts to log on with an incorrect password. It is designed to protect the computer against weak passwords. The problem is that weak passwords will eventually fall to an attack anyway, regardless of account lockout. The smart attacker will simply modify the attack in such a way as to not trigger the account lockout. A weak password will resist longer against such an attack when account lockout is used, but it will still eventually be broken."

"In addition, account lockout makes it trivial for a less sophisticated attacker to disable the computer completely. A simple batch file can be used to lock out every account on the computer, thereby crippling it. Account lockout, while designed to protect against weak passwords, instead create a condition where a trivial denial of service attack is possible."

Frequently Asked Questions About Passwords

share|improve this answer
Thanx for that. I'm not in a position to change the security policy, but this will support my attempt ;-). Are service accounts configured differntly in AD to prevent lockout evil doers? Cause that is a show stopper in any case I would say? – Syg Feb 27 '11 at 9:06

Having a user account locked because of a malicious user is annoying. Having a user account compromised because of a malicious user is quite bad.

The better way to handle this is to set a policy to:

  1. Lock an account after several unsuccessful attempts to authenticate (5 tries?)
  2. Unlock the account after some time (15 minutes?)

This way you can prevent both a malicious person to brute force your password and not bother too much a legitimate users that would have lock his account.

And service accounts should not be able to login through your web services but should be restricted to log only as tasks or services (this is also set using GPOs).

share|improve this answer
I think this is also the microsoft recommended solution, so this might be the way to go. Question in regard to your last line: in AD I can prevent service accounts from being locked out by configuring them differently? – Syg Feb 27 '11 at 8:58
Yes you can. You can either apply the GPO enforcing password rules on the OU containing only physical user's accounts or apply it to the whole domain (default GPO) and block inheritance on the OU containing only services accounts. – Benoit Feb 28 '11 at 10:46
In most cases, you're wrong. Prior to server 2008 R2, password policies can only be applied to the entire domain, not OUs. If all DCs are running 2008 R2 and the domain is set to 2008 R2 mode, then you can do what you're saying. Otherwise, you need separate domains to do separate password policies. – Jason Berg Mar 5 '11 at 21:04

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.