Traditional on-premises Active Directory Domain Services (AD DS) and Azure Active Directory (AAD) are not the same thing.
AD DS is focused on securing Windows desktops and servers. It allows you to join devices to your domain. It lets you authenticate to applications with LDAP, Kerberos, and NTLM authentication methods. It lets control your environment using Group Policy.
On the other hand, AAD is a version of directory services that runs in the cloud. It’s all about web-based authentication standards like OpenID and OAuth, and lets you sign into web-based applications like Office 365. It does not support domain-join of devices, LDAP, Kerberos, NTLM, or group policy.
So, what if you need to utilize traditional AD DS features in your Azure cloud? Azure has a few ways to accomplish that. This post will explore extending your current AD DS on-premises environment into Azure.
Scenario: Maybe you have a legacy app that runs in the cloud. This legacy app might only support LDAP for authentication. Let's say you want to keep that authentication flow in the cloud, and you don't want to send authentication traffic to any on-premises servers.
One solution is to extend your existing on-premises AD DS into Azure. Your on-premises site must have connectivity with Azure, either a site-to-site VPN, or an ExpressRoute connection. Then, just create a Windows Server VM in Azure IaaS, set it up as a new Domain Controller for your existing domain, and you're all set. Your cloud app can now talk with your cloud Domain Controller.
This solution has nothing to do with Azure Active Directory or Azure Active Directory Domain Services. In this scenario, AAD is an entirely separate and disconnected service. There are ways to connect & sync AD DS with AAD, but they are not explored in this post.
Some recommendations for this setup:
Deploy at least two cloud Domain Controllers in Azure for redundancy. No matter how many you create, make sure to put all of them in an Azure Availability Set.
Use a separate data disk on the VMs to hold the Active Directory database, logs, and SYSVOL directory. Do not store these items on the same disk as the operating system. Also, configure the data disk's Host Cache Preference setting with the option of None.
Do not configure the VMs with public IP addresses. Instead, configure them with private IP addresses. Make sure they are static, not dynamic.
Put your cloud Domain Controller in a dedicated Azure subnet, and configure a restrictive Network Security Group on that subnet. For detailed information about port requirements, see here.
In Active Directory create a separate Site for your Azure environment. Include the subnet for the cloud Domain Controllers, and any subnets containing Azure VMs that will access this AD domain. Then, configure a Site Link between on-premises and Azure.
It’s recommended that you do not assign the Operations Master FSMO role to a domain controller that is running in Azure.
Do not shutdown a domain controller VM using the Azure Portal. This causes the VM to become deallocated, which resets both the VM-GenerationID and the invocationID of the AD repository. This discards the RID pool and marks SYSVOL as nonauthoritative. It may require you to reconfigure the domain controller. Instead, shutdown and restart the VMs from within the guest operating system.
Also See:
Sources: