Drawbacks to syncing Active Directory and Azure Active Directory privileged accounts
Introduction
Microsoft’s Active Directory (AD) has been the go to identity management tool in the SMB and enterprise space for decades now, naturally as the demand for cloud services expands Microsoft’s Azure Active Directory (AAD) is a convenient and logical next step.
It is pretty much a given that most businesses will sync their on-premises AD accounts into AAD using Azure AD Connect or the newly released Azure AD Connect cloud sync.
A common and somewhat natural extension of syncing, is the syncing privileged accounts from AD to AAD and granting those same accounts privilege within the cloud.
There are some pretty large drawbacks to this approach.
The Risks of Syncing
Syncing unprivileged user accounts is great, for most end users they only have to manage one identity, their username and password which makes leveraging SSO and the like very convenient, users can even change their on-premise password using password writeback.
Syncing privileged accounts is where the risk starts.
The riskiest configuration is elevating synced productivity accounts.
Why?
Using productivity accounts as privileged accounts is already risky, when combining this with syncing it is riskier still. Productivity accounts have the largest scope of possible attack vectors, whether this be phishing emails, malicious websites, malicious downloads etc.
An example kill chain might be a productivity account opening a malicious email leading to malware installation and device exploitation. This foothold might then allow for credential theft. These stolen credentials now provide an attacker access to AD resources and a new target AAD. If this productivity account has the ability to elevate permissions within AAD then your cloud identity service is now compromised along with all the resources associated with it.
For synced privileged accounts, imagine a similar attack. Instead of an attacker then pivoting straight to the cloud using the initial foothold, the attacker attempts lateral movement locally and potentially compromises a privileged account, then compromises the domain. The attacker then use synced privileged accounts to impersonate the privileged AAD user and compromise AAD.
Always Assume Breach
There are many great on-premise controls that can alleviate some of this risk. Likewise there are cloud controls that can protect you as well, including just in time privilege, multi-factor authentication.
All these controls are worth implementing and greatly reduce risk but no controls are absolute. There is always residual risk.
Assuming breach is a core tenet of the ‘Zero Trust’ security model. This security model is the architecture underpinning the next iteration of information security for organisations.
Recommendations
Cloud privileged accounts should be cloud-native. This means having accounts with access to privileged roles completely managed within Azure AD. This segregates the privileges and embodies the ‘just enough’ privilege principle.
The control of the cloud will now rest in the cloud.
Key controls in protecting cloud-native administrators in no particular order:
Recommended Controls
- Multifactor Authentication
- Conditional Access Policies
- AAD Privileged Identity Management (PIM)
- Privileged Access Workstations (PAW)
- Treat key roles like Global Administrator (eg Privileged Authentication Administrator, Privileged Role Administrator)