| title | description | services | documentationcenter | author | manager | editor | ms.assetid | ms.service | ms.component | ms.workload | ms.tgt_pltfrm | ms.devlang | ms.topic | ms.date | ms.author |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Azure AD Domain Services: Compare Azure AD Domain Services to DIY domain controllers | Microsoft Docs |
Comparing Azure Active Directory Domain Services to DIY domain controllers |
active-directory-ds |
eringreenlee |
mtillman |
curtand |
165249d5-e0e7-4ed1-aa26-91a05a87bdc9 |
active-directory |
domain-services |
identity |
na |
na |
conceptual |
07/07/2017 |
ergreenl |
With Azure AD Domain Services you can deploy your workloads in Azure Infrastructure Services, without having to worry about maintaining identity infrastructure in Azure. This managed service is different from a typical Windows Server Active Directory deployment that you deploy and administer on your own. The service is easy to deploy and delivers automated health monitoring and remediation. We are constantly evolving the service to add support for common deployment scenarios.
To decide whether to use Azure AD Domain Services we recommend the following reading material:
- See the list of features offered by Azure AD Domain Services.
- Review common deployment scenarios for Azure AD Domain Services.
- Finally, compare Azure AD Domain Services to a do-it-yourself AD option.
The following table helps you decide between using Azure AD Domain Services and managing your own AD infrastructure in Azure.
| Feature | Azure AD Domain Services | 'Do-it-yourself' AD in Azure VMs |
|---|---|---|
| Managed service | ✓ | ✕ |
| Secure deployments | ✓ | Administrator needs to secure the deployment. |
| DNS server | ✓ (managed service) | ✓ |
| Domain or Enterprise administrator privileges | ✕ | ✓ |
| Domain join | ✓ | ✓ |
| Domain authentication using NTLM and Kerberos | ✓ | ✓ |
| Kerberos constrained delegation | resource-based | resource-based & account-based |
| Custom OU structure | ✓ | ✓ |
| Schema extensions | ✕ | ✓ |
| AD domain/forest trusts | ✕ | ✓ |
| LDAP read | ✓ | ✓ |
| Secure LDAP (LDAPS) | ✓ | ✓ |
| LDAP write | ✕ | ✓ |
| Group Policy | ✓ | ✓ |
| Geo-distributed deployments | ✕ | ✓ |
Azure AD Domain Services domains are managed by Microsoft. You do not have to worry about patching, updates, monitoring, backups, and ensuring availability of your domain. These management tasks are offered as a service by Microsoft Azure for your managed domains.
The managed domain is securely locked down as per Microsoft’s security recommendations for AD deployments. These recommendations stem from the AD product team's decades of experience engineering and supporting AD deployments. For do-it-yourself deployments, you need to take specific deployment steps to lock down/secure your deployment.
An Azure AD Domain Services managed domain includes managed DNS services. Members of the 'AAD DC Administrators' group can manage DNS on the managed domain. Members of this group are given full DNS Administration privileges for the managed domain. DNS management can be performed using the 'DNS Administration console' included in the Remote Server Administration Tools (RSAT) package. More information
These elevated privileges are not offered on an AAD-DS managed domain. Applications that require these elevated privileges cannot be deployed against AAD-DS managed domains. A smaller subset of administrative privileges is available to members of the delegated administration group called ‘AAD DC Administrators’. These privileges include privileges to configure DNS, configure group policy, gain administrator privileges on domain-joined machines etc.
You can join virtual machines to the managed domain similar to how you join computers to an AD domain.
With Azure AD Domain Services, you can use your corporate credentials to authenticate with the managed domain. Credentials are kept in sync with your Azure AD tenant. For synced tenants, Azure AD Connect ensures that changes to credentials made on-premises are synchronized to Azure AD. With a do-it-yourself domain setup, you may need to set up an AD domain trust with your on-premises AD for users to authenticate with their corporate credentials. Alternately, you may need to set up AD replication to ensure that user passwords synchronize to your Azure domain controller virtual machines.
You do not have 'Domain Administrator' privileges on an Active Directory Domain Services managed domain. Therefore, you cannot configure account-based (traditional) Kerberos constrained delegation. However, you can configure the more secure resource-based constrained delegation. More information
Members of the 'AAD DC Administrators' group can create custom OUs within the managed domain. Users who create custom OUs are granted full administrative privileges over the OU. More information
You cannot extend the base schema of an Azure AD Domain Services managed domain. Therefore, applications that rely on extensions to AD schema (for example, new attributes under the user object) cannot be lifted and shifted to AAD-DS domains.
Managed domains cannot be configured to set up trust relationships (inbound/outbound) with other domains. Therefore, resource forest deployment scenarios cannot use Azure AD Domain Services. Similarly, deployments where you prefer not to synchronize passwords to Azure AD cannot use Azure AD Domain Services.
The managed domain supports LDAP read workloads. Therefore you can deploy applications that perform LDAP read operations against the managed domain.
You can configure Azure AD Domain Services to provide secure LDAP access to your managed domain, including over the internet. More information
The managed domain is read-only for user objects. Therefore, applications that perform LDAP write operations against attributes of the user object do not work in a managed domain. Additionally, user passwords cannot be changed from within the managed domain. Another example would be modification of group memberships or group attributes within the managed domain, which is not permitted. However, any changes to user attributes or passwords made in Azure AD (via PowerShell/Azure portal) or on-premises AD are synchronized to the AAD-DS managed domain.
There is a built-in GPO each for the "AADDC Computers" and "AADDC Users" containers. You can customize these built-in GPOs to configure group policy. Members of the 'AAD DC Administrators' group can also create custom GPOs and link them to existing OUs (including custom OUs). More information
Azure AD Domain Services managed domains are available in a single virtual network in Azure. For scenarios that require domain controllers to be available in multiple Azure regions across the world, setting up domain controllers in Azure IaaS VMs might be the better alternative.
You may have deployment use-cases where you need some of the capabilities offered by a Windows Server AD installation. In these cases, consider one of the following do-it-yourself (DIY) options:
- Standalone cloud domain: You can set up a standalone ‘cloud domain’ using Azure virtual machines that have been configured as domain controllers. This infrastructure does not integrate with your on-premises AD environment. This option would require a different set of ‘cloud credentials’ to login/administer VMs in the cloud.
- Resource forest deployment: You can set up a domain in the resource forest topology, using Azure virtual machines configured as domain controllers. Next, you can configure an AD trust relationship with your on-premises AD environment. You can domain-join computers (Azure VMs) to this resource forest in the cloud. User authentication happens over either a VPN/ExpressRoute connection to your on-premises directory.
- Extend your on-premises domain to Azure: You can connect an Azure virtual network to your on-premises network using a VPN/ExpressRoute connection. This setup enables Azure VMs to be joined to your on-premises AD. Another alternative is to promote replica domain controllers of your on-premises domain in Azure as a VM. You can then set it up to replicate over a VPN/ExpressRoute connection to your on-premises directory. This deployment mode effectively extends your on-premises domain to Azure.
Note
You may determine that a DIY option is better suited for your deployment use-cases. Consider sharing feedback to help us understand what features would help you chose Azure AD Domain Services in the future. This feedback helps us evolve the service to better suit your deployment needs and use-cases.
We have published guidelines for Deploying Windows Server Active Directory on Azure Virtual Machines to help make DIY installations easier.