I am using the Microsoft Exception Management App Block (Enterprise Library)
with ASP.NET. When I try to publish an exception I get a
System.ComponentModel.Win32Exception: Access is denied exception on both my
WinXP development machine and both of my Win2k3 production servers.
I have followed the directions found at
http://support.microsoft.com/default.aspx?scid=kb;en-us;842795 however the
problem still occurs. I have identity impersonation turned on, and have even
given the NETWORK SERVICE account full permissions to the EventLog key.
Any assistance would be appreciated.
Welcome to ASP.NET newsgroup.
From your description, you're getting the Access Denied WIN32 exception
when using the Enterprise Library's Exception Handling Application block
I'm sure you're using the LoggingHandler , and specifying some eventlog
entry to log into? Is the problem occurs just when you use the default
logging setting to log some entry into the Application eventlog?
Also, as you mentioned that you're using impersonation in your asp.net
application, did you impersonate the client user's idenity or a fixed
account. Is it possible that the impersonated account dosn't have the
proper permission to access the eventlog? I suggest that you turn off the
impersonate and switch your process identity to "LOCAL SYSTEM" and test
again to see whether it works. This can ensure that the problems is caused
by account permission issue.
If there is any further findings, please feel free to post here also.
Microsoft Online Support
Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
How are you doing with your Application Block app, have you got any
progress or figured the problem out? After some further test, I think there
is also another possible cause ----- the preinstalled services( eventlogs,
WMI events....) which is necessary for the Logging and instrumenation
block to log monitor results.
After we intalled the EnterpriseLibrary, there will exist an "Install
Service" menu item in the Start Menu of the Enterprise Library. Have you
installed those services ? If the services has been installed, there will
exists some other EventLog entries in the Application EventLog, and when
there is access denied error when accessing registry, we won't get the
error directly on the page, but can find some eventLogs under those entry.
Please have a check to see whether this is the problem.
Thank you for your follow up. Your second reply actually reminded me to
tinker around with this a bit. I found out that I was able to solve this
problem on my Windows XP machine by adding the IUSR_xxxxxxxx account to the
local Users group >and restarting IIS<. The account was previously only a
member of the Guests group. An IIS restart was required to get this working.
I am going to test on my Win2k3 servers tonight, but I suspect this will
solve the problem there too.
Thanks for your help and quick responses!
Glad that you've made greate progress on this issue. I think your finding
on this problem is correct, since you're using impersonate, (and you're
allowing anonymous access to your web application also ,yes?). Then, the
default anonymous account (IUSER_Machine) will be used as the asp.net
request's executing account, then if you're access registry in asp.net
code, the permission will depend on the IUSER_Machine's access privileges.
I'm sorry to hear that the problem still occur on your W2K3 server.The
problem is likely with the EventSource. Are you loging to a Custom EventLog
or the exist Application EventLog? And is the EventSource an existing one
a not existing one? We can write to an existing eventSource just with
Users permission, the permission problem maybe caused by the account can't
create the eventsource rather than write into an existing one. So I think
you can first verify that the eventSource you're writing into already
exists, then using the Logging application block to write entry into it.
(Creating an eventSource in a windows application and then try writing into
it in your asp.net web appliation).
Please feel free to let me know if you have any progress.
I think you're right. The problem is likely due to the IUSR_MACHINE
anonymous account, I've just done a test through impersonate through IIS
anonymous account and did repro the problem you mentioned(my former test is
using a local custom account). Currently I'll do some further research to
see what's wrong with the IIS account. BTW, is it ok that we use a local
custom account to replace the default anonymous account?
Anyway I'll let you know if I got any further results. Meanwhile, if you
have any new findings , also feel free to post here. Thanks,
I would perfer to resolve this with the IUSR_MACHINE account as I don't
really like changing things on my production servers unless I absolutely
I found a group policy setting that I think may be responsible, but I am a
bit confused because the documentation on the Microsoft website is
conflicting with the documentation in Windows 2003 Server. The policy is
under Security Settings\Event Log and is named "Prevent local guests from
accessing application log." The inconsistency is that in the Group policy
editor, the description says "This setting only effects operating systems
earlire than Windows 2003" while the documentation at
says "This security setting affects only computers running Windows 2000,
Windows XP and Windows Server 2003".
Any ideas would be appreciated.
"Steven Cheng[MSFT]" <v-sc...@online.microsoft.com> wrote in message
Thanks for the followup.
After some further tests, I think the problem is something limited on the
WIN2K3 server. In fact, not only the default IUSR_MACHINE, any account(
even a custom created local account) which has sufficient permission on the
eventlog will failt to write entry when configured as IIS virutual dir's
anomymous account and implicitly impersonated in the ASP.NET.( <identity
So currently on W2K3 box, I think we have the following approachs:
1. Disable anonymous access for the IIS virutal dir and let the asp.net
running under the default process identity( or if impersonate, impersonate
the client user rather than the IIS's anonymous user).
2. If we still need to impersonate a certain account, we should use the
following configuration to specify the fixed account
<identity impersonate="true" userName="..." password="..." />
Anyway, since IIS anonymous acccount are too restricted, generally we'd
better avoid impersonate this account directly. (using the default process
idenity of asp.net is the perfered means).
"Steven Cheng[MSFT]" <v-sc...@online.microsoft.com> wrote in message
Thanks for your followup. I think the "CustomSD" key is just the things
we're looking for. That's the SDDL description of the windows eventlog
access. And as you mentioned, the (A;;0x0002;;;AU) experssion will grant
write access to the Authenticated users.
Also, the Buildin Adminstrators can also be granted through the
Then, when adding the IUSR_machine to local admin(not domain admin), it
will also have the write permission). The reason why I failed to get it
work is because I didn't do IISRESET after apply the new setting. So I
suggest you do a reset after you do any modification on the CUSTOMSD.
In addition, as for Domain Admins, i'm not sure on your specific
environment. But you can have alook to see whether the server's application
eventlog's CustomSD string contains the setting for Domain Admin group.(Is
is also possible that there is a group policy specified for domain admins).
Anyway, I also think using the (A;;0x0002;;;AU) to grant permission to
IUSR... is the best choice currently if you don't want to specify other
accounts as your asp.net's executing idenity.
The following reference has mentioned the eventlog security setting and the
wellknown sid strings:
#How to set event log security locally or by using Group Policy in Windows
Hope also helps. Thanks,