What's the difference in WCF between Ntlm and NTLM, and how can I fix it? - vb.net

Question

I've got a WCF service that's running on IIS 6, with integrated authentication and impersonation using NTLM.
Relevant portions of Web.Config
<system.web>
<identity impersonate="true"/>
<customErrors mode="Off"></customErrors>
</system.web>
<system.serviceModel>
<serviceHostingEnvironment aspNetCompatibilityEnabled="true" />
...
</system.web>
...
<wsHttpBinding>
<binding name="wsHttpEndpointBinding">
<security mode="Transport">
<transport clientCredentialType="Ntlm" />
</security>
</binding>
</wsHttpBinding>
I just added the aspNetCompatibility because I want to know who the user is that's logged in (at least as far as IIS is concerned). From the few searches I've done that's how you get the user.
Well, after adding that line and publishing my server I get what's possibly the stupidest error I've seen:
The HTTP request is unauthorized with client authentication scheme 'Ntlm'. The authentication header received from the server was 'NTLM'.
I thought, "Well obviously they're doing a very case-sensitive comparison." So I searched my entire client solution for Ntlm and replaced all non-variable occurrences with NTLM. No luck.
My primary goal, of course is to get whatever user was authenticated through IIS+NTLM. If I'm going about it the wrong way, I'd be happy to know of an easier/better way. Otherwise, how do I tell my client (or my server) that it's OK to go ahead and authenticate?

Answer 1

One other possibility if you are running across this error is that you are experiencing an issue with the loopback check with NTLM. I have a service which runs self-contained on a non-domain (workgroup) server. WCF is configured using BasicHttpBinding with Transport security mode and Ntlm client credentials. When trying to access the service using https://servername it works great. If I try to access it using the FQDN (https://servername.domain.com) it fails with the same error:
The HTTP request is unauthorized with client authentication scheme 'Ntlm'. The authentication header received from the server was 'NTLM'.
If you look inside the Windows security log you will see an Audit Failure with event ID 4625. In this you will see the following failure information:
Failure Information:
Failure Reason: An Error occured during Logon.
Status: 0xc000006d
Sub Status: 0x0
To resolve this you need to either add the back connect host names (preferred) or disable the loopback check. This was a security enhancement added for NTLM in Windows Server 2003 SP1 and later to close out an attack vector against the protocol. The fix, however, causes a lot of unclear error messages like this one from WCF and continues to haunt me in many obscure ways to this day.

Answer 2

Start Here . This should resolve your issue