Azure Active Directory Domain Services (AADDS)

Azure AD Domain Services (AADDS) is a Microsoft-managed domain service that provides a subset of traditional Active Directory Domain Services (AD DS) capabilities in the Azure cloud. It is designed for workloads that cannot use modern authentication protocols (OAuth2, SAML, OpenID Connect) and instead rely on legacy protocols such as Kerberos, NTLM, and LDAP. Common examples include:

AADDS eliminates the need to deploy, patch, monitor, and maintain domain controllers in Azure VMs. Microsoft manages the domain controllers as a PaaS (Platform as a Service) offering, ensuring high availability (two domain controllers per domain are deployed across availability zones) and automatic patching.

AADDS is not a replacement for Azure AD. Azure AD is a cloud-based identity and access management service for modern authentication (OAuth, SAML, etc.). AADDS provides traditional AD DS protocols. The two services coexist and synchronize: user and group objects from Azure AD are automatically replicated to AADDS, but AADDS does not sync back to Azure AD – it is a one-way sync from Azure AD to AADDS.

When you enable AADDS for an Azure tenant, the following happens under the hood: 1. Domain Creation: Microsoft provisions a managed domain in the Azure region of your choice. The domain uses the DNS name you specify (e.g., aadds.contoso.com). The default domain suffix is <tenant-name>.onmicrosoft.com if you don't specify a custom name. 2. Two Domain Controllers: Microsoft deploys two domain controllers (DCs) in a Windows Server Active Directory forest. These DCs are not accessible via RDP; they are fully managed. They run as VMs in a Microsoft-managed virtual network (a hidden subscription). One DC is the primary, the other is a replica. If the primary fails, the replica takes over automatically. 3. Synchronization with Azure AD: AADDS syncs user accounts, group memberships, and password hashes from Azure AD. The sync is one-way only: changes made in AADDS (e.g., a new user created via ADAC) are not synced back to Azure AD. The sync interval is typically within a few minutes but can take up to 30 minutes for password changes. - Password Hash Sync: For cloud-only users, password hashes are not stored in Azure AD by default. You must enable password hash synchronization for AADDS to work. This is done during AADDS setup (or later via Azure AD Connect if you have hybrid identity). The hashes must be in the correct format (NT hash for NTLM and Kerberos hash for Kerberos). 4. LDAP and Kerberos Endpoints: AADDS exposes LDAP (port 389), LDAPS (port 636), Kerberos (port 88), and NTLM (port 445) endpoints on the managed domain controllers. These endpoints are accessible only from within the virtual network (or peered networks) where AADDS is enabled, unless you configure secure LDAP over the internet. 5. DNS: AADDS provides DNS services for the managed domain. By default, it uses the domain name as the DNS zone. You can delegate DNS to AADDS from your custom domain. 6. Group Policy: AADDS includes a default Group Policy Object (GPO) for the AADDC Computers and AADDC Users containers. You can create custom GPOs using the Group Policy Management Console (GPMC) on a management VM joined to the managed domain.

While you cannot directly manage the domain controllers, you can verify connectivity and functionality using standard tools from a domain-joined VM.

Verify domain join:

# On a Windows VM joined to AADDS
Get-WmiObject Win32_ComputerSystem | Select-Object Domain

Verify LDAP connectivity:

# Using .NET DirectorySearcher
$ldapPath = "LDAP://aadds.contoso.com/DC=aadds,DC=contoso,DC=com"
$entry = New-Object System.DirectoryServices.DirectoryEntry($ldapPath)
$entry.psbase.Name

Verify Kerberos authentication:

klist get krbtgt

Check DNS resolution:

nslookup aadds.contoso.com

Using Azure CLI to check AADDS status:

az ds show --name mydomain --resource-group myrg --query provisioningState

A financial services company has a .NET application that uses Windows Integrated Authentication (Kerberos) and requires LDAP for user lookups. The application runs on Windows Server 2012 R2 VMs. The company wants to migrate these VMs to Azure but cannot modify the application to use modern auth. They enable AADDS in the same region as the VMs, configure DNS to point to the AADDS IPs, join the VMs to the managed domain, and assign the application's service account a user account in Azure AD (synced to AADDS). The application works without code changes. The company uses Premium SKU because they have over 25,000 users. They also enable secure LDAP to allow the application to query LDAP over TLS. The main challenge was ensuring the password hash sync was enabled for cloud-only users – they had to run a PowerShell script to trigger the sync. Performance is monitored via Azure Monitor metrics; average LDAP bind time is under 10ms.

A healthcare organization needs to deploy RDS session hosts in Azure for remote workers. The RDS deployment requires domain-joined servers for user profile disks, Group Policy for security settings, and Kerberos authentication. They cannot use Azure AD because RDS does not natively support Azure AD authentication for session hosts. They enable AADDS in the same VNet as the RDS infrastructure. They join the RDS session hosts to the managed domain. They create a 'RDS Users' group in Azure AD, which syncs to AADDS. They configure Group Policy to enforce screen lock and drive redirection. They also use Azure AD Application Proxy to publish the RDS web client. The deployment supports 500 concurrent users. The key consideration is that the AADDS domain name must be different from the on-premises domain to avoid DNS conflicts. They also set up a one-way outbound trust from AADDS (resource forest) to on-premises AD to allow on-premises users to access RDS resources. This required Premium SKU.

Common misconfigurations include: - DNS misconfiguration: VMs cannot resolve the AADDS domain, causing domain join failures. Solution: ensure VNet DNS points to AADDS IPs. - Missing password hash sync: Users can authenticate to Azure AD but not to AADDS. Symptom: login fails with 'The trust relationship between the workstation and the primary domain failed'. Solution: enable password hash sync. - Incorrect NSG rules: If NSGs block ports 443, 3389 (from Microsoft management IPs), or 636 (LDAPS), the service may become unhealthy. Microsoft monitors these ports; if blocked, the domain may be marked as degraded. - Using the same domain name as on-premises: This causes DNS conflicts and authentication issues. Always use a different domain name (e.g., aadds.contoso.com). - Trying to create custom OUs: Not possible in AADDS – all objects go into default containers. Attempting to create OUs via ADUC will fail with an access denied error.