How to Migrate to Office 365 the Secure Way
Cloud computing offers lower costs, 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’re looking at the different options for extending on-prem AD to Office 365, then discussing the available defense tactics for both.
Why manage access to Office 365 using Active Directory?
Office 365 can be managed standalone using cloud-only identities in Azure Active Directory (AAD), 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 AD to the cloud, each with varying levels of complexity and risk.
How to extend Active Directory’s identities to Office 365
Password Hash Sync (PHS) is the simplest of all the models, and it is best suited to organizations that want a quick and easy way to extend AD to the cloud. PHS isn’t the best option if you need to replicate all of AD’s features for cloud users.
Users can log in to Office 365 with their on-prem AD username and password since PHS synchronizes password hashes to Azure AD (AAD). Conceptually, a hash is an encrypted version of a user’s password. Cleartext passwords are never synchronized to the cloud.
When a user logs in to Office 365, their password hash is compared to what is stored in AAD to see if it matches. If there is a match, access is granted. If a user resets their on-prem AD password, the resulting hash is synchronized to AAD so the same password can be used to access cloud and on-prem resources.
In contrast to cloud-only identities, IT can 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 in to on-prem AD, they are also signed in to Office 365 without any additional action. Other key advantages are that no on-site infrastructure is required and users can continue to log in to Office 365 even if on-prem AD is unavailable.
But unlike the other models, some AD features cannot be used in the cloud. For example, user logon hours are not supported, so organizations can’t use AD to restrict when users access Office 365 resources. Furthermore, changes to user state are not replicated immediately to Office 365. If you disable an AD user account, access to Office 365 is not blocked instantly, which in itself is a major security drawback.
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 logon 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 major security features built in AAD that should be part of any AAD hygiene routine.
Federated Authentication (possibly combined with PHS)
The final option is to use a federation service like Active Directory Federation Services. Third-party federation services are also supported. 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 AAD, such as identity protection, require PHS. It is possible to combine federated authentication with PHS if your organization needs advanced AAD features or a means of signing in to Office 365 in the event the federated authentication provider or AD 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.
Because Office 365 is exposed to the public internet, it is open to brute-force attacks, i.e. where 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 AAD to AD is not trivial. But the results are rewarding enough that organizations 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 AAD hash were compromised, it couldn’t be used to directly authenticate against on-prem AD because 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 on-prem privileged AD 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 AD identity were compromised, an attacker could gain access to sensitive data stored in Office 365.
In our hybrid context, the security of AAD is only as good as the security of the on-prem AD. If an attacker gets a foothold in an organization’s on-prem Active Directory, authenticating to AAD is just a matter of time.
Thus, organizations wanting to extend their operations to the cloud should always harden and monitor their on-prem AD as a pre-requisite.
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 AD infrastructures.
Office 365-centric security tactics
Choosing the right identity model
While conventional wisdom has it that a federated model is the most secure, Password Hash Synchronization is likely to be the best option for most organizations because of its simplicity and its support for advanced Azure Active Directory 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 AD 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. And security professionals should always keep in mind that, taken separately, none of those solutions is sufficient. A good defense results from a consistent collection of technologies tightly sewed together by robust processes and capable people.
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-premise AD. Azure MFA is a separate product that has more capabilities, including the ability to secure on-prem AD. It is included in Azure AD Premium Plans and comes at a cost.
MFA, albeit a major step forward in collective security, is not the magic silver bullet: if a hacker were to compromise an on-prem AD, 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 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. Smart Lockout blocks sign-in attempts for one minute after 10 failed attempts by default. Accounts are locked again after each successive failed login for one minute and longer if login 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 AD.
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 in the dynamic blocking of 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-centric security tactics
Hardening Windows Server Active Directory
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), and GPOs against local policy and registry settings.
Credential misuse is one of the key avenues to AD compromise. Many organizations grant users permanent access to privileged AD 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. Default permissions should be changed to make sure that IT staff don’t need privileged AD accounts to support end-user devices or perform day-to-day administrative tasks. When users are granted privileged access to AD, changes should be made from devices that are specially purposed for privileged AD administration.
Furthermore, privileged access to domain controllers should be restricted to an ‘as-needed’ basis. A process should be established to ensure that any proposed changes are approved by stakeholders and that a rollback plan has been tested in the event of a problem.
Built-in tools like delegation, PowerShell Just Enough Administration (JEA), and Just-In-Time (JIT) Administration can be used to grant privileged access only when needed and for a limited time. Similar care should be taken 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 and AD must be monitored continuously to ensure potential threats and breaches are detected.
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. Viewed separately, the security and Active Directory talents pools are already scarce. Hiring a team of professionals that combine both skills is close to impossible. In this context, the use of specialized technologies that can combine AD-focused intelligence feed 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 AD-centric security solution, but that’s a story for later…