What are the Differences Between Azure Active Directory and Azure Active Directory Domain Services?

I met with some customers last week, and we had a great conversation about Active Directory and the differences between all the flavours available to them when adopting a hybrid posture.

 

More specifically, what are the difference between:

• Azure Active Directory (AAD)
• Azure Active Directory Domain Services (AADDS)
• Active Directory (AD)

It's essential to understand the differences when you’re looking at a “lift-and-shift” scenario from on-prem to IaaS.  If you are moving to the cloud by subscribing to SaaS applications or rewriting existing applications using modern PaaS services, you’ll want to take advantage of Azure Active Directory (AAD). AAD is our cloud-based identity solution that allows you to leverage users, groups, applications and security principal concepts. It supports web-based OAuth 2.0, SAML 2.0 and Open ID authentication frameworks.

 

However, AAD does not have capabilities like Group Policies or Application Containers or extensible schema, which is sometimes required by some workloads, among other capabilities.

 

 

When "lifting and shifting" applications to the cloud, there are a lot of identity needs that may be required, do they use AD services? Does the workload need a service account managed by AD both on-prem and in IaaS? Does the workload need to Extend the AD schema? Does the application need access to an Application Partition in AD?

 

 

You need to know your apps and how they interact with AD.  Once that is known, you can now decide if you will use one of the two remaining options, namely AD or AADDS, you can use to support your workload.

 

Here are some of the differences you need to keep in mind.

 

 

Azure Active Directory Domain Services (AADDS)

 

 

Azure Active Directory Domain Services (Azure AD DS) provides a managed domain services with a subset of fully compatible traditional AD DS features such as domain join, group policy, LDAP, and Kerberos / NTLM authentication.

It integrates with Azure AD and, when synchronized with an on-premises AD DS environment, allows you to extend your on-prem identities to run in Azure as part of a lift-and-shift strategy.

 

 

It all sounds wonderful, and it is in most cases. Here are some pros and cons. (This list is my own opinion)

Pros

The deployment of AADDS is relatively simple once you have your on-prem AD connected to AAD using Ad Connect.  It takes away the need for you to deploy your Domain Controllers in Azure and to ensure that your DCs are in different fault and update domains, and it takes care of the DC patching for you.

 

AADDS provides an experience that is fully compatible with a subset of features of Active Directory (see above). Depending on your apps, they may keep running in the cloud without any modifications.

 

As I mentioned since it's a managed Directory service, it is highly available the DCs and the AADDS will be automatically backed up.

 

You will not need to set up a site-to-site VPN or use ExpressRoute to facilitate the replication of self-managed regular AD domain controllers.

 

Cons

AADDS does support Group Policies. However, there is no GPO replication from on-prem; you must recreate the policies you need in the managed directory service. If you change one on-prem, you must perform the same change in the managed Directory.

 

AD domain/forest trusts are not supported at this point. (it's on the roadmap). 

 

There are no capabilities for Geo-distributed deployments.  Your managed AADDS is limited to the virtual network on which you deployed it. You can go around that problem by setting up VPNs and peered virtual networks, but it adds considerably more complexity to your environments.

 

As you can see in the diagram above,  the replication from your Azure AD tenant to AADDS is a one-way replication.  There are no facilities for LDAP writebacks outside of the managed domain in that virtual network, which means that the changes are NOT written back to the on-prem AD through the AD Connect sync process.

 

Active Directory (AD) in IaaS

 

Deploying Active Directory in IaaS is virtually the same as setting it up in remote offices.  You need a connection (site-to-site VPN or ExpressRoute), DCs deployed in each Virtual networks, defined sites in AD to managed replication and authentication requests.

These are tasks that we all know and have been doing for years. It feels familiar.  It's comfortable and that's ok.  This design also has Pros and Cons.

 

Pros

 

As I mentioned, it's familiar and comfortable.  It ensures that if an app worked on-prem it will still work once migrated to azure, the Application Partitions, the extended schema, the group policies will all be there.  Writebacks will occur natively without any duplicate work.

 

you are not limited to a single virtual network.  you can deploy as many sites as required anywhere in the world where Azure regions are found.
 

Cons

It's not a managed Directory Service, therefore you must take care of it.  Each additional domain Controller is another machine you must maintain and patch.

 

You must define where you deploy each DC to ensure availability. You must manage the backup and DR capabilities

 

Virtual Machines are typically more expensive than managed services (depending on how many Dcs you deploy and the size of the VMs)

 

Your environment is significantly more complex due to the VPN/ExpressRoutes added VMs and custom DNS service.

 

Conclusion

There is no right and wrong here.  Your design and directory choices are mandated by the workloads you are migrating.  Can they function adequately with AADDS?  do the absolutely require the full power of AD?

 

These are answers I cannot give you. You must find out for yourself. Do your due diligence before you start migrating. 

 

I hope this helps define where you need to look and how you need to think about AD integration when adopting a hybrid posture in Azure.

 

Cheers!

 

Pierre Roman