This chapter covers Azure AD Domain Services (AADDS), a managed domain service that provides domain join, Group Policy, LDAP, and Kerberos/NTLM authentication for Azure workloads without the need to deploy and manage domain controllers. For the AZ-104 exam, AADDS appears in approximately 5-10% of questions, often alongside scenarios requiring lift-and-shift of on-premises applications that cannot use modern authentication. You must understand when to use AADDS versus Azure AD or Active Directory Domain Services (AD DS), how to configure and deploy it, and the critical health and synchronization requirements.
Jump to a section
Imagine a company that needs a physical mailroom to receive and sort all incoming packages, but doesn't want to buy, staff, or maintain the mailroom itself. Instead, they rent a fully managed mailroom from a service provider. The provider supplies the building, the sorting equipment, the staff, and the security. The company simply tells the provider: 'Here are our mail rules—sort packages by department, forward urgent ones to the CEO, and log every package that arrives.' The provider handles all the backups, repairs, and upgrades. In Azure AD Domain Services, Azure provides the domain controllers (the mailroom) for your Azure AD tenant (the company). You don't have to patch, monitor, or back up those domain controllers—Microsoft does that. You just configure the managed domain with your users, groups, and policies (the sorting rules). Your Azure VMs (the packages) can then join the domain, use Kerberos or NTLM authentication (the sorting process), and apply Group Policy (the forwarding rules) without ever needing to see or manage a domain controller. If the provider's mailroom breaks, they fix it; you don't even know it happened. That's the core value of AADDS: legacy authentication and management without the infrastructure overhead.
What is Azure AD Domain Services?
Azure AD Domain Services (AADDS) is a Microsoft-managed service that provides domain services such as domain join, Group Policy, LDAP, and Kerberos/NTLM authentication to Azure virtual machines and applications. It is designed for workloads that require legacy authentication protocols or Active Directory–compatible management but cannot or should not be migrated to fully managed Azure AD. AADDS synchronizes identities from Azure AD (which itself can sync from on-premises AD DS via Azure AD Connect) and exposes them as a traditional AD domain. You get two domain controllers deployed across two availability zones in a virtual network, fully patched and monitored by Microsoft—you have no access to them, no RDP, no administrative privileges.
Why does AADDS exist?
Many enterprise applications—especially those built before 2010—require LDAP binds, Kerberos tickets, NTLM authentication, or Group Policy. Azure AD alone does not support these protocols. You could deploy your own domain controllers in Azure VMs (IaaS AD DS), but that requires patching, backup, disaster recovery, and monitoring. AADDS eliminates that operational burden. It is ideal for lift-and-shift scenarios where you move on-premises VMs to Azure and need them to authenticate with the same credentials, or for scenarios where you need to lift and shift applications that rely on LDAP.
How AADDS works internally
AADDS is deployed into an Azure virtual network (VNet) of your choice. When you enable AADDS, Microsoft provisions two domain controllers in a Microsoft-managed resource group (visible as a locked resource group with a name like "{"vnet-guid"}-aadds"). These domain controllers run Windows Server Datacenter edition, are fully patched, and are monitored via Azure health alerts. The service creates a DNS zone matching your domain name (e.g., contoso.com) and registers itself as the authoritative DNS for that zone. The domain controllers are joined to a separate, isolated AD forest that is synchronized with your Azure AD tenant. The synchronization is one-way: Azure AD → AADDS. Changes made directly in AADDS are not written back to Azure AD. The default sync frequency is every 5 minutes for user and group changes, but password changes sync immediately (within seconds).
Key components, values, defaults, and timers
Domain name: You choose a custom DNS name (e.g., aadds.contoso.com) or use the default .onmicrosoft.com domain. The custom domain must be verified in Azure AD.
SKU: Standard (up to 25,000 objects), Enterprise (up to 100,000 objects), and Premium (unlimited objects). Each SKU includes a different number of domain controllers and performance characteristics.
Password hash synchronization: Required. For cloud-only users, you must enable password hash sync in Azure AD. For synced users from on-premises, you must enable password hash sync in Azure AD Connect. Without this, authentication fails.
Password expiry: Password expiration policies from on-premises are not applied to AADDS. Passwords synced from on-premises have no expiration in AADDS. Cloud-only users' passwords expire per Azure AD policy.
Group Policy: AADDS provides two default GPOs: AADDC Users and AADDC Computers. You can create custom GPOs using the Group Policy Management Console on a domain-joined management VM.
LDAP: Simple LDAP (port 389) is enabled by default. Secure LDAP (port 636) can be enabled but requires a certificate and a public IP if accessed from outside Azure.
Kerberos and NTLM: Supported for authentication. Kerberos delegation is limited; constrained delegation is not supported.
Service health: Monitored via Azure Monitor. You can set up alerts for domain controller health, synchronization errors, and certificate expiry.
Configuration and verification commands
When deploying AADDS, you use the Azure portal or Azure PowerShell. Key PowerShell commands:
# Install the Azure AD Domain Services module (if needed)
Install-Module -Name AzureAD
# Get the AADDS instance details
Get-AzResource -ResourceType "Microsoft.AAD/DomainServices" | Select-Object Name, ResourceGroupName, Location, Properties
# Check sync status (run from a domain-joined VM)
repadmin /replsum
# Or use the AADDS health tool (from Azure portal: AADDS > Health)To verify domain join:
# On a domain-joined VM, run:
$env:USERDNSDOMAIN
# Should return your domain name
nltest /dsgetdc:<domainname>How AADDS interacts with related technologies
Azure AD Connect: Synchronizes on-premises AD DS users and groups to Azure AD. AADDS then syncs from Azure AD. AADDS does not sync directly from on-premises.
Azure AD: The identity source for AADDS. All users and groups must exist in Azure AD first.
Azure VNet: AADDS must be deployed into a dedicated subnet (or a subnet with no other resources). The subnet must be delegated to Microsoft.AAD/DomainServices.
Azure VPN Gateway/ExpressRoute: Used to connect on-premises networks to the AADDS VNet, enabling on-premises users to authenticate against AADDS or allowing domain-joined VMs in a hybrid network.
Azure Bastion: Recommended for managing domain-joined VMs without exposing RDP endpoints.
Azure Policy: Can enforce AADDS deployment requirements (e.g., SKU, domain name) across subscriptions.
Important limitations
AADDS does not support AD trusts (you cannot create a trust between AADDS and an on-premises AD forest).
AADDS does not support schema extensions.
You cannot install applications that require domain admin privileges on the managed domain controllers.
The domain name must be unique within Azure AD; you cannot reuse a domain name that is already federated.
Password writeback is not supported for AADDS (AADDS → Azure AD).
The OU structure is limited: only two default OUs (AADDC Computers and AADDC Users) and a container for the synchronization object. You cannot create custom OUs at the root; you can create sub-OUs under AADDC Users.
Step-by-step deployment overview
Enable password hash sync in Azure AD (for cloud-only users) or in Azure AD Connect (for synced users).
Create a dedicated subnet in your VNet and delegate it to Microsoft.AAD/DomainServices.
In the Azure portal, navigate to Azure AD Domain Services and click "Create".
Select your subscription, resource group, and region.
Choose a DNS domain name (custom or default).
Select the SKU (Standard, Enterprise, or Premium).
Configure the virtual network and subnet.
Review and create. Deployment takes 1-2 hours.
After deployment, update DNS settings on the VNet to use the AADDS domain controllers as DNS servers (the portal provides the IP addresses).
Join VMs to the domain and apply Group Policy.
Enable Password Hash Sync
Before deploying AADDS, you must ensure that password hashes are available in Azure AD. For cloud-only users, you must enable password hash synchronization in Azure AD (this is enabled by default for new tenants, but if you disabled it, re-enable it). For users synced from on-premises via Azure AD Connect, you must enable password hash sync as a feature in Azure AD Connect. Without this step, the managed domain controller will have no password hashes to validate against, and all authentication attempts will fail. The sync of password hashes occurs every 2 minutes for changes, but the initial sync may take longer. Verify by checking the Azure AD Connect configuration or using the PowerShell command: Get-ADSyncAADPasswordHashSyncStatus.
Create and Delegate Subnet
AADDS requires a dedicated subnet within your Azure virtual network. This subnet cannot contain any other resources (no VMs, no gateways, no load balancers). The subnet size must be at least /28 (14 usable IPs) to accommodate the two domain controllers and future scaling. In the Azure portal, navigate to your VNet, create a subnet (e.g., 'snet-aadds'), and then delegate the subnet to 'Microsoft.AAD/DomainServices'. Delegation tells Azure that this subnet is reserved for the AADDS service. If you try to deploy AADDS without delegation, the deployment will fail.
Deploy AADDS Instance
In the Azure portal, search for 'Azure AD Domain Services' and click 'Create'. Fill in the required fields: subscription, resource group, region, DNS domain name (e.g., 'aadds.contoso.com' – must be verified in Azure AD if using a custom domain), SKU (Standard for up to 25,000 objects, Enterprise for up to 100,000, Premium for unlimited). Select the virtual network and the delegated subnet. You can also configure secure LDAP (optional) and notification settings. Click 'Review + Create' then 'Create'. The deployment takes 1-2 hours. During this time, Microsoft provisions two domain controllers in a locked resource group, configures DNS, and starts synchronizing from Azure AD.
Update DNS on VNet
After the AADDS instance is deployed, you must update the DNS server settings for the virtual network. In the Azure portal, go to the AADDS instance and note the two IP addresses provided in the 'Properties' blade (e.g., 10.0.1.4 and 10.0.1.5). Then navigate to the virtual network, select 'DNS servers', and change from 'Default (Azure-provided)' to 'Custom'. Enter the two AADDS IP addresses as the primary and secondary DNS servers. This ensures that VMs in the VNet can resolve the AADDS domain name and locate domain controllers. If you skip this step, VMs will not be able to join the domain.
Join VMs and Apply GPO
With DNS correctly configured, you can now join Azure VMs to the AADDS domain. Use the same domain name you configured (e.g., aadds.contoso.com). On a Windows VM, go to System Properties > Change settings > Change... > Domain, enter the domain name, and provide credentials of a user in the AADDC Administrators group (e.g., 'admin@aadds.contoso.com'). After a reboot, the VM is domain-joined. Group Policy from the two default GPOs (AADDC Users and AADDC Computers) will apply. To create custom GPOs, install the Group Policy Management Console on a domain-joined management VM (add the Group Policy Management feature via Server Manager) and link GPOs to the AADDC Users or AADDC Computers OUs. Note that you cannot create new OUs at the root; only sub-OUs under AADDC Users are allowed.
Scenario 1: Lift-and-Shift of Legacy Line-of-Business Application
A financial services company has a legacy .NET application that uses Windows-integrated authentication (Kerberos) and LDAP to query employee details. The application runs on Windows Server 2012 R2 VMs on-premises. The company wants to migrate to Azure without rewriting the application. The solution is to deploy AADDS in the target Azure region, sync identities from on-premises AD via Azure AD Connect (including password hashes), and join the migrated VMs to the AADDS domain. The application continues to use Kerberos authentication and LDAP queries against AADDS. The company benefits from no domain controller management, automatic patching, and built-in high availability. Performance considerations: AADDS Standard SKU supports up to 25,000 objects and 10,000 authentication requests per second, which is sufficient for this 5,000-employee company. If authentication latency becomes an issue, they can upgrade to Enterprise SKU, which provides faster authentication performance.
Scenario 2: Development/Test Environment for AD-Integrated Apps
A software vendor develops an application that requires Active Directory for authentication. They need a test environment that mirrors production but without the cost of running full domain controllers. They deploy AADDS with a custom domain (testapp.contoso.com) and use cloud-only test users. The AADDS instance is deployed in a separate VNet with a VPN connection to the on-premises network for occasional integration testing. The vendor can quickly tear down and recreate the AADDS instance (by deleting and re-creating the resource) for different test cycles. Common misconfiguration: forgetting to enable password hash sync for cloud-only users, which causes authentication failures. The fix is to enable password hash sync in Azure AD (settings > Password reset > Password hash sync).
Scenario 3: Remote Access with RDS and AADDS
A healthcare organization uses Remote Desktop Services (RDS) to provide remote access to clinical applications. The RDS deployment uses Active Directory for user authentication and Group Policy for session configuration. They want to move RDS to Azure IaaS VMs. They deploy AADDS in the same VNet as the RDS servers, join the RDS servers to the domain, and configure Group Policy via the AADDC Computers GPO. Users authenticate using their Azure AD credentials (synced from on-premises AD). The AADDS domain controllers act as the authentication source for RDS. A common issue: the RDS license server must be domain-joined, and if DNS is not correctly configured, the license server cannot locate domain controllers. The fix is to ensure the VNet DNS points to the AADDS IPs and that the license server is rebooted after DNS change.
Exam Objective Coverage
AZ-104 Objective 1.1: Manage Azure Active Directory (including Azure AD Domain Services). The exam specifically tests: (1) When to use AADDS vs. Azure AD vs. IaaS AD DS, (2) Prerequisites for AADDS (password hash sync, VNet delegation), (3) Synchronization behavior (one-way, no writeback), (4) SKU limits, (5) Secure LDAP configuration, (6) Group Policy management limitations.
Common Wrong Answers and Why
'AADDS can sync directly from on-premises AD DS.' Wrong because AADDS only syncs from Azure AD. You must use Azure AD Connect to get on-premises identities into Azure AD first.
'AADDS supports AD trusts.' Wrong. AADDS does not support trusts to any other domain. If the exam asks about integrating AADDS with an on-premises domain, the correct answer is to use a VPN/ExpressRoute and join VMs to AADDS, not to create a trust.
'You can manage AADDS domain controllers via RDP.' Wrong. You cannot log into the managed domain controllers; they are fully managed by Microsoft.
'AADDS supports password writeback.' Wrong. Password changes in AADDS are not written back to Azure AD or on-premises AD.
Specific Numbers and Terms to Memorize
Password sync frequency: every 5 minutes for users/groups; password changes sync immediately.
Subnet size: minimum /28.
Default GPOs: AADDC Users, AADDC Computers.
SKU object limits: Standard 25,000; Enterprise 100,000; Premium unlimited.
Deployment time: 1-2 hours.
Domain join: uses same credentials as Azure AD (user@domain).
Secure LDAP: requires a certificate from a CA trusted by clients; must use port 636.
Edge Cases and Exceptions
If you change the AADDS domain name after deployment, you must redeploy.
If you delete the AADDS instance, all domain-joined VMs lose access and must be rejoined to a new domain.
AADDS cannot be deployed in a region that does not support availability zones (the service uses two zones for redundancy).
If you enable secure LDAP over the internet, you expose your domain to brute-force attacks; always use NSG restrictions and consider Azure AD Application Proxy for LDAP.
How to Eliminate Wrong Answers
If an answer mentions 'trust' or 'forest trust', eliminate it.
If an answer says 'direct sync from on-premises', eliminate it.
If an answer says 'modify the domain controllers' or 'install software on domain controllers', eliminate it.
If an answer says 'password writeback', eliminate it.
The correct answer will always involve: password hash sync enabled, dedicated subnet with delegation, DNS update, and domain join.
AADDS is a managed domain service that provides Kerberos, NTLM, LDAP, and Group Policy without managing domain controllers.
Prerequisites: password hash sync must be enabled in Azure AD (cloud-only) or Azure AD Connect (synced users).
AADDS syncs one-way from Azure AD only; no direct sync from on-premises AD.
Deployment requires a dedicated subnet (minimum /28) delegated to Microsoft.AAD/DomainServices.
After deployment, update VNet DNS servers to the AADDS IP addresses provided in the portal.
AADDS does not support trusts, schema extensions, or password writeback.
Standard SKU supports up to 25,000 objects; Enterprise up to 100,000; Premium unlimited.
Default GPOs: AADDC Users and AADDC Computers. Custom GPOs can be created but only linked to sub-OUs under AADDC Users.
Secure LDAP requires a certificate and can be exposed over the internet, but must be protected with NSG rules.
Deployment takes 1-2 hours; you cannot RDP into the domain controllers.
These come up on the exam all the time. Here's how to tell them apart.
Azure AD Domain Services (AADDS)
Fully managed by Microsoft; no patching, monitoring, or backup required.
No administrative access to domain controllers; cannot install software or modify OS.
Supports up to 25,000 (Standard), 100,000 (Enterprise), or unlimited (Premium) objects.
Synchronizes only from Azure AD; no direct on-premises sync.
No trust support; cannot extend schema.
IaaS AD DS (Domain Controllers in VMs)
You manage everything: patching, monitoring, backups, disaster recovery.
Full administrative control (Domain Admin, Enterprise Admin) over the domain.
Scalable by adding more VMs; no hard object limit (other than VM size).
Can sync directly from on-premises AD or be a standalone forest with trusts.
Full support for trusts, schema extensions, and custom applications.
Azure AD Domain Services (AADDS)
Provides legacy authentication: Kerberos, NTLM, LDAP.
Supports domain join and Group Policy.
Requires a VNet and dedicated subnet.
Synchronizes from Azure AD; one-way sync.
Ideal for lift-and-shift of legacy apps.
Azure AD
Provides modern authentication: OAuth, SAML, OpenID Connect.
No domain join or Group Policy; uses MDM (Intune) for device management.
Cloud-only; no VNet requirement.
Supports password hash sync, pass-through auth, federation.
Ideal for SaaS apps, Office 365, and modern app development.
Mistake
AADDS is the same as Azure AD.
Correct
Azure AD is a cloud-based identity provider using modern protocols (OAuth, SAML, OpenID Connect). AADDS is a managed domain service providing legacy protocols (Kerberos, NTLM, LDAP) and domain join. They serve different purposes and can be used together.
Mistake
AADDS can sync directly from on-premises Active Directory.
Correct
AADDS only synchronizes from Azure AD. To get on-premises users into AADDS, you must first sync them to Azure AD using Azure AD Connect, then AADDS syncs from Azure AD.
Mistake
You can create trusts between AADDS and other domains.
Correct
AADDS does not support any type of trust (one-way, two-way, forest, external). If you need trust, you must deploy IaaS domain controllers.
Mistake
You can RDP into AADDS domain controllers.
Correct
The domain controllers are fully managed by Microsoft. You have no administrative access to them. All management is done via Azure portal, PowerShell, or Group Policy on domain-joined VMs.
Mistake
AADDS supports password writeback to Azure AD or on-premises.
Correct
Password changes made in AADDS are not written back to Azure AD or on-premises AD. Password writeback is a separate Azure AD feature that works with Azure AD Connect, not AADDS.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
No. Password hash sync is mandatory. Without it, the managed domain controllers have no password hashes to validate authentication requests. For cloud-only users, enable password hash sync in Azure AD (Settings > Password Reset > Password Hash Sync). For synced users, enable it in Azure AD Connect. If you skip this step, domain join and login will fail.
Ensure the VM is in the same VNet (or a peered VNet) and that DNS points to the AADDS IPs. On the VM, go to System Properties > Change settings > Change... > Domain, enter the AADDS domain name (e.g., aadds.contoso.com), and provide credentials of a user in the AADDC Administrators group (e.g., admin@aadds.contoso.com). Reboot the VM. You can also use PowerShell: Add-Computer -DomainName aadds.contoso.com -Credential (Get-Credential) -Restart.
AADDS is a managed domain: Microsoft handles the domain controllers, patching, and availability. You have no admin access to the DCs. Traditional AD (IaaS) gives you full control but requires you to manage everything. AADDS also has limitations: no trusts, no schema extensions, no custom OUs at root, and limited Group Policy.
No. AADDS does not support trusts of any kind. If you need a trust, deploy IaaS domain controllers in Azure and create a VPN/ExpressRoute connection to your on-premises network. Then configure the trust between the IaaS domain and your on-premises domain.
In the Azure portal, go to your AADDS instance > Secure LDAP. Enable Secure LDAP, upload a certificate (issued by a CA trusted by your clients), and optionally enable access over the internet (requires a public IP). Then create an NSG rule to allow inbound traffic on port 636 from trusted sources. Update client devices to trust the CA.
All domain-joined VMs lose their domain membership and cannot authenticate. You must rejoin them to a new domain. The synchronized user data is not deleted from Azure AD, but any custom GPOs or OUs created in AADDS are lost. Always plan for a migration path if you need to replace AADDS.
Yes, but indirectly. Azure AD Connect syncs on-premises AD to Azure AD. AADDS then syncs from Azure AD. Do not attempt to sync directly from on-premises to AADDS; it is not supported. Also, Azure AD Connect should not be installed on a domain-joined VM (it can be, but it's not recommended).
You've just covered Azure AD Domain Services (AADDS) — now see how well it sticks with free AZ-104 practice questions. Full explanations included, no account needed.
Done with this chapter?