How is SPN related to Kerberos?

Kerberos is authentication protocol. If UserA wants to talk with ServiceB and ServiceB wants to know who is talking with, UserA must be authenticated. Kerberos works in this way: UserA is authenticated in secure way by kerberos server. Then UserA is given a ticket for ServiceB. UserA show ticket to ServiceB. Now ServiceB is sure that UserA is UserA because it trusts Kerberos server and all information written on tickets are secured and verifiable.

So kerberos ticket is a message from UserA to ServiceB. Now, as you know every Windows/Unix service is run on user account. On this scenario user account is not dedicated for human but technically is the same account type as for human user. Well, in fact kerberos ticket is a secure message from UserA to UserB. Secure - in cryptographic manner - it use pair of public/private keys (all messages to UserB are encrypted with his public key and decryptable only with UserB private key; all messages from UserA are signed with his private key and verifiable with UserA public key).

So if UserA wants to talk with SQL Server called SQL1.mycompany.com or HTTP Server called WWW1, how do we know that kerberos ticket is issued to UserS (SQL1) or UserW (WWW1)? This is where SPN appears (Service Princial Name). It connects service names with user account names, so Kerberos knows if UserA asks for a ticket for WWW1 service, ticket must be generated using UserW public key.

In Windows Server SPN are stored in Active Directory as user account attributes. One user account may have many SPN registered (for example: one user account runs multiple instances of SQL Server or one SQL Server is accessed by "short" NetBIOS name (without domain name) or "full" FQDN name (including domain name) - so SQL is registered under two SPNs). SPN is easily registered, listed, unregistered with SETSPN command (built-in since Windows Server 2008).

If you have Kerberos related problem start investigation from checking if user accounts have SPN registered for services they run. Windows Services MMC mangement console is a place where you setup an account for running service, but Kerberos does not know anything about it. SPN is second place where user account to service relationship is registered and the only place where Kerberos reads it. So, all noise about Kerberos and SPN is so simple - Kerberos just needs to know who is hidden under service (who serves a service) to generate ticket that user show to service to say "hello, that's really me, this is my ticket issued by Kerberos - you trust him". And SPN translates service address (SQL Server instance, server name, IP port or URL of webapp) to user name - "target" of kerberos ticket.