- Azure Sentinel—A real-world example - Tue, Oct 12 2021
- Deploying Windows Hello for Business - Wed, Aug 4 2021
- Azure Purview: Data governance for on-premises, multicloud, and SaaS data - Wed, Feb 17 2021
Businesses can move to the public cloud in several ways. Some pick Software as a Service (SaaS) services for email, collaboration, accounting, or CRM; this provides the easiest “deployment” method as long as the service offers the features you need.
In some cases, applications can be modernized to run on Platform as a Service (PaaS), which gets you out of having to maintain hardware, networking, and the OS that your code runs on. This is desirable but might require a fair bit of refactoring of code.
Many businesses, however, opt for “lift and shift:” pick your in-house application VMs (probably running on older hardware) and move them to the cloud. You still have to patch, secure, and maintain the OS on those VMs, but at least you’re out of the hardware and networking business.
In most cases, to do lift and shift into Azure Infrastructure as a Service (IaaS) means extending your Active Directory infrastructure to the cloud. These VMs are domain-joined so they may expect LDAP authentication services to be present or rely on Kerberos or NTLM—perhaps even Group Policy. Azure Active Directory is no help here as it’s an Identity as a Service option that doesn’t support traditional on-premises AD features.
So, at a minimum, you have to have one or two VMs running as Domain Controllers (DCs) and DNS servers, with a hybrid network (Site-to-Site VPN or ExpressRoute) back to your corporate datacenter. This is a fair bit of infrastructure to manage (and pay for).
Azure AD Domain Services vs. Azure Active Directory
In early October 2015, Microsoft introduced an alternative: AD as a service. There are lots of “AD” acronyms, so let’s sort them out before we go any further. AD is the on-premises Active Directory most business use today, and AAD is Azure Active Directory that underlies all Office 365 tenants as well as identities you use in Azure. You can link your on-premises AD to the cloud AAD using AAD Connect. AAD DS is the service that this article covers: Azure Active Directory Domain Services.
Let’s look at what it offers, what’s missing, and how to set it up. For a cloud-only tenant that doesn’t have an on-premises AD infrastructure, the workflow is straightforward: enable the Azure AD directory for AAD DS; corporate users can then log in to cloud VMs using Remote Desktop, and VMs in Azure Virtual Networks can take advantage of Group Policy, Kerberos, and LDAP. There are no DCs to manage and no AD replication to manage; it’s all provided as a service.
Azure AD Domain Services for hybrid organizations
The scenario with a company only in the cloud will be a very small minority. Most businesses have AD on premises and will want to extend that to the cloud without extra infrastructure to maintain. The first requirement is that you use password synchronization. If you’re using AD Federation Services (AD FS) or a third-party federation service to route all authentication back on premises, this won’t work for you.
Note that the domain provided is NOT an extension of the on-premises domain; it’s a standalone, managed domain where you don’t have Domain or Enterprise Administrator credentials. Nevertheless, you can use the same credentials you use today to log on to VMs, and you can manage accounts with the same groups you use on premises. There’s no AD replication from your on-premises AD infrastructure directly; instead, user accounts and groups flow to AAD via AAD Connect.
Because the service is specifically targeted at making it easier to domain-join VMs running in Azure, other limitations exist. Only the base computer AD object is supported; you can’t extend the schema for the AAD DS domain. There’s only a flat OU structure, and nested OUs are not supported. A built-in GPO exists each for computer and user accounts; you cannot target OUs with these GPOs, nor can you use WMI filters or security group filtering.
Limitations
Today, the preview is only available in the US and Asia regions. In addition, all the VMs that you want to be able to take advantage of AAD DS have to be in the same virtual network because only one can be enabled for the service.
Users cannot directly change their password for the cloud domain. Instead, they change it on premises or using AAD Premium’s self-service password reset feature. The new password is replicated to the cloud through AAD Connect.
Any applications running on VMs on premises that you’re looking to lift and shift can use LDAP read operations. However, writes aren’t supported because there’s no way (yet) to write those changes back to on-premises VMs.
How to enable AAD DS
At a high level, you need to create a group in your directory called AAD DC Administrators, add the relevant users to the group, and then enable the directory for AAD DS.
Adding the group for AAD DS
Pick the virtual network to use for AAD DS; after the provisioning is complete (20-30 minutes per IP address), you’ll be given two IP addresses that you set as the DNS servers for your virtual network. These IP addresses are your DCs and DNS servers. Finally, you need to change your passwords if you’re a cloud-only tenant; this causes the legacy credential hashes to be generated. If you’re synching an on-premises directory, you need to force a full password sync using a PowerShell script. Rather than rehash Microsoft’s step-by-step instructions, I’ll point you to this blog post.
Enabling AAD DS for a directory
The cost during preview is 50% of the GA price (currently about $75 US per month). After GA, several pricing tiers, depending on the number of objects in your AAD directory, will apply.
Conclusion
I’m not sure what to make of this service. On one hand, it makes perfect sense. Not having to spin up one (two, really, for redundancy) VMs as DCs with all the associated management is very nice. This is especially true because they really need to be running 24x7, whereas application VMs can be shut down during non-business hours. And it’s certainly good to see that Microsoft listens to feedback and tries to pave the road to the cloud with smooth tiles to make it as easy as possible to get there.
But the service as it stands today has limitations, and a fair bit of due diligence testing will be required to ensure that AAD DS delivers the required capabilities for your applications, your security requirements, and your particular business needs.
