"General access denied error" under IIS accessin..

Good afternoon,

I am hitting a rather difficult problem to fix. We have a component
server, COMSERVER, and a web server WEB-A and WEB-B. COMSERVER has been
around for some time, and so has WEB-A. We have a custom component on
COMSERVER with a role 'Local Users'. This role contains the IUSR_WEB-A
account, which allows WEB-A to access the components on the COMSERVER
machine. Both of these machines are Windows 2000.

Recently, we deployed a new web server, WEB-B, which is Server 2003.
Running the component Proxy installer, I installed the proxy COM+ app,
which in turn was automatically configured to talk to COMSERVER.

Creating a test.vbs script, I verified that with my own credentials I
was able to instantiate components from WEB-B. It worked.

Trying to instantiate that same component from IIS via. ASP pages yields
the following error in the event log:

DCOM got error "General access denied error " from the computer
<<COMSERVER>> when attempting to activate the server:
{F51AC338-115C-40F2-A261-481926F7DE1C}

The user that this error is associated with is 'IUSR_WEB-B', which is
the anonymous user account for IIS. This user has been added to the
same role as 'IUSR_WEB-A'. Also, on the component server, I have added
this user to the group that is allowed launch access to DCOM.

Oddly, when I run my test.vbs script using 'runas' with the IUSR
account, it works!!! Because I can successfully instantiate my component
with a VBS file and the IUSR_WEB-B account, I know that DCOM security
with respect to my target component is setup correctly. It's when this
component is instantiated through IIS and ASP that I get the 'General
access denied' error.

Also, when the error occurs, nothing is entered in the event log of the
component server. I believe this is normal. (I have failure auditing
turned on for both boxes)

So, if anyone can shed some light on my problem, I will be greatly
appreciative. I have a hunch it's to do with IIS intrinsics, but
haven't tested that. I know they are disabled on the component server.


Cheers!!
-Sean

Microsoft want to make Windows 2003 more secure, so they changed the way
they are sending anonymous account credentials, we have 2 solutions for
this problem

(1)Use the same Userid/password between these 2 machines (Recommended),Make
this user
id as anonymous user

(2) Or you can use domain account as an anonymous account

MORE INFO:
=============
The product documentation is pretty good about explaining the changes that
occurred IIS 6:

<http://www.microsoft.com/technet/treeview/default.asp?url=/technet/prodtech
nol/wind
owsserver2003/proddocs/standard/sec_auth_anonauth.asp>

Basically, the sub authentication stuff was removed by default on a clean
install - so you effectively have the "allow iis..." checkbox unchecked out
of the box. This means your metabase password needs to be correct.

This also dictates what kind of logon you get from IIS - with the subauth
logon, you got a network token (just like NTLM) and so an outbound request
would/should look like NTAUTHORITY\ANONYMOUS LOGON. Without the subauth
logon (allow iis... is unchecked/default in IIS 6), you get the logon type
based on what is specified in the LogonMethod metabase property which by
default is NETWORK_CLEARTEXT (which translates to the win32 logon type
LOGON32_LOGON_NETWORK_CLEARTEXT. In IIS5, this was INTERACTIVE by default.
With NETWORK_CLEARTEXT, you get similar behavior as interactive (server
can impersonate the client) but you can't actually logon
interactively at the console with this logon type.

Hope this helps!

Thank you,

Jackie Jaynes [MSFT]
Microsoft IIS
JackieJa RemoveThis @online.microsoft.com

Please do not send email directly to this alias. This
is our online account name for newsgroup participation only.

This posting is provided "AS IS" with no warranties, and confers no rights.
You assume all risk for your use. © 2001 Microsoft Corporation. All rights
reserved.