Cannot open log for source {0} -- again

[craig.wagner@gmail.com]

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.

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

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

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Servic es\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@gmail.com> wrote in message
news:1112228459.477004.93530@o13g2000cwo.googlegro ups.com...

> 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.
>
> [url]http://support.microsoft.com/default.aspx?scid=kb;EN-US;Q329291[/url]
>
> Decide to use "First Approach" and go into registry to add new registry
> key:
>
> HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Servic es\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?
>

[craig.wagner@gmail.com]

> 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]

<craig.wagner@gmail.com> wrote in message
news:1112628613.231445.35550@f14g2000cwb.googlegro ups.com...
<snip>

> 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\Servic es\Eventlog\Application\RestrictGuestAccess
value?

>

>> 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.

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.

[craig.wagner@gmail.com]

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

>> I have since been able to determine that the offending element in the
>> whole thing seems to be the Guests group.

>
>Perhaps the
>HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Servi ces\Eventlog\Application\RestrictGuestAccess
>value?

Silly me, I was looking for an ACL somewhere. I'll experiment with this.

>Removing the guest restriction probably isn't the way to go either.

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.

>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.

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.

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.

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).

--
Craig Wagner, craig.wagner(at)comcast.net
Portland, OR

"Don't ban high-performance vehicles, ban low-performance drivers!"

[Nicole Calinoiu]

<craig.wagner@gmail.com> wrote in message
news:qa6551h7amul04i86agh7jv66l35nlsmmr@4ax.com...
<snip>

> 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
[url]http://www.microsoft.com/technet/prodtechnol/windowsserver2003/library/serverhelp/f6e01e51-14ea-48f4-97fc-5288a9a4a9b1.mspx[/url]
if you're interested in comparing the groups.

>

>>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.

>
> 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.

>
> --
> Craig Wagner, craig.wagner(at)comcast.net
> Portland, OR
>
> "Don't ban high-performance vehicles, ban low-performance drivers!"

[Craig Wagner]

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

>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.

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.

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

>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.

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.

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.

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.

--
Craig Wagner, craig.wagner(at)comcast.net
Portland, OR

"Don't ban high-performance vehicles, ban low-performance drivers!"

[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


"Craig Wagner" <craig_d_wagner@hotmail.com> wrote in message
news:ukfa51dvep3bfd5cmfrk0547rvo3p9j1ii@4ax.com...

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

>>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.

>
> 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.
>
> Now what if there are no other apps running on the server? This is the
> only
> application.
>

>>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.

>
> 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.
>
> 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.
>
> 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.
>
> --
> Craig Wagner, craig.wagner(at)comcast.net
> Portland, OR
>
> "Don't ban high-performance vehicles, ban low-performance drivers!"

[Nicole Calinoiu]

"Craig Wagner" <craig_d_wagner@hotmail.com> wrote in message
news:ukfa51dvep3bfd5cmfrk0547rvo3p9j1ii@4ax.com...

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

<snip>

> 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.

>>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.

>
> 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.

>
> --
> Craig Wagner, craig.wagner(at)comcast.net
> Portland, OR
>
> "Don't ban high-performance vehicles, ban low-performance drivers!"