I like to imagine that in some corner of Microsoft, the team responsible for Entra ID, formally known as Azure AD, is caught in a constant state of whiplash. On one hand, they have the unique and undoubtedly fulfilling opportunity to design a next-generation identity infrastructure that learns from and moves beyond the directory sins of the past. Integrated multi-factor authentication, clear delineations between administrators and non-administrators, and forcing re-authentication based on behavioral risk factors!
But I also imagine the frustration that must come from having the forward-looking, next-generation Entra ID be so often tied to a directory infrastructure that is over twenty years old. A directory that is rife with well-known, intrinsic vulnerabilities that simply cannot be patched away.
This compromise of vision is far more than just theoretical or aesthetic – some of the most high-profile exploitations of Entra ID have been made by abusing Active Directory (AD).
In this post, we will look at three misconfigurations in Active Directory that affect the security of Entra ID, and how best to mitigate that risk.
Hybrid Entra ID users having administrative rights
In the world of Entra ID, hybrid users are user accounts that are linked to and mastered by on-premises Active Directory users. Using Entra ID in a hybrid configuration with Active Directory is supremely convenient to both organizations and end users. It seamlessly extends an on-premises user into the cloud and provides single sign-on.
The trouble comes when a hybrid user either has an administrative role assigned to them, can request a role membership using Azure Privilege Identity Management, or is the owner of a powerful service principal. If this is the case, an attacker only needs to take over the on-premises account to then take over the Entra ID administrative account – neatly circumventing the modern security controls that are baked into Entra ID.
To avoid this misconfiguration in Active Directory: any and all administrative accounts in Entra ID should be cloud native accounts.
One recent change in how privilege can be assigned in Entra ID are “Role Assignable Groups.” With “Role Assignable Groups” a group can be created that can have a privileged role assigned to it. Members of that group will then get that role’s administrative permissions over the Entra ID directory.
In a sense, this is a more traditional way of assigning privileges to users. It is similar to how privilege is assigned in Active Directory – a user account is added to a group like “Account Operators” that confers delegated permission to the directory.
The potential advantages to an organization aren’t hard to see. Many organizations have pre-existing systems that can help manage the lifecycle of group memberships. With role assignable groups, privilege in Entra ID can be plugged into these existing systems and managed just like on-premises AD.
However, I would be cautious in implementing role assignable groups, particularly for the most powerful roles like Global Administrator or User Administrator. Firstly, one of the attractive aspects of using groups for privileged administration is that existing workflows and toolsets can be used for managing them. But privilege, particularly high privilege, should be temporary, which means that any toolsets used to manage role assignable groups should be able to make “Just in Time” assignments. For instance, Azure Privilege Identity Management, included with Entra ID Governance or Azure AD Premium P2, can do this.
Yet, unlike a role, Azure PIM cannot control who is eligible for membership into a group, nor can it control other ways of getting added to a group, such as using the Exchange Administrative Center. All that to say, it is more difficult to place controls to prevent hybrid users from gaining administrative privileges in Entra ID if you are assigning privilege through groups. If you choose to use Role Assignable Groups, be aware of this risk.
Authenticating Entra ID users with Active Directory
In information technology, most decisions involve weighing tradeoffs, often between security and usability. Case in point: it is tempting to extend the well-established authentication patterns from Active Directory into Entra ID. After all, users are familiar with their Active Directory login and already use it every day. Organizations may even have mature tools or processes that they already use to manage Active Directory authentication. Further, the helpdesk is trained in how to ensure a good user experience when users call in with authentication issues.
The “pros” of sticking with Active Directory authentication are clear, and these “pros” are also often backed by organizational momentum. Microsoft gives you a system that enable you to take advantage of these “pros” – Active Directory Federation Services, or ADFS. ADFS federates Entra ID authentication to on-premises Active Directory, making Active Directory the authentication system for Entra ID.
But the downsides of this approach can be devastating. Firstly, Active Directory is an intrinsically less secure platform than Entra ID, in large part due to its being designed over 20 years ago. This means that to gain access to hybrid cloud accounts, an attacker can use well-known techniques against the on-premises Active Directory rather than the relatively more secure and modern Entra ID.
Even more than that, the ADFS system itself has been shown to be vulnerable to attack and has been the conduit for several high-profile breaches into Microsoft 365. Notably, the threat actor Midnight Blizzard is known for targeting ADFS, behind the attacks utilizing Solarwinds’ Orion software in late 2021.
To avoid this misconfiguration in Active Directory: migrate from using ADFS to Password Hash synchronization between Active Directory and Entra ID.
While this may be a massive undertaking, it is a good balance of security and usability. Users are not compelled to manage multiple passwords and can have a single sign-on experience, all while leveraging Entra ID security features like multi-factor authentication, passwordless authentication, and conditional access policies.
One thing to note on using password synchronization between Active Directory and Entra ID: Entra ID will happily accept any password that is set in on-premises Active Directory. Password policy in Entra ID is considerably more sophisticated than it is in Active Directory, with the ability to forbid passwords that are known to be compromised, for instance. And while passwords have become less important in modern authentication by using second factors or passwordless authentication, they are still important to secure. Fortunately, Microsoft has a solution for this – Azure Password Protection. This enables you to extend all the great Entra ID password rules back into the on-premises Active Directory, ensuring that the passwords that it syncs are no less vetted than if they were set using Entra ID specifically.
And of course, remember the first point – accounts with privilege in Entra ID shouldn’t be hybrid, even with properly designed authentication!
Treating Azure AD Connect like a member server
Azure AD Connect is the service that connects on-premises Active Directory to Entra ID. It is the service that makes a hybrid directory… hybrid.
Azure AD Connect also has had a long technical evolution, with substantial changes to its security model and the permissions it uses to interact with AD and Entra ID. Unfortunately, many installations are still using a legacy permissions model with too-powerful credentials.
Open-source toolsets, notably AADInternals, have commands that enable a local administrator of the Azure AD Connect system to extract plaintext credentials of the accounts that Azure AD Connect uses to interface with Entra ID and Active Directory.
This combination is devastating. This was used in the “Mango Sandstorm” nation-state attack.
“Two weeks before the ransomware deployment, the threat actors were observed using compromised credentials to access the Azure AD Connect device. Next, they set up an SSH tunnel to an attacker-controlled device. On a separate attacker-controlled compromised device, evidence indicates cloning of the AADInternals tool. One of the functions available in this tool’s library is Get-AADIntSyncCredentials, which allows any local administrator on a device where Azure AD Connect is installed to extract the plaintext credentials of both the Azure AD Connector account and the AD DS Connector account.”
In other words, attackers used access to the Azure AD Connect system to abuse it by dumping credentials that allowed them to move from on-premises dominance to dominance over the connected cloud environment.
And yes, the impact of this specific attack could be blunted by modernizing the Azure AD Connect permissions. But this is like playing whack-a-mole with security. More fundamentally, the problem began because the attackers were able to collect compromised credentials that allowed them administrative access to Azure AD Connect.
Reduce your AD attack surface.
To avoid this misconfiguration in Active Directory: Access to the Azure AD Connect server(s) should be controlled just like any other server that controls Active Directory.
Use PAM vaulted credentials with multiple factors coupled with network level controls – whatever tools that you have in your toolkit that you might use to protect your domain controllers, use those to protect Azure AD Connect as well.
You might know this concept of ultra-protected assets as being “Tier-0”, or control plane assets. Regardless, from a practical standpoint you cannot treat an Azure AD Connect server like you would most other member servers.
Conclusion
The biggest risk to Entra ID is its ties to complex, legacy, on-premises Active Directory environments. It is unlikely that most organizations will be able to completely sever those ties, as the impact on user productivity would simply be too high. However, if you can avoid these three common misconfigurations in Active Directory, you can markedly reduce the risk to your Entra ID directory without greatly decreasing user productivity and satisfaction.
