"Access Denied" when trying to connect to remote IIS server - C#

Question

I receive an "Access Deined" COMException when I try to connect to a remote IIS 6 server from my C# application that is running under IIS 5.1.

Any ideas? I am experiencing all the same issues with the original questions.

Update - 4/1/09

I found this solution (http://www.codeproject.com/KB/cs/Start_Stop_IIS_Website.aspx) that consists of a window application connecting to an IIS server to start and stop web sites. I am able to run it on my workstation and connect to the IIS server.

Ugh....why can I run this stand alone application but not my ASP.NET application?

Original

I receive an "Access Denied" COMException when I try to connect to IIS from a remote machine using the DirectoryEntry.Exist method to check to see if the IIS server is valid.

string path = string.Format("IIS://{0}/W3SVC", server);

if(DirectoryEntry.Exist(path))
{
    //do something is valid....
}

I am a member of an active directory group that has been added to the Administrators groups to the IIS server I am trying to connect to.

Has anyone experience this issue and know how to resolve it?

UPDATE:

@Kev - It is an ASP.NET application. Also, I can connect without an username and password to the remote server through IIS6 Manager.

@Chris - I am trying to connect to the remote server to display the number of virtual directorys and determine the .NET framework version of each directory. See this SO question.

@dautzenb - My ASP.NET application is running under IIS 5.1 trying to connect to an IIS 6 server. I can see fault audits in the security log for my local ASPNET account on the remote server. When I try to debug the application, I am running under my domain account and still get the Access is denied.

UPDATE 2:

@Kev - I was able to establish to create a DirectoryEntry object using the following overload:

public DirectoryEntry
(    
    string path,    
    string username,    
    string password
)

But, all of the properties contain a " threw an exception of type 'System.Runtime.InteropServices.COMException'" while I debug the app.

Also, the AuthenticationType property is set to Secure.

UPDATE 3:

The following two failure audit entries were in the remote IIS server's security event log every time I tried to establish a connection:

First event:

Event Category: Account Logon
Event ID: 680
Log attempt by: MICROSOFT_AUTHENTICATION_PACKAGE_V1_0
Logon account: ASPNET
Source Workstation:
Error Code: 0xC0000234

Second event:

Event Category: Logon/Logoff
Event ID: 529
Logon Failure:
Reason: Unknown user name or bad password
User Name: ASPNET
Domain: (MyDomain)
Logon Type: 3
Logon Process: NtLmSsp
Authentication Package: NTLM
Workstation Name: (MyWorkstationId)
Caller User Name: -
Caller Domain: -
Caller Logon ID: -
Caller Process ID: -
Transited Services: -
Source Network Address: 10.12.13.35
Source Port: 1708

Impersonation is set to true and the username and password are blank. It is using the ASPNET account on the remote IIS server.

Answer 1

If it is an identity problem, you could try setting your IIS 5.1 application to use Integrated Windows Authentication, and then add the following to you web.config on your IIS5.1 web site under system.web to enable impersonation.

<identity impersonate="true"/>
<authentication mode="Windows" />

Answer 2

Since this is an ASP.NET application, it runs in an Application Pool of IIS. This Application Pool runs using a specific user("Local System", "Network Service" or another user).

Does this user have enough rights to connect to a remote server ?

See MSDN for more info.

Answer 3

This looks like it may be a double-hop issue. If you are impersonating the current user of a website using NTLM, that impersonation is only valid on that server (your IIS 5.1 server in this case). If you try to connect to another server using the web site, you are actually going to have issues as it cannot pass the token to another server that was used during impersonation. The same is true if you are debugging your site through your machine, going to another box. Your local machine is authenticating you, but it cannot impersonate you to another server.

All of the solutions I have used in the past require you to hard code the app pool to use an account that has permissions, set the annony. account to a domain account with permissions on the other machine, or use a windows service running on the IIS 5.1 machine, under a domain account, to connect to the other server.

If you are using Kerberos, this wouldn't apply, but AD uses NTLM by default.

Answer 4

Where exactly are you trying to read too? Is it in under the same path as your application?

Answer 5

When I had this problem, I found that simply authenticating my self on a Windows file share solved the problem. From experience, I think that WMI/ADSI/COM doesn't have great support for not-already-authenticated users. I believe this issue occurs when you're not associated with a Windows domain.

Answer 6

If it is indeed a NTLM doublehop issue you could use the SETSPN utility to create service principal named instances for your target IIS servers.

Then you could go into Active Directory, and then allow the computer object (basically the NETWORK SERVICE or LOCAL SERVICE principals) to delegate its credentials to a correctly registered SPN.

Then you could hop-hop-hop all over the place! But, be warned! People can hurt themselves on sharp pointy things when you enable double-hop!

Good KB articles to read:

http://support.microsoft.com/kb/929650

Answer 7

I believe that DirectoryEntry.Exists silently ignores any credentials supplied and uses the creds of the authenticated user. This seems to match the behaviour you've described. For AD work, we never use it for this reason.

Answer 8

I'm sort of stumped at the moment as to why you can't get this working. There is a temporary work around you could try. When instantiating the DirectoryEntry object you could use one of the following constructor overloads:

public DirectoryEntry(
    string path,
    string username,
    string password
)

Documented at: MSDN: DirectoryEntry Constructor (String, String, String)

...or...

public DirectoryEntry(
    string path,
    string username,
    string password,
    AuthenticationTypes authenticationType
)

Documented at: MSDN: DirectoryEntry Constructor (String, String, String, AuthenticationTypes)

As it happens I'm building a test AD environment on my virtual server box for a new project to do similar stuff. When I get it up and running I'll have a play around to see if I can reproduce the problem you're encountering. In the meantime let us know what happens if you try these constructor overloads referenced above.

Update (In answer to Michaels comment):

For reasons that evade me just now, we couldn't use DirectoryEntry.Exists() in a particular scenario, there is this snippet of code that gets called now and again in one of our apps:

public static bool MetabasePathExists(string metabasePath)
{
  try
  {
    using(DirectoryEntry site = new DirectoryEntry(metabasePath))
    {
      if(site.Name != String.Empty)
      {
        return true;
      }
      return false;
    }
  }
  catch(COMException ex)
  {
    if(ex.Message.StartsWith("The system cannot find the path specified"))
    {
      return false;
    }
    LogError(ex, String.Format("metabasePath={0}", metabasePath));
    throw;
  }
  catch(Exception ex)
  {
    LogError(ex, String.Format("metabasePath={0}", metabasePath));
    throw;
  }
}

You could replace the constructor with one of the ones from above. Admittedly it's a stab in the dark :).