Identity: impersonate=True? Privlege missing?

This deals with .NET and IIS.

This issue has to do with security when accessing a web service anonymously and trying to write to appliication event log.

**** <identity impersonate="true" />
IIS anonymous account = domain\ProxyAccount

With the above setting when trying to write to the application event log I receive:
Source: security
Catagory: Privilege Use
Type: Failure Audit
Event Id: 578
Privileges: SeBackupPrivilege
User: ProxyAccount

I understand that SeBackupPrivilege is required by the RegSaveKey and RegSaveKeyExfunctions.

The thing I don't understand is when I use the following which is to hardcode the userName and password into the web.config I no longer see this error.

**** <identity impersonate="true" userName="domain\ProxyAccount" password="WhatEver" />


The goal is not to hardcode the username and password.
I have to get an explanation for management why using the domain account when not hardcoding it (impersonate="true": using the anonymous IIS) does not allow writing to the event log but when hardcoding the same domain account it does allow writing to the event log.
the "domain\ProxyAccount" does have the correct permissions on the server to write to the Event Log (file and registry).

I don't know but it seems like the hardcoded account gets the correct/all of the permissions and privleges but when impersonating the IIS anonymous account it does not.


Is there any articles on this that I am missing. I have been researching this and not finding a concrete explaination of why.

Also is there a fix for this issue.

Thanks!!

Just because you open a web browser as a particular user doesn't mean IIS is operating as that user. Unless you force IIS to authenticate the user IIS will operate in the Internet Guest user account, which won't have permissions to do stuff like write to the event log. The impersonate statement is how you force IIS to operate in a different user context.

What I have is a windows and another web service which comsumes the web service in question.
Authenication is set to Forms.
The other service consumes my web service which is set to allow anonymous in the location tag.
When this service consume mine with just the impersonate="true" without the userName and password I can see that it is using the "domain\ProxyAccount" which is set in IIS Anonymous (which has the correct permissions to write to the event log). When it tries to write to the event log I receive the error... I am able to do other function such as modify files on other shares, ect...
But when I had the same user "domain\ProxyAccount" into the identity tag then I am able to write to the event log.

What I need is provide an answer to management on why do we have to provide the userName and password in the identity tag when not using the userName which then uses the same identity to impersonate it errors out.

What is the difference hardcoding the userName and password and not hardcoding but allowing it just to use the IIS user (which is the same username and password).