How to Migrate to Office 365 the Secure Way

Looking to extend your Active Directory to the cloud? This guide explores options for securely migrating your on-prem identities and access controls to Office 365. 

Cloud computing offers lower costs, better flexibility and greater capacity beyond the limited resources most organizations have in their data centers.

But migrating data and extending user identities to the cloud is not risk-free. Compromising user identities in the cloud can lead to very immediate exposure of sensitive files that are de facto accessible directly on the internet.

Depending on the way data and users have been migrated, attackers can also leverage footholds in on-prem Active Directory to gain access to cloud data, and vice versa.

In this guide, we look at the different options for extending on-prem Active Directory to Office 365, then we discuss the available defense tactics for both environments.

Why manage access to Office 365 using Active Directory?

Customers can manage Office 365 using cloud-only identities in Azure Active Directory (Azure AD), a fully-managed identity and access service that is primarily designed for cloud-first applications.

This model suits organizations that have no investment in on-prem Active Directory. But organizations that already control access to on-prem resources using Windows Server Active Directory don’t want to manage an additional cloud-only directory separately. And who can blame them? It results in two identities for each user, which increases costs and effort for both users and IT.

Extending on-prem Active Directory to the cloud solves this problem by centralizing user identities in one directory, plus it provides some additional advantages, like seamless single sign-on and self-service password resets. There are several different models for extending Active Directory to the cloud, each with varying levels of complexity and risk.

How to extend Active Directory identities to Office 365

Password Hash Sync (PHS)

Password Hash Sync within Azure AD Connect is the simplest way to leverage existing on-prem directories, and it is best suited to organizations that want a quick and easy way to extend Active Directory to the cloud. PHS isn’t the best option if you need to replicate all of Active Directory’s features for cloud users.

With PHS, users can log into Office 365 with their on-prem Active Directory username and password, since PHS synchronizes password hashes to Azure AD. Conceptually, a hash is an encrypted version of a user’s password; cleartext passwords are never synchronized to the cloud. When a user logs into Office 365, their password hash is compared to what is stored in Azure AD to see if it matches. If there is a match, access is granted. If a user resets their on-prem Active Directory password, the resulting hash is synchronized to Azure AD so the same password can be used to access cloud and on-prem resources.

In contrast to cloud-only identities, PHS enables IT to manage a single set of identities for accessing both on-prem and Office 365 resources. PHS also provides single sign-on capability so that when users are signed into on-prem Active Directory, they are also signed into Office 365 without any additional action. Other key advantages are that no on-site infrastructure is required and users can continue to log into Office 365 even if on-prem Active Directory is unavailable.

But unlike the other models, adopting PHS by itself means that some Active Directory features cannot be used in the cloud. For example, user log-on hours are not supported, so organizations can’t use Active Directory to restrict when users access Office 365 resources. Furthermore, changes to user state are not replicated immediately to Office 365. If you disable an Active Directory user account, access to Office 365 is not blocked instantly, which in itself is a major security drawback.

Pass-through Authentication

Pass-through Authentication (PTA) is designed for organizations that need more control but don’t want the overhead of a federated architecture. PTA requires some on-site infrastructure, so it isn’t suitable for small organizations with no IT support. Instead of synchronizing password hashes to the cloud, PTA uses one or more agents installed on-prem to validate user credentials directly with Active Directory.

Unlike PHS, PTA immediately enforces on-prem user account states, password policies and log-on hours. Like PHS, PTA provides single sign-on capability. But PTA doesn’t work with leaked credential risk events or support Azure AD Connected Health integration, two important built-in security features that should be part of any Azure AD hygiene routine.

Federated Authentication (possibly combined with PHS) 

The final option is to use a federation service, either a third-party or the Active Directory Federation Services component built into Windows Server. Federation is suitable for large organizations that want to take advantage of all the security features supported by Active Directory. It is not suitable for small organizations because it is complex to set up and maintain. 

Federated authentication uses a trusted third-party to perform authentication duties, and it can integrate with different systems to provide additional value, like smartcard authentication and third-party multifactor authentication. But some advanced features of Azure AD, such as identity protection, require PHS. It is possible to combine federated authentication with PHS if your organization needs advanced Azure AD features or a means of signing into Office 365 in the event the federated authentication provider or Active Directory fails.

Extending Active Directory to the cloud involves risk

The authentication models described above, except for cloud-only identities, all provide single sign-on for users and a single set of identities for IT to manage. But with convenience comes risk. And while some attacks are targeted, many are arbitrary. So, even if you believe that your organization is not at risk or has nothing worth stealing, it doesn’t mean you won’t be compromised.

Password attacks

Because Office 365 is exposed to the public internet, it is open to brute-force attacks in which login attempts are repeated sequentially in the hope of discovering the correct password. Password spray attacks are similar but affect multiple users so that account lockout mechanisms aren’t triggered. Attacks can also result in denial-of-service (DoS) where users are unable to access Office 365.

Lateral movement from Office 365 to on-prem Active Directory

As an attacker, moving from Azure AD to Active Directory is not trivial. But the results are rewarding enough that defenders should keep it high on their risk list.

Hackers can use a technique called Pass-the-Hash (PtH) to authenticate without knowing a user’s password. However, if an Azure AD hash were compromised, it couldn’t be used to directly authenticate against on-prem Active Directory, since the synchronized hashes are “hashes of hashes.”Therefore, it is not automatic that an attacker could gain access to on-prem systems and data if a user’s identity is compromised through Office 365. 

That being said, knowing a user’s login credentials is often the first step to gaining deeper access to intranet servers and data, and attackers are keen on leveraging that incomplete information to progress toward their final target. Human error could also lead to privileged on-prem Active Directory accounts—like those with domain administrator rights—having their password hashes synchronized to Azure AD.

Lateral movement from on-prem Active Directory to Office 365

Conversely, if a user’s on-prem Active Directory identity were compromised, an attacker could gain access to sensitive data stored in Office 365.

In our hybrid context, the security of Azure AD is only as good as the security of the on-prem Active Directory. If an attacker gets a foothold in an organization’s on-prem Active Directory, authenticating to Azure AD is just a matter of time.

Thus, organizations wanting to extend their operations to the cloud should always harden and monitor their on-prem Active Directory as a prerequisite.

Mitigating migration risks

Organizations that move forward with their hybrid cloud strategy must implement strict mitigation tactics for both their Office 365 and on-prem Active Directory infrastructures.

Office 365 security tactics

Choosing the right identity model

While conventional wisdom says that a federated model is the most secure, Password Hash Sync (PHS) is likely the best option for most organizations because of its simplicity and its support for advanced Azure AD security features and threat detection. Organizations that need the features of a federated model can combine it with PHS to get the best of both worlds.

Manage privileged accounts

Users granted Office 365 global administrator rights need to be protected beyond standard Office 365 users because they have access to modify tenant permissions, access data and perform global operations that could affect how Office 365 works. These accounts should be treated much like privileged Active Directory accounts. Additional protections, like multifactor authentication, should always be enabled for Office 365 global administrators.

Implement security tools

Due to the inherent risks of extending any system to the internet, Microsoft provides tools for protecting identities and data in Office 365. But most of the advanced tools and features come at a price and aren’t included in entry-level subscription plans. Security professionals should always keep in mind that none of those solutions alone is sufficient. A good defense results from a consistent collection of technologies tightly sewed together by robust processes and capable people.

Multifactor authentication

Azure Multifactor Authentication (MFA) for Office 365 provides an additional layer of protection by requiring users to confirm their identity with a password and a device in their possession. When enabled, Azure MFA for Office 365 makes it almost impossible for a hacker to access an account even if they know the password or have access to the password hash.

However, Azure MFA for Office 365 does not provide MFA for on-prem Active Directory. Azure MFA is a separate product that has more capabilities, including the ability to secure on-prem Active Directory. It is included in Azure AD Premium Plans for an additional cost.

While MFA is a major step forward in collective security, it is not a silver bullet: If a hacker were to compromise an on-prem Active Direcotry, they would inevitably have the ability to control local, physical endpoints. In that scenario, said hacker would just have to wait for the host’s user to authenticate legitimately to start moving laterally on-prem or vertically to the cloud.

Conditional Access policies

Conditional Access is a premium service that blocks access to Office 365 unless certain conditions are met, including the use of MFA. Other conditions consist of determining location by IP address, sign-in risk and client application. For example, a policy could allow users to sign in from a predetermined IP address range if they are using Office desktop programs. Keep in mind that none of those solutions is sufficient on its own.

Smart Lockout and custom banned password lists

Smart Lockout is designed to protect identities from brute-force password attacks, and it is available to all Azure AD users. By default, Smart Lockout blocks sign-in attempts for one minute after 10 failed attempts. Accounts are locked again after each successive failed login for one minute, and longer if attempts continue. Hash tracking prevents account lockout if the same incorrect password is entered more than once providing that PHS synchronization is configured. Additionally, Azure AD Password Protection lets organizations use custom banned password lists for users with premium licenses. Password Protection can also be extended to on-prem Active Directory.

Advanced Threat Protection

Office 365 Advanced Threat Protection (ATP) and Threat Investigation provide additional protection against threats in email messages, hyperlinks and collaboration tools. ATP policies can protect against zero-day threats in email attachments, help dynamically block malicious internet links and block infected files shared on SharePoint, OneDrive and Microsoft Teams. There is also anti-phishing protection backed by machine-learning models.

However, ATP is largely a behavior-based technology. It creates statistical models of what is considered “normal” and compares users’ actual activities against their expected behaviors. It is by nature a construct that is either prone to false positives or ineffective, depending on how rigid the statistical model is.

Active Directory security tactics

Best practice configuration

Microsoft’s Server Manager tool includes Best Practices Analyzer (BPA) for identifying issues with Active Directory. BPA reports on security, performance, configuration, policy and operational issues. Organizations can use PowerShell to schedule BPA to run regularly to ensure compliance with Microsoft’s best practices.

The Security Compliance Toolkit (SCT) is a free download from Microsoft that contains security baselines for Windows 10 and Windows Server. The baselines can be used to configure devices with Microsoft’s recommended settings for server hardening. SCT also includes Policy Analyzer, a tool for comparing Group Policy Objects (GPOs) with each other and against local policy and registry settings.

Privileged accounts

Credential misuse is one of the key avenues to Active Directory compromise. Many organizations grant users permanent access to privileged Active Directory groups—like domain admins—to facilitate administrative and support functions. But these accounts can be used to compromise Active Directory, sensitive user accounts and data. 

Security teams should change default permissions to make sure that IT staff don’t need privileged Active Directory accounts to support end-user devices or perform day-to-day administrative tasks. When users are granted privileged access to Active Directory, they should make changes from devices specially purposed for privileged administration.

Furthermore, you should restrict privileged access to domain controllers on an “as-needed” basis. Establish a process to ensure that any proposed changes are approved by stakeholders and that a rollback plan has been tested in the event of a problem.

Using built-in tools like delegation, PowerShell Just Enough Administration (JEA) and Just-in-Time (JIT) Administration, you can also grant privileged access only when needed and for a limited time. Take similar care with servers and end-user devices. The Local Administrator Password Solution (LAPS) can help organizations manage and store administrator passwords.

Monitoring Active Directory

Auditing Active Directory using a tool like BPA can identify configuration issues, but audit data swiftly becomes stale. Security teams must continuously monitor Active Directory to ensure potential threats and breaches are detected.

Defenders also need tools to better analyze this data for the most urgent risks. The Windows Server Event Log collects security, configuration, performance and operational events for Active Directory and Windows. But the information collected is only useful if it is independently analyzed to alert on potential issues. Because the threat landscape is constantly changing, events collected from Active Directory should be analyzed against a threat intelligence feed to make sure that issues are flagged quickly and brought to the attention of IT staff. Unfortunately, this is hardly doable without specialized tooling. 

The security and Active Directory talent pools are already scarce. Hiring a team of professionals that combine both skills is close to impossible. Instead, the use of specialized technologies that can combine Active Directory-focused intelligence feeds and local logs is the only viable solution to monitoring Active Directory at scale.

And we might have a couple insights about choosing the right Active Directory security solution, but that’s a story for later…

This blog post originally appeared on the Alsid website on December 11, 2020.