Error: The target principal name is incorrect

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=””
contract=”ICalculator” >

<servicePrincipalName value=”MYSERVICE/MyMachine”/>


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.


4 Responses to “Error: The target principal name is incorrect”

  1. Colin Bowern Says:

    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.

  2. whycanfail Says:

    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. 🙂

  3. Rob Says:


    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!

  4. Andy Says:

    You saved me some hours too, thanks.

    A bit further reading may be found here

    and here:

    and a good section here:

    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.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: