I recently came across a weird error with a parnter that we're working with. He was getting SSPI errors at the the client side. I had seen these previously, but only when configuring SharePoint and our product (FirstPoint) for Kerberos.
After turning on Kerberos logging, it was clear that was clear that the client and service were trying to use Kerberos and failing with the error KRB_ERR_RESPONSE_TOO_BIG. Now it's normal for the client and service to negotiate the authentication scheme and fall back onto NTLM, but it seemed that in this case, WCF was not falling back to NTLM due to the error type.
It was pretty baffling since we did have any issues using the same configuration in our test environments.
Fortunately, I came across a listing about this issue. The solution is to simply add an invalid SPN to the service and client, which forces the usage of NTLM.
<endpoint address="net.tcp://myserver/myservice" binding="netTcpBinding" bindingConfiguration="DefaultTcpBinding" contract="IMyService" name="NetTcpBinding_IMyService"> <identity> <!--/// The value is left intentionally blank ///---> <servicePrincipalName value=""/> </identity> </endpoint>