The most expensive mistake I still see in hybrid identities isn’t “using on‑prem AD”, but connecting it to the cloud as if it were a natural extension of the datacenter: same groups, same hierarchies and, above all, the same privileges. On paper it sounds efficient. In a real incident, it’s an impact multiplier.
When you synchronize without segmentation to Entra ID (Azure AD) or to AWS IAM Identity Center, your local Active Directory stops being “legacy infra” and becomes the access control plane for your SaaS, your cloud and your accounts. The cloud can have excellent controls, but if the identity that governs it is tied to an exposed AD, the weakest link decides the outcome.
What went wrong: the day an on‑prem server opened the door to the cloud
The pattern usually repeats itself: a local server (sometimes a jump server, sometimes a “forgotten” file server) falls due to reused credentials, a pending patch, or inherited RDP access. The team that operates cloud, seeing that “cloud is fine”, interprets it as an incident limited to the on‑prem environment. Meanwhile, the attacker is already playing with the real target: AD.
With a foothold in the corporate network, the attacker looks for credentials and tickets. If they find an account with high privileges in the domain (or a poorly managed service account), escalation is a matter of technique and time. The critical point comes when those same groups or users are synchronized and mapped to administrative roles in Entra ID or in AWS. From there, the jump to the cloud is not “another attack”: it’s a direct consequence of how you designed the hybrid identity.
In companies, this often blows up as operational damage: creation of malicious OAuth applications in Entra ID, new persistent access credentials, or assignment of cloud permissions to “domain” accounts that were already compromised. The incident stops being “a server” and becomes “the whole organization”.
The real attack surface: local AD as a privilege bridge to Entra ID and AWS
Identity is the bridge between environments. If your local AD feeds (without controls) Entra ID or IAM Identity Center, you are extending to the cloud the trust in the on‑prem domain. That trust is not abstract: it’s people, groups and memberships that end up authorizing critical actions in the cloud.
In practice, many companies synchronize “the entire domain” because it’s the fastest way to enable SSO, email, Teams, access to internal apps or federation with SaaS. The problem comes when the “usual” groups (Domain Admins, Server Admins, groups from historical delegations) end up being used as the source of truth for cloud permissions. The attacker doesn’t need to “break” Azure or AWS: it’s enough to be “someone” with memberships that the cloud respects.
- Synchronization without segmentation: if any sensitive OU or group ends up in the cloud, a change on‑prem (legitimate or malicious) becomes cloud authorization. This includes onboarding/offboarding, membership changes, and account creation.
- Privilege inheritance: teams that historically used Domain Admin to “solve quickly” in Windows end up with high‑privilege accounts that also administer cloud. It’s convenient until a stolen hash becomes a global role.
- Service accounts with SPN and excessive permissions: they are typical Kerberoasting targets. If they are also synchronized or associated with app/role permissions, exploitation can end in persistent access in the cloud directory.
What matters is the business effect: the attacker doesn’t need to move laterally across dozens of cloud servers. By controlling the identity that grants permissions, they can operate “as an administrator” from the console, with actions that look legitimate and complicate attribution and response.
Abuse scenarios: Pass-the-Hash and Kerberoasting that end in “Cloud Admin”
Two classic techniques in on‑prem AD remain devastating when there are hybrid identities: Pass-the-Hash and Kerberoasting. It’s not nostalgia: they still work in real corporate environments because there is dependence on NTLM, uneven credential hygiene, and service accounts that live for years without rotation.
In Pass-the-Hash, the attacker uses captured hashes to authenticate without knowing the password. If that hash belongs to an account with privileges in the domain (or with access to a server where administrative tasks run), it can lead to AD control. In Kerberoasting, the attacker requests TGS tickets for SPNs and cracks them offline; if they recover the password of a service account with broad permissions, the domain falls silently.
The jump to the cloud happens when that account (or the groups it controls) are tied to roles in Entra ID or in AWS IAM Identity Center. A typical example: an on‑prem administration account that, for “convenience”, is also used to administer Microsoft 365 or assume roles in AWS. In the attacker’s timeline, the cloud is simply the next control panel.
- Entra ID: after compromising synchronized identities, the attacker looks for role assignment (for example, privileged roles) and persistence via applications/consents. The real impact is usually access to email, SharePoint and creation of persistent identities.
- AWS with IAM Identity Center: if the synchronized user or group has assignment to powerful Permission Sets, the attacker can obtain high‑privilege sessions in AWS accounts. From there, response becomes complex because there is “valid” activity from a corporate principal.
The organizational consequence is that the mental boundary between teams breaks: “on‑prem” and “cloud” are no longer separate risk domains. The local directory acts as a provider of authority for both, and any on‑prem breach is an identity breach with cloud effect.
How to do it in practice: segment synchronization and separate cloud privileges
The mitigation is not “stop synchronizing”, but to design synchronization as a minimum channel. In production, the first thing I recommend is treating the AD→cloud integration as a critical system: with defined scope, controls and periodic reviews. If today you synchronize “everything”, assume you have accumulated security debt.
Concrete actions that work in companies:
- Filter what is synchronized (OU and groups): create specific OUs for identities that must exist in the cloud (end users, app identities if applicable) and exclude administrative OUs. Validate that sensitive groups do not appear in the cloud directory nor are used for role assignment.
- Do not assign cloud roles to Domain Admins or equivalent groups: in mature environments, AD administrators and cloud administrators are different identities (and ideally different workstations). If you need cross‑administration, make it with dedicated accounts and with approval/justification.
- Strict MFA for federated administrative access: configure policies so that any access to portals and privileged actions require strong MFA (phishing‑resistant when possible). Operationally, this cuts many chains where the attacker “only” needs credentials.
Validation is part of the job: routinely review which groups are reaching the cloud, which roles they have assigned and whether there are indirect paths (for example, a “harmless” group that contains another privileged group). In internal audits the same finding usually appears: “the portal was restricted, but a permission assignment path was left via group synchronization”.
A frequent anti‑pattern is delegating the problem by silos: the Windows team “only” maintains AD; the cloud team “only” assigns roles. In hybrid identities, that division creates gaps: no one feels ownership of end‑to‑end risk. The real solution is shared ownership with explicit controls on the bridge (synchronization, group mapping, access policies).
Recommendations for corporate environments
If your on‑prem AD synchronizes with Entra ID or with AWS IAM Identity Center, assume the local directory is part of the cloud security perimeter. The most common operational mistake is synchronizing without segmentation and allowing on‑prem administration groups or accounts to have authority in the cloud.
In practical terms, the approach that reduces incidents is consistent: limit synchronization to what is necessary, avoid Domain Admins (or equivalents) being cloud administrators, and require strict MFA on any federated administrative access. This does not eliminate the risk of local AD, but it prevents an on‑prem compromise from automatically becoming a cloud compromise at scale.
The signal of maturity is not “we have SSO”, but being able to demonstrate that the hybrid identity is segmented, that privileges are not inherited for convenience and that cloud administration does not depend on reused credentials from the local domain. When that evidence exists, the impact of an on‑prem incident stops being catastrophic for the cloud.
Interested in Cloud Security?
Technical analysis, hands-on labs and real-world cloud security insights.