Updating WCF Service Descriptions

I have been reading Michele Leroux Bustamante’s book on WCF as this is a topic that has been very interesting to me lately.  She has been a guest on .NET rocks and other interesting podcasts several times, and her jovial personality on air intrigued me as to what her books would be like. 

Her book (so far) is great, and I feel that I have learned a lot from the lab examples that walk you though creating host and client solutions that gradually move from the simple to the real world.  I would highly recommend this book, especially if you want to understand all aspects of WCF including security.

Call to SSPI Failed

While going through the labs in chapter 2, I received the following unhandled SecurityNegotiationException:

A call to SSPI failed, see inner exception. 

 InnerException text read:

The Local Security Authority cannot be contacted

The bummer part was that I was on a plane and couldn’t search for what the heck this error meant.  Additionally, I do not have MSDN installed locally, so I was dead in the water.

After arriving at my destination, I posted a question on the MSDN forms (which it turns out Bustamante is the moderator for!) to see if that would provide an answer.  Unfortunately I didn’t give anyone enough time to respond as the answer came in analyzing what is happening when you add a service to your project.

Update Service ReferenceMy first thought was to update the service definition once I got connected to the Internet again.  Maybe my cached credentials woud somehow get jarred and things would start working.  It was a shot in the dark, but worth trying.  So I used the handy right-click option to refresh the reference of my WCF service.  While watching the output window, I noticed that there were 2 files being generated when I would have only expected the single .cs C# file:

  • localhost.cs

  • newapp.config

Since I figured at this point the problem must be in the config file, I looked to see what exactly was in the app.config file of the GigEntry project.  Sure enough, there was an XML element called <identity> that had my domain and username baked into it (seemingly from the CodeGen associated with the proxy).  Here is an example of what the configuration section looked like:


          <userPrincipalName value=<domain>\<username> />


I am not exactly sure what the ramifications are, but I do know that deleting that section allowed the example code to work.  Maybe Michele will reply to my post with some more info? Only after knowing what some keywords to search on were did I find some other interesting reads such as: http://msdn2.microsoft.com/en-us/library/aa702636.aspx