COMException during authentication when managing IIS remotely using Microsoft.Web.Administration

Question

Scenario:

I need to remotely administer an IIS server (create and destroy applications) that is on the same domain as the server requesting the changes. I have an application pool set up to run under an authorized account. I have tested remote configuration using the IIS Manager and the account under which the web pool is running successfully so I know the permissions are correct.

The error I get while doing this via code is this.

Type=System.Runtime.InteropServices.COMException
Source=mscorlib
Message=Retrieving the COM class factory for remote component with CLSID {2B72133B-3F5B-4602-8952-803546CE3344} from machine <SERVERNAME> failed due to the following error: 800706ba <SERVERNAME>.

If I look at the event logs on the remote IIS machine on which I am trying to authenticate with, I see the following error.

Log Name:      Security
Source:        Microsoft-Windows-Security-Auditing
Date:          7/13/2011 5:20:22 PM
Event ID:      4625
Task Category: Logon
Level:         Information
Keywords:      Audit Failure
User:          N/A
Computer:      FQDN.local
Description:
An account failed to log on.

Subject:
    Security ID:        NULL SID
    Account Name:       -
    Account Domain:     -
    Logon ID:       0x0

Logon Type:         3

Account For Which Logon Failed:
    Security ID:        NULL SID
    Account Name:       UserName
    Account Domain:     DOMAIN

Failure Information:
    Failure Reason:     An Error occured during Logon.
    Status:         0xc00002ee
    Sub Status:     0x0

Process Information:
    Caller Process ID:  0x0
    Caller Process Name:    -

Network Information:
    Workstation Name:   -
    Source Network Address: -
    Source Port:        -

Detailed Authentication Information:
    Logon Process:      Kerberos
    Authentication Package: Kerberos
    Transited Services: -
    Package Name (NTLM only):   -
    Key Length:     0

This event is generated when a logon request fails. It is generated on the computer where access was attempted.

The Subject fields indicate the account on the local system which requested the logon. This is most commonly a service such as the Server service, or a local process such as Winlogon.exe or Services.exe.

The Logon Type field indicates the kind of logon that was requested. The most common types are 2 (interactive) and 3 (network).

The Process Information fields indicate which account and process on the system requested the logon.

The Network Information fields indicate where a remote logon request originated. Workstation name is not always available and may be left blank in some cases.

The authentication information fields provide detailed information about this specific logon request.
    - Transited services indicate which intermediate services have participated in this logon request.
    - Package name indicates which sub-protocol was used among the NTLM protocols.
    - Key length indicates the length of the generated session key. This will be 0 if no session key was requested.
Event Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <Provider Name="Microsoft-Windows-Security-Auditing" Guid="{54849625-5478-4994-A5BA-3E3B0328C30D}" />
    <EventID>4625</EventID>
    <Version>0</Version>
    <Level>0</Level>
    <Task>12544</Task>
    <Opcode>0</Opcode>
    <Keywords>0x8010000000000000</Keywords>
    <TimeCreated SystemTime="2011-07-13T21:20:22.234292500Z" />
    <EventRecordID>12046</EventRecordID>
    <Correlation />
    <Execution ProcessID="556" ThreadID="8984" />
    <Channel>Security</Channel>
    <Computer>FQDN.local</Computer>
    <Security />
  </System>
  <EventData>
    <Data Name="SubjectUserSid">S-1-0-0</Data>
    <Data Name="SubjectUserName">-</Data>
    <Data Name="SubjectDomainName">-</Data>
    <Data Name="SubjectLogonId">0x0</Data>
    <Data Name="TargetUserSid">S-1-0-0</Data>
    <Data Name="TargetUserName">UserName</Data>
    <Data Name="TargetDomainName">DOMAIN</Data>
    <Data Name="Status">0xc00002ee</Data>
    <Data Name="FailureReason">%%2304</Data>
    <Data Name="SubStatus">0x0</Data>
    <Data Name="LogonType">3</Data>
    <Data Name="LogonProcessName">Kerberos</Data>
    <Data Name="AuthenticationPackageName">Kerberos</Data>
    <Data Name="WorkstationName">-</Data>
    <Data Name="TransmittedServices">-</Data>
    <Data Name="LmPackageName">-</Data>
    <Data Name="KeyLength">0</Data>
    <Data Name="ProcessId">0x0</Data>
    <Data Name="ProcessName">-</Data>
    <Data Name="IpAddress">-</Data>
    <Data Name="IpPort">-</Data>
  </EventData>
</Event>

I have done a lot of searching on this and have not found anything that seems to point me in the right direction. I did find something that talked about forest trust and that might be the issue but I am not a AD wiz and it all went over my head. I feel like the appropriate permissions are in place since I can get this to work using the IIS Manager just fine, it only fails when using Microsoft.Web.Administration and ServerManager.OpenRemote()

UPDATE

I did disable UAC on both machines and I added the certificate from the target IIS machine to the certificate store on the requesting machine. Still getting the same error.

Answer 1

it sounds strage - just some thoughts:

Update: Check that the user has "Act as part of the operating system" user right, please cf. the bottom of this page under the header "Windows Server 2003 considerations".

1. Most likely to me it sounds like an issue of Kerberos Constraint Delegation. It was introduced from Windows Server 2003 and is targeted at constrainting web servers to access remote ressources through Kerberos (since, if the web server is compromised, it gets kind'a ugly). Check out this to configure a server to be trusted for delegation: http://technet.microsoft.com/en-us/library/ee675779.aspx.

2. Another idea: Have you verified that your client app is using the credentials that you expect it to use (perhaps you are already aware, but it is not guaranteed that it uses the app pool identity, especially if you have smth like <identity impersonate="true"/> in your web.config or impersonation in code - please check out smth like http://retkomma.wordpress.com/2009/07/28/how-to-debug-http-error-401-unauthorized-in-asp-net-via-iis/)?

3. Final debugging idea: Also, you can get a more low level view of wether the Kerberos authentication is successful by using a tool like WireShark - kerberos can be really nasty sometimes...