Introduction to Service Principal Names (SPNs)
What is an SPN? Even a Windows Admin with some experience with Active Directory may be unaware of the role that Service Principal Names have in domain environments. A security principal name (SPN) is a unique identifier that links a specific service instance to the account running it, enabling clients to authenticate and connect to the right service within Active Directory (AD). This is particularly important in large enterprise environments where multiple instances of a service may run on different servers. In this article we will discuss what the active directory SPN is, what its contribution is to security, and how its uses continue to expand in modern networks today.
Role of SPNs in Kerberos authentication
Just as you need a ticket to board a plane or enter a movie theater, you also need a ticket to access resources within Active Directory (AD). When a client requests access to an AD-hosted service, the process unfolds as follows:
- A client trying to use a service creates an SPN for that service
- The client asks the domain controller for a ticket using that SPN
- The domain controller searches Active Directory for that SPN
- Once found, the domain controller issues a service ticket
- The client uses this ticket to authenticate to the service without needing a password
Breaking Down the Basics
Components of an SPN
SPN consists of multiple components that when combined provide a complete identity for a specific service:
- Service Class: This is the name of the service instance, such as “MSSQLSvc” for Microsoft SQL Server or “www” for web services.
- Hostname: Specifies the server or host where the service is running. This can be the NetBIOS name of a Windows machine such as “FilerServer” or the fully qualified domain name like “fileserver.company.com”
- Account: The Active Directory account associated with the service. This is not part of the SPN string itself but is the account to which the service principal name is registered.
- Port (Optional): If the service runs on a non-standard port, it can be specified in the SPN.
Examples of Common SPNs in Active Directory
- Web Services – HTTP/webserver.netwrix.com
- SQL Server – MSSQLSvc/myhost.redmond.microsoft.com:1433
- File Shares – CIFS/fileserver.contoso.com
- Remote Desktop Services – TERMSRV/rdserver.abcdomain.com
- LDAP Authentication – LDAP/domaincontroller.fabricam.com
SPNs and Active Directory: The Connection
How SPNs integrate with Active Directory objects
SPNs are attributes associated with AD objects such as user accounts, service accounts, or computer objects. They work as labels that show which services run under which accounts. This connection lets computers use Kerberos for secure authentication without sending passwords across the network. When a service is installed or configured, it registers an SPN that allows Kerberos to map authentication requests to the correct account. Without a properly configured SPN, Kerberos authentication will fail, potentially causing authentication errors and service disruptions.
SPN storage in the servicePrincipalName attribute
SPNs are stored within Active Directory as part of an object’s servicePrincipalName attribute. This attribute exists on computer accounts and service accounts. You can see this attribute in the advanced properties of an object using Active Directory Users and Computers as shown in the screenshot below.
The attribute holds a list of SPNs that have been assigned to the object. Each SPN entry follows a structured format that includes the service type, host, and optional port number.
You can view the SPNs of an AD object by using the command: setspn –L hostname. In the example below, the command has been used to see the list of SPNs generated by a domain controller for a domain called ABCDomain.com
Importance of SPN uniqueness in an AD forest
Each service principal name must be unique throughout the entire Active Directory forest. This uniqueness ensures Kerberos can correctly route service requests to the proper account.Duplicate SPNs on different accounts cause authentication conflicts, resulting in unpredictable behavior or outright authentication failures.
Configuring SPNs: Step-by-Step Guide
Tools required for SPN configuration
The primary tool for SPN configuration is setspn.exe, which is built into the Windows Server operating systems. This command-line tool allows administrators to read, modify, and delete service principal names for Active Directory service accounts.
In a previous example, we used the setspn -L to view the SPN od a computer object. You can also use setspn -S to add a SPN. For instance, to add an HTTP SPN to a computer called webserver1, the command would be:
setspn -S HTTP/webserver1.abcdomain.com abcdomain\serviceaccount
Note that the setspn -S command automatically checks for existing identical SPNs before creating new ones to prevent duplicate entries.
To remove a SPN, use the setspn -D command. You can also use PowerShell in multiple ways for SPNs. For instance, the following PowerShell cmdlet will find all the SPNs registered in Active Directory:
Get-ADObject -Filter {servicePrincipalName -like “*”} -Property servicePrincipalName | Select-Object Name, servicePrincipalName
While this one will detect all the duplicate SPNs.
$SPNs = Get-ADObject -Filter {servicePrincipalName -like “*”} -Property servicePrincipalName |
Select-Object -ExpandProperty servicePrincipalName
Best practices for SPN registration
- Grant minimal necessary permissions to service accounts for SPN registration
- Use PowerShell to check for duplicates before registering a new SPN:
- Conduct periodic audits of SPNs to identify and remove unnecessary or outdated entries
- Use a standardized SPN naming format when adding SPNs
Troubleshooting Common SPN Issues
Duplicate SPNs can cause authentication failures and must be resolved. Watch for users reporting intermittent access problems as this could indicate SPN conflicts. You can use the setspn -x command to find duplicates within a single domain as shown in the screenshot below.
Use the setspn -F command to search the entire forest. To resolve duplicate SPNs:
- Identify the accounts holding the duplicate SPNs.
- Determine which account should legitimately hold the SPN.
- Remove the SPN from the incorrect account using setspn -D <SPN> <AccountName>8.
- Add the SPN to the correct account using setspn -S <SPN> <AccountName>
In addition to duplicates, some other common SPN misconfigurations include:
- Missing SPNs for services
- SPNs registered to incorrect accounts
- Outdated SPNs after server name changes
(No need to relist the same tools here again that we already covered)
Advanced SPN Concepts
The role of SPNs in multi-service and multi-host environments
Service accounts are specialized user accounts created for services running on Windows Server. They help isolate and protect domain accounts in critical applications like Internet Information Services (IIS). In complex environments, multiple services often run on the same machine, each requiring distinct Service Principal Names (SPNs) for proper authentication.
A common example is a server hosting a web application might run both SQL Server and IIS. Each service needs its own SPN to ensure correct Kerberos authentication:
- For IIS: HTTP/servername.domain.com
- For SQL Server: MSSQLSvc/servername.domain.com:1433
In multi-host environments, where a service runs across multiple servers for load balancing or failover, SPN configuration becomes more intricate. Consider a web application hosted across multiple servers (Web01, Web02, Web03) under a shared DNS name. In this scenario, SPNs must be registered on a single service account to allow seamless authentication across all hosts:
Special cases: HOST SPNs and their unique behavior
HOST SPNs are a special type of SPN automatically registered on computer objects in Active Directory. They act as a catch-all identifier for services running under a machine’s local system or network service account. This simplifies management for many standard Windows services and reduces the need for manual SPN configuration.
The following chart sums up when you should use HOST SPNs vs. Custom SPNs:
| Scenario | Use HOST SPN? | Use Custom SPN? |
| Running a service as Local System | YES | NO |
| Running a service as Network Service | YES | NO |
| Running a service under a Domain User Account | NO | YES |
| Multi-host service or Load Balancing | NO | YES |
Tip: You should never manually modify HOST SPNs as they are managed by AD.
SPNs and Security Implications
Why securing SPNs is critical in an AD environment
The reason why security is important for SPNs is simple. Service accounts often have elevated privileges. They also have continuous access to critical systems within the network and are often forgotten once they are created. All of this makes them high value targets by attackers. Compromising a SPN can lead to unauthorized access to critical services and potentially allow attackers to move laterally within the network and escalate their privileges
How weak SPNs can be exploited
When SPNSs are weakly configured, they can be exploited through attacks like Kerberoasting. Here’s how an attacker would carry out such an attack:
- An attacker with minimal domain privileges can request service tickets for any SPN Requests service tickets for these SPNs
- The service ticket, encrypted with the service account’s password hash, can be extracted and taken offline for cracking
- Performs offline password cracking on these and if the password is weak, attackers can potentially crack it and gain access to the service account, often with elevated privileges
Once the attacker cracks a service account password and if that account has high privileges, they can move laterally through the network or escalate their access.
Best practices for securing SPNs and service accounts
Below is a list of best practices to mitigate security risks associated with SPNs:
- Use long, complex passwords for accounts with SPN and regularly rotate them
- Avoid assigning SPNs to high-privilege accounts such as Domain Admins
- Restrict service accounts to only the permissions necessary for their function
- Disable interactive logon for service accounts
- Monitor for unexpected use of SPN-related commands in PowerShell.
- Since any user with domain authentication can search for SPNs, you should limit who can perform these queries by changing the permissions in Active Directory.
Detecting and Mitigating SPN Abuse
Continuous monitoring of your AD environment and auditing of Kerberos-related events can prove highly effective to prevent SPN abuse. Some of the things you should detect include:
- Unusual SPN enumeration requests as attackers may query AD for SPNs using LDAP tools.
- Frequent Kerberos Ticket Requests as any sudden surge in service ticket requests could indicate an attack in progress.
- Service account Logins from unexpected locations instead of the usual designated locations.
- Failed authentication attempts as repeated failures suggest brute-force or password spraying attempts.
Implementing mitigation strategies against SPN-based attacks
If your organization operates within a Windows Active Directory environment, you should consider the following preventive security controls to minimize the risk of SPN abuse and Kerberoasting attacks.
- Use long, complex passwords (absolute minimum 14 characters) for service accounts
- Prevent password reuse across different accounts and rotate passwords regularly
- Apply the principle of least privilege to limit account permissions.
- Enforce shorter Kerberos ticket lifetimes to minimize the attack window
- Regularly review and remove outdated or unnecessary SPNs
- Adopt a multi-layered defense strategy combining strong service account management, sophisticated monitoring, and regular training programs.
Using Group Managed Service Accounts and strong encryption methods
Implement Group Managed Service Accounts (gMSAs) to benefit from automated password management. Group Managed Service Accounts (gMSAs) are specialized service accounts in Active Directory that provide enhanced security features compared to traditional service accounts. They are particularly useful for domain-joined servers running services like SQL Server, IIS web applications, scheduled tasks, and other services that need to run in a security context with specific permissions. Utilizing gMSAs will eliminate manual password assignments and reduce credential theft risk. In regards to encryption, enforce strong AES128/AES256 Kerberos encryption while disabling weaker DES and RC4 encryption types in Active Directory.
Practical Applications and Use Cases
As mentioned, SPNs are used in Kerberos authentication for web applications and databases. IIS uses SPN in the format “HTTP/ServerName” which is mapped to the domain account running the application pool, while “MSSQLSvc/host.domain.com:1433” is an example of a SQL service account. The role of Service Principal Names (SPNs) is evolving beyond traditional use cases however, as enterprises increasingly adopt hybrid network architectures. Today we are even seeing SPNs facilitate secure authentication between on prem resources and cloud native applications. Other examples include:
- SPNs are being used to manage identities and access for containerized applications and services located in containerized environments.
- Edge environments use SPNs to facilitate secure communication between edge devices and centralized cloud resources.
- Azure AD Connect uses SPNs for synchronization services between on-prem AD and Azure AD.
There is also a growing use of SPNs within enterprise environments today. For instance, security teams are monitoring SPN usage logs to detect unauthorized access attempts or Kerberos failures. Other examples include:
- Single Sign-On (SSO): SPNs enable Kerberos-based SSO across multiple applications and services.
- Application integration: SPNs facilitate secure communication between different enterprise applications and services.
- Delegated authentication: SPNs allow services to authenticate on behalf of users for multi-tier applications.
Conclusion
Service Principal Names (SPNs) have been a cornerstone of Kerberos authentication since the inception of Active Directory’s inception. They have been a staple for many of the classic services that network users rely on and SPNs play a vital role in ensuring secure and seamless operations across numerous background services. As organizations continue to expand and evolve, the applications of SPNs are broadening into things such as cloud integration and IoT. With the growing emphasis on security in enterprises today, SPNs will most likely play a larger role, adapting to new technologies and security challenges in the ever-expanding digital landscape.
