In planning your Active Directory migration, have you decided how to handle SID History, the glue that sticks your legacy permissions to your current domain?
We’ve been posting about the top security considerations in an Active Directory migration and I feel that security identifier (SID) History deserves its own discussion.
The background of SID History
SID History is an attribute in Active Directory (AD) that provides backward compatibility when you have not re-permissioned a resource in the old domain. According to many best practices for Active Directory migrations — even the ones built into Quest® tools — SID History is written when objects are migrated from other domains. It enables historic Access Control List (ACL) entries to continue to work after migration.
SID History was introduced in Windows Server 2000 to help enterprises move off of Windows NT 4.0 and adopt Active Directory. And it certainly made migrations easier and faster.
SIDs guarantee the uniqueness of a security principal within an Active Directory domain. So if you re-use them, you run the risk of granting unauthorized access to systems that depend on SID-based ACLs.
Suppose, for example, that your Human Resources department has a shared folder called \Compensation and that Thomas Wyatt has full access to that folder. One day, Wyatt leaves the company and his user account in AD is removed.
However, Wyatt’s entry in the security properties of \Compensation is not completely removed; instead, AD changes that entry from “Thomas Wyatt” to something like “Account Unknown (S-1-5-21-428333439-…)” — a SID with the same permissions.
That introduces the risk that a new security principal could adopt that SID since it is available. The new security principal would automatically inherit the same, full access to \Compensation, whether that was the company’s intention or not.
If you’re going to re-use SIDs in Active Directory, you should think of it as having an extra set of keys for getting into your house — with many of the same advantages and disadvantages.
Removing SID history
Lots of organizations decide that they want to keep that extra set of keys.
“Migration’s over,” they say. “We’ll just keep the SID History. We’re not going to re-key our source AD. We’re going to use the old key and have two matching keys now.”
The problem is that the previous owner could come back and use the extra key to break into the new house, as in the example above. Or, someone with mimikatz or a similar tool could perform a SID History injection to enable impersonation of arbitrary users or groups such as Enterprise Admins. That kind of manipulation could result in elevated access to local resources. An attacker could access otherwise inaccessible domains via lateral movement techniques such as remote services, Windows admin shares and Windows Remote Management.
TIP: Like Microsoft, we recommend that you remove SID History once the migration is complete and everything has been reACLed. By then, you’ll have correctly re-permissioned everything. Another mitigation is to apply SID filtering to interforest trusts, such as forest trusts and external trusts, to exclude them from requests to access domain resources. Removing SID History should be the last step in your migration.
Product risk vs. security risk
Of course, it’s entirely possible to perform an Active Directory migration without using SID History. There is, after all, risk inherent to migrating it. By that I mean that you run more product risk if you don’t migrate it, because users will encounter more issues with authentication.
Consider the product risk: Is it important that your applications have seamless, backward compatibility from target to source?
- If you migrate SID History, then you get that backward compatibility. When users try to access an application in the source environment, the application will authenticate and connect them as before. You incur no product risk, but you incur the security risk of having the extra set of house keys I mentioned above.
- If you don’t migrate it, then you don’t get the backward compatibility. The application in the source environment will prompt users for credentials when they try to access it. You’ve mitigated your security risk at the expense of product risk.
It’s up to you to decide which risk poses the bigger obstacle in your organization.
Mind you, certain types of migrations and application access will need it. By and large, though, those are rare.
TIP: Make sure you understand how your applications use authentication. Does the business depend on having those applications function as they did before? If not, then don’t migrate SID History.
Cleaning before migrating
A lot of AD migrations happen because of a merger or acquisition. We rarely have enough time in IT to do things the way we know they should be done, and it seems as though there’s even less time during M&A. Management wants you to move fast, leaving you little time to reACL all your different resources so you can clean up SID History in the future.
Reduce your AD attack surface.
One solution. Many workloads.
One risk in moving fast is that you’ll migrate SID History data — like that Thomas Wyatt entry I mentioned above — from the source environment to the target. I’ve seen too many organizations migrate old data like that without cleaning it up.
TIP: If you’re doing an AD migration and the source environment already has SID History, consider cleaning it up before migrating to the new environment. You’ll have less stuff to worry about moving over in the future. To continue the example above, do you need a set of keys for a house you no longer own? Of course not. Clean out your drawer so that you don’t keep collecting keys that you’ll never use anymore. Similarly, there’s no need to migrate inactive users since their accounts will only clutter up your new AD.
Conclusion
How much time do you have to accomplish your AD migration? Probably not a lot, so as you’re deciding what to migrate, it looks easier to migrate SID History than not to migrate it. And you don’t want to kick yourself later for not having migrated it when you had the chance.
But I’ve tried to emphasize that, unlike your Active Directory objects, migrating it is not a slam dunk. Be sure to weigh the pros and cons first.
