Search This Blog

Apr 20, 2007

What's SPN's role in Kerberos

When a client needs to access a service or resource from a target server, it goes to DC to request a Service Ticket first. Because a target server can provide more than one services, in its request, the client has to include what type of resource/service it wants, this is done by including SPN in the request.



So it's easy to understand that, in an AD environment, servers(namely services providers) have to registered their SPN properly in AD in order to advertise/provide services properly. For example, Exchange server will normally register exchangeAB, exchangeMDB, exchangeRFR, and SMTP SPNs. Likewise, DC will register ldap, ntfrs, etc.



There are a few special SPNs that all servers will register automatically. HOST is one of them, sometimes in the form of cifs.



When the KDC gets a Service Ticket Request from a client, it extracts the SPN from the request, locate the server in its database(in Windows world, it's AD) based on SPN. KDC then prepares the ticket, encrypted it with the resource server's master key or service account's master key, and returns the ticket to client.



Kerberos error KRB_APP_ERR_MODIFIED (in Event ID 4 for AD) will occur if a service ticket was encrypted with one key while to be decrypted with another. This happens when a ticket is sent to a wrong computer, which in turn is often caused by duplicated DNS records, different computers have same name, etc. It can also be caused in the following scenario:



Target server (named DesiredServer)provides a service named "serviceA"; serviceA is running a service account named "ServiceAaccount"

Ideally, SPN 'serviceA\Targetserver' should be registered under DesiredServer's name. However in our example, it was registered under a different server's name, say, "WrongServer". Or same SPN 'serviceA\Targetserver' was registered twice under both "DesiredServer" and "WrongServer"

A client is requesting serviceA, it applies the service ticket from a DC with SPN 'serviceA' specified

DC searches its database based on SPN provided. It gets "WrongServer" as result. DC encrypts the ticket with "WrongServer"'s master key

The ticket is still sent to "DesiredServer" for service, and "DesiredServer" won't be able to decrypted the ticket.

A Kerberos error is logged on "DesiredServer"



Or there are chances that, when a ticket should be encrypted with a service account's key, but instead, it is encrypted with the computer's master key.