We’re about to do a migration where we will migrate both Exchange and Active Directory. We’re confused about the use/need of SID History. We’ve seen some articles on the internet and heard from consultants and other “smart people” conflicting messages about SID History.
We want to do this the right way and not create issues for ourselves. So, should we migrate the SID History, or not?
The simple answer is: do NOT migrate SID History before users logon to the new domain.
The longer answer is this…
In the windows security model, access to an object is controlled by an attribute called a Security Descriptor. This attribute describes the owner of the object, system access privileges, and a list of one or more objects that have specific permission to the object.
Consider this simplified example:
Object: VirtualWidget
Name: Vader1
Owner: DOM-A\JoeUser
Permissions:
1: Creator/Owner = Full Control
2: DOM-A\RichMartin = Read Attributes
3: DOM-A\$SERVER-6 = Read, Write, Modify
Each object in AD has a security identifier that uniquely describes the forest, domain, type, and the object itself.
Some identifiers (the SIDs) are simplified and represent a well-known value. Creater/Owner, Self, Anonymous, Everyone, Administrator, etc. are some well known objects and their SIDs are simplified and don’t have forest/domain components.
Other objects have a fully qualified SID that uniquely identifies them in the domain/forest.
If I have an application that wanted to use the same security framework, I would need to know the SID of the user that wants to access my resources and would need to compare that SID against a list of SIDs that I have in my database and if there was a match, I’d allow access, provided rights were assigned (I could have the SID, but with no rights listed).
The key phrase in the above is that I would look “…in my database…”. So, if we installed my application in a new forest, and configured the my application to give RichMartin access to stuff provided by my application, some configuration would be necessary. Someone, after installation, would need to add permissions. Since my application is now running in the new domain, when I show a dialog to the admin to select an account, I would likely and naturally show users from the same domain/forest in which my application is running.
An admin would likely search for Rich, and if such an object were found, I’d save Rich’s SID in my database. However, the SID I saved would be the one from the target domain.
That should seem fairly simple and reasonable. Now lets imagine that my software is enterprise ready and has some understanding of multi-domain/multi-forest setups. Let say that in the user picker dialog I present to the admin, that there’s a button that lets the admin pick users from remote trusted domains.
The admin, being very smart here, changes the context of the selection to the source domain (DOM-A) and finds Rich. However, my application, also being very smart, get’s the SID back from the dialog and validates the SID to make sure no tricks are trying to be played on me – don’t want some clever hacker adding bogus SIDs to my database! So, I search AD looking for an account with the SID I received from the dialog. Well, guess what, Rich was found in the local AD forest because someone added Rich’s source SID to Rich’s target AD object as an additional SID.
My application then takes the SID of the DOM-B\Rich and writes that to the database. Later, when Rich attempts to access my data (which is now over here in the new domain), I compare that SID to my list of SIDs I stored. I don’t find a match because I never wrote the SID of DOM-A\RichMartin in the previous operation – I wrote the SID of DOM-B\RichMartin.
The fundamental thing to understand with SID History has to do with the second word of the term: History. By definition, history as a “back in time” idea. Migrating SIDs beforehand has no value at all if those same users are not logging in with the new account. And, as Zoltan shows and as I’ve said it only causes issues.
Context is the real focus here: which environment is providing the context of authentication to the resource. If a user is logging in at the source domain, he/she has a SID from the source domain. That SID must match in the list of SIDs that have been given rights. It’s a simple comparison routine “does this match that – nope, check the next one” and so on.
My rule that I provide to AD admins and architects is this: do NOT migrate SIDs except at the moment in time when the user will begin logging on with that new account. At that point, SID History does it’s job; it lets the user, who was authenticated in the new domain, access old resources in the old domain. When DOM-B\RichMartin attempts to access my data in my app, running in the old domain, my app is presented with multiple SIDs to compare with: the DOM-B SIDs and the DOM-A SID that was brought over by SID history.
