This (like just about all posts on this blog) is more of a reminder to myself in case I ever see this problem again.
Whilst running some integration tests that exercise end to end WCF functionality I encountered an odd problem that only seemed to manifest itself when I was running the test application against the service running within IIS (or so I thought). When the service was running in Visual Studio 2008’s Cassini server, all my tests pass, but when I reconfigure to point to IIS (the dev environment sits on Windows 2008 Server R2) I get the following error:
The HTTP request is unauthorized with client authentication scheme ‘Ntlm’. The authentication header received from the server was ‘Negotiate,NTLM’.
At this point in time I’m a relative WCF noob and WCF security is (I’m led to believe) a huge topic that I just don’t have much time to learn about right now. My debugging process is fairly simple:
- I know the tests work when running against the dev environment so it’s not code.
- The solution uses Web Deploy projects. So I delete the virtual application in IIS and rebuild. That deploys correctly, so it’s not the deployment.
- The exact same settings running against localhost work for another Service I recently checked in, so I know that this should work.
- I checked to ensure that the configurations for that other Service were identical (where it mattered) to the one that had problems with authentication.
- I was using Fiddler to ensure that the client is talking to the service and that the service in turn is talking to other stubbed services.
That last point is where I kind of tripped up and where my WCF and general ignorance raised its head.
I had configured the client to use Fiddler’s localhost equivalent (ipv4.fiddler) in order to view the messages that are sent across the wire. The server was naturally configured to just use localhost. Although fiddler can and does intercept ipv4.fiddler and routes it to localhost, WCF – or more likely Windows Authentication – sees it as a domain and will point out that there’s a mismatch in authentication – hence the 401 error above.
The solution in the end was very simple – ensure that all client endpoints match all server endpoints and that security is configured the same way for both client and service – the problem then goes away. It took a bit of Google magic but I eventually found this post on Stackoverflow which pointed me in the right direction.