Post by Brian LalondeShouldn't this be the developer's decision?
Yes, it is the developer's decision. We are simply making it disabled by
default and forcing developers to actively enable it.
Post by Brian LalondeIs that the right link? I don't see how allowing users to log in
when the security log is full has any relevance.
The security implication is that anonymous remote requests can be used to
fill the event log and cause the server to stop responding (for very legal
reasons -- failure to log to the event log results in lack of repudiation
which in itself is a security vulnerability/violation).
Post by Brian LalondeAs AspErrorsToNTLog is already off by default, I don't follow the
logic for further disabling it. Is event log performance significantly
worse than a database insert or appending to the IIS log?
I would say that the prior design (allowing toggle of ASP Errors to event
log instead of the normal log file) was flawed from a security perspective,
so IIS6 is merely fixing it the right way (see my suggestion below).
Furthermore, the Event Log locked itself down from anonymous/unprivileged
event logging on WS03, so that is another change.
Post by Brian LalondeHere's what I'm missing: when I get a support call from a user,
they will not have the detailed error (either we hide it, or they
don't record it), so I used to be able to audit the error because
all errors were stored persistantly. Now, I have no auditable
error log.
How about using the web log file? You do log requests to your server(s),
correct? All ASP errors are quite identifiable from the web log file, and
it includes the offending URL as well as ASP error number (the same info you
get with AspErrorsToNTLog). I'm sure with normal web logging plus Log
Parser to query/search your log files, you can find your error information
just as fast and and with less security implications. I realize that this
method is "different" than what you have gotten used to, but it should be
comparable so please give it a try.
Log Parser 2.2
http://www.microsoft.com/downloads/details.aspx?FamilyID=890cd06b-abf8-4c25-91b2-f8d975cf8c07&displaylang=en
--
//David
IIS
http://blogs.msdn.com/David.Wang
This posting is provided "AS IS" with no warranties, and confers no rights.
//
"Brian Lalonde" <***@stcu.org> wrote in message news:uWE$***@TK2MSFTNGP12.phx.gbl...
Shouldn't this be the developer's decision?
Is that the right link? I don't see how allowing users to log in when
the security log is full has any relevance.
As AspErrorsToNTLog is already off by default, I don't follow the logic
for further disabling it. Is event log performance significantly worse
than a database insert or appending to the IIS log?
I'm not sure of the security implications of client-side debugging, but
I'd be surprised if they were any less dangerous than a theoretical DoS
attack that takes advantage of event log performance or concurrency issues.
However, determining errors during a formal debugging session is not
what I am interested in.
Here's what I'm missing: when I get a support call from a user, they
will not have the detailed error (either we hide it, or they don't
record it), so I used to be able to audit the error because all errors
were stored persistantly. Now, I have no auditable error log.
This is a big problem in that it takes significant resources to try to
reproduce a problem, particularly errors idiosyncratic to a peculiar
platform, e.g. a version of Mac IE that sends a Content-Type header of
application/octet-stream for an uploaded image file.
Post by Brian LalondeBy design. IIS6 does not have permissions to write to the event log by
default.
The reasons? Allowing remote, potentially anonymous requests the ability to
DoS the server is not acceptable by default. You will have to change
security settings to allow this behavior.
http://support.microsoft.com/?id=832981
ASP has had integrated debugging for quite some time now, supporting remote
and local step-through using a GUI debugger -- so I'm not certain what you
are missing.