A fellow community member sent me an email saying he was having trouble authenticating with Kerberos.  Here is the error he was receiving:

SSPI handshake failed with error code 0x8009030c, state 14 while establishing a connection with integrated security; the connection has been closed. Reason: AcceptSecurityContext failed. The Windows error code indicates the cause of failure.  [CLIENT: <named pipe>].

You’ll notice that he was using Named Pipes and a lot of folks might think that is the reason for the error and that SQL Server doesn’t support Kerberos over Named Pipes.  However, that’s not the case as it is version dependent.  Kerberos over Named Pipes started being supported in SQL Server 2008 and this person was running SQL Server 2008 R2.  In this instance, that was not the issue.

I walked him through some troubleshooting scenarios to narrow down the cause.  I had him verify his SPNs to make sure they were correct, were located on the correct object in Active Directory, and he had SPNs for both the FQDN and NetBIOS names.  That all checked out so I had him verify that port 88 (Kerberos) was open between the client and server.  That also checked out fine.  I asked him this one last thing:

Also, make sure you are using Windows authentication since Kerberos does not work with SQL authentication.  If you are using Windows authentication then make sure the client and server are in the same domain or a trusted domain.

That last sentence was the ticket.  He replied that his client and server were in different domains that were NOT trusted.  Unfortunately for him, there is nothing he can do short of moving the servers into the same domain or setting up a trust between them.  That’s a core concept for how Kerberos works.  Clients and servers MUST be in the same domain or a trusted domain.