Azure

Azure Active Directory Domain Services

Azure Active Directory Domain Services (Azure AD DS) provides managed domain services that are fully compatible with Windows Server Active Directory. You can use Azure Active Directory Domain Services to join Azure virtual machines to a domain, without having to deploy domain controllers. Also using Azure Active Directory Domain Services you can use features like group policy, LDAP, NTLM and Kerberos authentication for your infrastructure. All these capabilities can be achieved without deploying domain controllers as Azure virtual machines or use a VPN connection back to your identity infrastructure.

In Azure Active Directory Domain Services you don’t need to deploy, manage, and patch domain controllers. Azure AD DS integrates with your existing Azure AD tenant, which makes it possible for users to sign in using their existing credentials. You can also use existing groups and user accounts to secure access to resources, which provides a smoother lift-and-shift of on-premises resources to Azure.

Azure AD DS replicates identity information from Azure AD, so it works with Azure AD tenants that are cloud-only or synchronized with an on-premises Active Directory Domain Services (AD DS) environment. If you have an existing on-premises AD DS environment, you can synchronize user account information to provide a consistent identity for users. For cloud-only environments, you don’t need a traditional on-premises AD DS environment to use the centralized identity services of Azure AD DS. The same set of Azure AD DS features exist for both environments.

Azure AD DS features and benefits

To provide identity services to applications and VMs in the cloud, Azure AD DS is fully compatible with a traditional AD DS environment for operations such as domain-join, secure LDAP (LDAPS), Group Policy and DNS management, and LDAP bind and read support. LDAP write support is available for objects created in the Azure AD DS managed domain, but not resources synchronized from Azure AD. The following features of Azure AD DS simplify deployment and management operations:

Simplified deployment experience: Azure AD DS is enabled for your Azure AD tenant using a single wizard in the Azure portal.
Integrated with Azure AD: User accounts, group memberships, and credentials are automatically available from your Azure AD tenant. New users, groups, or changes to attributes from your Azure AD tenant or your on-premises AD DS environment are automatically synchronized to Azure AD DS.
Use your corporate credentials/passwords: Passwords for users in your Azure AD tenant work with Azure AD DS. Users can use their corporate credentials to domain-join machines, sign in interactively or over remote desktop, and authenticate against the Azure AD DS managed domain.
NTLM and Kerberos authentication: With support for NTLM and Kerberos authentication, you can deploy applications that rely on Windows-integrated authentication.
High availability: Azure AD DS includes multiple domain controllers, which provide high availability for your managed domain. This high availability guarantees service uptime and resilience to failures.

Some key aspects of an Azure AD DS managed domain are as follows:

The Azure AD DS managed domain is a stand-alone domain. It isn’t an extension of an on-premises domain.

Your IT team doesn’t need to manage, patch, or monitor domain controllers for this Azure AD DS managed domain

To see Azure AD DS in action, let’s look at a couple of examples:

Azure AD DS for hybrid organizations

Many organizations run a hybrid infrastructure that includes both cloud and on-premises application workloads. Legacy applications migrated to Azure as part of a lift and shift strategy may still use traditional LDAP connections to provide identity information. To support this hybrid infrastructure, identity information from an on-premises Active Directory Domain Services (AD DS) environment can be synchronized to an Azure AD tenant. Azure AD DS can then provide these legacy applications in Azure with an identity source, without the need to configure and manage application connectivity back to on-premises directory services.

Let’s look at an example for Litware Corporation, a hybrid organization that runs both on-premises and Azure resources:

Applications and server workloads that require domain services are deployed in a virtual network in Azure.
- This may include legacy applications migrated to Azure as part of a lift and shift strategy.
To synchronize identity information from their on-premises directory to their Azure AD tenant, Litware Corporation deploys Azure AD Connect.
- Identity information that is synchronized includes user accounts and group memberships.
Litware’s IT team enables Azure AD DS for their Azure AD tenant in this, or a peered virtual network.
Applications and VMs deployed in the Azure virtual network can then use Azure AD DS features like domain join, LDAP read, LDAP bind, NTLM and Kerberos authentication, and Group Policy.

Azure AD DS for cloud-only organizations

A cloud-only Azure AD tenant doesn’t have an on-premises identity source. User accounts and group memberships, for example, are created and managed in Azure AD.

Now let’s look at an example for Contoso, a cloud-only organization that only uses Azure AD for identity. All user identities, credentials, and group memberships are created and managed in Azure AD. There is no additional configuration of Azure AD Connect to synchronize any identity information from an on-premises directory.

Applications and server workloads that require domain services are deployed in a virtual network in Azure.
Contoso’s IT team enables Azure AD DS for their Azure AD tenant in this, or a peered virtual network.
Applications and VMs deployed in the Azure virtual network can then use Azure AD DS features like domain join, LDAP read, LDAP bind, NTLM and Kerberos authentication, and Group Policy.

You can access the service by following the step