Subscribe to the Non-Human & AI Identity Journal

Notifications
Clear all

AWS Managed Active Directory: why default machine joins still matter


(@nhi-mgmt-group)
Member Moderator
Joined: 1 year ago
Posts: 8534
Topic starter  

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.

NHIMG editorial — based on content published by Permiso Security: An Arrow to the Heel: Abusing Default Machine Joining to Domain Permissions to Attack AWS Managed Active Directory

By the numbers:

  • 10., default, the ms-ds-MachineAccountQuota attribute is 10.

Questions worth separating out

Q: What breaks when non-privileged users can create machine accounts in managed Active Directory?

A: The trust model breaks because machine creation becomes an escalation path, not a harmless provisioning action.

Q: Why do AWS Managed Active Directory defaults increase the risk of delegation abuse?

A: Managed directory defaults can preserve AD behaviours that assume full domain administration, even when the customer only has partial control.

Q: How do security teams know whether machine creation is being abused?

A: The clearest signal is unexpected computer-account creation by a non-admin identity, especially where CloudWatch records Event ID 4741 and the creator is not a domain controller or approved administrator.

Practitioner guidance

  • Remove Domain Users from workstation-join groups Restrict AWS Delegated Add Workstations to the Domain so only administrators can join machines, and validate that ordinary domain users cannot create computer objects through the default path.
  • Review every policy that grants ds:CreateComputer Inventory EC2 instance profiles and service roles with directory-service privileges, then remove broad create-computer access from workloads that do not explicitly need to provision domain machines.
  • Audit machine-object delegation rights Check computer object ACLs for GenericWrite, WriteDACL, WriteOwner, and similar permissions that could let a low-privilege identity modify RBCD settings.

What's in the full article

Permiso Security's full analysis covers the operational detail this post intentionally leaves for the source:

  • Step-by-step breakdown of how ms-ds-MachineAccountQuota interacts with AWS Delegated Add Workstations to the Domain
  • CloudWatch monitoring examples for spotting non-admin machine creation and DirectoryService Event ID 4741
  • The AWS policy paths, including AmazonSSMDirectoryServiceAccess and AmazonEC2RoleforSSM, that can enable ds:CreateComputer abuse
  • Permiso's recommended detection logic for identifying computer-account creation by non-instance identities

👉 Read Permiso Security's analysis of AWS Managed Active Directory machine-join abuse →

AWS Managed Active Directory: why default machine joins still matter?

Explore further

View Full Forum →  |  NHI Foundation Course →



   
Quote
(@mr-nhi)
Member Moderator
Joined: 1 month ago
Posts: 7990
 

Default machine-join controls were designed for a world where directory admins control the boundary. That assumption fails in AWS Managed Active Directory because the customer does not control the same objects, the same service paths, or the same enforcement surface as on-prem AD. The implication is that quota-based thinking alone is insufficient for managed directory governance, because the trust boundary has shifted underneath the control.

A few things that frame the scale:

  • 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to The 2026 Infrastructure Identity Survey.
  • Systems with least-privileged AI access had a 17% incident rate vs 76% for over-privileged systems, showing that scope control is a measurable security variable.

A question worth separating out:

Q: Who is accountable when a managed directory permits RBCD-style escalation?

A: Accountability is shared across the cloud provider, the platform team, and the identity team, but the customer still owns group membership, workload permissions, and monitoring. A managed service does not remove the need to govern who can join machines, who can create them through APIs, and who can modify delegation paths.

👉 Read our full editorial: AWS Managed Active Directory machine creation enables RBCD abuse



   
ReplyQuote
Share: