What is SPN in Active Directory?

A service principal name (SPN) is a unique identifier for a service instance running on a server in Active Directory (AD) and is used by Kerberos authentication to associate a service instance with a specific service logon account.

When a user attempts to access a service in a Windows environment, whether it's an SQL Server database, web application, or file share, AD needs a way to uniquely identify that service for authentication purposes. This is where SPN become critical. Without a correctly configured SPN, the ticket-based handshake of Kerberos authentication falls apart, forcing your system to fail back to the less secure NTLM protocol—or worse, deny access entirely.

The anatomy of an SPN

An SPN follows a specific syntax that uniquely identifies the service. The standard format is:

• Service class: This serves as the foundational prefix of the SPN string and identifies the service being requested by the client. This is the first thing the key distribution center (KDC) looks at to categorize the request during authentication. Some common examples of service class include www, MSSQLSvc, and HOST.
• Host: The host component is the critical component of the SPN that identifies the specific computer or cluster resource that is actively providing the service to the network. The Fully Qualified Domain Name or NetBIOS name of the server is used as the host.
• Port: This is an essential addition to the SPN string and is used when a service runs on a non-standard port or when multiple instances of the same service run on a single host. For example, if you have an SQL Server instance running on port 1433, the SPN would include :1433.
• Service name: This is another optional identifier used primarily for complex services like LDAP or specialized replicated services.

How SPNs work in Kerberos authentication

A Kerberos handshake begins when a user attempts to access a resource, requiring the client to identify the target service to the domain controller (DC) for authorization. Here's what happens:

• Request: The client constructs an SPN and asks the KDC for a ticket.
• SPN lookup: The KDC searches for the servicePrincipalName attribute across all computer and user objects in the forest to identify which account's secret key is needed for encryption.
• Mapping: Once found, the KDC encrypts a ticket using the password hash of the account associated with that SPN.
• Handshake: The client sends this ticket to the service. The service decrypts it using its own password, proving its identity.

Managing SPNs using the setspn command

While Windows often automates SPN registration, manual intervention is often required for custom service accounts. The setspn utility allows administrators to add, view, or delete SPNs in AD.

Managing SPNs via ADUC and PowerShell

While setspn remains the standard tool, modern administrators often prefer the automation capabilities of PowerShell or the visual interface of Active Directory Users and Computers (ADUC) for rapid auditing of SPNs.

Steps to manage SPNs using ADUC

1. In the ADUC menu, click View and select Advanced Features.
2. Right-click the specific User or Computer account and select Properties.
3. Click the Attribute Editor tab.
4. Scroll down to the servicePrincipalName attribute and click Edit.
5. From here, you can manually add or remove SPN strings in a multi-valued list.

While the Attribute Editor is convenient, it does not perform the forest-wide duplicate check that setspn -S provides. If you accidentally enter an SPN that exists elsewhere, you will cause a Kerberos conflict without receiving an immediate error message.

Managing SPNs with PowerShell

The AD PowerShell module allows for deep queries and bulk updates that are often impossible with basic command-line tools, particularly when auditing hundreds of accounts.

• View SPNs

  You can view SPNs using the following PowerShell script:

  Click to copy script

  Get-ADUser -Identity -Properties servicePrincipalName | Select-Object -ExpandProperty servicePrincipalName
• Add an SPN

  To add an SPN, use the following script:

  Click to copy script

  Set-ADUser -Identity <account> -Add @{servicePrincipalName="HTTP/zanger.com"}

SPN enumeration and Kerbroasting

Understanding SPN also requires understanding how attackers exploit them; because any authenticated domain user can query the directory for SPNs without triggering traditional alarms, hackers use this as a reconnaissance phase to map out high-value targets.

This is how the Kerbroasting attack path works:

1. Enumeration: Attackers search for SPNs associated specifically with user accounts rather than computer accounts.
2. Request: They request a service ticket for that SPN from the KDC.
3. Extraction: The ticket is encrypted with the service account's password hash; the attacker takes this ticket offline to crack the password using brute-force tools.

To mitigate these risks, always utilize Group Managed Service Accounts (gMSAs), which utilize 240-character passwords that rotate automatically, making them virtually immune to traditional Kerberoasting attempts.

Troubleshooting SPN errors

When a service fails, your first step should be examining the Windows system event logs on the client or the security logs on the DC for these specific status codes:

• Error 0x7 KDC_ERR_S_PRINCIPAL_UNKNOWN: This error signifies that the KDC cannot find the requested SPN and indicates the SPN is missing, misspelled, or there is a DNS suffix mismatch between the client and the server.
• Error 0x8 KDC_ERR_PRINCIPAL_NOT_UNIQUE: This error indicates that the KDC found the same SPN on two different accounts and blocked the request to prevent a security breach.
• Kerberos event 4: This error occurs when an SPN is registered to the wrong account and the client receives a ticket encrypted with Account A's key, but the service is running as Account B and cannot be decrypted.
• The SQL Server Network Interface library could not register the Service Principal Name : This error indicates that the service account lacks the Write servicePrincipalName permission to register a SPN in AD.

Streamline your AD management with ADManager Plus

Manually overseeing SPNs, whether through command-line utilities like setspn.exe, complex PowerShell scripts, or the hidden menus of ADUC is a high-risk strategy that often leads to misconfigurations, security vulnerabilities, and frustrating authentication outages. In a modern enterprise, you need a solution that replaces manual guesswork with automated precision.

ADManager Plus, an AD management and reporting tool, is designed to bridge the gap between complex AD requirements and efficient IT administration. By centralizing your identity management into a single, intuitive interface, ADManager Plus ensures that your IT environment is always accurate, secure, and compliant.

FAQ

1. What does SPN stand for?

   In AD, a service principal name (SPN) is a unique, string-based identifier used to link a specific instance of a service, such as a database, web application, or file share to the security account under which that service is currently running. This identifier allows the Kerberos protocol to perform mutual authentication between a client and a server.

2. What is an SPN number?

   Technically, there is no such thing as an SPN number within AD or the Kerberos protocol. When IT professionals use this term, they are typically referring to the port number within an SPN string. For example, in the SPN is MSSQLSvc/sqlserver.zanger.com:1433, the number 1433 identifies the specific port the service is listening on.

3. When should I use the setspn utility vs. PowerShell for managing SPNs?

   The setspn command-line utility is the standard tool for quick, manual tasks like adding or deleting individual SPNs. For bulk auditing, reporting, or complex automation across hundreds of accounts, PowerShell is preferred because it can query multiple attributes simultaneously using the Get-ADUser cmdlet.

4. Why is an SPN important?

   An SPN account is critical because it defines the security boundary for a service. Without a properly mapped SPN, Kerberos authentication fails, and the system may revert to NTLM, which is more vulnerable to relay attacks. Furthermore, mismanaged SPNs can lead to Kerbroasting, where attackers attempt to crack the password hashes of service accounts.

5. What are common examples of Windows SPN service classes?

   The service class is the first part of an SPN string. Some common examples in a Windows environment include:

• www : Used for web services (IIS).
• MSSQLSvc: Used for SQL Server instances.
• CIFS: User for file sharing and storage access.
6. When should I create SPNs manually?

   While Windows often automates SPN registration for computer accounts, manual intervention necessary in several enterprise scenarios. The most common requirement is when a service, such as SQL Server or IIS, is configured to run under a specific user account rather than the default LocalSystem or NetworkService accounts. Additionally, manual SPNs are critical for load balanced clusters where multiple servers provide a single service under a shared virtual IP or load balancer name, requiring the SPN to be mapped to a single service account.