Migrating to Office 365 the secure way
Cloud computing offers lower costs, flexibility, and greater capacity beyond the limited resources most organizations have in their datacenters.
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.
Moreover, and depending on the way data and users have been migrated, attackers can also leverage footholds on on-premise Active Directory to gain access to cloud data, and vice versa.
In this whitepaper, ALSID looks at the different options for extending on-premise AD to Office 365, then discuss the available defense tactics for Office 365 and on-premise AD.
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-premise Active Directory. But organizations that already control access to on-premise resources using Windows Server Active Directory don’t want to manage an additional cloud-only directory separately because it results in having two identities for each user, which increases costs, and effort for both users and IT.
Extending on-premise Active Directory to the cloud solves this problem by centralizing user identities in one directory and 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-premise AD username and password because 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 ADD to see if it matches. If there is a match, access is granted. If a user resets their on-premise AD password, the resulting hash is synchronized to AAD so the same password can be used to access cloud and on-premise resources.
In contrast to cloud-only identities, IT can manage a single set of identities for accessing both on-premise and Office 365 resources. PHS also provides single sign-on capability so that when users are signed in to on-premise 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-premise 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. For example, 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, Pass-Through Authentication (PTA) uses one or more agents installed on-premise to validate user credentials directly with Active Directory.
Unlike PHS, PTA immediately enforces on-premise 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 and 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, like 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-Premise Active Directory
As an attacker, moving from AAD to AD is not trivial. But the results are sufficiently rewarding, and therefore motivating, that organizations should keep it high on their risks 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 straightforwardly to authenticate against on-premise AD because the synchronized hashes are ‘hashes of hashes’.
Therefore, it is not automatic that an attacker could gain access to on-premise 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 those incomplete information to progress toward their final target. Human error could also lead to on-premise privileged AD accounts, like those with domain administrator rights, having their password hashes synchronized to Azure AD.
Lateral Movement from On-Premise
Active Directory to Office 365
Conversely, if a user’s on-premise 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-premise AD. If an attacker gets a foothold into an organization’s on-premise Active Directory, authenticating to AAD is just a matter of time.
Thus, organizations which want to extend their operations to the cloud should always harden and monitor their on-premise AD as a pre-requisite.
Mitigating Migration Risks
As previously demonstrated, organizations that move forward with their hybrid cloud strategy must implement strict mitigation tactics for both their Office 365 and on-premise 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-premise AD. It is included in Azure AD Premium Plans and comes at a cost.
Finally, MFA in general, albeit a great progress for our collective security, is not the magical silver bullet: if a hacker were to compromise an on-premise AD, he/she will inevitably have the capability of controlling local, physical endpoints. In that scenario, said hacker will just have to wait for the host’s user to authenticate, legitimately, to start moving laterally on-premise, 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, 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.
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-premise 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, 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 for a large part 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 make sure 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 it is need 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.