A Data Migration Mystery Solved – Can an Active Directory Object Have Two Security Identifiers?

Recently, I was working with a customer who wanted to test using a Security Identifier (SID) Map file in DobiMigrate. For those unfamiliar with SID mapping, DobiMigrate has the ability to replace source SIDs with new SIDs as the data is written to the destination file server, and can do the same for User IDs (UIDs) and Group Identifiers (GIDs). This is very useful in various circumstances, such as if your organization acquired a new company and you need to merge user data into your domain. 

Creating a SID Map File with DobiMigrate

The process to create a SID map file is quite easy. You simply create a CSV file with the source SID or domain user/group, and the destination SID or domain user/group separated with a comma. The format is {source user/group SID},{destination user/group SID}.

For example:

S-1-5-21-1856787266-2252976897-2088865751-1131,S-1-5-21-2359887231-7699783452-0401289234-2001

Or

OldDomain\JSmith,NewDomain\JSmith

Or

S-1-5-21-1856787266-2252976897-2088865751-1131, NewDomain\JSmith

In this case, the customer chose to create the file with domain groups. The SID map file was applied to the DobiMigrate advanced SMB options, and a metadata update was run to update all the data already written to the destination. 

After the update completed, we began verifying the data and to our surprise none of the SIDs were replaced! So, the customer and I began to troubleshoot the issue because there had to be something incorrect with the file. SID maps are generally easy to use and 99% of the time it is a problem with the formatting in the file, but in this case, there were no formatting issues. 

The customer opened Windows Explorer to the source share and showed the security properties of random directories and files to verify that the domain groups in the mapping file were correct. They were perfect with no typos. 

Next, he opened PowerShell and performed a Get-ADGroup against one of the groups and it returned everything you would expect for a valid account. As we both scratched our heads trying to figure out what was happening, I decided to cross reference the SIDs in the mapping file against what was listed in the DobiMigrate File Browser.

You can view the contents of a SID map file in the DobiMigrate SMB advanced options by clicking on the ‘Details’ view (the eye icon). What is nice about this view is it will also list the resolved SIDs beside the users and groups if you choose to use the friendly user/group names rather than SIDs in your mapping file. I captured a screenshot of the values and then navigated to ‘File Browser.’ The File Browser allows you to browse the file systems on any configured source or destination file server using the DobiMigrate SMB and NFS proxies. It provides a read only metadata view of the file/directory size, attributes, time stamps, and NTFS and/or UNIX permissions. 

Using the File Browser, we were able to see that the source SID on the file system did not match the SID listed in the SID map file that DobiMigrate resolved. How could this be? Was DobiMigrate incorrectly resolving the SIDs? Even more strange was that the customer performed a lookup against both SIDs and both resolved to the same group!  How can it be that one Active Directory object could have two different SIDs?

The answer is SID History.

Using Two Active Directory SIDs to Migrate Data

The Active Directory SID history attribute for an object allows an account to essentially clone another account by using a second SID. This is used most often when migrating users and groups to a new domain. Active Directory migrations tools will move the users/groups to the new domain. These objects will get new SIDs, and their old domain SIDs will be added to the SID History attribute, and this effectively allows an object access to resources where either SID is used.

In this customer’s situation, they had the historic SID written to the source file server NTFS permissions. The SID lookup by DobiMigrate to the domain controllers returned the new SID. When the metadata update was run to replace the SIDs on the destination, DobiMigrate was unable to find a match in the SID map file so no changes were made to the destination. The customer was able to resolve this problem by creating a new SID map file using the historic SIDs for the source, and the friendly group name for the target. 

…and that’s how an Active Directory object can have two SIDs.

Learn more about DobiMigrate.