“Don’t worry,” your manager says. “Take all the time you need for that Active Directory migration.”
You pause and wonder if they are feeling all right.
You’ve never gotten as much time as you wanted for any other Active Directory migration before. Why would this one be any different? You’ve got a long list of things you’ve always wanted to do the right way but never had time to do correctly.
But if your boss is being straight with you, then this is your chance to start almost from scratch and get serious about Active Directory security. That’s a tempting prospect for any IT administrator. You begin making mental notes of how you want your new Active Directory to be more secure than the one you have now.
Still, you want to clarify one small thing with your boss:
“May I have that in writing?”
5 levels of an Active Directory migration
No, you can’t have it in writing, and no, your boss didn’t really say you could take all the time you need. But what if you did have all the time in the world to perform your migration? What would you do that you usually don’t have time to do?
Joe Sharmer and I presented at this year’s The Experts Conference, on the topic, “Security considerations during an Active Directory migration.” We examined Active Directory migration security on five different levels:
1) Identity
2) Groups
3) Applications
4) Data
5) Devices
We put ourselves in your shoes and gave you all the reasons why an Active Directory migration is the best possible time to improve your security stance. In this post, I’ll go through those reasons, along with concrete tips you can put on your list for the next time you migrate.
First, why migrate?
Most migrations fall into three categories:
Mergers and acquisitions. Your company acquires another company, so speed is in the air. Management wants you to merge the two different organizations together as quickly as possible. “The computers do all the work,” they say. “How long could the IT part of this take?”
Security. You, or your new boss, or the new CIO comes in and traces the history of the existing directories back to Windows NT 4.0. An Active Directory migration is a good opportunity to refresh the security posture on your AD and keep ancient artifacts from making it vulnerable.
Simplicity. Some organizations decide that they would rather manage one forest or one domain than many. In the name of modernization, they migrate.
Whatever your reason for migrating, you can be sure that attacks are not going away, so focus on Active Directory security at five levels.
1. Identity — What can the user do? What can the user access?
Identity is at the heart of authentication, and then authorization. Identity is associated with NTFS permissions, with SharePoint, with SQL Server and with access to all resources in the Active Directory domain.
The clean source principle requires that all security dependencies, such as identities, should be as trustworthy as whichever object — a server, a domain, a device — you’re trying to secure. In an Active Directory migration, you have to think about who has access to the object to begin with. That’s because, if those permission sets move over to the target during an Active Directory migration, then the access migrates with them.
TIP: If you’re migrating to improve your security posture, consider migrating Active Directory to a clean slate as well. That way, you won’t carry old or unknown dependencies to the new AD.
Passwords are a big part of identity, and it’s important to know who has access to them in the source environment before you migrate. As shown in Figure 1, the permission set at the domain level of Active Directory includes Replicating Directory Changes All — in three entries here.
Figure 1: Permission set at domain level of Active Directory
The Replicating Directory Changes All permission is what is needed to get password hashes. Whoever has that permission can use it to get the krbtgt hash, which is the hardest piece of information to obtain when trying to create a golden ticket. You may have an old Blackberry account or self-service password manager utility that created that permission.
TIP: Find out who in the source environment has permission to get password hashes. Users and objects with that permission may have enough information to create a golden ticket, which you wouldn’t want to migrate unknowingly to your new environment.
How recently have you changed your krbtgt password? If you examine its properties, will you see something like the pwdLastSet property in Figure 2?
Figure 2: krbtgt properties
Changing your krbtgt password is a good way to thwart golden tickets that may be in your source environment.
TIP: Plan to change your krbtgt password at least twice a year. You can use the script from Microsoft that automates the process, and running it before a migration is a good idea. But take care not to change it twice in rapid succession, because that will invalidate all of the Kerberos tickets that exist in your environment. You should change it twice in short order only if you’ve been compromised and you need to regain control of your environment.
An Active Directory migration is an opportune time to revisit your policy on passwords for system accounts and user accounts. How many characters do you require? Do you allow special characters? How frequently must users change passwords? How strong must passwords be?
TIP: Require your users to change their passwords before the migration. It’s a small inconvenience compared to the security gaffe of blindly migrating potentially compromised passwords.
2. Groups — Delete the obsolete ones
Groups are good for security, until they aren’t. It’s convenient to create a group so you can manage permissions in one place. But how about tracking its lifecycle? Eliminate it when, like a Y2K group, it has served its purpose.
Consider that your users create distribution lists, and Microsoft Exchange creates dynamic distribution groups in Active Directory to expedite the mass sending of email messages and other information. If you’ve never examined and deleted obsolete groups, an Active Directory migration is the ideal opportunity to focus on this — provided you can find the time and tools.
TIP: Use dsquery to help you identify obsolete groups and make sure that you don’t migrate them. Dsquery requires that the Active Directory Domain Services (AD DS) server role be installed, and you have to run it from an elevated command prompt. As shown in Figure 3, the command dsquery * -filter “(objectCategory=group)” -attr cn whenChanged whenCreated generates a list of changed- and created-dates.
Figure 3: dsquery on groups
Think about the groups in your source environment that have the same name as groups in the target environment, like an Engineering group or a Facilities group. How do you know they have the same kinds of members and permissions?
Here’s an example. Think of a file server in your source environment that contains a directory with everybody’s salary information. The folder is protected by the Human Resources group, which has three members, all of whom need access to that information. Now, due to a merger, you migrate to a new environment that also has a Human Resources group. But they use the group differently: besides HR users, its members include people in Finance and IT. If you migrate users from the source group to the target group, people are going to be unexpectedly able to view files they couldn’t see before.
TIP: Study duplicate groups before you merge them. You risk increasing the scope of permissions inadvertently and granting unintended access to information.
3. Applications — Authentication and GPOs
Which of your applications will be affected by your Active Directory migration? Mostly, the answer has to do with the authentication your apps require.
Authentication is top-of-mind in the wake of the PetitPotam NTLM relay attack. Plenty of companies still use NTLM (NT LAN Manager) version 1 for authentication, but if you’re migrating for security reasons, you probably won’t want that version in the destination environment.
Among the additional mitigations for PetitPotam, Microsoft suggests that you “disable NTLM Authentication on your Windows domain controller,” but that won’t help if your app depends on it.
TIP: As you’re migrating objects to the new environment, try enabling NTLM version 2 and disabling NTLM version 1. Or, to make sure Kerberos is the only authentication protocol allowed, disable NTLM and allow only Kerberos. Then see whether any of your applications break.
It happens that an Active Directory migration is also a good time to revisit your approach to authentication — maybe you can disable NTLM and use Kerberos. A good way to test that is through the Protected Users account (see Figure 4).
Figure 4: Protected Users account
TIP: Configure the Protected Users group to use NTLM authentication and force members to use Kerberos. Then, place a member from each department into the group during your acceptance testing. If those members can still access the application using Kerberos, then you can disable NTLM for them. (Note that there’s a four-hour authentication lag when a user becomes a member of the Protected Users group.)
If you’ve relied on Group Policy Objects (GPOs) for a long time, there’s no telling what state they’re in. Migrating them blindly to a new AD is another way to introduce the risk of obsolescence and potential vulnerability to an otherwise pristine environment. You may have a lot of GPOs to examine, but trimming out the dead wood now is better than migrating it unexamined.
4. Data — Who has permission?
Your directories are filled with data, and whenever you have data, you think about permission. Keep in mind that in most cases of data exfiltration, the attacker obtains access to the object through an account that already has it.
Figure 5 shows permissions for an Accounts Receivable directory.
Figure 5: Accounts Receivable directory object
It makes sense that the Finance Data and Accounts Receivable groups would have permissions to the data in this directory, but why the two individuals? For that matter, as shown in Figure 6, Sam Smith is in the Accounts Receivable group, so he doesn’t need explicit rights to the directory.
Figure 6: Accounts Receivable group properties
TIP: Eliminate individual access for data sets and directories containing sensitive data. That way, when the individuals are deleted later on, you won’t have unresolved SIDs (Security Identifiers) in your Active Directory. Allow only groups to have data access.
TIP: Audit which users have access to data and how frequently they use it. Examining usage over time, you can regulate access through groups. Have the business owner periodically attest to the need for each user to have continuing access.
5. Devices — Hardened before the migration
Which tools are you using for your Active Directory migration? Do they require that you temporarily disable the firewall (see Figure 7) or enable remote registry (see Figure 8) during the migration?
Figure 7: Windows Defender Firewall setting
Figure 8: Remote Registry Properties
Older tools had pre-requisites for remote connectivity. But if you’re migrating for security reasons, do you really want to weaken your security posture — even temporarily — so you can migrate to a new environment?
Reduce your AD attack surface.
One solution. Many workloads.
TIP: Use Active Directory migration tools that don’t force you to disable security properties on either your source or destination server during the migration project. It’s not necessary to weaken a server and configuration in the cause of migrating to a more secure environment.
Conclusion
The point is that Active Directory migration in a hurry is a bad idea.
A lot of doors swing open during an Active Directory migration or consolidation project. If attackers know you’re migrating — or even if they just get lucky — your company will suffer in the long run because you’ll be consolidating already compromised systems.
Your boss will probably not let you take all the time you need to ensure a secure migration. But the faster your migration, the greater the risk that some kind of vulnerability will slip in undetected. If you want to mitigate that risk in your destination AD, eliminate it in the source AD before migration.
