TL;DR: Default machine-joining behaviour in AWS Managed Active Directory can let non-privileged users create computer accounts and set up Resource-Based Constrained Delegation abuse, despite AWS restrictions on domain controller access, according to Permiso Security. The core problem is that shared-responsibility boundaries and default AD assumptions still leave a machine-account path open to escalation.
At a glance
What this is: Permiso Security shows that default machine-join permissions in AWS Managed Active Directory can be used to create computer accounts and set up Resource-Based Constrained Delegation abuse.
Why it matters: IAM and cloud security teams need to treat managed directory defaults as an identity control boundary, because machine-account creation can become an escalation path even without direct domain controller access.
Context
AWS Managed Active Directory is an AWS-hosted Active Directory service, so it inherits core directory behaviours even when AWS restricts direct domain controller access. The issue here is not the service model itself, but the default machine-join and delegation assumptions that still govern who can create computer accounts and how those accounts can be used.
In practical terms, the article is about how a non-privileged identity can move from ordinary domain membership to machine-account creation and then to delegation abuse. That makes the topic directly relevant to NHI governance, service account boundaries, and cloud identity control design.
Key questions
Q: What breaks when default machine joins are left open in AWS Managed Active Directory?
A: Default machine joins let non-privileged users create computer accounts, which turns a routine domain function into an escalation path. Once a computer object exists, attackers can target delegation settings and use Resource-Based Constrained Delegation to impersonate higher-privilege identities. The failure is not only excess permission, but the assumption that workstation creation is operationally harmless.
Q: Why do machine-account creation rights increase delegation risk in managed Active Directory?
A: Because the machine object is not the end of the attack, it is the platform for abuse. If the attacker can also influence the target computer’s delegation attributes or ACLs, the new machine becomes a trusted intermediary for service ticket requests. That combination creates privilege transfer without needing domain admin access.
Q: What are the signs that AWS Managed Active Directory machine creation is being abused?
A: Look for computer-account creation by identities that are not the domain controller machine account, especially when the event appears in CloudWatch rather than from normal administrative activity. Also watch for unexpected changes to delegation-related attributes on computer objects and for new machine accounts that appear outside approved provisioning workflows.
Q: Should organisations rely on AWS defaults for workstation join permissions?
A: No. The default join model can preserve an attack path that was already risky on-prem and make it easier to exploit in a managed directory. Organisations should decide explicitly which identities may create machines, how those actions are logged, and which computer objects are allowed to delegate.
Technical breakdown
How default machine-join permissions create an attack path
Active Directory lets authenticated users create computer objects when ms-ds-MachineAccountQuota is greater than zero, and AWS Managed Active Directory cannot change that default attribute. In this case, AWS also exposes a delegated workstation-join path that gives domain users the ability to add machines even when the managed domain controller itself is not accessible. The result is that a low-privileged identity can place a machine account into the domain and use that object as the foothold for later delegation abuse. The important detail is that the join right, not domain admin access, opens the door.
Practical implication: treat machine-account creation as a privileged capability, not a harmless directory convenience.
How RBCD turns a machine account into delegated access
Resource-Based Constrained Delegation works by letting the target machine decide which other machine accounts may act on its behalf through the msDS-AllowedToActOnBehalfOfOtherIdentity attribute. If an attacker can write that attribute, or gain GenericWrite, WriteOwner, or WriteDACL on the computer object, they can add an attacker-controlled computer and request tickets as a delegated identity. That is why machine creation alone is not the end state. The dangerous combination is a newly created computer object plus writeable delegation settings on the target system.
Practical implication: review computer-object ACLs and delegation settings together, not as separate controls.
Why managed directory visibility changes the detection problem
In a normal on-prem environment, computer creation is typically visible through domain controller event logs such as Event ID 4741. In AWS Managed Active Directory, that same signal appears in CloudWatch instead, and the identity behind creation can change depending on whether the action came from a user or from an AWS API path. That means defenders need to distinguish legitimate controller-driven creation from non-controller machine creation, because the logging surface is different even when the underlying directory event is the same.
Practical implication: move directory-account monitoring into CloudWatch and alert on non-controller machine creation.
Threat narrative
Attacker objective: The attacker wants delegated access that can be used to impersonate a privileged identity on target systems without needing direct domain admin rights.
- Entry occurs when a low-privileged domain user, or a host with delegated AWS directory privileges, is able to create a new computer account in AWS Managed Active Directory.
- Credential access and escalation follow when the attacker uses the machine account to write delegation-related attributes on a target computer object or leverage permissive ACLs.
- Impact occurs when the attacker requests service tickets as a delegated identity and obtains access equivalent to the delegated account, enabling lateral control within the managed directory.
Breaches seen in the wild
- Codefinger S3 ransomware 2025: Codefinger used victims' compromised AWS keys to re-encrypt S3 buckets with SSE-C, set 7-day deletion and demanded ransom for the key.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Default machine joining is a privileged identity event, not an administrative convenience. AWS Managed Active Directory keeps the old AD assumption that the right to add a workstation is low risk. That assumption fails when machine creation becomes the first step in a delegation attack. Practitioners should treat join permissions as part of the identity governance surface, not as a desktop-management exception.
Machine-account creation and delegation rights form a single control plane. The article shows that computer creation, write access to delegation attributes, and ticket issuance are not separate problems. They are stages in one abuse path that turns an ordinary domain object into a delegated execution point. The control gap is not just excessive privilege, but the absence of object-level lifecycle oversight on computer accounts.
Managed directory services do not remove inherited Active Directory attack paths. AWS limits direct domain controller access, but that does not neutralise default AD behaviours such as ms-ds-MachineAccountQuota or RBCD. This is a classic shared-responsibility blind spot: the platform constrains one access path while leaving the delegated identity path intact. Security teams should evaluate managed directories against the same abuse patterns they would apply on-prem.
Identity governance for cloud directories must include computer objects and join pathways. Many IAM programmes focus on human accounts, SSO, and role mapping, then leave machine account creation outside the governance model. This article shows why that is incomplete. If a non-privileged user can create a machine and use it to influence delegation, the directory is already governing more than its policy model admits.
Cloud-managed AD needs a named control concept: default join exposure. The core issue is not merely overprivilege or misconfiguration, but the exposure created when default workstation-join behaviour is inherited into a managed environment without equivalent administrative friction. That is a governance failure in the identity plane, and it should be tracked as such in programme design and audit reviews.
What this signals
Default join exposure: managed directory services can inherit legacy AD assumptions even when the cloud platform restricts direct controller access. For practitioners, that means the governance question shifts from 'can users see the domain controller' to 'who can create a machine object and what can that object do next'.
Cloud directory monitoring has to follow the event surface, not the on-prem mental model. If machine creation is only watched in traditional domain controller logs, the alerting strategy will miss the actual control plane where AWS Managed Active Directory records the event.
The critical design mistake is to separate workstation join, computer-object ACLs, and delegation rights into different operational owners. In this attack path, those controls are one governance problem, because abuse begins when a low-friction join right meets a delegable machine object.
For practitioners
- Restrict workstation-join membership Move AWS Delegated Add Workstations to the Domain away from broad Domain Users membership and limit it to a tightly controlled administrative group.
- Monitor machine creation events in CloudWatch Alert on Event ID 4741 and flag any machine account creation performed by a non-controller identity or a non-administrative identity.
- Review computer-object delegation rights Audit msDS-AllowedToActOnBehalfOfOtherIdentity and the ACLs that permit GenericWrite, WriteOwner, or WriteDACL on computer objects.
- Inventory directoryservice:CreateComputer access Identify instance profiles and IAM policies that allow ds:CreateComputer and ds:DescribeDirectories, then scope them to the smallest feasible set of workloads.
Key takeaways
- AWS Managed Active Directory still exposes an AD attack pattern where default machine creation can become an escalation path.
- The article shows that low-privilege machine creation and delegation abuse are linked through computer-object permissions, not through domain admin access.
- Practitioners should treat machine joins, delegation attributes, and CloudWatch monitoring as one control set if they want to contain RBCD abuse.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | Computer accounts and delegated access must be removed when join privileges change. |
| NHI-05 — Overprivileged NHI | The attack depends on excessive join and delegation rights on machine objects. | |
| NHI-08 — Environment Isolation | Managed AD join behaviour crosses trust boundaries when broad users can create machines. | |
| Recommendation — Revoke stale machine-join pathways and offboard unused computer accounts from managed AD. Reduce machine-account creation and delegation rights to the minimum required set. Separate administrative join paths from general domain users to preserve environment boundaries. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Computer-account credentials and delegation settings are part of authenticator lifecycle governance. |
| Recommendation — Apply authenticator lifecycle controls to machine accounts and their delegated access paths. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The issue is an entitlement problem that lets low-privileged users create domain machines. |
| Recommendation — Review entitlements that allow machine creation and remove unnecessary join permissions. | ||
Key terms
- Resource-Based Constrained Delegation: Resource-Based Constrained Delegation is a delegation model that limits which systems can act on behalf of others. It reduces the abuse potential of older delegation settings by making the target resource control the trust relationship rather than the delegating account.
- Machine Account Quota: The Active Directory setting that limits how many computer objects a non-admin user can create. In managed directories, the quota may remain in place even when customers cannot fully administer the domain, which makes the surrounding join workflow and group membership just as important as the setting itself.
- Computer Object ACL: The permissions that control who can read, modify, own, or delegate a computer account in Active Directory. When these ACLs include write or ownership rights, they can become the mechanism that turns a machine join into delegation abuse.
- Delegated Workstation Join: A directory permission or group membership that allows users or systems to add machines to a domain. In AWS Managed Active Directory, broad membership in this join path can create a machine-account foothold even without direct domain controller access.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on June 25, 2026.
Updated on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org