Login retry delay for administrator

Account lockout works fine for normal userids but the administrator account
does not lock out. This allows hackers to remotely try dictionary attacks to
login.
My suggestion is to provide a retry delay parameter that kicks in after the
default account lockout limit is reached that is set to something like 1 to
60 seconds (default to 0 for existing behaviour) . It would allow anyone
with a keyboard to keep trying but would render a brute force automated
attack pretty useless since the time would increase dramatically for their
retries. Even better if the ip address captured in the 529 event log could
be the one address the delay is applied to so other automated and valid
logins continue normally. Renaming administrator account is one remedy but
this is suggestion for additional improvement.

----------------
This post is a suggestion for Microsoft, and Microsoft responds to the
suggestions with the most votes. To vote for this suggestion, click the "I
Agree" button in the message pane. If you do not see the button, follow this
link to open the suggestion in the Microsoft Web-based Newsreader and then
click "I Agree" in the message pane.

http://www.microsoft.com/communities...erver.security

Hello Tom,

You shouldn't work with the administrator account nor have it enabled. So
make sure to have more then one full administrator account with long/strong
passwords. Then set also a long strong password for the administrator and
DISABLE it.

Best regards

Meinolf Weber
Disclaimer: This posting is provided "AS IS" with no warranties, and confers
no rights.
** Please do NOT email, only reply to Newsgroups
** HELP us help YOU!!! http://www.blakjak.demon.co.uk/mul_crss.htm


> Account lockout works fine for normal userids but the administrator
> account does not lock out. This allows hackers to remotely try
> dictionary attacks to login. My suggestion is to provide a retry
> delay parameter that kicks in after the default account lockout limit
> is reached that is set to something like 1 to 60 seconds (default to 0
> for existing behaviour) . It would allow anyone with a keyboard to
> keep trying but would render a brute force automated attack pretty
> useless since the time would increase dramatically for their retries.
> Even better if the ip address captured in the 529 event log could be
> the one address the delay is applied to so other automated and valid
> logins continue normally. Renaming administrator account is one
> remedy but this is suggestion for additional improvement.

I GET IT!!! Now please note this is a suggestion.
Address your reply as to why the suggestion is bad or good.
I am not looking for workarounds. I think this is something that should be
done anyway.

"Meinolf Weber [MVP-DS]" wrote:

> Hello Tom,
>
> You shouldn't work with the administrator account nor have it enabled. So
> make sure to have more then one full administrator account with long/strong
> passwords. Then set also a long strong password for the administrator and
> DISABLE it.
>
> Best regards
>
> Meinolf Weber
> Disclaimer: This posting is provided "AS IS" with no warranties, and confers
> no rights.
> ** Please do NOT email, only reply to Newsgroups
> ** HELP us help YOU!!! http://www.blakjak.demon.co.uk/mul_crss.htm
>
>
> > Account lockout works fine for normal userids but the administrator
> > account does not lock out. This allows hackers to remotely try
> > dictionary attacks to login. My suggestion is to provide a retry
> > delay parameter that kicks in after the default account lockout limit
> > is reached that is set to something like 1 to 60 seconds (default to 0
> > for existing behaviour) . It would allow anyone with a keyboard to
> > keep trying but would render a brute force automated attack pretty
> > useless since the time would increase dramatically for their retries.
> > Even better if the ip address captured in the 529 event log could be
> > the one address the delay is applied to so other automated and valid
> > logins continue normally. Renaming administrator account is one
> > remedy but this is suggestion for additional improvement.
>
>
> .
>