In the first part of this series, I reviewed the risks that on-premises infrastructure can pose to the security of Microsoft 365 and two pieces of advice from Microsoft’s Pramila Padmanabhan and Michael Epping about how to mitigate these risks based on their TEC (The Experts Conference) 2021 talk “Protecting Microsoft 365 from On-Premises Attacks.” I added my perspective as someone who works with large organizations in North America as to what works well in reality, and what takes more effort to implement.
Let’s dive in and look at their final three guidelines for protecting Microsoft 365 from on-premises vulnerabilities.
Do not Allow Hybrid Users Have Admin Rights in Azure Active Directory
I consider this recommendation to be closely related to “Isolate Microsoft 365 Administrators” from the first article. You should never allow hybrid Azure AD users to have administrative rights in a Microsoft 365 tenant. Simply put, while it is never good to have an account compromised, if an attacker can compromise an on-premises account their “blast radius” is reduced if that account doesn’t have administrative rights in the cloud.
While this seems straightforward in principle, in practice I have seen many instances where this principle is violated. Let’s discuss a couple of examples.
First, it is not uncommon to discover a service account used by an on-premises configured for synchronization into Azure AD by Azure AD Connect. This account is then granted an administrative role in Microsoft 365.
The rationale I hear for this usually goes like this: The on-premises application needed user rights to Microsoft 365. The the service account password was already being managed through a Privileged Access Management system – so why not? Why keep track of multiple accounts and multiple passwords when one will do?
Of course, this is the point. It is this inconvenient separation of accounts between different directories which improves their security posture – so that the misuse of an on-premises account can’t cause a vulnerability in the cloud.
Another example: It can also be difficult to maintain the separation between hybrid users and privilege. Ryan Hausknecht at SpecterOps details an interesting attack path where ownership by a “regular account” of an administrative service principal can be used to exploit the privilege granted to that account.
To summarize, owners can create shared secrets for their service principals – essentially application specific passwords. And while service principals cannot log into administrative portals, they can be used with many PowerShell cmdlets. At the end of the day, if an account owns a service principal, that account essentially has the same rights granted to that service principal.
In my experience, maintaining a strict separation between hybrid accounts and administrative privilege requires constant vigilance. It isn’t a single process or even a static set of policies, but rather continual reevaluation of the complex relationship between directories.
Use Azure AD Authentication and Conditional Access Policies
Since Microsoft Ignite 2018 (and probably longer), Microsoft has been pushing Microsoft 365 customers away from using Active Directory Federation Services (ADFS) or pass-through authentication in favor of password hash synchronization for hybrid users. Padmanabhan and Epping continue this drumbeat, and for good reason.
When using password hash synchronization, Azure AD Connect synchronizes the password as set on on-premises Active Directory user to the hybrid cloud user. Authentication against that hybrid cloud account is then handled by Azure AD. While it has the same password as the Active Directory user, Active Directory is never touched during the authentication process.
Contrast this to ADFS or pass-through authentication. While they differ in their technical implementation, at the end of the day both directly leverage an Active Directory domain controller for authentication.
There are a raft of advantages to exclusively leveraging Azure AD authentication. Users can still authenticate to cloud applications even if there is an Active Directory outage. Conditional Access Policies work more broadly, particularly with federated applications. Cloud only and hybrid users utilize the same policies and authentication flow.
But most importantly, this recommendation is all about removing the possibility that Azure AD could trust a vulnerable on-premises component for authentication. This is how the Nobelium attack happened. The on-premises ADFS servers that Azure AD trusted became compromised and were used to generate trusted access tokens for cloud applications.
Anecdotally, I see this point of advice being broadly implemented. Even in large organizations, it is far more common to use password hash synchronization than ADFS or pass through. And most organizations that I work with have purchased at least Azure AD Premium P1. While beyond the scope of this article, this license level unlocks many of the advantages of using cloud native authentication for all users – such as conditional access policies.
Collect and Analyze Logs
Padmanabhan and Epping’s final word of advice is to not neglect the “block and tackle” work of collecting logs. While this recommendation may seem obvious, they stress that this goes beyond just setting up a few alerts in the Microsoft 365 Compliance center and calling it good. While checking events which accrue in the Microsoft 365 unified audit log periodically is extremely important, with a hybrid directory, it is also important to collect Active Directory audit logs as well as logs from endpoint devices.
According to Padmanabhan and Epping, organizations should keep logs for however long is necessary. This might mean that you need to export log data to a SIEM (Security Information and Event Management) repository. In practice, I see log collection implemented in a couple different ways across organizations I work with – often at the same time. Products like Microsoft Sentinel and Splunk can accept almost any type of log data at large scale, search and analyze the log data, and keep that data for as long as necessary.
But there are challenges with this approach. the charging for SIEM systems is typically based on the storage they consume, which can make it quite costly to keep data for long periods. But perhaps even more daunting is the expertise needed to create insights from logs. Because they contain so many different events, making use of the collected audit log data often requires dedicated expertise which can come at a costly premium.
Alternatively, another approach organizations take is to use platform focused products pre-configured for specific audit sources, such as Quest’s On Demand Audit. The path to insight with products like these is typically shorter due to built-in normalization and pre-built queries and visualizations. Additionally, these products are generally not licensed by the storage used, so their cost is more predictable.
Naturally, there are trade offs for these products as well. Platform focused auditing products are designed for a limited set of data sources, so new ones typically need to be added by the vendor. It is also unusual for these products to be able to handle Azure AD, Active Directory, and end-point devices.
Conclusion
Padmanabhan and Epping’s presentation was very insightful, and their advice lines up with where I see organizations headed too. Again, I highly recommend viewing their original presentation. I hope that I’ve been able to provide some value through my perspective as someone who works with organizations to navigate every step along this path.
