For many traditional domain migrations, the use of sIDHistory is a common vehicle to avoid disruptions. As users and groups are migrated to other domains, they inherit new SIDs. This is because SIDs are domain specific. So historically problems arose when users and groups attempted to access resources in the source domain. Because the DACLs (Discretionary Access Control List) of the source resources are still attuned to the original SID's, users who migrated to a new domain or forest would be denied access. So to circumvent this starting with Windows 2000 Microsoft introduced the sIDHistory attribute. The premise of this attribute is to store the users or groups SID from the previous source domain and append it to the access token along with their new SID. Now users and groups in the midst of a migration could have access to source resources like file servers that have yet to be migrated.

That being said, what is the problem? If users and groups have the ability to access their resources throughout the life cycle of a domain or forest migration, what is the issue? The problem we are finding is many of our clients never end up purging this attribute. So later on, when their company undergoes another consolidation or merger, the residual sIDHistory attribute sticks. So when a user generates a Kerberos access token, it not only represents their SID and the SID of all the groups they are participants of, but it injects the sIDHistory of these objects as well.

This swelling effect then becomes a problem because the Kerberos token has a maximum setting of 64k bytes. That means a user token exceeding 1015 SIDs can experience logon failures. This might sound like a lot, but in an environment where people have 2 or more instances of sIDHistory along with thick group membership, this value adds up quickly.

Though steps could be taken to depress the token swelling effect, such as reducing group membership, etc., the proper course of action would be to purge sIDHistory (provided the proper security address translation that was performed on server and workstation objects alike). The most direct way of doing this is using the outlined instructions at Vbscript.

 Vbscript

To learn more, please contact us at info@rutter-net.com

See more on Virtualization at the Rutter Networking Website