Exception Management App Block - System.ComponentModel.Win32Except

0 views
Skip to first unread message

Steven

unread,
Mar 31, 2005, 2:35:03 PM3/31/05
to
Hi all,

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.

Regards,

--
-Steven

Steven Cheng[MSFT]

unread,
Apr 1, 2005, 3:42:37 AM4/1/05
to
Hi Steven,

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
,yes?

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.

Steven Cheng
Microsoft Online Support

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

Steven Cheng[MSFT]

unread,
Apr 4, 2005, 9:17:03 PM4/4/05
to
Hi Steven,

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.

Thanks,

Steven

unread,
Apr 4, 2005, 11:15:01 PM4/4/05
to
Hi Steven,

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!

Regards,

Steven

Steven Cheng[MSFT]

unread,
Apr 5, 2005, 5:23:54 AM4/5/05
to
Thanks for your followup Steven,

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.

GOOD luck!

Steven

unread,
Apr 5, 2005, 10:25:11 AM4/5/05
to
I am actually not having as much luck in Win2k3. I have <identity
impersonate="true" /> in my web.config file. I have added the IUSR_xxxxxx
account to the Users group, and given it access in the registry but i am
still getting the same error. Any ideas?

Steven Cheng[MSFT]

unread,
Apr 6, 2005, 6:34:26 AM4/6/05
to
Hi Steven,

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

Thanks,

Steven

unread,
Apr 7, 2005, 11:43:01 AM4/7/05
to
I don't think the problem is with the EventSource. It works fine when the
IUSR_xxxxx account is a member of the Domain Admins group, but not when it is
only a member of Domain Users, even though the IUSR_xxxxxx account has Full
access to the entire HKLM\System\CurrentControlSet\EventLog key (and all the
children). What am I missing here?

Thanks,

Steven

Steven Cheng[MSFT]

unread,
Apr 8, 2005, 2:56:45 AM4/8/05
to
Thanks for your followup Steven,

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,

Steven Berkovitz

unread,
Apr 10, 2005, 3:47:04 PM4/10/05
to
Hi Steven,

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

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
http://www.microsoft.com/technet/prodtechnol/windowsserver2003/library/ServerHelp/1d920fd7-aac5-42a5-b92d-28ee7a30bc91.mspx
says "This security setting affects only computers running Windows 2000,
Windows XP and Windows Server 2003".

Any ideas would be appreciated.

Thanks,

Steven


"Steven Cheng[MSFT]" <v-sc...@online.microsoft.com> wrote in message
news:cIjT3gAP...@TK2MSFTNGXA01.phx.gbl...

Steven Cheng[MSFT]

unread,
Apr 11, 2005, 5:01:28 AM4/11/05
to
Hi Steven,

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
impersonate="true" />)

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 Berkovitz

unread,
Apr 11, 2005, 12:00:16 PM4/11/05
to
This doesn't really explain why it works if IUSR_MACHINE is a member of the
Domain Admins group. There must be an ACL somewhere. What about the
HKLM\System\CurrentControlSet\Services\EventLog\Application\CustomSD value?

"Steven Cheng[MSFT]" <v-sc...@online.microsoft.com> wrote in message

news:dd5mUUnP...@TK2MSFTNGXA01.phx.gbl...

Steven Berkovitz

unread,
Apr 11, 2005, 12:39:06 PM4/11/05
to
I have found a solution to this problem. Append the following to the
CustomSD value to give all authenticated users write access:

(A;;0x0002;;;AU)

Steven Cheng[MSFT]

unread,
Apr 12, 2005, 1:33:55 AM4/12/05
to
Hi Steven,

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
(A;;0x0002;;;BA),

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
Server 2003
http://support.microsoft.com/kb/323076/en-us#2

#SID Strings
http://msdn.microsoft.com/library/en-us/secauthz/security/sid_strings.asp?fr
ame=true

Hope also helps. Thanks,

Reply all
Reply to author
Forward
0 new messages