Active Directory: A practical way to clean up dead SPNs in Active Directory
Introduction
It’s been much more than a decade that Active Directory has published. This period of more than 15 years was big enough that most of the companies around the world are constantly moving their system from other directories to Microsoft Active Directory. Although Active Directory is one of the most common directories around the globe and organization are constantly co-op with this infrastructure, it cannot function without its underlying protocol for authentication which is called ‘Kerberos’.
There are so many articles published by quite number of experts or well-known organizations on how ‘Kerberos’ works so in this article we will not going to cover this topic. Instead we will be trying to focus on the most important concept of ‘Kerberos’ which is called ‘Service Principal Name’. Also, within this article, a custom PowerShell script will be introduced in a way which can be used in order to generate reports of ‘Service Principal Names’ in our Active Directory. But before talking about the script let us have a quick look at ‘Service Principal Names’ so we can gain a better understanding of the script.
What are ‘Service Principal Names’ or SPN?
To be honest, SPNs can not be explained very easily. As we said, SPNs are one of the most important concepts of ‘Kerberos’. So, it is better to have a solid understanding of Kerberos and how it works to have a better understanding of this article. If you enjoy watching and replaying videos instead of skimming and then re-reading the text, I highly recommend you do yourself a favor and watch my video about ‘Kerberos’. This video is published in my channel at YouTube and there is a link at the end of this article to this video. However, it is a bit long (nearly 50 minutes), but I talk on how an authentication will happen in Active Directory when you type your username and password and hit enter. So, priority number one: ‘Kerberos’.
But if you have not watched the video, I will explain it in 10 seconds. For authentication in Active Directory, you will need tickets, for having a ticket from Kerberos you will need to know the SPN, and for knowing the SPN you need to have the Hostname of the system in which you are trying to access. Having that set-in mind, you should conclude that Kerberos will work only if you are trying to access a resource using hostname and not IP.
SPNs creation process
SPNs are always present in Active Directory, even if you have a simple Active Directory domain of 10 users, they do the job in the background without any manual implementation. There are other cases in which SPNs are directly written to Active Directory by installation wizard of the service. For example, AFAIK, Backup Exec writes the appropriated SPNs directly. However, there are some cases that you need to manually define a SPN in Active Directory. One example is FIM 2010 R2. In case there is a problem in defining SPN or you do not define it properly, Kerberos will not work as expected and tickets will not be generated appropriately.
SPNs Removal
So SPNs are created automatically within Active Directory, but there is no way that guaranties that they are also deleted from the database when there is no request for them. By introducing more servers and services that use service accounts SPNs are created for them and when after some time those services are removed from Active Directory, the SPNs will rest in place if you do not have a proper way of cleaning user accounts. It is worth mentioning that there are many organizations that using the approach of “One-Account-All-Purpose” which is not a good idea however to use a single account for all services that need SPN.
Also, many organizations have good user life cycle management and they constantly monitor user accounts for their inactivity. In most of the cases, this type of account management is applied to simple user accounts and service accounts and administrators are exempted from this process. Once they are exempted, they do not get processed for their inactivity and SPN attributes. As a result, Active Directory database will end up in a situation where there are basically so many dead SPNs and there is no one to take care of them. This SPNs however are considered as data, and data in NTDS.DIT means more space in storage. Besides from that, I would like to hear about if there a security issue of having dead SPNs in Active Directory and if they can be manipulated in a way to help attackers to forge tickets and as a result escalate privileges. So, I invite security experts to share their opinion about this idea in the comments section.
How to clean dead SPNs
Since there is no built-in possible way to clean database of unwanted and dead SPNs, I developed a script in PowerShell for this problem. What this script does is so simple. It queries for all SPNs in Active Directory and categorize them into 5 different ways which will be covered in next section. However, this script will not delete anything from Active Directory database so there is nothing to worry about. Instead it will report all the SPNs and then based on the category that they are fallen to, you need to take proper action against them which can be either removing or ignoring.
A quick look at the report once it is generated will be like this:
Running the script
After downloading the script from here, the very first things to do in order to run the script is to “dot source” it within PowerShell. The simplest way to do this, is by adding two characters at the beginning of the script name when you have typed the name. Allow me to walkthrough on how to run the script by images.
Step 1
Change the directory to the folder where the script is located. Type “Get-SPN” and hit TAB. The name will be automatically completed if you are in the right directory.
Step 2
As we stated, you must type two characters. A dot “.” And a Space “ “. Then hit the enter. The script will be loaded into memory.
Step 3
Once the script is loaded into memory, you can simply calling the function by typing the name as “Get-SPNReport” and hit Enter in order to run the script.
Step 4
The script will do the rest of job which depending on your environment, will take some time. All you must do during this process is to wait.
Step 5
Once the script is complete, the report will be prepared and ready to view.
As you can see within the report, there are many information which needs to be explained. We will cover that in next section. In a nutshell, each row is basically representing a SPN within your database, so if you are seeing 200 rows in the report, you are viewing 200 SPNs of your Active Directory. We will be covering the details in analyzing section. The only point in mind is that due to security reasons and not breaching out the data of my production environment I had to change the name of domain to something different. Also, since the hostnames were so many, I could not change them to something else, instead I masked them with white spaces. Sorry for that!
Analyzing the report
However I had to mask some information within the report, the most important column, “SPN Status” is clearly visible and is not submitted to any changes. Look at the “SPN Status” column.
At this column, as the name states, you can see the status of each SPN in your Active Directory. This status is divided into 5 categories:
- Valid
- Valid (Child Domain)
- External
- Phantom
- Phantom (Semi)
Let’s discuss each category with more detail. The first category to discuss is “Valid”. This column is basically informing us that there is nothing with this SPN. The hostnames are accessible with no problem. I included a separate column for user account status, so in case the status is “Valid” but the user account is not enabled, you might remove this SPN after testing one of them and assuring that they do no harm.
The second category is “Valid (Child Domain)”. This category indicates that the SPN is valid and the hostname is accessible, however this hostname is located in another domain in the forest. Again, the same approach can be taken against this group as the “Valid” ones.
The next category is “External”. This category means that the domain which the SPN is configured is not within the forest. So, it is considered as an external SPN where the hostname is not traceable. Use this for report purposes. If you really want to remove these SPNs, you need to find out what are those external domains are responsible for or even if those SPNs are really in use or not.
The next category is however the key. This category is called “Phantom”. These SPNs are bad! Basically, when you see an SPN like this, it means that the hostname configured for that SPN is not trackable. A common case of why these kinds of SPNs appear is installing services and creating SPNs but uninstalling them months or years later without even cleaning the SPNs. This is one of the problems that will arise when service accounts are not used for each service. Because mostly service accounts are created based on a single service and once the service is uninstalled, they will get processed by the cycle of user management. As a result, when the service is uninstalled, the service account will be disabled or deleted automatically. The very quick solution for this SPNs are removing them.
The last category is called “Phantom (Semi)”. These SPNs will probably have no domains configured for them. However, when the domain is empty, the script will try to find a match in local domain and if not found, it will contact a Global Catalog in local site to check other domains. In case all of this process fails, it will be tagged as “Phantom (Semi)”. These type of SPNs can appear when a local service (messaging, ticketing …) is established and acting as a standalone server which needs Kerberos tickets. A proper action against this SPN is to query the service to see who the owner is and then question the usage of SPN or use the approach of ‘Hit and Wait’ which basically is removing the SPN and see what will fail to find the owner.
Conclusion
In this article I tried to explain a little about the SPN and their function in accessing a service using Kerberos. SPNs are the requirements for a healthy Kerberos, otherwise there will be no tickets. Although the writing of SPNs in Active Directory is done either using installation wizards or the commands, there is no automated way to clean the orphaned SPNs when their parent service is uninstalled.
Using the method presented in this article, you can have an informative report of all the SPNs in your Active Directory and check for orphaned SPNs. The method in this article will not remove or cause any changes within Active Directory database, so it is up to the audiences to check the result and take proper actions.