How does SPN with Kerberos works

Learn how does spn with kerberos works with practical examples, diagrams, and best practices. Covers kerberos, windows-authentication, spnego development techniques with visual explanations.
Tags:
Categories:

Understanding SPN and Kerberos Authentication

Hero image for How does SPN with Kerberos works

Explore the intricate dance between Service Principal Names (SPNs) and Kerberos authentication, crucial for secure service access in Windows environments.

Kerberos is a network authentication protocol that works on the basis of 'tickets' to allow nodes communicating over a non-secure network to prove their identity to one another in a secure manner. A key component of Kerberos, especially in Windows environments, is the Service Principal Name (SPN). Without correctly configured SPNs, Kerberos authentication will fail, often falling back to less secure NTLM authentication or failing entirely. This article delves into how SPNs function within the Kerberos protocol to enable secure service access.

What is a Service Principal Name (SPN)?

An SPN is a unique identifier for a service instance that a client wants to connect to. It's essentially a name that uniquely identifies a service running on a server within a Kerberos domain. When a client attempts to connect to a service, it uses the SPN to request a Kerberos service ticket for that service. The SPN must be registered in Active Directory under the account that the service is running as. If the SPN is not registered, or if it's registered incorrectly (e.g., to the wrong account or duplicated), Kerberos authentication will not succeed.

The Kerberos Authentication Flow with SPNs

The Kerberos authentication process involves several steps, where the SPN plays a critical role in the client's request for a service ticket. This flow ensures that both the client and the service can verify each other's identity securely without sending passwords over the network. The process typically involves a Key Distribution Center (KDC), which is usually a Domain Controller in a Windows environment, and two main types of tickets: the Ticket Granting Ticket (TGT) and the Service Ticket (ST).

sequenceDiagram
    participant Client
    participant KDC as Key Distribution Center (AD DC)
    participant Service as Target Service (e.g., SQL Server)

    Client->>KDC: 1. AS-REQ (Authentication Service Request)
    KDC-->>Client: 2. AS-REP (TGT + Session Key)
    Client->>KDC: 3. TGS-REQ (Ticket Granting Service Request) with SPN
    KDC-->>Client: 4. TGS-REP (Service Ticket + Session Key)
    Client->>Service: 5. AP-REQ (Application Request) with Service Ticket
    Service-->>Client: 6. AP-REP (Application Reply) (Optional, for mutual auth)
    Client<->>Service: 7. Secure Communication

Kerberos Authentication Flow with SPN involvement

Let's break down the steps in the diagram:

  1. AS-REQ (Authentication Service Request): The client sends its username to the KDC, requesting a TGT.
  2. AS-REP (Authentication Service Reply): The KDC verifies the client's identity and issues a TGT, encrypted with the client's password hash, along with a session key. The client decrypts this using its password hash.
  3. TGS-REQ (Ticket Granting Service Request): The client, now possessing a TGT, wants to access a specific service. It sends the TGT to the KDC along with the SPN of the service it wishes to access.
  4. TGS-REP (Ticket Granting Service Reply): The KDC looks up the SPN in Active Directory to find the service account associated with it. It then generates a Service Ticket for that service, encrypted with the service account's password hash, and a new session key for client-service communication. This Service Ticket is sent back to the client.
  5. AP-REQ (Application Request): The client sends the Service Ticket to the target service. The service decrypts the ticket using its own password hash, verifies the client's identity, and extracts the session key.
  6. AP-REP (Application Reply): (Optional) If mutual authentication is required, the service can send a reply to the client, proving its identity.
  7. Secure Communication: Both client and service now share a session key and can communicate securely.

Managing SPNs: Registration and Troubleshooting

SPNs are critical for Kerberos, and their correct registration is paramount. SPNs are registered using the setspn command-line tool. Incorrectly configured or duplicate SPNs are common causes of Kerberos authentication failures.

Common SPN Issues:

  • Missing SPN: If a service's SPN is not registered, clients cannot request a service ticket for it, leading to NTLM fallback or connection failures.
  • Duplicate SPN: An SPN must be unique across the entire Active Directory forest. If the same SPN is registered to two different service accounts, Kerberos authentication will fail unpredictably, as the KDC won't know which account's key to use for encryption.
  • Incorrect SPN Registration: The SPN must be registered to the service account under which the service is running, not the machine account (unless it's a built-in account like Network Service or Local System, which use the machine account's SPN).

Troubleshooting often involves using setspn -L <account_name> to list SPNs for an account or setspn -X to find duplicate SPNs.

# List all SPNs registered to a specific user account
setspn -L "DOMAIN\ServiceAccount"

# List all SPNs registered to a specific computer account
setspn -L "ComputerName"

# Find duplicate SPNs in the entire forest
setspn -X

# Register an SPN for a service running on a specific port
# Example: HTTP service on server 'WebServer1' running as 'DOMAIN\WebAppService'
setspn -S HTTP/WebServer1.domain.com:80 DOMAIN\WebAppService
setspn -S HTTP/WebServer1:80 DOMAIN\WebAppService

Examples of setspn commands for managing SPNs