If you are work with Active Directory (AD) for any reasonable amount of time, you may have come across the term SPN or Service Principal Name. But what is an SPN? Why is it important? Why does it matter?
I wore this blog post, sort of trying to remind myself about this concept, and how I can save this for my future self.
What is an SPN?
An SPN is a sort of an alias for an AD object. It can be added to a Service Account, User Account, or Computer object. It’s purpose is to let other AD resources know which services are running under which accounts and creates associations between them in AD.
For example, imagine you have an IIS web server running on a computer named WEBSERVER01, and IIS is running under a service account named svc_web. If you want clients to authenticate to the web service using Kerberos, you need to register a SPN for the service account svc_web, such as HTTP/WEBSERVER01. Once done, clients can request a Keberos ticket for HTTP/WESERVERB01 and authenticate to the web service.
Why are SPNs important?
As established above, SPN’s are used for Kerberos authentication. This comes with a few advantages:
Improved security by using strong authentication between client and server;
Less network traffic and Domain controller load for authentication, due to the use of cached Kerberos tokens;
Simplified service account and permission management;
Potential scalability benefits, due to the previous points.
Unfortunately it’s not all roses. SPN’s do come with a few drawbacks as well:
SPN’s must be unique and properly registered for each service and instance, or they can cause authentication errors and security issues.
SPNs can be vulnerable to spoofing or replay attacks.
SPNs can cause performance issues for the network and domain controllers. Requests a service ticket for an SPN that is not registered or is registered to multiple accounts, will force the domain controller to search the entire AD database to find a match or return an error.
How to manage SPNs in Active Directory?
You can create a SPN using Active Directory Users and Computers (ADUC) or command setspn. PowerShell can also help to manage SPN’s, by adding the -ServicePrincipalNames to Get-ADUser or Get-ADCOmpouter cmdlets, for example.
Tradicionaly, the setspn -L <samaccountname> command is used view all the SPNs registered to a particular account. Setspn can also add and remove SPN’s for an account by using the switches -A or -D as show below:
setspn -A HTTP/WEBSERVER01 svc_web
Conclusion
SPN’s can be very useful and every sysadmin needfs to understand how they can be used and how they must be managed.
I hope this helps any reader, besides myself, to better understand this tool and to make good use of it.