Skip to content

The Merger That Can Fracture

M&A - Your active directory... and your business

In this guide, Alsid explores how Active Directory is critical to your entire IT infrastructure, how migrating Active Directory during company mergers and acquisitions puts businesses at risk, and how to mitigate these risks by following security best practices and deploying the right tools.

M&A
Business as usual

It can be difficult for IT to keep pace with ever-shifting business demands. Even with recent technological breakthroughs like containerization that allow IT to deliver quicker results, security due diligence is often left by the wayside in the rush for change. The consequences can be disastrous.

Company mergers and acquisitions are commonplace for large organizations, but the speed and demands placed on IT mean the resulting infrastructure is usually less than ideal. To expedite the process, security is often left to chance or poorly implemented.

In any merger or acquisition, Active Directory (AD) is the most complicated component to migrate because it manages access to your entire IT infrastructure, including applications, servers, and data. The remainder of this guide looks at the risks associated with Active Directory migration and the impact a resulting security incident could have on your business.

AD
A critical business
infrastructure

Active Directory Management

Active Directory is an identity management solution from Microsoft that is used by most Fortune 500 companies and enterprises of all sizes around the world. AD is a critical infrastructure service that controls who and what can access IT resources, when and where. It has advanced features that allow organizations to manage the configuration and security of Windows servers and PCs, secure access to resources using encryption, federate access between disparate infrastructures, synchronize identities to the cloud, deliver single sign-on to cloud apps like Office 365, and provide directory services to line-of-business apps, such Microsoft Exchange and SharePoint Server.

Due to the central role that AD plays, any compromise or downtime can stop service across your entire IT estate. If AD is unavailable to authenticate users, they lose access to resources. In the event of a catastrophic failure, like the 2017 NotPetya virus which destroyed the servers that provide AD services (domain controllers) for many companies, the cost extends well into the millions. In the worst-case scenarios, businesses are taken offline completely.

A properly engineered AD infrastructure is highly accessible by design. But in extreme cases, as demonstrated in the NotPetya attack, an entire directory can be taken down in seconds, where the only remaining option is to restore the complete AD infrastructure from backup. It goes without saying this is a time-consuming and disruptive process.

Many organizations fail to follow basic AD security best practices, which is why Microsoft suggests assuming compromise when planning a defense strategy. Hackers that successfully breach AD often lie low for long periods so they can gather information about your networks without being noticed. Stealth techniques allow hackers to rummage through your system unnoticed, so organizations are often unaware they have been compromised.

Not all attacks are targeted. Regardless of whether you believe you have information that is worth stealing, most malware is automated and will strike wherever it finds an opportunity. Even fully-patched servers can be vulnerable if security best practices are not followed. Once AD is compromised, you can either restructure your existing AD in a new forest or adopt a strategy to manage a compromised domain by implementing Microsoft’s Enhanced Security Administrative Environment (ESAE). ESAE is designed to secure privileged access to AD and can be especially useful in situations where it is believed that AD is compromised. But ESAE requires additional infrastructure, it is complex to manage, and it is beyond the reach of many organizations due to the costs and skills required to implement it.

Merging infrastructures
risks

No two organizations follow the same best practices or governance, so there will always be one infrastructure with a weaker security posture. This leaves one domain at risk if insecure objects are migrated to the target domain or if weaker security policies need to be applied to ensure compatibility with applications. Federation is the most secure way to provide access to another AD domain, and it works well when you need to give a business partner access to internal resources. But mergers and acquisitions require a greater level of access without the complexity that federation brings.

While the smallest organizations might be able to migrate all resources from the source to target AD domains in one go, that’s not realistic in most cases. The migration process is complex and should be executed in stages to ensure that users retain access to resources as objects are migrated. If server applications relying on AD are also involved, like Microsoft Exchange Server, migration becomes even more complicated

Active Directory Migration Tool

Standard practice is to establish a cross-forest trust between the two infrastructures so that users retain access to resources in the source domain when their accounts are migrated to the target domain. Some tools, like Microsoft’s Active Directory Migration Tool (ADMT), require a cross- forest trust. Others can migrate objects between forests without a trust but with some limitations, like no support for coexistence. A one-way trust between source and target domains is sufficient when using ADMT but you must add the migration group to the local administrators group on every workstation. Otherwise, a two-way cross-forest trust is required, and this increases the risk of compromise between forests.

An Active Directory forest is a security boundary, providing data and service isolation, even when a standard trust is created between two forests. Administrators in forest A can’t get privileged access to forest B if there is a security boundary. This is important if you don’t trust the administrators in a trusted forest or if you believe the trusted forest might be compromised. But a migration scenario requires that Security Identifier (SID) filtering be disabled on the cross-forest trust so that the two forests can coexist for a given period. If SID filtering is disabled on a trust, a user’s SID history maintains access to resources in the source domain when user accounts are migrated to the target domain. But when SID filtering is disabled, there is no longer a security boundary between the AD forests, exposing AD to threats.

While Microsoft states that AD forests represent a security boundary, researchers have shown that in current versions of Windows Server, it is possible to compromise forests when standard two-way trusts are established. Microsoft has recognized this issue but has stated that it cannot be fixed with a simple patch, although Microsoft has committed to addressing the problem in the next version of Windows Server.

The researchers were unable to demonstrate compromise with a one-way trust. Still, they believe that it may be possible to compromise trusted forests.

The risks associated with merging AD forests, such as inheriting poor security hygiene, badly thought-out trust relationships, and active exploits in the source domain, should not be underestimated. For example, migrating users holding privileged AD access to the target domain poses significant risk, especially if best practices for the privileged account use were not followed in the source domain. It could let an attacker move laterally between devices, planting malware and eventually owning AD domain controllers.

NotPetya cost Danish shipping company Maersk two days of downtime and an estimated $300 million when the malware took out much of its infrastructure, including Active Directory domain controllers. Disaster extend beyond domain controllers, as well. Norsk Hydro was forced to switch to manual operations after LockerGoga encrypted and disconnected systems managing factory equipment. The attack originated with an AD exploit. Whatever the actual target, Active Directory provides a path for attackers to inflict the maximum level of damage.

The effect that AD outages have on IT is clear. But like any IT issue, there’s more widespread collateral damage. Because of the catastrophic effect that AD failures have on IT infrastructure, brand reputation and customer trust also become casualties amid the regular information leaks that make the public wary of how their personally identifiable information (PII) is stored and secured.

Competitive advantage also suffers. Not only can you lose clients and prospects during a lengthy outage, but hackers might use malware to steal intellectual property. Breaches can also crash stock prices and inflict direct financial losses.

Mitigating AD
merger risks

Before starting a migration project, it is prudent to assess the security posture of each environment and evaluate whether changes should be made. Because moving objects that are insecurely configured can introduce vulnerabilities in the target domain, it’s worth cleaning up the source domain to make sure that it adheres to the same best practices.

Because of AD’s complexity, it is best to use a tool to automate ongoing risk assessments of your environments—before, during, and after migration. While it is possible to provide a list of high- level configuration settings to be audited, there are thousands of settings which can affect the security of your domain. Automating the process is the only way to thoroughly understand your security posture. Some settings that you should check include:

• Accounts assigned privileged access to Active Directory, not limited to Domain Admins
• Rootanddomaincontrollerobjectaccesspermissions
• adminSDHolderpermissions
• Kerberosdelegation
• Accountswithweakornever-expiringpasswords
• Misconfiguredtrustrelationships
• Localadministratoraccountsconfiguredwithacommonpassword
• KRBTGTaccountlastpasswordchange

Before starting a migration project, it is prudent to assess the security posture of each environment and evaluate whether changes should be made. Because moving objects that are insecurely configured can introduce vulnerabilities in the target domain, it’s worth cleaning up the source domain to make sure that it adheres to the same best practices.

Bringing the security posture of each AD environment into line with a set of best practices significantly reduces the risk of compromise during a migration project. Assuming compromise when planning your migration further reduces the risks involved. For example, migrating with a one-way cross-forest trust with SID filtering enabled provides a greater level of isolation between the two environments than using a two-way cross-forest trust with SID filtering disabled. But the trade-offs might be convenience and simplicity.

If you don’t want to disable SID filtering on the trust, users can still be migrated to the target domain and retain access to resources in the source domain, but the process is more complex.

Here is a simplified overview of the steps required:

• Migrate user accounts, but do not enable them in the target domain.
• Run security translation in add mode on all resources that users access in the source domain, including files, shares, printers, local groups, and domain local groups.
•Migrate local user profiles and then workstations in batches.
• Re-migrate user accounts and all attributes in batches. Set them to enabled in the target domain.
• Re-migrate all global groups.
• Run security translation again in remove mode.

This process still migrates users’ SID histories to the target domain to ensure that processes like Offline Files continue to work correctly. Since SID filtering is enabled on the forest trust, migrating SID history does not pose a security risk.

Much will depend on the tool you choose for the migration. Microsoft’s ADMT is free, but it does not officially support migration to the latest versions of Windows Server. Third- party tools provide a streamlined migration process and can support scenarios where trusts are not used.

Risks can be managed – Alsid

The risks associated with AD migration projects can be managed by ensuring good security hygiene in source and target domains, using a standard trust with SID filtering during the migration and coexistence periods, and deploying a specialized tool that monitors the infrastructures in real- time for the latest threats.

Without a reliable tool to surface configuration settings and compare them to the latest threat information, no amount of in-house expertise will protect you from attack. Hackers move quickly, deploying automated tools to arbitrarily target networks, and can move around laterally unnoticed if the right protections aren’t in place to monitor changes in configuration.

Comments are closed.

Download pdf

The task of securing Active Directory, in or out of a migration project, might seem unsurmountable. But by following best practices, planning in advance, and harnessing new technologies, Active Directory can be secured to reliably provide the infrastructure services needed to keep your business running and reassure clients and investors that your data is securely stored and available in today’s ever-changing threat landscape.

Contact us