Azure Infrastructure Services enable you to deploy a wide range of computing solutions in an agile manner. With Azure Virtual Machines, you can deploy nearly instantaneously and you pay only by the minute. Using support for Windows, Linux, SQL Server, Oracle, IBM, SAP, and BizTalk, you can deploy any workload, any language, on nearly any operating system. These benefits enable you to migrate legacy applications deployed on-premises to Azure, in order save on operational expenses.
A key aspect of migrating on-premises applications to Azure is handling the identity needs of these applications. Directory-aware applications may rely on LDAP for read or write access to the corporate directory or rely on Windows Integrated Authentication (Kerberos or NTLM authentication) to authenticate end-users. Line of business applications running on Windows Server are typically deployed on domain joined machines, so they can be managed securely using Group Policy. In order to ‘lift-and-shift’ on-premises applications to the cloud, these dependencies on the corporate identity infrastructure need to be resolved.
In order to satisfy the identity needs of their applications deployed in Azure, administrators often turn to one of the following solutions:
- Deploy a site-to-site VPN connection between workloads running in Azure Infrastructure Services and the corporate directory on-premises.
- Extend the corporate AD domain/forest infrastructure by setting up replica domain controllers using Azure virtual machines.
- Deploy a stand-alone domain in Azure using domain controllers deployed as Azure virtual machines.
All of these approaches suffer from high cost and administrative overhead. Administrators are required to deploy domain controllers using virtual machines in Azure. They need to subsequently manage, secure, patch, monitor, backup and troubleshoot these virtual machines. The reliance on VPN connections to the on-premises directory causes workloads deployed in Azure to be vulnerable to transient network glitches or outages. This in turn results in lower uptime and reduced reliability for these applications.
Azure AD Domain Services are designed to provide a much easier alternative.
Introducing Azure AD Domain Services
Azure AD Domain Services provide managed domain services such as domain join, group policy, LDAP, Kerberos/NTLM authentication etc. that are fully compatible with Windows Server Active Directory. Azure AD Domain Services enable you to consume these domain services, without the need for you to deploy, manage and patch domain controllers in the cloud. Azure AD Domain Services integrate with your existing Azure AD tenant, thus making it possible for users to login using their corporate credentials. Additionally, you can use existing groups and user accounts to secure access to resources, thus ensuring a smoother ‘lift-and-shift’ of on-premises resources to Azure Infrastructure Services.
Azure AD Domain Services work seamlessly regardless of whether your Azure AD tenant is cloud-only or synced with your on-premises Active Directory.
A cloud-only Azure AD tenant (often referred to as ‘managed tenants’) does not have any on-premises identity footprint. In other words, users, their passwords and group memberships are all native to the cloud – i.e. created and managed in Azure AD. Consider for a moment that Contoso is a cloud-only Azure AD tenant. As shown in the below illustration, Contoso’s administrator has configured a virtual network in Azure Infrastructure Services. Applications and server workloads are deployed in this virtual network in Azure virtual machines. Since Contoso is a cloud-only tenant, all user identities, their credentials and group memberships are created and managed in Azure AD.