Active Directory (AD) vs Azure AD (AAD) vs Azure AD DS (AADDS)

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

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

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

AAD

No domain controller, just a identity management solution ,
sub dns name onmicrosoft.com 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

AADDS

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?

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.

Azure AD Connect

AD or AAD

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 https://www.apps4rent.com/blog/active-directory-domain-services-vs-azure-active-directory/

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.