What is a Service Principal Name (SPN)?

Updated on September 10, 2025

A Service Principal Name (SPN) is a unique identifier used by the Kerberos authentication protocol to identify a service instance on a network. SPNs are essential for Kerberos to function, as they allow a Kerberos client to uniquely locate and authenticate to a service, even when multiple instances of the same service are running on different machines.

A deep technical understanding of SPNs is critical for network administrators and security professionals. Misconfigurations are a common cause of authentication failures and can be exploited by attackers. This reference guide provides the technical depth needed to properly implement and troubleshoot SPN configurations in enterprise environments.

Breaking Up with Active Directory

Don’t let your directory hold you back. Learn why it’s time to break up with AD.

Read Now

Definition and Core Concepts

A Service Principal Name (SPN) is a unique identifier that a Kerberos client uses to identify a service instance. It is associated with the Active Directory account—either a user or a computer account—that the service is running under.

SPN Format

An SPN follows a specific, standardized format:

serviceclass/host:port/serviceinstance@REALM

Each component serves a distinct purpose:

• serviceclass: A string that identifies the class of the service. Common examples include http for a web service, MSSQLSvc for a SQL Server, or HOST for generic host services.
• host: The DNS hostname or fully qualified domain name (FQDN) of the machine where the service is running. This must match exactly what clients use to connect to the service.
• port (optional): The port number on which the service is listening. This is only required when the service runs on a non-standard port.
• serviceinstance (optional): Additional identifier for the service instance. This is rarely used in most implementations.
• @REALM: The Kerberos realm, which represents the administrative domain the service belongs to. In Active Directory environments, this is the domain name in uppercase.

Authentication Process

When a client requests a service ticket, it uses the SPN to identify the target service. The Kerberos Key Distribution Center (KDC) uses this SPN to find the correct service account and its password hash to encrypt the ticket. This ensures that only the legitimate service can decrypt and use the ticket.

How It Works

SPNs are at the heart of the Kerberos authentication workflow, enabling a client to securely connect to a service through a multi-step process.

SPN Registration

SPNs must be registered in Active Directory before they can be used for authentication. For services running under the LocalSystem or NetworkService accounts, the SPNs are registered automatically by the system. For services running under a user account (a service account), the SPN must be registered manually using tools like setspn.exe.

The registration process creates a mapping between the SPN and the service account in the Active Directory database. This mapping is critical for the KDC to locate the correct account when processing ticket requests.

The Kerberos Process

The authentication flow demonstrates how SPNs enable secure service access:

1. A client attempts to access a service, such as a web application at https://app.corp.contoso.com.
2. The Kerberos client on the user’s machine constructs the SPN for the service, which would be http/app.corp.contoso.com.
3. The client sends a request to the KDC for a Service Ticket for that specific SPN.
4. The KDC searches the Active Directory database for the SPN, locates the associated service account, and uses that account’s password hash to encrypt the Service Ticket.
5. The client receives the encrypted ticket and sends it to the service. The service uses its own password hash to decrypt the ticket and authenticate the client.

This process ensures that both the client and service are authenticated through their respective Active Directory accounts, providing mutual authentication and secure communication.

Troubleshooting and Considerations

SPN-related issues are among the most common causes of Kerberos authentication failures in enterprise environments. Understanding these problems is essential for effective troubleshooting.

SPN Duplication

An SPN must be unique across an entire Active Directory forest. If two services have the same SPN registered, Kerberos cannot determine which service should receive the ticket, and authentication will fail. This scenario commonly occurs when:

• Services are migrated between servers without proper SPN cleanup
• Administrators manually register SPNs without checking for existing entries
• Automated deployment scripts create duplicate registrations

The setspn -X command can identify duplicate SPNs across the forest, allowing administrators to resolve conflicts before they cause authentication failures.

SPN Mismatch

Authentication fails when the SPN in the client’s request does not match the SPN registered for the service. The KDC logs this failure as Event ID 4769, and the authentication attempt is rejected. Common causes include:

• DNS name changes that are not reflected in SPN registrations
• Load balancer configurations that present different hostnames to clients
• Services listening on non-standard ports without corresponding SPN updates

How to Modernize Your AD Instance

The IT Professional’s Roadmap to Augmenting or Replacing AD

Download Today

Security Implications

SPNs play a central role in Kerberoasting attacks, making their security configuration critical for enterprise defense. An attacker can query Active Directory for a complete list of all SPNs using standard LDAP queries. They can then request Service Tickets for any of these SPNs, and the KDC will issue the tickets without additional validation.

If the associated service account has a weak password, attackers can take the encrypted ticket offline and attempt to crack the password hash. This reveals the plaintext password, potentially granting the attacker access to the service account and any resources it can access.

Defense strategies include:

• Using strong, complex passwords for service accounts
• Implementing managed service accounts where possible
• Regular auditing of service account permissions
• Monitoring for unusual ticket requests

Key Terms

• Service Principal Name (SPN): A unique identifier that enables Kerberos clients to locate and authenticate to specific service instances.
• Kerberos: A network authentication protocol that uses tickets to allow secure communication between clients and services over potentially insecure networks.
• Service Account: The Active Directory account under which a service runs, providing the security context for the service’s operations.
• Ticket-Granting Service (TGS): The component of the Kerberos Key Distribution Center responsible for issuing service tickets to authenticated clients.
• Kerberoasting: An attack technique that exploits weak service account passwords by requesting service tickets and attempting to crack the encrypted password hashes offline.