Cannot open log for source {0} -- again

[craig.wagner]

I've done a ton of searching on this error and have not found any
solution that actually solves the problem.

My environment is Windows XP Professional with SP2. I'm using VS.NET
2003 and .NET Framework v1.1.

I created a brand new ASP.NET application to ensure that some other
aspect of my real app wasn't causing the problem. I put a button on the
form and added the following lines of code.

System.Diagnostics.EventLog log =
new System.Diagnostics.EventLog( "Application", ".", "aaa" );
log.WriteEntry( "hello" );

That resulted in the "Requested registry access is not allowed"
exception being thrown.

Did some searching and found this article.

http://support.microsoft.com/default.aspx?scid=kb;EN-US;Q329291

Decide to use "First Approach" and go into registry to add new registry
key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Eventlog\Application\aaa

Run the app again, now it logs correctly.

Go into web.config and add:

<identity impersonate="true" />

This should result in the application running under the identity of the
IUSR account, because that is the account that anonymous access is
configured to use.

Now I'm getting.

InvalidOperationException: Cannot open log for source {0}. You may not
have write access.

I tried adding the IUSR account to the Administrators group. Same
error.

Just for kicks, I configured the anonymous user as the local-machine
Administrator account. Everything worked.

I created a new account called blah. Put it in the Guests group and
made it the anonymous use. Everything worked.

Switched back to the IUSR account for the anonymous user. Failed.

What is it about the IUSR account that it won't work? Why would another
account that appears to be identically configured work?

 

[Nicole Calinoiu]

When you add an existing user to a group, the new group membership will not
take effect until the next time the access token for the account is
generated. For typical user accounts, this will be at the next login. For
the IUSR account, this is far more difficult to control. The best way to
ensure that the token is refreshed is to reboot the machine.

BTW, adding a user to the administrators groups is not exactly the safest
way to gain write access to the application event log...

 

[craig.wagner]

When you add an existing user to a group, the new

group membership will not take effect until the
next time the access token for the account is
generated. For typical user accounts, this will
be at the next login. For the IUSR account, this
is far more difficult to control. The best way to
ensure that the token is refreshed is to reboot the
machine.

I was finding this to be the case. I also found that doing an iisreset
after changing group membership solved the problem.

I have since been able to determine that the offending element in the
whole thing seems to be the Guests group. If the IUSR account is a
member of the Guests group, regardless of any other group membership
then writing to the event log fails (i.e. IUSR could be a member of
Administrators as well as Guests and it would still fail). I removed
IUSR from all groups and it worked. So apparently it has nothing to do
with the IUSR account but rather the Guests group. There must be an
explicit "deny" somewhere in the system for that group that is causing
the failure, but I have been unable to locate it with regmon, filemon,
and auditing.

BTW, adding a user to the administrators groups
is not exactly the safest way to gain write access
to the application event log...

I'm fully aware of that. Unfortunately, given the thundering silence
that is the response to this problem it becomes necessary to try
various combinations to see what might work so one can compare the
differences between account and group permissions in an attempt to
figure out exactly what is necessary to make it work. I realize using
the Administrators group or Administrator account is not a long-term
solution, it was simply another data point in trying to narrow down the
problem.

 

[Nicole Calinoiu]

I have since been able to determine that the offending element in the
whole thing seems to be the Guests group. If the IUSR account is a
member of the Guests group, regardless of any other group membership
then writing to the event log fails (i.e. IUSR could be a member of
Administrators as well as Guests and it would still fail). I removed
IUSR from all groups and it worked. So apparently it has nothing to do
with the IUSR account but rather the Guests group. There must be an
explicit "deny" somewhere in the system for that group that is causing
the failure, but I have been unable to locate it with regmon, filemon,
and auditing.

Perhaps the
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Eventlog\Application\RestrictGuestAccess
value?

I'm fully aware of that. Unfortunately, given the thundering silence
that is the response to this problem it becomes necessary to try
various combinations to see what might work so one can compare the
differences between account and group permissions in an attempt to
figure out exactly what is necessary to make it work. I realize using
the Administrators group or Administrator account is not a long-term
solution, it was simply another data point in trying to narrow down the
problem.

Removing the guest restriction probably isn't the way to go either. If you
really need to write directly to the event log from your web application
(which isn't necessarily a great idea in the first place), a better approach
might be to run your application under another user context. This could be
accomplished simply by mapping anonymous use of your applicaiton to another
user in IIS.

 

[Nicole Calinoiu]

From what I've been able to determine, the Guests group and the Users
group are
virtually identical, with the exception of being able to write to the
event log.
I seem to recall even seeing somewhere (and of course I can't find the
reference
now) that said something to the effect that Users and Guests had the same
privileges except for the Guest account, which was further restricted.

Not true. The exact differences depend on the platform, but you might want
to start at
http://www.microsoft.com/technet/pr...elp/f6e01e51-14ea-48f4-97fc-5288a9a4a9b1.mspx
if you're interested in comparing the groups.

The above doesn't make sense to me, for two reasons.

1. The way the app is set up, there is a global exception handler in
Global.asax. It sends the user to a generic error page. That page captures
the
exception and logs it. That way our IT Ops group can set up monitors on
the
event log and we can be proactive about investigating problems with the
site. I
don't see the problem. It seems to me plenty of applications log
unexpected
behavior to the event log so details can be captured for later
investigation.

Sure, but web applications are a poor candidate for writing to the
application log for security reasons. Even if you're only logging
exceptions, a malicious user of the web application could cause your event
log to either fill or dump (clearing old entries to make place for new ones)
simply by forcing exceptions, thereby exposing you to either a denial of
service attack (via log filling) or hiding of clues to other activities (via
log dumping). For this reason, you would be better off writing to a custom
log rather than the default application log. At least with this approach,
abuse of your web application won't affect the logging activities of local
applications. You should also select the fill/dump behaviour of your custom
log carefully since you'll still be subject to the DOS vs overwrite issue,
even if it's restricted to only the single application.

2. What difference does it make if I create a new account to run the
application
under or simply make IUSR a member of Users? Either way I've got an
account that
has the access it needs.

If you grant the permission to the IUSR account, all web applications that
run under this account will gain the permission. If you grant the
permission to a new account that is used for only your application, other
applications will still be unable to write to the log.

In effect, we have done #2 anyway. Our IT Ops group has set up the same
user on
each server in the farm (e.g. IUSR_TheWebUser, not the real name BTW).
They
could have called the account Bob, but they chose to use the IUSR prefix
for
whatever reason. That is the context in which the web applications (a mix
of
ASPNET and ASP) run. That way a consistent user is granted access to
external
resources (e.g. shares on the NAS).

That's fine if only your application (and/or others that also require the
same logging permissions) are run under this account. However, applications
that cannot be trusted to write to the log should not run under an account
with logging permissions.

 

[Joseph MCAD]

April 6, 2005

I haven't read all of this thread, but check the Web Application Cannot
Access Event Log 4/4/2005 in microsoft.public.dotnet.security. I have
already helped some one out there and it appears that everything is solved!


Joseph MCAD

 

[Nicole Calinoiu]

"Nicole Calinoiu" <calinoiu REMOVETHIS AT gmail DOT com> wrote:

So when you said that writing to the event log from a web app wasn't a
good
idea, what you really meant was writing to the default application event
log
wasn't a good idea.

Writing to a custom event log incurs less overall risk than writing to the
default application log, but I still wouldn't consider it to be a
particularly wonderful approach for many situations.

Now what if there are no other apps running on the server? This is the
only
application.

I suspect that you might other applications (e.g.: IIS) writing to the
application event log on your server.

Agreed. But every application running on the server is an in-house
developed
application, so they can all be trusted to write to the log and, in fact,
we
want them logging a subset of their activities and unhandled exceptions
should
they occur for troubleshooting and debugging purposes.

Today, every application meets these criteria. Tomorrow, something new may
be installed.

We could mitigate some of the potential for abuse by having each
application
(assuming there was more than one at some point) write to a different
custom
event log I suppose. But it seems to me the bottom line from this thread
is that
we just keep moving or mitigating the potential for trouble.

Yup. Personally, I would probably choose an alternate mechanism for
tracking application events. However, it's really a risk-management issue
more than anything else, and nobody else can specify your level or risk
tolerance for you....

And I purposely used the term "potential" twice, because we're a very
targeted
site used by our clients only. Yes, someone could stumble on it and try to
be a
dick and bring it down, but we're hardly worth the effort. We've had no
incidents in the past five years. Sure, ignorance is no defense, and it
isn't
the only thing we do to take steps to protect ourselves, but we also need
to
weigh potential against complexity.

As a trade-off between complexity and security, why not at least have all
your in-house apps write to a single custom log rather than the main
application event log? Besides avoiding the possibility of filling the main
log, you'll also gain the advantage of having all your applications' events
isolated in a single file that doesn't need to be filtered to eliminate
"noise" from other applications.