Explanation of Service Principal Names in Active Directory.
In this article, we’ll talk about identity management in Windows Server 2016. Specifically, we’ll talk about SPNs (Service Principal Names) and how beautiful they are.
First of all, SPN is similar to an alias for an AD object, which can be a service account, user account, or computer object that allows other AD resources to know which services are running under which accounts and creates links between them in Active Directory.
There are several ways to check which SPNs are assigned to an object. One is through Active Directory Users and Computers and the other is through the command line.
View SPNs in Active Directory
To be able to see SPNs by Active Directory users and computers, you need to enable additional functionality in the console by going to the View menu. Once enabled, navigate to the desired AD object, select Properties and go to the Attribute Editor tab:
Then find the servicePrincipalName attribute and click Edit. Here you will see a list of all SPNs, as well as the option to add SPNs.
Another way is to use setspn –l on the command line to view the SPNs for that particular object.
We can also add other SPNs to this object, depending on which object is hosting, which type of service, and so on.
Create an SPN in Active Directory
Let’s say we have a new service and we want to add an SPN so that other AD resources can find out which server hosts this service and which user it is authenticating with.
First, let’s create a service account in Active Directory.
New-ADServiceAccount -Name MSA-syslab-1 -RestrictToSingleComputer
We will now link the managed service account to our server.
Add-ADComputerServiceAccount -Identity rmc-syslab-1 -ServiceAccount MSA-syslab-1
Then let’s set up this service account on the server.
Finally, let’s create our shared service.
New-Service -Name GENSERV -BinaryPathName C: Windows System32 notepad.exe
We now use the setspn –s command, which creates an SPN and uses the –s switch to make sure there is no duplicate SPN.
setspn -s GENSERV / rmc-syslab-1.rmcsyslab.com rmcsyslab MSA- syslab-1
The command adds a GENSERV service hosted on rmc-syslab-1, running under the MSA user MSA-syslab-1. Now it remains to configure the service to work under an MSA account.
As you can see in the Logon tab in the service properties, I configured an MSA account and left the password field blank as we know MSA passwords are managed by Windows.
Now let’s check the service account and see which SPN was added to it.
As you can see, it has the SPN GENSERV / rmc-syslab-1.rmcsyslab.com, since this user logs in and authenticates this service.
Well, that’s about SPN for now. Remember that SPNs are very sensitive. You should only go deeper into this if there is a problem or if you are creating some kind of special service.
Thanks for your time, I hope you found this article interesting. Enjoy!