- Docker logs tail: Troubleshoot Docker containers with real-time logging - Wed, Sep 13 2023
- dsregcmd: Troubleshoot and manage Azure Active Directory (Microsoft Entra ID) joined devices - Thu, Aug 31 2023
- Ten sed command examples - Wed, Aug 23 2023
What is a service principal name (SPN)?
The service principal name is used for mutual authentication between a user and a service account. Essentially, SPNs help with Kerberos authentication, enabling users to connect to services without providing their credentials multiple times.
They associate a service with a service account or computer account. When a client wants to access a service, it locates the SPN of the service in Active Directory. The SPN combines the service name with the hostname, providing a unique identity for a specific service on a specific computer. This naming combination allows multiple services to run under a single hostname, each with a distinct SPN.
Windows Server and SPNs
A domain-joined Windows Server helps manage SPNs automatically. When services that require SPN registration are installed (such as Microsoft SQL Server), Windows Server automatically generates default SPNs. However, some scenarios require manual modification.
Active Directory Domain Services manages both the service principal names and the associated Active Directory service accounts. An SPN is a unique identifier for each instance of a service. If two instances of a service are running on different computers, they will have separate SPNs within the domain.
Permissions needed to modify SPNs
Modifying service principal names in Active Directory requires specific permissions. These permissions are typically granted to domain administrators but can be delegated to other accounts if needed. Here are the permissions required:
Write ServicePrincipalName permission
The Write servicePrincipalName permission is required to modify SPNs. This permission can be assigned to a user or group using the Security tab in the Active Directory Users and Computers snap-in or using the dsacls command-line tool. This permission allows an account to add or remove SPNs from the servicePrincipalName attribute of a user or computer account.
Validated Write to Service Principal Name permission
The Validated Write to Service Principal Name permission is a more specific permission that allows an account to register an SPN to its own account object. This permission is typically used with service accounts and enables the service to register its own SPN dynamically.
Self permission
In addition to the above permissions, the Self permission allows a service account to modify its own SPNs, provided that it also has the Write servicePrincipalName and Validated Write to Service Principal Name permissions.
Managing SPNs using setspn
The setspn tool is the built-in tool used to read, modify, and delete service principal names in Active Directory. It provides many options that allow admins to view, reset, add, or delete SPNs in AD DS.
You can run setspn -? or simply setspn from an elevated command prompt to see the available options.
To view the current SPNs associated with a specific account, you can use the setspn -L command, followed by the account name. With this command, you can view all the SPNs registered to a particular user or service account.
setspn -L accountname or setspn -L localhost
Register, delete, and reset SPNs
setspn includes switches that allow you to add, delete, and reset SPNs. When registering a new SPN, you can use the setspn -A command.
For example, to add an SPN for a service account for SQL Server, you would use the following:
Setspn -A MSSQLSvc/<server name> <service account>
To remove an SPN, use the setspn -D command. For example, use the following:
setspn -D <registered SPN> <service account>
The setspn -R command can be used to reset the hostnames associated with the SPNs for a computer. This command is useful if you see incorrect names for server SPNs displayed.
For example, use the following command:
setspn -R <server name>
Setspn and SQL Server
Like many other services, SQL Server relies on SPNs to function properly. SQL Server uses SPNs to authenticate and secure connections. An incorrectly configured SPN can lead to authentication errors and connection failures. You may have seen errors similar to the following in error logs on a SQL Server with SPN issues:
Cannot generate SSPI context
Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'. (Microsoft SQL Server, Error: 18456)
Login failed for user ‘(null)’
Login failed. The login is from an untrusted domain and cannot be used with Windows authentication.
The setspn command is an invaluable tool for troubleshooting and correcting SPN issues with SQL Server. Often, SSPI errors with SQL Server indicate that the SQL Server has an SPN registered in Active Directory that does not match the service account under which it is running.
You can use the setspn -L command, as shown above, to check entries for the SQL Server or the service account under which it has been registered after modifying SPNs or making changes.
Handling duplicate SPNs
Duplicate SPNs can also cause authentication issues. The setspn tool provides a way to identify duplicate SPNs. With the -X switch, setspn will check the entire domain for duplicate SPNs and report any it finds.
Wrapping up
Service principal names are essential for authentication and access to critical services, such as Microsoft SQL Server. Incorrect, duplicate, or missing SPNs will cause a wide range of issues that can create challenges in troubleshooting. The setspn command line tool provides the capabilities needed to check SPNs and ensure they have been properly configured and match the service accounts configured for application services.
This is one of the best articles I’ve seen on SPNs.
Excellent background explanation and easily relatable configuration!