Securing Active Directory on AWS: A Practical Guide to AD Tiering with ANSSI and AWS SRA Alignment

95% of enterprises use Active Directory for authentication. When you migrate AD to AWS under regulatory pressure — ANSSI in France, NIS2 across the EU — the architecture decisions get surprisingly hard. This post breaks down how to align the AD tiering model with AWS multi-account patterns, and which AWS security services fill the compliance gaps.

The Problem

Most enterprises federate their on-premises Active Directory with AWS through IAM Identity Center. It works, it’s convenient, and it gives users single sign-on across AWS accounts. But here’s the thing nobody talks about: if your on-prem AD Tier 0 is compromised, your entire AWS environment is compromised too.

The attack chain is straightforward:

1. Attacker compromises on-prem AD (phishing, vulnerability, insider)
2. Modifies AD group memberships mapped to IAM Identity Center permission sets
3. Issues valid SAML assertions for any AWS role
4. Gets admin access to the AWS Organization — CloudTrail, S3, IAM, everything

There is no security boundary between a compromised AD domain and the AWS resources that trust it via federation. Tier 0 AD = Tier 0 AWS. And if you’re subject to ANSSI recommendations (the French national cybersecurity agency), you need to treat this seriously — their AD security guide (ANSSI-PA-099) explicitly mandates a tiered administration model.

The real challenge: how do you implement AD tiering on AWS while staying compliant with ANSSI and aligned with the AWS Security Reference Architecture?

The Solution

Map the ANSSI 3-tier model directly onto your AWS multi-account strategy. Use AD self-managed on EC2 for Tier 0 (not AWS Managed AD), IAM-only access for privileged admins, and layer AWS SRA security services on top to close the compliance gaps that AD alone cannot address.

How It Works

The ANSSI Tiering Model — Quick Primer

The ANSSI guide ANSSI-PA-099 (October 2023) mandates a privileged access management model based on Microsoft’s 3-tier architecture:

Tier	Scope	What’s at Stake
Tier 0	Domain Controllers, Enterprise Admins, PKI, Federation services	Total domain control — if compromised, everything falls
Tier 1	Application servers, databases, management infrastructure	Workload impact, business data exposure
Tier 2	Workstations, user accounts, mobile devices	Individual user compromise

The fundamental rule: Tier 0 credentials must never touch Tier 1 or Tier 2 systems. If a Domain Admin logs into a standard workstation, their credentials sit in memory and can be extracted with tools like Mimikatz. This breaks the entire tiering model.

ANSSI takes this further with recommendation R68 — Kerberos Armoring (section 4.12): enable “blindage Kerberos” on all Tier 0 systems. This protects Kerberos exchange traffic using the machine account (240-bit password), making offline brute-force attacks unrealistic. It requires machine certificates from a PKI infrastructure and a Domain Functional Level >= 5 (Windows Server 2012+).

Why AWS Managed AD Doesn’t Work for Tier 0

This is the insight that’s not documented anywhere in AWS docs: AWS Managed AD is incompatible with ANSSI Tier 0 requirements.

Here’s why:

Requirement	AWS Managed AD	AD on EC2
Domain Admin access	No (delegated admin only)	Yes (full control)
RDP access to DCs	No	Yes
ANSSI audit tools (PingCastle, Purple Knight)	Cannot run (no DC access)	Full access
AD Certificate Services (PKI)	Not supported	Full support
Kerberos Armoring (R68) GPO deployment	Constrained	Full control
Custom schema extensions	Enterprise Edition only	Full control
Isolated Tier 0 forest	Not feasible (1 forest per instance)	Multiple forests possible
Security hardening (dSHeuristics, adminSDHolder)	Limited	Full access

The deal-breaker for ANSSI compliance: you cannot audit what you cannot access. ANSSI requires full audit capability on Tier 0 systems, and Managed AD gives you a delegated admin account — not Domain Admin. You can’t run PingCastle. You can’t inspect the adminSDHolder. You can’t verify dSHeuristics values. You’re flying blind on the most critical part of your infrastructure.

There’s also a concrete technical blocker: Kerberos Armoring (R68) requires machine certificates issued by an AD CS PKI. AWS Managed AD doesn’t support AD Certificate Services. And if you try to use IAM Identity Center with an AD Connector for Tier 0 access, you can’t implement Kerberos Armoring or machine certificate authentication — AD Connector is a simple LDAP/Kerberos proxy that doesn’t support these features.

Mapping AD Tiers to AWS Accounts

Here’s how the tiers translate into AWS multi-account architecture:

AD Tier	AWS Scope	Access Method	Example
Tier 0	Management Account, Security OU (Log Archive, Audit, Security Tooling)	IAM users only — no federation, hardware MFA, PAWs	~15 users: AD admins, network team, AWS admins
Tier 1	Workload accounts (Infrastructure OU, Workloads OU)	Federation via Entra ID + Conditional Access + TOTP MFA	Server admins, database admins, DevOps
Tier 2	Sandbox accounts, read-only, application access	Standard federation, push notification MFA	Developers, read-only users

The critical design principle: Tier 0 AWS access must never go through federation. If your AD is compromised, federated access is compromised. Tier 0 admins authenticate with native IAM users stored in a physical safe, with hardware MFA tokens. This is your break-glass path that works even when Active Directory is down.

Align this with AWS Control Tower OUs:

Root
├── Security OU (Tier 0) ← Ultra-restrictive SCPs
│   ├── Log Archive Account
│   ├── Security Tooling Account
│   └── Audit Account
│
├── Infrastructure OU (Tier 1) ← Restrictive SCPs
│   ├── Network Account
│   ├── Shared Services Account (Managed AD + IAM IDC)
│   └── Management Tools Account
│
├── Workloads OU (Tier 1)
│   ├── Production Accounts
│   └── Non-Production Accounts
│
└── Sandbox OU (Tier 2) ← Budget + blast radius SCPs
    └── Developer Sandbox Accounts

Building Tier 0 AD on EC2

For the AD infrastructure itself, the architecture follows these patterns:

AD Forest design — 2 domains:

• Root Domain (pure Tier 0): Domain Controllers, PKI Root CA (offline), SubCA dedicated to Tier 0
• Child Domain (operational): Domain Controllers behind NLB, SubCA for Tier 1, WSUS

PKI hierarchy — separated by tier:

PKI Root CA (offline) ← Private key never exposed to network
    │
    ├── SubCA/T0 ← Certificates for Tier 0 machines (Kerberos Armoring)
    │
    └── SubCA/T1 ← Certificates for Tier 1 machines

This separation means a compromised Tier 1 SubCA cannot issue Tier 0 certificates. The Root CA being offline means its private key cannot be stolen through a network attack — it’s the gold standard for PKI security recommended by both ANSSI and Microsoft.

Network isolation:

• Dedicated VPCs per T0 account (Network T0, Windows T0, Backup T0)
• Transit Gateway for inter-account connectivity
• NLB in front of Domain Controllers (LDAP/Kerberos load balancing)
• AWS Client VPN as the single entry point for T0 admins from PAWs
• Route 53 Resolver Rules for DNS resolution of AD domains

Backup — immutable:

• AWS Backup Vault Lock with retention + lock periods (e.g., 180 days production)
• Even a compromised AWS admin cannot delete these backups
• This is your anti-ransomware insurance for the AD database

Admin access:

T0 Admin → PAW (hardened workstation) → Client VPN → Network T0 → NLB → Domain Controllers

No shortcuts. No RDP from a standard workstation. No VPN from a corporate laptop. PAWs only.

AWS SRA Security Services for Tier 0

The AD infrastructure handles identity and authentication. But the AWS accounts hosting it need their own security posture. Here’s where the AWS Security Reference Architecture comes in.

Must-have services for Tier 0 accounts:

Service	Why It Matters for Tier 0
Security Hub CSPM	Continuous posture management with NIST 800-53 and CIS AWS Foundations standards. Validates ~200+ controls: CloudTrail enabled, MFA on root, EBS encrypted, VPC Flow Logs active. This is your ANSSI compliance baseline on the AWS side.
CloudTrail	Organization trail logging all API actions across T0 accounts. Immutable logs in S3 with SSE-KMS. If someone disables GuardDuty or modifies a Security Group on a DC, you’ll know.
GuardDuty	Behavioral anomaly detection: abnormal federated logins, credential exfiltration, privilege escalation, off-hours activity. Extended Threat Detection catches multi-stage attacks.
AWS Config	Continuous config audit. Conformance packs for NIST/CIS. Detects drift: “someone changed the Security Group on the DC subnet” triggers an alert.
KMS	Customer-managed keys for EBS encryption (NTDS.dit contains all AD secrets), CloudTrail logs, and backups.
SCPs	Preventive guardrails: deny CloudTrail deletion, deny GuardDuty disable, deny Security Hub disable, restrict regions. First line of defense.

High-value additions:

Service	Why
IAM Access Analyzer	Validates that none of the ~15 Tier 0 IAM users have excessive permissions. Detects external access to S3 buckets or IAM roles.
VPC Flow Logs	Captures all network traffic in T0 VPCs. Essential for detecting lateral movement and abnormal AD traffic (LDAP, Kerberos, SMB).
Security Lake	Normalizes all logs to OCSF format for correlation with on-prem SIEM.
EventBridge	Automated remediation: CloudTrail disabled → Lambda re-enables it in < 2 minutes.
Secrets Manager	Automatic rotation of AD service account passwords. Aligned with ANSSI remediation guide (krbtgt, DSRM, admin accounts).
Inspector	Vulnerability scanning of Windows DCs. Detects unpatched CVEs on your most critical servers.

SRA Meets ANSSI — Mapping the Gaps

Here’s the cross-reference table that ties everything together:

ANSSI Requirement	Covered by AD/GPO	Covered by AWS SRA
R1 — Tiered administration model	OU structure, GPOs, dedicated admin accounts	SCPs per tier, multi-account isolation
R18 — Security baselines	Microsoft security baselines via GPO	AWS Config conformance packs + Inspector
R29 — Control secret dissemination	Tier isolation, Protected Users group	GuardDuty (credential exfiltration), IAM Access Analyzer
R68 — Kerberos Armoring	PKI SubCA/T0 machine certificates, GPO config	Not covered by AWS (AD-level config)
R71 — Prohibit NTLM for Tier 0	Protected Users group, GPO NTLM restriction	VPC Flow Logs detect abnormal NTLM traffic
R73 — Block outbound NTLM from Tier 0	GPO outbound NTLM blocking	Network Firewall can filter at network level
Section 2.4 — Logging and detection	Windows Event Forwarding, SIEM	CloudTrail + VPC Flow Logs + Security Lake
Immutable backups	N/A	AWS Backup Vault Lock
Compliance posture	N/A	Security Hub CSPM (NIST 800-53 / CIS)
Incident response	N/A	Security Incident Response + CIRT (free with Enterprise Support)

The key insight: neither AD alone nor AWS alone covers everything. AD handles identity-level security (Kerberos, NTLM, GPOs, tiering). AWS handles infrastructure-level security (posture management, logging, detection, backup immutability). You need both, working in concert.

What I Learned

• Tier 0 AD = Tier 0 AWS when federated — this is the single most important insight. If your AD is compromised and you federate to AWS, your AWS environment is compromised. No exceptions. Design for this assumption.

• AWS Managed AD is great for Tier 1/2, but incompatible with ANSSI Tier 0 — the lack of Domain Admin access, DC access, and AD Certificate Services makes it impossible to implement the full ANSSI hardening recommendations. AD on EC2 is the right choice when regulatory compliance requires full audit capability.

• Kerberos Armoring (ANSSI R68) is a concrete technical blocker for IAM Identity Center on Tier 0 — this isn’t theoretical. If ANSSI requires R68, and R68 requires machine certificates + GPO deployment on DCs, then AD Connector / IAM IDC cannot serve Tier 0. Use native IAM users with hardware MFA instead.

• The AWS SRA and ANSSI are complementary, not competing — ANSSI covers identity-level security (AD, GPO, PKI, Kerberos). The AWS SRA covers infrastructure-level security (CSPM, logging, detection, remediation). Map them together for full coverage.

• Backup Vault Lock is the AD anti-ransomware insurance — if an attacker takes over your domain, they’ll try to destroy backups. AWS Backup Vault Lock makes this physically impossible for the lock period. This single feature justifies hosting AD on AWS.

What’s Next

• Build an open-source SCP template library for AD Tier 0/1/2 accounts (CloudFormation + Terraform)
• Create an AWS Config conformance pack mapping ANSSI-PA-099 recommendations to AWS controls
• Write a follow-up on the ANSSI AD Remediation Guide and how it maps to AWS migration (Scenario 3 = migration checklist)
• Test Security Hub NIST 800-53 standard coverage against the full ANSSI-PA-099 recommendation set