Active Directory Insights (Part 11) – sIDHistory

If you would like to read the other parts in this article series please go to:

Active Directory uses the Kerberos v5 authentication protocol and its extensions for verifying the identity of users and hosts using a system of public key authentication, authorization data transport and delegation. While Kerberos authentication usually works as designed in Active Directory environments, there are some issues that can cause problems under certain circumstances, particularly in environments where Microsoft Exchange has been deployed. Several of these issues revolve around a parameter called MaxTokenSize which determines the maximum allowed size for a Kerberos ticket. For background information on how the Kerberos protocol is implemented in Active Directory see, and for an explanation of the basic concepts of the protocol see

In this article and the next of this series we will explore such issues with the help of Justin Harris, a Microsoft Most Valuable Professional (MVP) and Microsoft Exchange Certified Master who will explain the underlying concepts, highlight some of the problems that can occur, and describe some remediation steps you can take to ensure the resiliency of your environment. Over the past 18 years, Justin has worked with a global customer base to deliver enterprise-level messaging, unified communications, and cloud-enabled virtualization solutions. Justin is one of a handful of professionals globally who holds the MCM/MCSM and MVP designations with Microsoft for Exchange. Justin can be found on Twitter at @ntexcellence and on the web at

In this first article Justin will delve into the underlying concepts of SIDs and sIDHistory since understanding these concepts is essential for understanding how MaxTokenSize works and why certain problems can happen in Active Directory environments. Then in the next article in this series, Justin will explain MaxTokenSize in detail and describe various steps that can be taken to remediate some of the issues that can arise with respect to this parameter.


For the last eighteen years, I have been working as a Microsoft IT Pro and have learned some valuable lessons. One of the most critical lessons that I have learned is to avoid those pesky “uh-oh” moments. You know the one – the sinking feeling in your stomach when you instantly realize that the server you restarted did not reboot properly and oh by the way has missed the last 2 weeks of backups; been there and lost sleep over those sort of moments. Forging a successful career in this industry will teach you (sometimes the hard way) that preparation is key!

Working as a consultant in the Exchange migration field all these years has really enabled me to appreciate the value of preparation, process and documentation. These items drive successful Active Directory and Exchange migration projects for customers and enhances the value in the service that I provide. Sometimes though, as a consultant, you have to work with what the customer has and help them navigate the murky migration waters. Yes, even with the best intentions, problems can arise.

If not quickly remediated, enterprise wide problems can quickly turn into a demoralizing event for the administrator. There is nothing worse than spending months working with a customer to migrate Active Directory or Exchange and you discover a sporadic problem that is seemingly impossible to nail down and remediate; this puts you and the client in a precarious situation.

A common example of this issue in action that I have seen is with Kerberos MaxTokenSize issues. Kerberos problems like this have proven tricky for me more than a few times over the years.

This can quickly become a complex subject to tackle. While it may be easy to write a short article that provides pinpoint guidance on how to mitigate MaxTokenSize issues, there are a lot of nuances to these problems that deserve the full story to be told. My goal is to equip you with the information required to completely understand why and how the problem is happening. For this reason, I’m going to take a broad approach and start by explaining security identifiers, sIDHistory, Kerberos access tokens and finally MaxTokenSize.

First, lets set the scene by defining examples of these problems and then discuss what can attribute to the creation of these issues.

Examples of problems

Typical symptoms of MaxTokenSize issues are small subsets of users that are not able to log in to resources or applications that they normally have access to. This type of behavior can be exhibited when trying to access a file or folder, IIS resources, a Group Policy Object not applying to certain users, SQL errors, or even when a user is trying to access Exchange for mailbox access or free/busy information using Outlook! Basically, the administrator will see that authorization errors randomly arise for a small subset of users. One day things work and the other day they do not. This behavior will quickly frustrate end users and prevent them from accomplishing their day-to-day tasks. It is up to us administrators to resolve this problem as quickly as possible.

What can cause these issues?

In my experience these issues can always be attributed to a cross-forest migration where sIDHistory was brought over or a user is a member of way too many Active Directory groups. Oftentimes, these two issues go hand in hand. While tracking down the symptoms in the enterprise may not be so easily stated, the reasons for MaxTokenSize issues are.

Let’s start the technical discussion and identify what a security identifier is.

What are SIDs?

Oftentimes, during Active Directory migrations, trusts are set up between the source and target forests. These trusts help to provide a level of coexistence by allowing security principals that have been migrated to the target environment to reach out and access files and resources housed in the source Active Directory environment. A common practice during long term migrations is to leverage the SID-History (sIDHistory) attribute for target Active Directory users to help facilitate the coexistence story during a project. You may ask how the sIDHistory attribute contributes to providing coexistence.

Let’s go back to basics here and examine what a SID is before we go into detail and define sIDHistory.

When you create a new user account (or group) within Active Directory each security principal is stamped with a set of attributes that are tied to the domain that the account resides in. For instance, when a new user account is created within Active Directory a unique security identifier (SID) is generated and stored in the Object-SID (objectSID) property of the user object. The object-SID property has been coded to prohibit multiple entries from being stored thus ensuring that a user’s SID is unique.

A SID itself is made up of several different groupings of numbers that are extremely important to understand as they describe the structure and domain membership of the account. There is a domain identifier portion of the SID which is uniquely tied to the issuing domain. There is also a relative identifier portion of each SID to help provide uniqueness as well. These relative identifiers (RID) are actually provided by domain controllers within the domain the account was created in.

Each domain controller is provided a unique grouping of RIDs by the domain controller that holds the RID Master FSMO role. This method ensures that only one domain controller, the RID Master, can hand out groups of RIDs to ensure that domain controllers do not duplicate RIDs within the domain. When a domain controller hands out all the RIDs in the pool that were initially allocated, the domain controller will simply request an additional allocation from the RID Master.

So how can you see what the value of a SID for a single user is? Using the Active Directory Users and Computers tool to verify the value contained in the objectSID property is the easiest method as shown in Figure 1. First, you will want to turn on the advanced features within the Active Directory Users and Computers tool by selecting the View dropdown and clicking on Advanced Features. At this point you can navigate to a user and right-click the account and choose Properties. Within the user properties dialog box select the Attribute Editor tab and scroll down to the objectSID property.

Figure 1:
The objectSid field in the Attribute Editor tab for the properties of user Joe Black

The important concept in the context of this article to keep in mind is that when a user object moves from one domain to another, a new SID must be generated for the user account and stored in the objectSID property. Remember, the relative identifier portion of each SID is tied to the issuing domain and cannot be used successfully in a new domain. So you cannot take the objectSID property of a source account and simply inject the value into the objectSID property of a matching user in a target domain. The objectSID property is what allows the security principal to remain unique within the domain and provides the mechanism that can be used for authorization.

What is sIDHistory?

Ok, now that we have a firm grasp on what SIDs are and how they work let’s examine what sIDHistory is. During cross-forest migrations each account in the source environment is synchronized or migrated to the target environment. We know that this creates a new objectSID for the user which is different than what existed in the source environment. So for example, if a user that has been migrated tries to access a file share in the source environment for which they previously had rights (with their source account) they will be denied access (even if a trust has been setup). The simple reason for this is that the account in the target Active Directory has a different objectSID which does not match the SIDs that have been granted access to the resource in the source environment.

When dealing with an Active Directory migration, we need to keep in mind how the permission model works behind the scenes. Active Directory uses SIDs in access control entries to identify what users are allowed or denied access. When a user logs into a domain, a domain controller queries the user’s objectSID property along with the SID for each group they belong. All these SIDs are then added to an access token for the user.

So when a user tries to access a file share within the domain they present his or hers access token that contains all their SIDs. If one of the SIDs in the user’s access token is listed on the configured permissions of the file share to grant access – they are provided access to the resource. Likewise, if one of the SIDs in the user’s access token is listed with a deny permission – they are denied access to the resource.

When talking about this scenario, I like to use the example of keys on a key ring. We can link a user’s access token to a key ring and each SID that they have is simply a key on that key ring.

Luckily, Microsoft has made provisions for the limitations of SIDs when performing cross-forest migrations. When creating a new user in the target Active Directory that matches a user in the source environment we can utilize the sIDHistory attribute found on user objects. The sIDHistory attribute can hold multiple values unlike the objectSID attribute. The reason for this is that the sIDHistory value exists to allow administrators to store all the old SIDs (keys on the key chain) that previously existed for the user in the source Active Directory. This means when the target user authenticates against a domain controller in the target domain, all their SIDs and all the values found in the sIDHistory field is added to the user’s key ring.

You can quickly see the values contained in the sIDHistory field in much the same manner that we used to examine the object-SID of a user. Using Active Directory and Computers we can scroll down to the sIDHistory field within the attribute editor tab for a specific user as show in Figure 2.

Figure 2: The sIDHistory field in the Attribute Editor tab for the properties of user Joe Black.

Leveraging the sIDHistory field during cross-forest migrations is a great resource to help provide coexistence, but it is not free of issues. As the key ring (access token) grows for migrated users, the larger the access token becomes. Remember, each group that the user is a member of is represented with a SID as well. If groups are nested inside of each other this dramatically increases the number of SIDs maintained within a user’s token. This scenario is typically referred to as token bloat. Therein lies the problem with sIDHistory.

If not closely monitored, authentication requests will start being denied for users that present a token that exceeds the maximum token size (MaxTokenSize) configured on the remote server. This means that a subset of your user base could start having problems accessing Exchange mailboxes with RPC/HTTP, SQL, and even with Group Policy Objects applying.

Alas, solving one problem only introduces another one, namely the issues associated with sIDHistory which will be discussed in the next article in this series.

Still got questions about Active Directory?

If you have any questions about domain controller hardware planning, the best place to ask them is the Active Directory Domain Services forum on TechNet. If you don’t get help that you need there, you can try sending your question to [email protected] so we can publish it in the Ask Our Readers section of our newsletter and see whether any of the almost 100,000 IT pro subscribers of our newsletter have any suggestions concerning your problem.

If you would like to read the other parts in this article series please go to:

About The Author

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top