[quoted text, click to view] On Mar 18, 7:33=A0am, "G" <gregstiger...@spamcop.net> wrote:
> Well, I'm posting because I don't understand what's wrong. If someone is
> trying to crack the Admin account, whatever they are doing depends on havi=
ng
> the Default Web Site up and running on this member server, because stoppin=
g
> that website stops these errors. I am guessing that the IUSR_SVR1 account
> somehow tries to use NT AUTHORITY\SYSTEM, causing the Logon attempt by
> MICROSOFT_AUTHENTICATION_PACKAGE_V1_0, whose Logon account is Administrato=
r.
> But maybe I'm misreading the Event Log.
>
> Bottom line, I just want these websites to work, without filling the Event=
> Log on the DC.
> ________
> Greg Stigers, MCSA
> remember to vote for the answers you like
Well, it makes sense that if someone is trying to crack tho Admin
account, they need *some* website which accepts authentication to be
running (so that IIS tries to logon for authentication using username/
password provided by the hacker). Thus, stopping the website stops the
entire logon process and hence the events.
FYI: Your guess is pretty much non-factual in all aspects. Let's look
at what are true.
Since you cannot stop hackers from trying to attack, and you have no
way for the web server to select who to allow authenticate (you don't
know the user until after authentication), there is nothing you can
configure in IIS to stop this.
Actually, I suspect that you have Administrator hardcoded in IIS
somewhere as the Anonymous user for a specific vdir and that password
has changed -- so everytime someone tries to anonymously browse that
vdir in the website, it causes IIS to attempt (and fail) to logon as
the Anonymous user (which is configured to be the Administrator) and
generate the event.
How Windows deals with this is to lockout a user account after so many
failed login attempts -- hence the events stop generating afte
reaching the lockout limit.
FYI: you have to accept that event logs will get filled with lots of
things and that you have to filter to find the right information. It
is literally impossible to avoid the event you mention because you'd
have to stop people from making incorrect logons, and that's obviously
never going to happen because you cannot control those people at all.
And since you're telling Windows "log those auth logon failures" and
there is no way to determine if someone accidentally or intentionally
enters the wrong credentials, there is no way to achieve your bottom
line unless you turn off authentication everywhere.
//David
http://w3-4u.blogspot.com http://blogs.msdn.com/David.Wang