Azure AD Domain Services - What it is and isn't

Azure, Identity, Azure-AD

The AAD DS team has released new features that mean some of the limitations in this article are no longer present. Be sure to read my update on this service to get the latest information.

Azure AD has always been a little bit confusing to new users of Azure, the name implies it’s a cloud version of AD, but it quickly becomes clear to most that it very much is not. However, to add more confusion to this mix an additional product, Azure Active Directory Domain Services (AAD DS) has recently gone GA, which does bring some of the functionality of on premises domain controllers to Azure as a PaaS service. The problem is that what this new service is and isn’t for is somewhat confusing.

What it is:

AAD DS’s primary reason for existence is for lift and shift, to help clients move applications from on premises to Azure when they require the ability to talk to a proper LDAP AD for authentication or communication, and in this scenario AADDS is well suited. It provides an LDAP and Kerberos enabled directory that applications can talk to without any changes required, you can join machines to the domain, create users, manage DNS and even apply some GPO’s. So for providing domain services with a small scope and a limited set of services it works well. Users in AAD DS are automatically synced to Azure AD and so can then be used by apps that are able to talk to AAD as well.

What It’s Not:

One question I see a lot when talking about AAD DS is whether or not this can be used to replace an on premises domain or provide domain services for a large Azure deployment, and this is where the AD as a service paradigm falls down, and where it’s clear that this service is designed for a very specific need. AAD DS has some quite significant limitations that mean for many users it will be a no-go, even if you are deploying all in Azure:

  • You don’t actually get Domain Admin or Enterprise Admin rights so if anything you need to deploy (like Exchange) needs these your out of luck.
  • The lack of admin rights also means things like setting up Kerberos Delegation aren’t possible, so that means thinks like app proxy Window Auth are off the list
  • You can’t create custom GPOS, you can only edit the existing 1 user and 1 computer GPOs
  • You can create custom OUs but these OUs are only shown on the AD DS side of things, any users in these custom OUs won’t show in the Azure AD
  • You can only apply the default GPOs to custom OUs, you can’t create new ones.
  • AAD DS Requires a v1 VNET, so if your using v2 VNETs you’ll need to create a separate VNET and join them either by VNET peering or VPN

Conclusion

If you’ve got an app you want to move to Azure and it needs access to a full LDAP AD, or needs to be on a domain joined machine then AAD DS is a great solution for a lift and shift of that application without having to run your own IaaS solution.

However, if your looking to do anything that requires domain admin rights, or anything complex with GPO or OU’s the AAD DS quickly becomes a no go. The available options are too restrictive if you are looking for anything more than the the simple setup AAD DS provides. AAD DS is not a replacement for your on premises domain controllers.

AAD DS is designed for a very specific purpose, and if you need to stray outside of the scope of that you quickly see you need to fall back to using IaaS and full domain controllers. Maybe in the future things will be added to make AAD DS more of a full blown AD as a service option, but it’s not there currently.