Microsoft Azure AD Domain Services: Managed Domain Services for Small Businesses in Berlin

Microsoft Azure Active Directory Domain Services (Azure ADDS, now part of Microsoft Entra Domain Services) provides managed Active Directory Domain Services in Azure without requiring domain controller virtual machines. For small businesses in Berlin with legacy Windows applications that require Kerberos authentication, LDAP directory queries, NTLM authentication, or domain-joined machine policies, Azure ADDS provides AD compatibility without the operational overhead of maintaining on-premises or IaaS domain controllers.

What Azure AD Domain Services Solves

Pure Azure AD (now Microsoft Entra ID) uses modern authentication protocols: OAuth 2.0, OpenID Connect, and SAML. These protocols work perfectly for Microsoft 365, cloud-born SaaS applications, and modern line-of-business apps. They do not work for applications that require legacy AD protocols: Kerberos tickets for Windows file shares, LDAP queries for directory lookups, NTLM authentication for older web applications, or Group Policy Objects for Windows machine configuration.

Azure ADDS creates a managed domain in Azure that supports these legacy protocols while synchronizing identities from Microsoft Entra ID. Users can authenticate against the Azure ADDS domain using their existing Entra ID credentials. This means a small Berlin business can migrate its on-premises server infrastructure to Azure IaaS, domain-join those VMs to Azure ADDS, and apply Group Policy without managing domain controller VMs, patching, replication, and backup.

Architecture: How Azure ADDS Works

When you enable Azure ADDS for your Entra ID tenant, Microsoft provisions two managed domain controller replicas in your chosen Azure region (Frankfurt for European deployments). These domain controllers are fully managed — Microsoft handles OS patching, backup, replication, and availability. You cannot RDP into the managed domain controllers or install software on them. Administrative access to the domain is provided through LDAP, Group Policy, and the “AAD DC Administrators” group.

Identity synchronization flows one direction: from Entra ID to Azure ADDS, not the reverse. User accounts, group memberships, and password hashes synchronize from Entra ID. Changes made directly in Azure ADDS (if LDAP write were used) do not propagate back to Entra ID. This one-way sync model preserves Entra ID as the authoritative identity store while providing AD protocol compatibility for workloads that need it.

Password hash synchronization must be enabled for Azure ADDS users to authenticate against Kerberos. Users who authenticate against Entra ID only via modern protocols have a different credential hash than what Kerberos requires. When password hash sync is enabled (required for Azure ADDS), both modern protocol hashes and Kerberos-compatible NTLM/Kerberos hashes are synchronized to Azure ADDS. This is an important architectural consideration: enabling password hash sync means credential hash data is stored in Azure, which some organizations may need to evaluate from a data residency perspective.

Domain-Joined VMs and Group Policy

Azure IaaS virtual machines can be joined to the Azure ADDS managed domain just like physical machines join an on-premises domain. Once joined, the VMs receive Group Policy from Azure ADDS, can authenticate users with Kerberos, and can access domain-joined resources using Windows-integrated authentication. For Berlin businesses migrating legacy Windows applications (ERP systems, line-of-business apps requiring Windows authentication, RDS session hosts) to Azure IaaS, Azure ADDS enables the migration without refactoring applications to use modern authentication.

Group Policy Objects can be created and linked to the Azure ADDS domain. Custom OUs can be created for segmenting computer accounts and applying different GPO configurations to different workload groups. The “AADDC Computers” built-in OU receives all domain-joined machines by default; best practice is to move machines to custom OUs and apply targeted GPOs rather than modifying the built-in OU structure.

LDAP and Kerberos for Applications

Applications that use LDAP for directory lookups (on-premises web apps, monitoring tools, older SaaS connectors) can be configured to query Azure ADDS via Secure LDAP (LDAPS) over port 636. Azure ADDS supports both standard LDAP and LDAPS; Microsoft recommends LDAPS for all production applications. Configuring LDAPS requires creating a certificate and uploading it to Azure ADDS — Azure ADDS manages the certificate lifecycle for the managed domain controllers once the certificate is provided.

Kerberos-based single sign-on for IIS-hosted applications, SharePoint on-premises, or other Kerberos-aware services works against Azure ADDS when the application servers are domain-joined. Users authenticate with their Entra ID credentials (which are mirrored to Azure ADDS) and receive Kerberos tickets for service access without additional credential prompts. This provides a seamless authentication experience for legacy applications while identity management remains in Entra ID.

Azure ADDS vs Entra ID: When to Use Which

Azure ADDS is appropriate when you have workloads that specifically require legacy AD protocols and cannot be refactored to use modern authentication. This includes: lifting-and-shifting on-premises AD-dependent applications to Azure IaaS, supporting Azure Virtual Desktop session hosts that require domain join for application compatibility, providing LDAP directory services for on-premises applications migrated to Azure without code changes, and running RDS workloads on Azure IaaS that require domain-joined session hosts.

Entra ID covers all modern authentication scenarios and should be the identity foundation for all new development and cloud-first workloads. The distinction is not either/or: most small Berlin businesses deploying Azure ADDS use it alongside Entra ID, with Entra ID as the primary identity store and Azure ADDS providing backward compatibility for a specific subset of legacy workloads. As legacy applications are modernized or replaced, the scope of Azure ADDS usage naturally shrinks.

Cost and Licensing for Berlin SMBs

Azure ADDS is priced per hour based on the SKU (Standard or Enterprise) and the Azure region. For Frankfurt-region deployments, the Standard SKU costs approximately 0.15–0.20 EUR per hour, totaling roughly 110–150 EUR per month for a continuously running instance. The Enterprise SKU adds features like forest trusts and fine-grained password policies. For small Berlin businesses, the cost is justified when the alternative is maintaining one or two IaaS domain controller VMs with associated compute, storage, and operational management costs. Azure ADDS eliminates the DC management overhead entirely while typically costing less than two always-on domain controller VMs.