Azure AD Directory Service - New Features

Azure, Azure-AD, Identity

Back in November I published an article on Azure Active Directory Domain Services (AAD DS), detailing some of the limitations of the service and what it is and isn’t intended for. If you’ve not read that I recommend going back and reading through that first so this article makes sense.

Since this article was published there have been some big updates to the service that mean some of these limitations have gone away, so I thought it was time to detail some of these changes and what they mean for Azures Domain Controller as a Service offering.

Kerberos Delegation

The initial release of AAD DS did not allow you to set up Kerberos Delegation, therefore if any of your apps needed this to impersonate user between web and SQL layers, or to use things like Azure App Proxy then this wasn’t possible and was a big limiting factor in adopting AAD DS.
The AAD DS team have now enabled this, to some extent. With AAD DS you can now use Resource based Kerberos Constrained Delegation. This version of delegation is available in Server 2012 and later and moves away from the use of SPN’s for resource to which an impersonating account can get access, to instead storing a list of accounts that are allowed to act on behalf or a resource. Using this does require that your using Server 2012 or later on your VM’s, and that your application is able to support it, but it does now mean that for most people this barrier will go away.

See [this article](http://(https://docs.microsoft.com/en-us/azure/active-directory-domain-services/active-directory-ds-enable-kcd) on how to set up resource based constrained delegation in AAD DS

GPOs

This was a big blocker previously, AAD DS only allowed you to use the two built in GPOs (one for computers, one for users), you could not add more GPOs and you could not target GPOs on specific OUs. This is now possible, you can create as many GPOs as required and these can be target at your custom created OU’s.
This article shows you how this works, however it’s not really any different from using your on premises GPO’s.

Limitations

These two new features do remove a lot of the blockers on AAD DS we discussed previously, however a number of the limitations are still in place, and will mean this solution just won’t work for some situations:

  • 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.
  • AAD DS still 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
  • AAD DS still requires you to use the old Azure portal, and there is not PowerShell or ARM template way to automate it’s deployment

As I mentioned in the previous article, AAD DS is designed for a very specific purpose, to help you lift and shift applications from on premises into the cloud. It isn’t intended to help you replicate your full on premises directory to the cloud and it’s not a replacement for on premises AD.