Active Directory Migration – How to remove sidHistory after migration – Part 1

About sidHistory

In almost all Active Directory Inter-Forest migration scenarios the sidHistory functionality of Windows Server plays an important role to maintain resource access from migrated users to their not yet migrated Windows resources (e.g. file shares, Exchange mailbox etc.).

The sidHistory attribute of a migrated user in the target domain contains the SID of the original user from the source domain. When the user logs on with his/her account to the target Active Directory domain, the security token generated by the DC, contains both, the SID of the actively logged on target user account and the SID of the source user account of the source domain. If the user now accesses resources in the source domain, the target account and the source account SID are presented for ticket granting process. This ensures that the user can use his/her resources seamlessly, no matter if the resources are located in the source Forest or are migrated to target Forest already. An alternative to using sidHistory is the re-ACLing of the resources in the source Forest, which can be a large, long running task.

NOTE: SidHistory does not work in the following cases:

• SID Filtering is enabled on the Forest Trust or Domain external Trust Relationship
• For all permissions that are set by using well known SIDs (like Domain Users, Account Operators etc.). Those well-known SIDs are filtered out by default when accessing resources over the trust.
   

Disadvantages of sidHistory

Although sidHistory is a very big help in Inter-Forest Active Directory migration, it challenges all security considerations at the same time. A rogue administrator can add the SID of a given user account to his account’s sidHistory and thus gets access to the user’s resources. Another disadvantage is the blow up of the security token of a user account, since when using sidHistory, the token contains the SID of the account and the SIDs of all groups where the account is member of + the source account’s SID  and all SIDs of all the groups from source domain – assuming the groups have been migrated. There is a system limitation on token size which allows a maximum of 1015 groups. Using sidHistory for groups every group membership in a migrated group counts twice. If the source user is member of 550 groups in source domain and all groups have been migrated to target domain with sidHistory, the target account will most likely not be able to log on, because the security token is bloated. As long as the groups contain their sidHistory from before the migration, the group membership of users must be monitored constantly.

For Active Directory limits check here:

(http://technet.microsoft.com/en-us/library/active-directory-maximum-limits-scalability(v=ws.10).aspx#BKMK_Groups)

RECOMMENDATION: Taking into account the security and system related disadvantages of sidHistory, we recommend removing the sidHistory value after migration of accounts and resources.

In Part 2 of this thread we will show some ways to remove sidHistory values which is not possible via ADUC and ADSIEDIT and other LDAP based tools.