There are lots of confusion when talking about following three topics relating to Microsoft AD:

In this post, those terms and related technologies will be summarized in a easy way to understand. 

Differences among those three

from Microsoft

User accounts, group memberships, and credential hashes are synchronized one way from Azure AD to Azure AD DS. 


  • Active Directory is a database that organises your company’s users and computers. It provides authentication and authorization to applications, file services, printers, and other resources on the network. It uses protocols such as Kerberos and NTLM for authentication and LDAP to query and modify items in the Active Directory databases.
  • Secure Object store, including Users, Computers and Groups
  • Object organization – Organisational Units (OU), Domains and Forests
  • Common Authentication and Authorization provider
  • LDAP, NTLM, Kerberos (secure authentication between domain joined devices)
  • Group Policy – for fine grained control and management of PCs and Servers on the domain


  • No domain controller, just a identity management solution , 
  • sub dns name by default, but it can be customized
  • modern authentication mechanisms: OAuth2, SAML, WS-FED
  • Cloud auth, PTA, federation – seamlessly connecting to any Microsoft Online Services, thousands of SaaS applications
  • Not able to do
    • not offer Group Policy, LDAP, NT LAN Manager (NTLM) and Kerberos authentication
    • You can’t join a server to it
    • You can’t join a PC to it in the same way – there is Azure AD Join for Windows 10 only (see later)
    • It is a flat directory structure – no OU’s or Forests


  • Microsoft Managed, support OUs and GPOs
  • not connecting to AD, different site/forest
  • You are not enterprise admin, not Schema Admin, not Domain Admin
  • Common Use Cases 
    • Traditional Authentication as a Service (Kerberos, NTLM)
    • Cloud solutions that need domain join (Microsoft Virtual Desktop, AD Auth for file shares)

Another Option – DC in Azure Cloud

Domain Controllers in Cloud

  • install domain controller to a virtual machine in Azure
    • for organizations that use both on-premises and cloud-based resources which are connected through VPN or an Azure ExpressRoute.
  • full control

thumbnail image 4 of blog post titled 

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




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.


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.

Azure AD Connect


Use both AD and AAD (sync-ed):

If you have a traditional on-premise set up with AD and also want to use Azure AD to manage access to cloud applications (e.g. Office 365 or any of thousands of SaaS apps) then you can happily use both. You can synchronise AD with Azure AD so that the users only have one set of credentials which they use for both their network logon, and access to O365. You use Azure AD Connect to do this, it is a small free piece of Microsoft software that you install on a server to perform the synchronisation.

Use both AD and AAD (Unsync-ed):

If you are using Office 365 then your users will have a username and password for that (managed by Azure AD), as well as a username and password for their network logon (managed by AD). These two sets of credentials are un-related. This is fine, and just means that if you have a password change policy that users will have to do this twice (and they could of course choose the same password for both).

Use Only AAD:

If you are a new business or one that is looking to transition away from having any traditional on-premise infrastructure and using purely cloud based applications, then you can operate purely using Azure AD. In this case, although you will have all your applications in the cloud, you will of course still have physical devices – PCs and smart phones – that your team will use to access and work with these cloud applications.

More comparing can access this post at

Azure AD lets you manage the identity of devices used by the organization and control access to corporate resources from those devices. Users can also register their personal device (a bring-your-own (BYO) model) with Azure AD, which provides the device with an identity. Azure AD then authenticates the device when a user signs in to Azure AD and uses the device to access secured resources. The device can be managed using Mobile Device Management (MDM) software like Microsoft Intune. This management ability lets you restrict access to sensitive resources to managed and policy-compliant devices.

Traditional computers and laptops can also join to Azure AD. This mechanism offers the same benefits of registering a personal device with Azure AD, such as to allow users to sign in to the device using their corporate credentials. Azure AD joined devices give you the following benefits:

  • Single-sign-on (SSO) to applications secured by Azure AD.
  • Enterprise policy-compliant roaming of user settings across devices.
  • Access to the Windows Store for Business using corporate credentials.
  • Windows Hello for Business.
  • Restricted access to apps and resources from devices compliant with corporate policy.

Securely Manage AAD Join Devices

In the case of PCs (this applies to Windows 10 only) you can Azure AD Join them and login to machines using Azure AD user accounts. You can apply conditional access policies that require machines to be Azure AD joined before accessing company resources or applications. However Azure AD Join provides limited functionality compared to AD Join (as there is no Group Policy) and in order to gain fine grained control over the PCs you would then use a Mobile Device Management solution, such as Microsoft Intune, in addition to this.

Other devices (Windows 10, iOS, Android, and MacOS) can be Azure AD Registered (which means you sign into the device itself without requiring an Azure AD account, but can then access apps etc using the Azure AD account) and controlled using Microsoft Intune.

If you can’t get all your applications as SaaS apps and have some that still need to run on your own servers, then you can migrate these to Virtual Machines (VMs) in Azure. If those VMs need to be domain joined, then you can either deploy a Domain Controller on another VM in Azure, or you can use Azure Active Directory Domain Services (Azure AD DS) which is a PaaS service (you don’t have to manage it) for domain joining Azure VMs. Azure AD DS automatically synchronises with Azure AD so all your users get the application access you want.


Here are some of the main differences between AD (Not AAD) and AADDS:





Managed service

Secure deployments

You secure the deployment

DNS server

✓  (managed service)

Domain or Enterprise administrator privileges

Domain join

Domain authentication using NTLM and Kerberos

Kerberos constrained delegation


Resource-based & account-based

Custom OU structure

Group Policy

Schema extensions

AD domain/forest trusts


LDAP read

LDAP write

  (within the managed domain)

Geo-distributed deployments



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.



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.

The problem with Azure AD is that it treats organizations like “tenants” who access Azure AD through the Azure portal to manage their employees, passwords and permissions. Azure AD allows users to access various services once they have authenticated themselves, but you have no way of configuring access rights in details, as Azure AD does not meet the necessary structural conditions for this.

Microsoft’s solution to this problem is Azure AD Domain Services (AAD DS). AAD DS is an Azure product that provides an Active Directory domain (managed by Microsoft) on two domain controllers. The domain controllers support LDAP, domain joining and authentication via Kerberos and NTLM. This version of Azure Active Directory also supports the use of organizational units and group policies.

On an Azure AD-joined or registered device, user authentication happens using modern OAuth / OpenID Connect based protocols. These protocols are designed to work over the internet, so are great for mobile scenarios where users access corporate resources from anywhere.

With Azure AD DS-joined devices, applications can use the Kerberos and NTLM protocols for authentication, so can support legacy applications migrated to run on Azure VMs as part of a lift-and-shift strategy

Aspect Azure AD-joined Azure AD DS-joined
Device controlled by Azure AD Azure AD DS managed domain
Representation in the directory Device objects in the Azure AD directory Computer objects in the Azure AD DS managed domain
Authentication OAuth / OpenID Connect based protocols Kerberos and NTLM protocols
Management Mobile Device Management (MDM) software like Intune Group Policy
Networking Works over the internet Must be connected to, or peered with, the virtual network where the managed domain is deployed
Great for… End-user mobile or desktop devices Server VMs deployed in Azure

Create Azure AD Domain Services

Change SKU to standard from enterprise to save some cost. 


By netsec

Leave a Reply

Ads Blocker Image Powered by Code Help Pro

Ads Blocker Detected!!!

We have detected that you are using extensions to block ads. Please support us by disabling these ads blocker.