Active Directory (AD) vs Azure AD (AAD) vs Azure AD DS (AADDS) & MDM vs Group Policy

 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. 

AD

• 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)

Difference between Azure AD Registered, Azure AD joined, Hybrid Azure AD joined

What is the difference between: 

1. Domain Joined device 

2. Hybrid Joined device 

3. Azure AD joined device 

4. Azure AD registered device

What you choose depends on the 

1. Who owns the data and 

2. Who gets to manage the device 

3. Where features do the applications need 

4. Where is the authentication going to happen

1. Domain Joined: 

a. Traditional devices connected to on-prem AD. b. Login with corporate user id. c. Authentication only via on-prem AD. d. Managed using group policy e. Gives local apps features such as Kerberos/NTLM authentication, LDAP connections etc...

2. Hybrid Azure AD Joined is for: a. corporate owned and managed devices b. Authenticated using a corporate user id that exists at local AD & on AAD. c. Authentication can be done using both: On-Prem AD & Azure AD. d. Managed using group policy e. Gives local apps features such as Kerberos/NTLM authentication, LDAP connections etc... f. Gives cloud apps features such as Oauth, SAML authentication g. Ideal for corporate owned laptops.

3. Azure AD Joined is for a. Corporate owned and managed devices b. Authenticated using a corporate id that exists on Azure AD c. Authentication is only through AAD. d. Management is using MDM tools e. Gives access to only cloud apps features such as Oauth, SAML authentication f. Ideal for corporate owned laptops or mobile devices in a cloud only or cloud centric environment

4. AAD Registered Device is for a. Personally owned corporate enabled b. Authentication to the device is with a local id or personal cloud id (such as outlook.com) c. Authentication to corporate resources using a user id on AAD. d. Apps can be locally installed or cloud apps. e. Management can done using MDM tools but may or may not be enforced. f. Ideal for personally owned laptops or mobile devices in a personally owned, corporate enabled devices.

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

 

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： MDM vs Group Policy

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.

On the surface, it looks like MDM and Group Policy accomplish the same goals. The major difference between Windows 10 MDM vs Group Policy is that they each work in different environments. For example, Group Policy only supports domain-joined machines in a traditional Active Directory environment. Conversely, a Windows 10 MDM provider like Intune only supports MDM-enrolled machines that reside in a cloud tenant like Microsoft Azure. With MDM, machines can be non-domain-joined, or hybrid domain-joined (on-prem Active Directory vs Azure Active Directory).

Windows 10 MDM Settings for the Control Panel Are Weak

Managing the Windows 10 Control Panel is critical for security and desktop standardization. Today, Microsoft Intune only manages 16 Control Panel Settings, while Group Policy manages 50 settings. Group Policy allows you to manage key components like “Add or Remove Programs,” “Printers,” and “Programs.” Windows 10 MDM software does not provide the same functionality.

If you plan to manage the Windows 10 control panel with MDM exclusively, you risk gaping security holes. MDM alone will not allow you the same granularity and flexibility as Group Policy.

Windows 10 OMA-URIs Are Limited and Difficult to Configure

When you configure a setting in Windows 10 using the Intune GUI, that setting is delivered through a corresponding configuration service provider (CSP). A CSP is a component of the Windows 10 operating system and gives MDMs the ability to apply device-specific settings. Now there are more CSP settings available than are currently covered by Intune, which means that there are more possible settings to configure than there are clickable options within the Intune interface.

So how do we configure settings on a CSP that doesn’t appear within Intune? Well, that is where the role of custom profiles comes into play. Custom profiles are necessary when you want to manage device settings and features that aren’t built into Intune. Customer profiles can be created for multiple platforms including Android, iOS, and Windows 10. Windows 10 MDM custom profiles use something called the Open Mobile Alliance Uniform Resource Identifier (OMA-URI) to configure settings and features. These settings, for the most part, are provided by a special CSP called the policy CSP. To create a custom OMA-URI Intune Windows 10 setting, you need to provide the following information:

• Name for the customer setting (this can be anything)
• Description of the setting’s purpose/li>
• The OMA-URI path for the setting
• The data type used by the setting
• The designated value for the setting

Windows 10 ADMX Templates Don’t Play Nice with Windows 10 MDM

Starting in Windows 10 version 1703, something new happened in MDM. Group Policy admins have been working with it for a long time. You could say that, with 1703, MDM brought in something old and made it new. That new old thing is ADMX-backed policies.

In an earlier screenshot, you may have seen the Windows 10 ADMX Template (Preview) option available in the Profile Type menu. Unfortunately, you cannot view the available settings when selecting this profile type like you can when choosing the “Device restrictions” option. You can only review the available settings after creating the profile and then accessing it.

At this writing, there are around 270 available settings (again, curated, guaranteed settings). Most of these are dedicated to Office, Internet Explorer, and OneDrive. The following screenshot shows some of the available settings listed in alphabetical order, and there is no hierarchal view. You must know the setting you are after by using the “Search to filter items…” bar seen in the image.

Windows 10 MDM Has Fewer Settings Available than Group Policy

So as of this writing, Intune has about 300 curated Windows 10 MDM settings you can select, plus approximately 300 available via Intune’s Administrative Templates function.

We are using the word curated to indicate that the MDM team at Microsoft has indicated that these settings are guaranteed to work in cloud-specific scenarios.

You might be interested to know how many settings are covered:

• By Intune and not Group Policy, and
• By Group Policy and not Intune

MDM vs Group Policy

Description	Count
Windows 10 MDM Settings exclusive to Intune (and not in Group Policy)	48
Computer Side Windows 10 ADMX Settings shared by Group Policy and Intune	655
User Side Windows 10 ADMX Settings shared by Group Policy and Intune	232
Computer Side Windows 10 ADMX Settings only in Group Policy	1,813
User Side Windows 10 ADMX Settings only in Group Policy	1,499

So in an Intune-only world, you are missing out on 3,312 Group Policy ADMX settings.

Keep in mind, too, that many of the Windows 10 ADMX settings that are available in Intune are not existing settings, but only become settings if you create custom policies.

Moreover, there is Group Policy Preferences, as shown in the following image. When you consider Group Policy Preferences, the number of missed settings grows to about 10,000.

How is that possible?

Well, let’s look at some commonly used Group Policy Preferences setting categories.

Group Policy Preferences vs MDM

Category	Has Group Policy Preferences Coverage	Has MDM Settings Coverage
Data Sources	Yes	No
Printers	Yes	No
Drive Maps	Yes	No
Folder Options	Yes	No
Registry Settings	Yes	No
Services	Yes	No
Shortcuts	Yes	No
Scheduled Tasks	Yes	Yes (Partial)
Local Users and Groups	Yes	Yes (Partial)

Windows 10 MDM has a total void in these valuable setting categories. What about Scheduled Tasks? Well, you can schedule a reboot for your MDM-enabled devices in Intune, because there is a CSP called Reboot CSP. In other words, you can only create the few scheduled tasks for which there is a designated CSP. Of course in Group Policy Preferences, you have the freedom to create any scheduled task you want.

What about Security Settings, which you can see in the following image?

While Intune includes just as many Password settings as Group Policy, it has none in other categories.

Intune Settings

Category Name	# of Group Policy Settings	# of Intune Settings Settings
Password Policies	6	7
Account Lockout Policies	3	0
Kerberos Policies	5	0
Audit Policies	45	0
Security Settings	106	0

 

Windows 10 MDM doesn’t come close to the extensive coverage that Group Policy offers. With Group Policy, administrators can manage some 4,000 Windows 10 ADMX settings. Then, if you factor in Group Policy Preferences, which have around 10,000 unique combinations and settings, you’re up to about 14,000 Windows 10 ADMX settings.

The additional benefit of Group Policy Preferences is that it also provides a GUI interface that emulates the component you are configuring. A lot of the Windows 10 ADMX settings utilized by Group Policy are legacy settings from years ago, and MDM is only thinking forward. We can only assume that Microsoft will extend the clickable setting coverage of Intune and the coverage gap will close as time goes on.

Windows 10 MDM or Group Policy: Final Thoughts Summary

When contrasting MDM and Group Policy, there is no right or wrong answer. Group Policy continues to serve as a staple in the Domain Admin’s trusted tool kit. At the same time, MDM is drawing much interest, and rightly so, since so many organizations are choosing to host some of their devices, users, and applications in the cloud.

MDM is most definitely a useful tool that will play a more significant role as time goes on. However, MDM and Intune have definite limitations for the time being.

Those who are used to the extensive setting and feature coverage of Group Policy need to bridge the gap in some way. This action can be done the hard way with custom OMA-URIs and PowerShell scripts, or the easy way using PolicyPak MDM.

MDM and Intune are also not trying to solve some more significant, common Enterprise desktop management problems. For instance, removing local admin rights, managing multiple browsers and Java environments, as well as dealing with making a dynamic Start Menu or dealing with Windows 10 default file associations.

The good news is that it doesn’t have to an either-or scenario. We suggest you check out PolicyPak MDM Edition.

AD vs AADDS

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

 

Feature	AADDS	AD
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	Resource-based & account-based
Custom OU structure	✓	✓
Group Policy	✓	✓
Schema extensions	✕	✓
AD domain/forest trusts	✕	✓
Secure LDAP (LDAPS)	✓	✓
LDAP read	✓	✓
LDAP write	✓  (within the managed domain)	✓
Geo-distributed deployments	✕	✓

AADDS

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.

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

Azure Icon 

• Azure architecture icons
• Amazing Icon Downloader
• svg to png - https://ezgif.com/optimize

References

• Compare Active Directory to Azure Active Directory
• What are the Differences Between Azure Active Directory and Azure Active Directory Domain Services?
• Tutorial: Join a Windows Server virtual machine to an Azure Active Directory Domain Services managed domain
• Don’t Use Azure AD Domain Services to Replace Windows Domain Controllers