Okay, it is the typical message: The Security Support Provider Interface (SSPI) negotiation failed. But the scenario is different than when I've run into it before. In our setup, we have a workstation within a very secure environment running
an application that needs to call one of our WCF services which are using Windows Authentication. If I run this app on our regular network with a domain account it runs just fine. Within the secure environment on this workstation, it throws the
SSPI error. Here's where it gets interesting. For at least one user, who had logged into the machine before it had been fully "hardened" the application still works. For users logging in since then, fail. I am guessing there
is some specific facet of local profile creation that doesn't work in our hardened environment that does not apply to the user whose profile already existed. I have previously run into the service-to-service issue where you have to create a local profile
for your back end service account before its upn will work in the config (which still makes no sense to me). I'm hoping this is somehow related and one of you internals geniuses will know what part of my profile is missing. Thanks in advance.
View Complete Post