Problem with Event Log (long)

[Dan Brill]

Hi,

I'm sure this issue has been covered before but after searching around I
can't find anything which deals with quite the same set of circumstances or
suggests an optimal solution.

The issue is, broadly, that when I try to write to the Windows Event Log
from ASP.NET code I receive a System.Security.SecurityException ("Requested
registry access is not allowed").

Originally, I thought this was a problem with creating event logs and event
sources, so I wrote a custom installer (an EventLogInstaller) which I could
use to create an event log called 'MyLog' and a source called 'MySource' at
deployment time. This was following the instructions at
http://support.microsoft.com/default.aspx?scid=kb;en-us;329291.

This works great and now I can navigate to
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Eventlog and see a key
called 'MyLog' with a sub-key called 'MySource'. So far so good. The problem
is that I still can't write an entry.

I've examined what is happening from the perspective of the Registry (using
Regmon) and I can see that when I execute code such as
EventLog.WriteEntry("MySource", "MyMessage"), all of the keys representing
event logs are searched (possibly sequentially) for an event source called
'MySource'.

Although the ASPNET account has enough permissions to access 'MyLog' and
'MySource' (and I can even execute EventLog.Exists("MyLog") successfully) it
isn't even getting that far because as soon as the search hits the Security
log then the process fails with an ACCESS DENIED error.

I would expect the behaviour to be to ignore such errors unless I actually
want to write to that log (which I don't) and to continue searching until
either the correct source or nothing is found. Unfortunately, it seems to
just fail as soon as it receives an ACCESS DENIED for *any* log.

I had hoped to get round this by creating an instance of the EventLog class
rather than using its static methods, like this:

EventLog el = new EventLog("MyLog", Environment.MachineName, "MySource");
el.WriteEntry("MyMessage");

However, even this fails (on the second line) because the EventLog
constructor doesn't appear to do anything with the source except store it.
It also doesn't limit the search (described above) to the scope of 'MyLog'
and continues to bail on the Security key.

Now, I realise that there are a few ways around this problem, all of which
would probably require adding more code to my custom installer (since I want
the process to be automated):

1) Change the account under which the ASP.NET Worker Process runs to one
with suitable permissions (this seems like a manual process to me).
2) Change the permissions in the Registry either for the Security key only
or for its parent key (presuming that it inherits, I haven't checked).

I really wanted to know if there was a simpler way to do this or a
work-around because, to me, the behaviour seems bizarre. Also, what would
happen if another application created a log with extremely restrictive
permissions - would my code then bail attempting to access that log's key?

Any assistance would be appeciated!

-dan
(e-mail address removed)

 

[Steven Cheng[MSFT]]

Hi Dan,

Welcome to ASP.NET newsgroup.
As for writing Event Entreis into CustomLog. As far as I known, the
ASP.NET's default process idenity (machine\aspnet on win2k or
NetworkService on IIS6 WIN2K3) has the proper permission to write entry
into CustomLog (as long as the log exists). I think the problem you
encountered is likely to be a environment specific issue.

Are you using impersonate in your app or what's the executing account of
your asp.net application? As for the
===============
it
isn't even getting that far because as soon as the search hits the Security
log then the process fails with an ACCESS DENIED error.
==================

you mentioned, it may be caused by your asp.net process identity dosn't
have read permission to the Security log. You can try granting the read
permission to the asp.net 's executing account since this is necessary if
we need to write custom log.

In addition, here is a kb article which describing the general security
setting for eventlog which maybe helpful for you to troubleshooting
EventLog's permission problem though it may not suit this issue:

#How to set event log security locally or by using Group Policy in Windows
Server 2003
http://support.microsoft.com/default.aspx?scid=kb;en-us;323076

If there are anything else we can help, please feel free to post here.
Thanks,


Steven Cheng
Microsoft Online Support

Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)

 

[Dan Brill]

Hi Steven,

Thanks for your reply.

The ASP.NET Machine Account is running as a member of the Users group only.
I know that it can write to the custom event log but, unfortunately, this is
broken by the fact that it cannot read the Security log. If I give the
ASP.NET process the right to read the Security account then everything
functions correctly (it can now write to the custom log). This appears to be
because an attempt to write to an event log seems to fail if the process
doesn't have read permission for *all* of the event logs. You're correct
that I can manually change the permissions here - it is just that having to
give access permissions to a event log (Security) that I have no desire to
read, just to be able to write to my custom event log seems
counter-intuitive. It also doesn't seem very secure - I only want my
application to have permissions for the custom event log not access to any
of the others (but I'd settle for the defaults).

Also, I really just expected this to work but it is begining to look as if I
have to add more custom code to the installer in order to set particular
permissions for registry keys, or amend group policies, or whatever. As you
suggest, this may well be environment specific otherwise I would have
expected many people to be beating their heads against this issue. It is,
however, difficult to diagnose why my environment (a pretty clean XP
install) would be much different from anyone else's.

-dan

 

[Steven Cheng[MSFT]]

Thanks for your followup Dan,

Yes, read permission is a very basic access permission and by default the
local users group will have this permission. So I'm not sure why your
machine's users group didn't have that permission. Anyway, in most cases,
you can assume that the target box should have read permission granted to
the users group and you can do some further verification in your installer
if necessary.

Thanks,

Steven Cheng
Microsoft Online Support

Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)

 

[Dan Brill]

Steven,

Thanks a lot for your assistance. You are correct - I went to deploy on the
production server and it already had the correct registry permissions set.
Thanks again.

-dan

 

[Steven Cheng[MSFT]]

Sounds great Dan!,

Good Luck! :- )

Steven Cheng
Microsoft Online Support

Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)