User account lockout from OWA login attempts

Here's the situation:

Single Exchange 2003 Enterprise server in the network running OWA.  We have account lockout policies in place so that after 5 failed attempts to login, the user ID is locked out.  Is there a way to prevent a denial-of-service attack from a malicious user from locking out the domain account?  In other words, I know a user's ID; but not their password and I hate them.  So, I intentionally try to log into their account 5 times with a bad password causing their domain ID to lockout.

I was trying to determine whether I can set some sort of lower limit (say 3 failed attempts) that would somehow lock the user out of OWA so that they would not be locked out of the domain they belong too; but haven't found anything remotely like that.

I looked at; but that seems like a bunch of trouble to go to simply to prevent this issue.

Anyone doing anything like this?

Who is Participating?
SembeeConnect With a Mentor Commented:
Thats what password lock is for.
Most attackers on a Windows domain don't bother with individual user accounts anyway. There is only one target - the administrator account. As it doesn't lock out it is perfect for brute forcing. The other accounts might get a casual attack, but that is all.

There is very little you can do.
What is the difference between someone doing it out of spite and someone doing to try and guess the password?

If I have a significant number of users who work out of hours then I will have the accounts reset after a set amount of time (30 minutes) so that they can try again later.

Manfre7874Author Commented:
There's no difference at all and I kind of expected that answer.  I just wondered if there was some methodolgy for preventing a DOS attack on OWA that I was unfamiliar with.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.