Why Can Fail?!
After <security mode=”Transport”> is set, when my web application tries to call my WCF service, which is residing on a different server, this error pops up.
“The target principal name is incorrect.”
( >_< )
Why Like That?!
Apparently this issue has to do with Kerberos authenication, NTLM, SPN and all those stuff. (welcome any others to give a more accurate definition of “all those stuff”) If the client and service reside on the same server, all works fine as it is using NTLM. On separate servers, Kerberos authenication is used, which fails.
What To Do?!
A workaround is to insert a dummy identity element into the endpoint section of the client config.
<endpoint name=””
address=”http://localhost:8000/servicemodelsamples/service”
binding=”wsHttpBinding”
bindingConfiguration=”Binding1″
contract=”ICalculator” >
<identity>
<servicePrincipalName value=”MYSERVICE/MyMachine”/>
</identity>
</endpoint>
</client>
Ironically, what this does is to force the service to fall back to NTLM authentication after Kerberos authentication using the dummy identity element fails. The service does not fall back to NTLM authentication without a identity element, don’t ask me why…. ( @_@; )
A more concrete solution seems to define the ServicePrincipalName for the assigned username or run the service (or client) under higher privileges. Both of these solutions has yet to be tested. To be investigated further if time permits.
Where Got Clue?!
I got the information from these 2 forum posts.
http://www.bokebb.com/dev/english/2047/posts/204720629.shtml
http://www.bokebb.com/dev/english/2047/posts/204721253.shtml
Why Can Fail?! 
July 26, 2008 at 12:35 am |
I hit this one, and wow, it was not a fun one to try and find. I threw it back over the wall to PSS to see if I can get an explanation because it doesn’t make sense.
July 26, 2008 at 2:05 am |
Yuh, I couldn’t figure this out as well. If they do give you an explanation please let me know, thanks.
One thing I did notice after an update though, once Keroberos is properly set up on the Sharepoint server, the identity element will properly pass the credential through instead of falling back to NTLM after failing. Did not try with servicePrincipalName as I did not have an valid account to do that.
By the way, nice blog Colin. 🙂
July 7, 2010 at 3:34 pm |
Colin,
many thanks for posting this up – I was worried that I would be spending hours scratching my head on the same problem you’ve hit – thank god I found your post!
Thanks again for sharing!
July 2, 2012 at 9:17 am |
You saved me some hours too, thanks.
A bit further reading may be found here
http://msdn.microsoft.com/en-us/magazine/cc163570.aspx
and here:
http://msdn.microsoft.com/en-us/magazine/cc163570.aspx
and a good section here:
http://msdn.microsoft.com/en-us/library/bb628618.aspx
It appears that the Service Principal Name is used to decouple the client from having to know the particular Windows account being used by the server. The last link I provided describes what happens when the SPN is empty.