Shared Configuration and Remote Provisioning
When using the IIS 7 Shared Configuration featured in an environment where site provisioning tasks are driven from a remote machine, you can encounter what is know as the "double-hop authentication issue". This issue will prevent you from executing provisioning tasks. This article describes the problem and provides workarounds for it.
Problem Description
The provisioning topology illustrated in the following diagram could be one common option for leveraging the new shared configuration feature available in IIS 7, which the configuration is centralized on a network share, and a centralized provisioning server will perform provisioning operations in multiple web server farms. We assume all web server farms are running Windows Server® 2008 R2 with IIS 7.
Typical Provisioning Topology
Shared Configuration can be enabled easily via IIS Manager as shown in the following screen shot.
A set of new managed APIs has been provided in IIS 7 in the Microsoft.Web.Administration namespace. The APIs contain a method OpenRemote, which enable remote administrations across the network as illustrated in the following diagram.
The following code snippet demonstrates the use of OpenRemote to provision an application on a different web server.
When shared configuration is enabled for the remote web server, you get the following error when execute the sample code:
The issue does not exist if the remote web server is using local configuration instead of shared configuration.
Disable the shared configuration:
Re-run the sample application:
The modification is successfully committed.
This is a double-hop authentication issue caused by shared configuration across multiple servers. The OpenRemote call is simply remotely invoking the COM object via DCOM. If the configuration is not configured locally, the COM object will try to do the double hop which is not allowed when using COM. Keep in mind that this only occurs in write operation to the shared configuration.
When read operation is performed, the underline configuration system is using the credential stored in the redirection.config file to authenticate on the remote network share server, which will not have this double-hop issue. With write operations, the underline configuration is using the caller security token to conduct the operations which the security token is invalid on the remote network share server.
Workarounds
Option 1: Modify the DCOM Configuration for Configuration COM Object Using a Specified Account
To work around the double-hop issue with configuration COM object, we need to change the DCOM configuration to use a specified account instead of caller's security context to enable the configuration COM object authenticating at the remote network share server with specified credential.
You can locate the IIS 7 configuration COM object – ahadmin under DCOM Config by using Component Services on the remote web server as illustrated in the following diagram:
Right-click the ahadmin node, and select properties…, select the Identity tab, change the option to This User instead of The launching user, and specify a user account with the following permissions:
- Have change permissions on the shared configuration files on the network share server.
- Have read permission to redirection.config file stored under system32\inetsrv\config
- Member of local administrators group, otherwise you will have can't decrypt exception.
Click OK.
After the change, re-run the sample application, it works successfully.
The Test application is provisioned correctly.
Using a specified account for the configuration COM object might expose additional security risks (i.e. any users could modify the configuration as long as they have permission to invoke the COM object). To reduce the security risks, only configure one web server in the web server farm using this option for provisioning, and configure firewall to only allow certain IP to access the server.
**Security Warning**
This approach can potentially allow a non-administrator to make administrative level changes on the server, since the component will not be running under the security context of the caller.
Option 2: Using a Hosting Services Sample Approach
An alternative option is not using OpenRemote via DCOM call and instead creating a service like the Hosting Services Code Sample, which is a set of web services built on top of WCF (Windows Communication Foundation), on one of the web server in the web farm as illustrated in the following diagram:
You can use Windows Service to hosting the services if you have concerns hosting in IIS 7. The web service is built on top of Microsoft.Web.Administration APIs and provides better integration option, and furthermore there is no needs to open the firewall as OpenRemote required.
Security Consideration
The service should be secured to only allow authorized and authenticated users to call into the service.
Option 3: Using WMI
Another option to avoid the double-hop issue is to use WMI service as illustrated in the following diagram.
WMI service has the option for you to specify the credential to connect to remote web server, the WMI service on the remote server will impersonate the identity while performing the provisioning option as shown in the following code snippet. To enable the operations working with shared configuration, you must specify the impersonate option while connecting to WMI on the remote server. WMI also requires certain ports open in the firewall for remote invocation.
