If Your SIDs Don’t Match, Your Active Directory Migration is in TroubleJuly 11, 2014
How can you complete an Active Directory migration when your accounts have a different name from those in your destination domain?
Here’s the situation: You want to perform an AD migration, but you have already created accounts in the destination domain and those accounts have a different name than your original ones. Maybe you already tried to migrate those accounts and are wondering why the names aren’t matching up. What should you do?
First of all, your problem is not uncommon. If fact we’re seeing more of this in both medium and large enterprise migrations. Why? As many companies get ready to move to the cloud (such as with Microsoft Office 365), they decide on a new naming convention — and ta-da! — it’s created. The problem occurs when your source accounts don’t match your new accounts. In other words, there is no mapping or connection between the source (original) name and the target (new) name. Surprised? Don’t be. Right now we’re working on a 30,000-user migration that has four domains and a mish mash (technical term) of naming conventions. Again, you are not alone.
Let’s review two basic components to help unravel this. There are only two unique items in any domain or Active Directory—your samAccountName (which is your logon name or user-friendly name) and your SID (which is the security identifier for your account). Every time a new account is created, a new SID is created. If the new domain has a different samAccountName and a different SID, there’s no easy way to correlate the source domain with the new domain. That’s why when a company creates a new naming convention (after moving to Office 365, for instance) and a user tries to connect to resources such as files, folders and email boxes, they no longer have any rights to read or access anything! It’s as if the resource doesn’t exist.
You might ask: don’t all migration products have a correlation engine to create the association between the two accounts? Not all, and not to the extent you may need. What’s really happened is that the new account has been created without any correlation between the source and the target. This has resulted in two separate accounts—the source and the target—one completely disconnected from the other.
From our experience, most migration products out of the box don’t do it right; and self-serve migrations rely too heavily on the user for success. Users are neither reliable nor predicable when it comes to Active Directory migration behavior, so we typically do not recommend those products. How to resolve this scenario?
Option #1: If you choose to change the samAccountName, you could start by writing scripts that would modify everything. You could also supply the correlation field ahead of time, put it into a delimited file, and automate the process. This may be time consuming and may not completely solve the problem.
Option #2: Use a migration product that can create a scenario between Active Directory attributes that match up—something unique that connects the origin and the destination name, such as an employee ID number. Perhaps you could use last name and first name to match up, or a description field, or even multiple attributes to create a match. Binary Tree’s SMART Active Directory Migrator software has all of these capabilities as well as the flexibility to apply multiple attributes.
Remember, the first step to using any software is to discover what all of the problems are (or may be) and determine their cause. In other words, planning can make all the difference for a smooth and uninterrupted AD migration—or fixing a botched one.
In the end, the only thing that matters is that the user has no disruption! Active Directory migrations should be invisible to the user. That’s my motto!