sota.io
2026-05-01·14 min read·
AWS Directory Service is Amazon's managed offering for running Microsoft Active Directory (AD) in the cloud. It comes in two main flavours: **AWS Managed Microsoft AD** (a full Windows Server AD domain, AWS-operated) and **AD Connector** (a proxy that forwards authentication requests to an on-premises AD without caching credentials). A third option, **Simple AD**, provides basic LDAP-compatible directory functions via Samba 4 without full AD features. For European companies that need to manage user identities, authenticate employees, and control access to internal applications, AWS Directory Service looks attractive: no AD domain controller hardware to maintain, automatic patching, multi-AZ replication, and seamless integration with other AWS services. The catch is that every identity record, every authentication event, and every HR attribute stored in that directory is now on US-controlled infrastructure — directly reachable under the US CLOUD Act. This post breaks down what AWS Directory Service actually holds, why CLOUD Act jurisdiction applies to every record, and what EU-native alternatives provide equivalent functionality without surrendering control of your corporate identity layer. --- ## What AWS Directory Service Actually Stores Before analysing the GDPR implications, it is worth being precise about the data held in AWS Managed Microsoft AD. A corporate Active Directory is far richer than most developers realise. **Core identity objects stored by default:** - User accounts: sAMAccountName, userPrincipalName, displayName, given name, surname, email addresses - Authentication secrets: password hashes (NTLM and Kerberos), Kerberos ticket-granting tickets - Group memberships: security groups, distribution lists, organisational unit assignments - Computer objects: domain-joined machine names, OS versions, last logon timestamps - Service principal names: SPNs for services that authenticate to the domain **Extended attributes that HR systems populate:** This is where AWS Directory Service moves far beyond a simple username database. Active Directory's schema includes hundreds of optional attributes that HR systems routinely populate: - `department`, `title`, `company`, `manager` — organisational hierarchy - `telephoneNumber`, `mobile`, `physicalDeliveryOfficeName` — contact and location data - `employeeID`, `employeeNumber`, `employeeType` — HR identifiers - `extensionAttribute1` through `extensionAttribute15` — custom fields, frequently used for payroll grades, contract types, disability accommodation flags, union membership status, and security clearance levels - `userAccountControl` — account status flags (disabled, locked, must-change-password) - `whenCreated`, `whenChanged`, `lastLogon`, `lastLogonTimestamp` — temporal behavioural data **Authentication and access logs (CloudTrail + AWS CloudWatch):** Every LDAP bind, Kerberos authentication, and NTLM challenge-response is logged. CloudWatch captures domain controller events including Event ID 4624 (successful logon), 4625 (failed logon), 4768 (Kerberos ticket requested), and 4776 (NTLM credential validation). These logs identify not just that a user authenticated, but from which IP, at what time, using which protocol — a detailed portrait of workplace behaviour. --- ## GDPR Vector 1 — Art.9 Special Category Data in AD Attributes Article 9 GDPR prohibits processing special category data (health, disability, union membership, religious/philosophical beliefs, political opinions, biometric data used for identification) without explicit consent or another specific Art.9(2) basis. AWS Managed Microsoft AD routinely holds exactly this data. **Disability accommodations:** HR departments commonly use `extensionAttribute` fields or custom AD attributes to flag employees who require reasonable adjustments (screen reader software, ergonomic equipment, reduced working hours). A field like `extensionAttribute3: accessibility=screen_reader_required` is health data under Art.4(15) and Art.9(1). **Union membership:** Works councils and trade unions frequently request group-based access policies. Creating a security group `CN=UnionMembers,OU=Groups,DC=company,DC=com` and adding relevant employees is standard AD practice. Union membership is Art.9(1) special category data. This group — and its membership list — now lives in AWS Managed Microsoft AD. **Religious accommodations:** Calendar integrations for prayer times, dietary requirement flags for corporate catering systems, holiday entitlement variations based on religious observance — all frequently stored as AD attributes or group memberships. **Political opinions:** Less common but not rare: employees who have declared conflicts of interest relating to government contracts, employees subject to political exposure person (PEP) screening — sometimes flagged in AD attributes for access control purposes. **The CLOUD Act consequence:** Art.9 data requires a higher standard of protection than ordinary personal data. Placing Art.9 data in AWS Managed Microsoft AD means this heightened-sensitivity data is on US-controlled infrastructure with no adequate protection agreement (the EU-US Data Privacy Framework does not provide CLOUD Act immunity). A CLOUD Act order directed at Amazon Web Services yields not just employee names but disability status, union membership, and religious accommodation flags — for every employee in the directory. --- ## GDPR Vector 2 — CLOUD Act Scope: The Identity Data Treasure Trove The US CLOUD Act (18 U.S.C. § 2713) requires US providers to disclose stored data regardless of where that data is physically stored. For AWS Directory Service, this means: **What a single CLOUD Act order can reach:** 1. **All user objects** — every employee account including name, username, email, phone, department, manager, job title, HR identifiers, custom attributes 2. **All group memberships** — full mapping of who belongs to which security group, revealing organisational structure, access privileges, and sensitive group memberships (union, HR, legal, executive) 3. **Authentication logs** — CloudWatch domain controller logs showing exactly when each employee logged in, from where, using which workstation, and which services they authenticated to 4. **Password metadata** — password last-set dates, account lockout history, failed authentication counts (revealing potential security incidents or terminated employees who kept trying) 5. **Group Policy Objects** — the security policies applied to different classes of employees, revealing what restrictions apply to which staff categories 6. **Trust relationships** — if AWS Managed Microsoft AD has trust relationships with on-premises AD or other directories, the order can extend to those trust relationships **The silent disclosure problem:** Unlike a data breach, CLOUD Act compliance does not require Amazon to notify the data subject or the data controller. Art.5(2) GDPR requires controllers to demonstrate accountability — but if Amazon complies with a CLOUD Act order silently, the controller has no record of what was disclosed, to whom, or why. This makes it structurally impossible to demonstrate compliance with Art.5(2) for identity data held in AWS Managed Microsoft AD. --- ## GDPR Vector 3 — Art.28 Processor Chain and Schrems II AWS acts as a data processor when running your Managed Microsoft AD domain. This creates several specific GDPR obligations. **The Art.28 DPA gap:** AWS's Data Processing Addendum covers AWS services broadly, but Managed Microsoft AD domain controllers run on EC2 instances within AWS's infrastructure. The AWS Microsoft AD domain is an extension of your domain namespace — AWS's engineers have administrative access to the domain controllers for patching and operations. This is elevated processor access: not just infrastructure access, but domain administrator-level access to your identity layer. **Schrems II and Standard Contractual Clauses:** The Court of Justice's Schrems II judgment (Case C-311/18) invalidated the EU-US Privacy Shield and established that SCCs alone are insufficient when the destination country's surveillance laws override contractual obligations. The US CLOUD Act is precisely such a surveillance law — it overrides any contractual commitment Amazon makes in its DPA. The German Data Protection Conference (DSK) and the EDPB have consistently held that SCCs do not legitimise transfers where the US provider is subject to CLOUD Act compulsion. **The sub-processor maze for hybrid setups:** Many companies use AWS Managed Microsoft AD alongside AWS WorkSpaces (virtual desktops), AWS SSO/IAM Identity Centre, AWS RDS with Windows Authentication, and Microsoft 365 with AD sync. Each of these creates additional processor relationships. The AD serves as the identity backbone for all of them. A single CLOUD Act order targeting the AD yields authentication data for every integrated service. --- ## GDPR Vector 4 — Art.5(1)(e) Storage Limitation and Stale Identity Records Article 5(1)(e) requires personal data to be kept no longer than necessary. Active Directory's design creates systematic violations of this principle. **The tombstone problem:** When you delete a user account in Active Directory, it is not deleted immediately. AD creates a "tombstone" object — a stripped-down version of the deleted account — which persists for the tombstone lifetime, typically 180 days. During this period, the former employee's identity record (name, username, SID) remains in the directory. In AWS Managed Microsoft AD, this tombstone is replicated across AWS's multi-AZ infrastructure. **Recycle Bin objects:** If the AD Recycle Bin feature is enabled (common in AWS Managed Microsoft AD for operational safety), deleted objects are preserved with all their attributes intact for a configurable period (default 180 days, configurable up to the tombstone lifetime). A deleted account with disability accommodation flags, union group memberships, and 5 years of authentication logs remains fully accessible for 180 days after termination. **Inactive accounts and Art.17 right to erasure:** Former employees who request erasure under Art.17 present a specific challenge. Tombstoned accounts cannot be immediately hard-deleted without risking replication conflicts. AWS Managed Microsoft AD does not provide a "GDPR erasure" mechanism — you must wait for the tombstone lifetime to expire, or manually force garbage collection, which requires domain administrator intervention on the AWS-managed domain controllers. --- ## GDPR Vector 5 — Art.25 Data Minimisation and Default Over-Collection Article 25 requires data minimisation by design: only data necessary for the specific processing purpose should be collected and retained. Active Directory's design philosophy is the opposite of data minimisation. **The extended attribute problem:** AWS Managed Microsoft AD supports the full Windows Server AD schema, including all extensionAttributes and the ability to extend the schema with custom attributes. HR systems, identity management tools, and IT provisioning workflows routinely populate attributes beyond what authentication strictly requires. Payroll grades in `extensionAttribute1`, office building access card IDs in `extensionAttribute4`, catering system preferences in `extensionAttribute7` — none of this is necessary for the core directory function of authenticating users, but it accumulates in the directory over years. **Group proliferation:** Active Directory security groups tend to proliferate. Marketing-Team-2021, Project-Alpha-2022-External-Access, Contractor-Batch-37 — each group and its membership list is personal data. Dissolved projects and departed contractors leave ghost group memberships that technically constitute stale personal data. **Schema extension risks:** AWS Managed Microsoft AD allows schema extensions. Once an attribute is added to the AD schema, it cannot be removed — only disabled. This means bad data minimisation decisions made years ago are permanently baked into the schema, potentially capturing data that has never had a legitimate basis. --- ## GDPR Vector 6 — Art.13/14 Transparency and the Invisible Directory Article 13 and 14 require data subjects to be informed about processing, including transfers to third countries. Employees rarely understand that their HR attributes, authentication behaviour, and group memberships are processed by Amazon Web Services in a US-controlled infrastructure. **The transparency gap:** A company's privacy notice typically describes HR data processing (payroll, contracts, performance management) but rarely specifies that Active Directory — and the identity metadata it holds — is managed by a US cloud provider. Employees consent to HR data processing; they do not consent to their disability accommodations being replicated in Amazon's data centres. **The authentication surveillance blind spot:** Every time an employee logs into a domain-joined workstation, authenticates to an internal application, or resets their password, a log entry is created in AWS CloudWatch. This constitutes processing of behavioural data about the employee. Art.14 requires informing data subjects of processing of data not collected directly from them — but authentication log processing is almost never mentioned in employee privacy notices. **The IT admin access question:** AWS domain engineers have administrative access to the Managed Microsoft AD infrastructure. This access is necessary for operations and patching, but it means Amazon's engineers can potentially read directory contents. This constitutes transfer of personal data to Amazon's staff — a transfer that must be disclosed under Art.13(1)(e) as a recipient of personal data. --- ## EU-Native Alternatives to AWS Directory Service European companies need directory services that authenticate users, manage access control, and integrate with line-of-business applications — without routing identity data through US-controlled infrastructure. Several mature alternatives exist. ### Samba 4 — Open-Source Active Directory Domain Controller [Samba 4](https://www.samba.org/) is the open-source implementation of the Active Directory protocols (Kerberos, LDAP, SMB, DNS). It is compatible with Windows domain-joined clients, supports Group Policy, and can act as a full AD domain controller. Deployed on EU infrastructure (Hetzner, OVHcloud, Ionos), it provides complete GDPR compliance: no US parent company, no CLOUD Act jurisdiction, full administrative control. **Strengths:** Full AD-protocol compatibility including Windows domain join, Group Policy, Kerberos, and LDAP. Self-hosted — you control every log, every attribute, every deletion. Zero licensing cost. **Considerations:** Requires Linux administration expertise. No managed operations layer — you handle patching, replication, backup, and availability. Multi-site replication requires careful SYSVOL and DFS-R configuration. **Best for:** Organisations with existing Linux infrastructure expertise that need full Windows AD compatibility for domain-joined clients. ### FreeIPA / Red Hat Identity Management [FreeIPA](https://www.freeipa.org/) (upstream of Red Hat Identity Management) is an integrated identity management system combining LDAP (389 Directory Server), Kerberos, DNS, certificate management (Dogtag CA), and optional Active Directory trust. It provides a web UI and CLI for user/group management, sudo rules, host-based access control (HBAC), and two-factor authentication. **Strengths:** Comprehensive identity stack in a single deployment. Integrates with Linux systems natively (sssd). Supports AD trust for hybrid environments. HBAC rules provide fine-grained access control. Strong EU deployment community. **Considerations:** Primarily Linux-centric; Windows domain join requires AD trust configuration. Higher operational complexity than a pure AD deployment. **Best for:** Organisations running predominantly Linux infrastructure that need Kerberos SSO, certificate management, and host-based access control. ### Keycloak — Open-Source Identity and Access Management [Keycloak](https://www.keycloak.org/) (Red Hat/CNCF) is an open-source identity provider supporting OpenID Connect, OAuth 2.0, SAML 2.0, and LDAP. It is not a traditional AD replacement but covers the modern identity use case: web application SSO, API authentication, social login federation, and enterprise LDAP/AD integration. **Strengths:** Mature OIDC/OAuth implementation. Extensive protocol support. Self-hosted on any EU infrastructure. Active community and long-term Red Hat backing. Handles both legacy enterprise auth and modern microservice authentication. **Considerations:** Not a drop-in AD replacement for domain-joined Windows clients — better suited to application-level authentication than OS-level domain management. **Best for:** Modern application stacks needing SSO, API authentication, and identity federation without legacy Windows domain requirements. ### Zitadel — EU-Native Cloud Identity [Zitadel](https://zitadel.com/) is a Swiss-founded, open-source identity infrastructure platform supporting OIDC, OAuth 2.0, SAML 2.0, and LDAP. It offers both a managed cloud product (hosted in EU, no US parent) and a self-hosted option. Purpose-built for GDPR compliance with fine-grained audit logging, data residency controls, and EU-native infrastructure. **Strengths:** Modern API-first design. EU company (Switzerland, adequate country under GDPR Art.45). CLOUD Act does not apply to Swiss infrastructure. Self-hosted option available on any EU provider. Built-in organisation/instance multi-tenancy for SaaS scenarios. **Considerations:** Smaller community than Keycloak. Limited legacy Windows domain compatibility. **Best for:** Modern SaaS and cloud-native applications needing a GDPR-native identity provider with EU company backing. ### Authentik — Self-Hosted Identity Provider [Authentik](https://goauthentik.io/) is an open-source identity provider with LDAP, OIDC, OAuth 2.0, SAML 2.0, and proxy authentication support. German-founded, self-hostable on any infrastructure, with an active community. Supports forward auth (for Nginx/Traefik/Caddy), application proxy, and password policy enforcement. **Strengths:** User-friendly web UI. LDAP outpost for legacy LDAP-dependent applications. Forward auth for applications that cannot handle OIDC natively. Active development and responsive community. **Considerations:** Smaller community than Keycloak. Production deployments require PostgreSQL and Redis. Multi-tenant support is less mature than Zitadel. **Best for:** Self-hosted environments needing flexible authentication including legacy LDAP applications and HTTP proxy authentication. --- ## Migration Strategy: From AWS Directory Service to EU-Native Identity **Phase 1 — Audit your directory contents.** Before migrating, inventory what is actually in your AWS Managed Microsoft AD. Use `ldapsearch` or PowerShell `Get-ADUser` with `-Properties *` to identify which extended attributes contain personal data. Map Art.9 data to specific attributes. This audit is your Art.30 record of processing for the identity layer. **Phase 2 — Classify and minimise.** For each attribute populated in your directory, determine whether it is necessary for the processing purpose. Disability accommodation flags needed for IT provisioning? Keep them. Catering preferences accumulated by an old HR system? Delete them. Apply Art.25 data minimisation before migration, not after. **Phase 3 — Choose your target architecture.** For Windows-heavy environments: Samba 4 for domain services + Keycloak for web SSO. For Linux-heavy: FreeIPA end-to-end. For modern applications: Zitadel or Authentik as the primary identity provider with LDAP compatibility for legacy systems. **Phase 4 — Migrate with LDIF export.** Export user accounts from AWS Managed Microsoft AD using `ldifde` or PowerShell. Clean sensitive attributes from the export. Import into your EU-hosted replacement. Handle passwords separately — AD password hashes are NTLM format; a password reset wave is typically cleaner than attempting hash migration. **Phase 5 — Update Art.30 records.** Document the new processor chain: your organisation → EU infrastructure provider (e.g., Hetzner) → no US sub-processor. Update your data transfer impact assessment to reflect that CLOUD Act jurisdiction no longer applies to the identity layer. --- ## The Broader Identity Security Posture Moving directory services to EU-native infrastructure does more than satisfy GDPR requirements. It reduces the blast radius of a compromise: **Domain compromise scope:** If AWS Managed Microsoft AD is compromised, the attacker gains access to AWS's integrated services (WorkSpaces, SSO, RDS Windows Auth, etc.). A self-hosted Samba 4 or FreeIPA directory with explicit network boundaries limits lateral movement. **Kerberoasting and AS-REP roasting:** These Active Directory attack techniques work equally well against AWS Managed Microsoft AD as against on-premises AD — the attack surface is not reduced by running AD in the cloud. Self-hosted AD alternatives with modern Kerberos configurations (AES-only, no RC4) can reduce attack surface. **Audit log control:** With self-hosted directories, authentication logs go to your SIEM, not to Amazon CloudWatch. You control retention, access, and deletion. This matters for Art.17 compliance when a former employee requests erasure of their authentication history. --- ## Practical Decision Matrix | Requirement | AWS Managed Microsoft AD | Samba 4 | FreeIPA | Keycloak | Zitadel | |---|---|---|---|---|---| | Windows domain join | ✅ Full | ✅ Full | ⚠️ Via trust | ❌ | ❌ | | OIDC/OAuth 2.0 | ❌ | ❌ | ⚠️ Limited | ✅ Full | ✅ Full | | LDAP compatibility | ✅ | ✅ | ✅ | ✅ | ✅ | | CLOUD Act exposure | ❌ Yes | ✅ None | ✅ None | ✅ None | ✅ None | | Art.9 data risk | ❌ High | ✅ Low | ✅ Low | ✅ Low | ✅ Low | | EU managed service | ❌ | ❌ DIY | ❌ DIY | ❌ DIY | ✅ Cloud option | | Managed ops | ✅ AWS | ❌ | ❌ | ❌ | ✅ | | Licensing cost | 💰 High | Free | Free | Free | Free/paid | --- ## Why Your Corporate Identity Layer Is Your Highest-Value GDPR Asset The directory service is not a peripheral system — it is the keystone of your identity architecture. Every other system (email, ERP, CRM, HR platforms, development tools, cloud console access) ultimately authenticates against the directory. This means: 1. **The directory is a complete employee dossier.** Name, contact details, organisational structure, access privileges, authentication behaviour, HR attributes — more comprehensive than most dedicated HR systems. 2. **The directory is permanent.** Unlike application databases where records can be cleanly deleted, Active Directory's tombstone mechanism means identity records persist for months after deletion. Art.17 erasure is structurally difficult. 3. **The directory is the CLOUD Act's highest-value target.** A single order yields not just one user's data but the entire corporate identity map — who works where, who has access to what, how the organisation is structured, which employees have special status. Placing this keystone on US-controlled infrastructure through AWS Managed Microsoft AD creates a GDPR exposure that cannot be fully remediated with SCCs, DPAs, or encryption. The only complete mitigation is moving the directory to EU-native infrastructure where CLOUD Act jurisdiction does not apply. [sota.io](/) provides EU-native platform infrastructure for deploying identity services — Keycloak, Authentik, Zitadel — without routing your authentication traffic through US-controlled platform layers. Deployed on sota.io, your identity provider runs in EU jurisdiction, with no US parent company in the processor chain.

EU-Native Hosting

Ready to move to EU-sovereign infrastructure?

sota.io is a German-hosted PaaS — no CLOUD Act exposure, no US jurisdiction, full GDPR compliance by design. Deploy your first app in minutes.

Start free — no credit cardView pricing