Microsoft Entra Domain Services (formerly Azure AD Domain Services) gives you a Microsoft-run Active Directory domain in Azure, and in doing so it stores the NTLM and Kerberos password hashes that Entra ID otherwise never keeps. That one design fact drives most of the security decisions: who can reach the managed domain, which legacy protocols stay switched on, and whether secure LDAP is ever exposed to the internet. Teams adopt it to lift and shift legacy applications, then leave the defaults in place for years. This guide is for Azure and identity administrators who run or are about to deploy a managed domain. It covers the identity model, the AAD DC Administrators group, service accounts, secure LDAP, NSG rules, audit logging, the security settings blade and when not to use the service at all. For general AD and Entra ID hardening, see the Active Directory and Entra ID Hardening Guide.
This is an independent guide from NHI Mgmt Group, based on Microsoft's public documentation as of November 2026. It is not sponsored or reviewed by Microsoft. Product features change, so confirm settings against Microsoft's current documentation.
Key takeaways
- Enabling the service creates new credential material. Once Domain Services is enabled, Entra ID generates and stores legacy NTLM and Kerberos hashes for every user in scope, so the managed domain becomes a credential store that attackers can target with password spraying and Kerberoasting.
- The defaults are permissive. Microsoft documents that NTLM v1 and TLS 1.0 are enabled by default; disable them, and disable Kerberos RC4 and NTLM password synchronisation where workloads allow.
- AAD DC Administrators is your tier zero for this domain. Members get directory administration, DNS Administrator rights and remote desktop to every domain-joined machine, even though nobody gets Domain Admins or Enterprise Admins.
- Secure LDAP over the internet is the biggest exposure. It opens TCP 636 to password brute force; if you must enable it, lock the NSG rule to known source addresses and protect the PFX private key.
- Auditing is off until you turn it on. Security audits stream to Log Analytics, Event Hubs or Storage only from the moment you enable them, so configure them at build time.
How identity and access work in Entra Domain Services
A managed domain is a single-domain, single-forest Active Directory instance with two domain controllers run by Microsoft in a dedicated subnet of your virtual network. You cannot sign in to the domain controllers, add more of them, create child domains or extend the schema. You administer it from a management VM joined to the domain, using the normal RSAT tools.
- One-way synchronisation: users and groups flow from Entra ID into the managed domain. Objects created in the managed domain do not flow back, and synchronised users and groups cannot be modified there, including moving them out of the AADDC Users OU.
- Password hashes: NTLM and Kerberos need hash formats that Entra ID does not create until Domain Services is enabled for the tenant. Cloud-only users must change their password before their account appears in the managed domain, which means self-service password reset or forced expiry must be in place first. Synchronised users need password hash synchronisation in Microsoft Entra Connect sync; Microsoft Entra Cloud Sync is not supported for this service.
- Trusts: forest trusts to another domain are supported (two-way, one-way outgoing, one-way incoming). External domain trusts are not.
Password and lockout policy
| Setting | Default value | Applies to | Security note |
|---|---|---|---|
| Account lockout threshold | 5 failed attempts within 2 minutes | All users | Lockout is local to the managed domain and does not lock the Entra ID account |
| Lockout duration | 30 minutes, then automatic unlock | All users | Slow spraying stays below the threshold; monitor 4625 and 4776 failure patterns, not only 4740 |
| Maximum password age | 90 days (or the Entra value if longer) | All users | Not synchronised with Entra ID, so passwords can expire in the managed domain first |
| Minimum length and complexity | 7 characters, complexity on | Accounts created directly in the managed domain only | Apply a custom fine-grained policy for service accounts |
| Default fine-grained policy precedence | 200, cannot be modified | All users | Create custom policies with precedence below 200 in the Password Settings Container |
When to avoid it
Domain Services makes sense when an application genuinely needs domain join, Group Policy, Kerberos, NTLM or LDAP bind in Azure and you do not want to run domain controllers. Avoid it, or limit it with scoped synchronisation, in these cases:
- Modern applications: anything that can use OpenID Connect, SAML or managed identities should use Entra ID directly. Every user synchronised into the managed domain gains a legacy hash and a new attack surface.
- Need for full AD control: no Domain Admins, no schema extensions, no DHCP authorisation and no DC access. If an application requires these, run your own domain controllers in Azure as a tier zero workload instead.
- Federated tenants without password hash sync, or organisations whose policy forbids storing password hashes in the cloud.
- Recovery expectations: Microsoft states backups every 5 days on Standard, every 3 days on Enterprise and daily on Premium, with an RPO of up to five days for data loss incidents. Objects created only in the managed domain, such as service accounts and custom OUs, need their own documented rebuild procedure.
Scoped synchronisation (Filter by group entitlement) limits the managed domain to members of named groups. Nested groups are not synchronised, changing the scope triggers a full resynchronisation and deletes objects that fall out of scope, and the scope is held by a service principal (application ID 2565bd9d-da50-47d4-8b85-4c97f669dc36) that must not be deleted. Use it so that only the people and accounts the legacy applications need ever get legacy hashes.
Admin roles and privileged access
Two separate permission planes control a managed domain: Azure and Entra roles that control the resource, and the in-domain group that controls the directory.
| Role or group | Where it lives | What it can do | Hardening |
|---|---|---|---|
| Domain Services Contributor | Azure RBAC | Create and configure the managed domain resource, including security settings, secure LDAP and audit settings | Assign through PIM, scope to the resource group, review quarterly |
| Application Administrator and Groups Administrator | Entra ID roles | Required to deploy and to change the synchronisation scope | Eligible only, never permanent; these roles also affect the rest of the tenant |
| AAD DC Administrators (Microsoft Entra DC Administrators) | Entra ID group synchronised into the domain | Administer users, groups, OUs, Group Policy and fine-grained password policies; DNS Administrator; remote desktop to all domain-joined machines | Small, named membership; dedicated admin accounts; phishing-resistant MFA on the Entra side; privileged access workstation as the management VM |
| Network Contributor on the virtual network | Azure RBAC | Edit the NSG and route tables protecting the domain subnet | Restrict; changes here can expose LDAPS or break service management |
- Treat the group as tier zero: because membership is managed in Entra ID, anyone who can add members to the AAD DC Administrators group, including Groups Administrator and owners of the group, effectively controls every domain-joined server. Make it a role-assignable or PIM-for-Groups managed group where your licensing allows, and alert on membership changes in the Entra audit log. See the Tiered Administration and Enterprise Access Model Guide.
- Separate admin accounts: members should be dedicated cloud admin accounts, not daily user accounts, because the same password hash that unlocks Outlook now also works for NTLM against the managed domain.
- Management VM: build it as a privileged access workstation with no email or browsing, reach it through Azure Bastion or just-in-time access rather than a public RDP endpoint. See the Privileged Access Workstations Guide.
Integrations, API tokens and service accounts
Most of the non-human identities in a managed domain are the reason it exists: application service accounts that bind to LDAP, run Kerberos services or join machines.
- Create service accounts in the managed domain: accounts that only legacy applications use can be created directly in a custom OU, so they never exist in Entra ID and never get cloud sign-in. Apply a custom fine-grained password policy with a long minimum length (long random passwords generated and stored by a vault) and no expiry only where rotation is automated.
- Kerberoasting exposure: any account with a service principal name can have a service ticket requested by any authenticated user and cracked offline (T1558.003). Long random passwords and AES-only encryption types reduce the risk. See the Kerberoasting and AS-REP Roasting Defence Guide.
- LDAP bind accounts: applications that use LDAP simple bind send the password to the domain controller; use LDAPS (636) or signed LDAP, never cleartext 389 across networks. Simple binds depend on NTLM password synchronisation, which is the main reason organisations cannot switch it off. See the LDAP Security Deep Dive Guide.
- Domain join accounts: automated join (for example from image pipelines) should use a dedicated account delegated only to create computer objects in one OU, with its secret held in a vault, not a member of AAD DC Administrators.
- Synchronised users used as service accounts: if a service account is synchronised from Entra ID, its password changes must be made in Entra ID or on premises, and it inherits whatever Conditional Access does not cover: NTLM and Kerberos to the managed domain bypass Entra sign-in policies entirely.
- Azure automation identities: scripts that change security settings call
Set-AzResourceagainst theMicrosoft.AAD/DomainServicesresource. Run them with a managed identity scoped to that resource, not a stored service principal secret. See the Service Account Security Guide.
Secure LDAP and network exposure
Secure LDAP is disabled by default, and internet access to it stays disabled even after you enable LDAPS. Microsoft warns that allowing secure LDAP over the internet makes the domain susceptible to password brute force attacks.
| Exposure | Port | Default | Recommended setting |
|---|---|---|---|
| LDAPS inside the virtual network | TCP 636 | Off until secure LDAP is enabled | Enable when applications need encrypted LDAP; preferred over 389 |
| LDAPS over the internet | TCP 636 | Off | Keep off; if required, NSG rule (for example AllowLDAPS, priority 401) restricted to specific source CIDRs |
| Domain management by Microsoft | TCP 5986 (WinRM) from AzureActiveDirectoryDomainServices tag | Allowed by created NSG | Required; do not edit or delete |
| Microsoft support RDP | TCP 3389 from CorpNetSaw tag | Optional | Microsoft documents it can be set to Deny and opened only when needed |
| Outbound management traffic | TCP 443 to service tags | AllowInternetOutbound | Optionally restrict to AzureActiveDirectoryDomainServices, AzureMonitor, Storage, AzureActiveDirectory, GuestAndHybridManagement (plus EventHub for Log Analytics) |
- Certificate: a wildcard certificate for the managed domain name, key usage digital signature and key encipherment, purpose server authentication, uploaded as a PFX. The default onmicrosoft.com name cannot receive a public certificate, which is one reason to choose a routable domain you own at creation (the name cannot be changed later, and Microsoft advises against .local).
- Private key handling: the PFX contains the private key that decrypts LDAPS traffic. Generate it in a controlled process, store it in a vault, delete working copies and give clients only the public CER.
- Do not rebuild the NSG: the deployment creates its own NSG. Editing required rules, adding user-defined routes that break the 0.0.0.0/0 path or locking the network resources can stop Microsoft servicing the domain, and the Azure SLA no longer applies.
Logging and detection
Enable security audits under Diagnostic settings on the managed domain. Destinations can be Azure Storage (archive), Event Hubs (SIEM) and Log Analytics (query), with different categories per destination. Audits are not retroactive.
| Audit category | Key event IDs | What to detect |
|---|---|---|
| Account Logon | 4776, 4777 | NTLM credential validation; failures in volume indicate spraying (T1110.003) |
| Kerberos Tickets | 4768, 4769 | RC4 tickets (encryption type 0x17), many service tickets requested by one account (Kerberoasting) |
| Logon-Logoff | 4624, 4625, 4648, 4672 | Failed logons by source, special privileges assigned to unexpected accounts, logons with explicit credentials |
| Account Management | 4720, 4728, 4732, 4738, 4740, 4756 | New accounts, additions to privileged groups, account changes, lockouts |
| Directory Services Access | 5136, 5137, 5141 | Changes to OUs, Group Policy objects and delegation |
| Policy Change | 4719, 4739, 4706, 4713 | Audit policy changes, domain policy changes, new trusts, Kerberos policy changes |
In Log Analytics the events land in tables such as AADDomainServicesAccountLogon and AADDomainServicesAccountManagement. Microsoft publishes sample queries for lockouts, bad passwords and RC4 tickets. Correlate with the Entra audit log for AAD DC Administrators membership changes and with the Azure activity log for changes to the Microsoft.AAD/DomainServices resource, its NSG and secure LDAP. See the Active Directory Security Monitoring and Event IDs Guide for rule design.
Metrics that show it is working
- Legacy protocol usage: count of NTLM authentications and RC4 Kerberos tickets per week, trending to zero.
- Synchronised population: number of users in scope of the managed domain against the number the legacy applications actually need.
- Privileged membership: AAD DC Administrators members, and the percentage that are dedicated admin accounts with PIM.
- Exposure: whether internet LDAPS is enabled, and the number of source CIDRs allowed on 636.
- Certificate health: days until the LDAPS certificate expires.
Hardening baseline
The Security settings blade (or the DomainSecuritySettings properties via Set-AzResource) holds the protocol controls. Change them in a planned order.
| Setting | Property | Target | Dependency to check first |
|---|---|---|---|
| TLS 1.2 Only Mode | TlsV1 | TLS 1.0 disabled | Old LDAPS clients; enforce with the built-in Azure Policy in Audit, then Deny |
| NTLM v1 Authentication | NtlmV1 | Disabled | Very old clients and appliances |
| Kerberos RC4 Encryption | KerberosRc4Encryption | Disabled | 4768 and 4769 events with type 0x17 |
| Kerberos Armoring | KerberosArmoring | Enabled | Client support for FAST |
| LDAP Signing and LDAP Channel Binding | Portal settings | Enabled | Applications binding unsigned over 389 |
| NTLM Password Synchronisation | SyncNtlmPasswords | Disabled where possible | LDAP simple binds, NTLM-only apps, connections by IP address |
Microsoft's page records the Windows Kerberos RC4 hardening timeline: audit signals from 13 January 2026, AES-first enforcement in April 2026 with manual rollback, and final enforcement in July 2026 with rollback removed (as documented when checked on 8 November 2026). Workloads still on RC4 are therefore already breaking or about to.
Rollout order
- Enable audits first to Log Analytics and your SIEM, including Account Logon and Kerberos Tickets, and collect at least two weeks of baseline.
- Inventory legacy usage: run the RC4 query, find NTLM authentications (4776, and 4624 with NTLM as the authentication package) and list LDAP simple bind clients.
- Disable TLS 1.0 and NTLM v1 in a maintenance window; test application sign-in and LDAPS from each client subnet.
- Disable RC4 and enable Kerberos armoring; for a workload that still needs RC4 temporarily, set
msDS-SupportedEncryptionTypeson that one service account as Microsoft describes, with an end date. - Enable LDAP signing and channel binding once unsigned binds are gone.
- Disable NTLM password synchronisation if no application needs simple bind or NTLM, then run a full password hash sync in Entra Connect so existing NTLM hashes are removed rather than lingering until each user's next password change.
- Roll back by re-enabling the single setting that broke an application; keep a record of each change and the exception owner.
Common misconfigurations
- Internet LDAPS with an open NSG rule: enabling secure LDAP access over the internet with source Any invites brute force against every synchronised account, and lockout only protects the managed domain copy.
- Syncing the whole tenant: all users, including executives and admins, receive legacy hashes when only a few hundred application users need them. Use scoped synchronisation.
- Daily accounts in AAD DC Administrators: a phished user password becomes RDP and directory admin across every domain-joined server, bypassing Conditional Access because NTLM and Kerberos never touch Entra sign-in.
- Defaults left on: NTLM v1, TLS 1.0 and RC4 enabled years after deployment, often with no audit data to show whether anything uses them.
- Short service account passwords: accounts created in the managed domain fall under the 7-character default policy unless a custom fine-grained policy applies, which makes Kerberoastable accounts crackable.
- Tampering with service resources: custom NSGs, resource locks, route tables or deleted enterprise applications that break Microsoft's management path and leave the domain unpatched and outside the SLA.
Framework mapping
| Control area | NIST SP 800-53 Rev. 5 | NIST CSF 2.0 | ISO/IEC 27001:2022 Annex A | ATT&CK technique addressed |
|---|---|---|---|---|
| Scoped sync, account lifecycle | AC-2 | PR.AA-01 | 5.15 Access control | T1078.002 Domain Accounts |
| AAD DC Administrators, delegation | AC-6 | PR.AA-05 | 8.2 Privileged access rights | T1078.002 |
| Password policy, service account secrets | IA-5 | PR.AA-01 | 8.5 Secure authentication | T1110.003, T1558.003 |
| TLS 1.2, LDAPS, signing, channel binding | SC-8 | PR.DS-02 | 8.21 Security of network services | T1557 Adversary-in-the-Middle |
| NSG, internet LDAPS | SC-7 | DE.CM-01 | 8.20 Networks security | T1110.003 |
| Disabling NTLM v1 and RC4 | CM-7 | PR.PS-01 | 8.9 Configuration management | T1558.003 |
| Security audits | AU-2, AU-6 | DE.CM-01 | 8.15 Logging | All of the above |
Practitioner checklist
- Confirm a managed domain is the right answer for each consuming application; prefer modern protocols on Entra ID.
- Enable scoped synchronisation so only the groups the legacy applications need receive legacy hashes.
- Keep AAD DC Administrators small, made of dedicated admin accounts, managed through PIM, with alerts on membership change.
- Enable security audits to Log Analytics and the SIEM on day one, with retention that meets your policy.
- Disable TLS 1.0, NTLM v1 and Kerberos RC4; enable Kerberos armoring, LDAP signing and channel binding after testing.
- Disable NTLM password synchronisation where no simple bind or NTLM dependency remains, then run a full hash sync.
- Keep internet LDAPS off; if unavoidable, restrict TCP 636 to named source CIDRs and protect the PFX in a vault.
- Apply a custom fine-grained password policy to service accounts created in the managed domain and give SPN accounts long random passwords.
- Leave the generated NSG, load balancer and enterprise applications untouched; restrict Network Contributor on the virtual network.
Standards and references
- Microsoft Learn: Disable weak ciphers and password hash synchronization to secure a Microsoft Entra Domain Services managed domain
- Microsoft Learn: Configure secure LDAP for a Microsoft Entra Domain Services managed domain
- Microsoft Learn: Virtual network design considerations and configuration options for Domain Services
- Microsoft Learn: Enable security and DNS audits for Microsoft Entra Domain Services
- Microsoft Learn: Management concepts for user accounts, passwords and administration in Domain Services
- Microsoft Learn: Configure scoped synchronization for Domain Services
- NIST: SP 800-53 Rev. 5
- MITRE ATT&CK: Kerberoasting
Related NHI Mgmt Group resources: Active Directory and Entra ID Hardening Guide · Microsoft Entra Connect and Cloud Sync Hardening Guide · NTLM Deprecation and Elimination Guide · LDAP Security Deep Dive Guide