I am having a problem with a WCF service using Windows authentication on one of the servers I am deploying it to (it's a Windows Server 2008 R2 machine), while it works flawlessly on all other machines I have access to (Windows 7, Windows Server 2008 and Windows Server 2008 R2). I managed to reproduce the issue with a really simple sample application which more or less completely excludes my code as the cause of the problem.
The minimum application I can reproduce the issue with is a minor modification of the WCF service project template:
[ServiceContract]
public interface IService1
{
[OperationContract]
string GetData(int value);
}
[AspNetCompatibilityRequirements(RequirementsMode=AspNetCompatibilityRequirementsMode.Allowed)]
public class Service1 : IService1
{
public string GetData(int value)
{
return string.Format("You entered: {0}\nUsername: {1}",
value,
ServiceSecurityContext.Current == null ?
"<null>" :
ServiceSecurityContext.Current.PrimaryIdentity.Name);
}
}
Basically I enabled ASP.NET compatibility (I need it because the actual code uses an HttpHandler for authentication) and the username of the authenticated user is returned.
The contents of web.config
are as follows:
<?xml version="1.0"?>
<configuration>
<system.web>
<compilation debug="true" targetFramework="4.0" />
<authentication mode="Windows"/>
</system.web>
<system.serviceModel>
<behaviors>
<serviceBehaviors>
<behavior name="ServiceBehavior">
<serviceMetadata httpGetEnabled="true" />
<serviceDebug includeExceptionDetailInFaults="true" />
</behavior>
</serviceBehaviors>
</behaviors>
<bindings>
<basicHttpBinding>
<binding name="HttpWindowsBinding" maxReceivedMessageSize="2147483647">
<readerQuotas maxBytesPerRead="2147483647" maxArrayLength="2147483647" maxStringContentLength="2147483647" maxNameTableCharCount="2147483647" maxDepth="2147483647"/>
<security mode="TransportCredentialOnly">
<transport clientCredentialType="Windows" />
</security>
</binding>
</basicHttpBinding>
</bindings>
<serviceHostingEnvironment multipleSiteBindingsEnabled="true" aspNetCompatibilityEnabled="true" />
<services>
<service name="TestService.Service1" behaviorConfiguration="ServiceBehavior">
<endpoint address=""
binding="basicHttpBinding"
bindingConfiguration="HttpWindowsBinding"
contract="TestService.IService1" />
<endpoint address="problem"
binding="basicHttpBinding"
bindingConfiguration="HttpWindowsBinding"
contract="TestService.IService1" />
</service>
</services>
</system.serviceModel>
<system.webServer>
<modules runAllManagedModulesForAllRequests="true"/>
</system.webServer>
</configuration>
Notice the two endpoints: one with the default address, the other one with a relative address. Calling the first one succeeds even on the problematic server, while the call to the second one fails with following error:
Exception type: HttpException
Exception message: Failed to Execute URL.
at System.Web.Hosting.ISAPIWorkerRequestInProcForIIS6.BeginExecuteUrl(String url, String method, String childHeaders, Boolean sendHeaders, Boolean addUserIndo, IntPtr token, String name, String authType, Byte[] entity, AsyncCallback cb, Object state)
at System.Web.HttpResponse.BeginExecuteUrlForEntireResponse(String pathOverride, NameValueCollection requestHeaders, AsyncCallback cb, Object state)
at System.Web.DefaultHttpHandler.BeginProcessRequest(HttpContext context, AsyncCallback callback, Object state)
at System.Web.HttpApplication.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)
The call only fails when the classic pipeline is used (I need it because of the HttpHandler, but the issue can be reproduced even without it). With integrated pipeline the problem is gone. Also if I disable Windows authentication, the problem is gone as well:
<binding name="HttpBinding" maxReceivedMessageSize="2147483647">
<readerQuotas maxBytesPerRead="2147483647" maxArrayLength="2147483647" maxStringContentLength="2147483647" maxNameTableCharCount="2147483647" maxDepth="2147483647"/>
<security mode="None">
<transport clientCredentialType="None" />
</security>
</binding>
I have noticed another detail with an HttpHandler registered. The value of HttpRequest.CurrentExecutionFilePath property for the endpoint with the relative address differs between the problematic server (~/Service1.svc/problem
) and the working servers (~/Service1.svc
). Although I'm not that well familiar with IIS, I suspect this could hint at the cause of the problem - maybe something related to the routing of requests?
I am running out of ideas therefore I'm posting this here in the hope the someone will recognize what the problem could be. Any suggestion are welcome.
Do you have URL rewriting on IIS turned on? This smells like a permission issue of some sort. What is the difference between Classic and Integrated pipeline mode in IIS7? Might be helpful.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With