After completing multiple cross-organization migration projects with differing co-existence periods, I’ve found myself having to go back to the books for a refresher course on intra-forest migrations. Among the many differences on how to approach and implement a migration intra-forest versus inter-forest, one of the most important is how Active Directory objects are migrated between domains.
When working with separate forests there will typically be duplicate instances of all objects considered "in-scope" for a given project, as each source object will have a matching target object. This offers the ability to deploy and test many scenarios in the new target domain before actually moving a production user or resource into the target domain. But when migrating objects to another domain within the same forest, only Computer account are left in the source domain. All group and user accounts are effectively moved, by deleting the source account and creating a new copy of that object in the target domain, retaining many of the original attributes.
One of the account attributes that is changed from the source is the Security Identifier (SID), as each domain obviously contains it’s own unique set of IDs. When sIDHistory is enabled during a migration, the source object’s SID is inserted into the sIDHistory attribute of the new target object, effectively allowing the new account to access resources in which the old account was explicitly granted permissions.
When using the Active Directory Migration Tool (ADMT) it is recommended to routinely run the Security Translator Wizard after each migration set to insure that resources still in the source domain, as in shared folders on member servers, have the Access Control Lists (ACL) updated to reference an account’s new SID. The tricky part is understanding what is actually happening behind the scenes between the separate object migration and security translation steps, as viewing the Access Control Entries (ACE) displays the common names and masks the actual value of the individual entries (the SIDs themselves).
To demonstrate the changes, we’ll use a simple shared directory on a member server in a source domain. The ACL for the NTFS folder is configured to allow modify access to the global group OLDA_TestShare_GG. This group contains 4 user accounts that also reside in the source domain, named OLD.
Next, we’ll migrate that group into the target domain using ADMT. Once the process is completed the global group no longer exists in the source domain and is created as a new universal group in the target domain. (If all members of the group currently reside in the target domain as well, then ADMT will convert the group scope back to the original global group setting. But if any unmigrated users or groups still exist as members, ADMT can’t yet change the group scope as global groups cannot contain members from domains other than itself.)
If we take a look at the permissions on the folder now, the domain portion of the path has changed to reflect the groups new location, NEWA_TestShare_GG.
It is important to point out that at no time did the ADMT Group Migration wizard modify this ACL. The updated path to the new object is displayed because of the functionality of sIDHistory.
First, let’s find out what the original and new SIDs are for the group in question is it will be easy to identify and confirm the following steps. Using the Windows Server Resource Kit tool whoami.exe while logged on as a user in the group A_TestShare_GG will display each SID in the user’s latest security token:
C:whoami /groups /sid
[Group 1] = "OLDDomain Users" S-1-5-21-3725033245-1308764377-180088833-513
[Group 2] = "Everyone" S-1-1-0
[Group 3] = "OLDA_TestShare_GG" S-1-5-21-3725033245-1308764377-180088833-5314
If we step back to look at the individual ACEs of the folder but this time view the raw SID hiding behind the common name, we can see how sIDHistory actually works. The command fileacl.exe can extract the raw SID values in the access control entries, shown here:
C:>fileacl testshareGG /rawsid
C:\testshareGG;S-1-5-21-3725033245-1308764377-180088833-5314:RWXD
C:\testshareGG;S-1-5-32-544:F
C:\testshareGG;S-1-5-21-3725033245-1308764377-180088833-513:RX
C:\testshareGG;S-1-5-18:F
Executing this command before or after the group migration will return the same results, as the ACL is NOT modified by the Group Account Migration Wizard in ADMT. But the reason the display name changed in the GUI after migration is because the SID contained in the first ACE was resolved to the sIDHistory attribute of NEWA_TestShare_GG.
So at this point the users in the migrated group A_TestShare_GG still have the proper access to the folder because their security tokens contain the SID from the sIDHistory attribute of this group.
But since it is recommended to update ACEs to include the primary SID of migrated objects, this is where the Security Translation Wizard comes into play. When it is run for previously migrated objects against the member server containing the shared folder, only THEN is that access control list modified. Because the ADMT database knows both the old and new SIDs of all migrated objects, any ACEs containing the old SID are updated to contain the new SID.
After running the Security Translator, no changes can be seen when viewing the folder’s access control list through the GUI, as the updated group path and name was already displayed when we looked earlier.
But when the raw SIDs are viewed, we can see what has actually changed behind the scenes: the first ACE now shows a completely different SID then before, which correlates to the target account’s primary SID.
C:>fileacl testshareGG /rawsid
C:\testshareGG;S-1-5-21-1498467717-2710971069-1432213540-1138:RWXD
C:\testshareGG;S-1-5-32-544:F
C:\testshareGG;S-1-5-21-3725033245-1308764377-180088833-513:RX
C:\testshareGG;S-1-5-18:F
