When it comes to managing Windows 10 devices, it is important to consider the Identity relationship of that device. It is a topic that is often quickly glossed over where there are many assumptions which can lead to confusion, especially when terms like “hybrid” start getting mixed into the conversation. Here’s a relationship grid that I hope helps.
From the left are three identity relationship types that a “Company Owned” Windows 10 device could have. A device can only be in one of these states.
From the top are three methods of management that could be used. A device can only be in one of these states.
Any particular device will fit into just one region of this grid, but each organization can have different devices that are in different regions. For example, some devices might be in A1, and some others may be in C3, while yet others may even be in B2 or C2. Devices can be deployed and managed in whatever way you feel is appropriate for it’s use case.
The above text was initially all I intended to post, but as I started to share the chart, it spawned a lot of conversation that frankly demanded more details, so I decided to expand on the topic below. Each section below is just a cursory explanation of related topics, but hopefully it helps!
The combination of Device Identity and Device Management options provides different levels of capability and complexity. Let’s briefly explore each region of this grid.
When talking about Company Owned devices, a Windows device Identity will only be in one of these Joined states:
- AD Domain Joined
- Hybrid Joined
- Azure AD Joined
There are many other states that the identity of a Windows device could be in, such as WORKGROUP joined or even Azure AD Registered, but those would be more appropriate for Personal devices. In this post, we’ll focus on Company Owned Windows Devices.
Active Directory Domain Joined
AD Domain Join is what most organizations already know and use today, where the devices are “Joined” to a Windows Active Directory Domain.
A Computer account is created in AD, and Windows uses authentication protocols like Kerberos to authenticate and access network resources and the likes of AD Group Policy Objects (GPOs).
A Domain Joined computer requires network line of sight to an AD Domain Controller as it uses UDP/88 (among others) which is considered to be a non-Internet friendly transport. This was typically not an issue when computers were desktop machines that stayed at the office, but with laptops and mobility becoming more the norm, connecting these remote devices back to the corporate network is necessary so they can interact with Domain Controllers. Many organizations would implement client VPN solutions to tunnel traffic over a secure channel like SSTP/PPTP/L2TP and so on to accommodate this dependancy.
Azure Active Directory Joined
Another option for Windows 10 is is to be Azure AD Joined where the device establishes an identity relationship only with AAD.
This has no relationship with, nor a dependency on Windows AD. It also does not use protocols like Kerberos. Instead, Azure AD uses more Internet-friendly, claims-based, modern authentication protocols like OpenID Connect and OAuth 2.0, and the device is issued a certificate from Azure AD.
This means AAD Joined devices do not require a network tunnel to the corpnet because they do not need to interact with a Domain Controller. Instead, they are able to perform authenticate over an HTTPS/TLS tunnel directly to Azure AD.
Keep in mind that the user account in AAD is usually synchronized with an account that exists in AD using Azure AD Connect. When the User Principal Name (UPN) of the AAD user who is signed in to the device matches the UPN of their account synced in AD, Windows is able to obtain a Kerberos ticket when accessing corporate resources. This mean Windows Authentication can still provide SSO to corpnet resources even when using an AAD Joined device. The device identity typically has nothing to do with permissions on file shares or on-prem applications. So user actions or user access to company resources are often unaffected by the device not being Domain Joined.
Technical Deep Dive: Azure AD joined in Managed environments
When a device is Domain Joined, it can also be Registered with Azure AD, and this is what’s referred to as “Hybrid Joined.”
To restate, this device is first Domain Joined and then is Registered with AAD (it is technically not AAD Joined despite what dsregcmd says). As mentioned earlier, “AAD Registration” is normally used for personally owned / BYOD devices, but because this device already has an identity relationship with the corporate Active Directory, we can use Azure AD Connect to correlate the AD Joined computer object with the AAD Device object, and issue the device a certificate from Azure AD, similar to (but different from) the AAD Joined scenario.
A Hybrid Joined device carries the same dependencies on AD as a normal Domain Joined device, so solutions like VPN are often still required for mobile or remote workers, but the Registration with AAD enables new management capabilities, security controls and Web SSO for users. It is a very good thing to do for existing devices that are already Domain Joined.
Technical Deep Dive: Hybrid Azure AD joined in Managed environments
Since we’re covering Company Owned devices, and not personally owned or “BYOD” scenarios, this means a user will log in to Windows using an account that is provided by the Organization (they are not using a Local Account, nor an MSA). This user “corporate account” for Windows will exist in Active Directory (AD) or Azure AD.
|When Windows is…||the User logs in with an…|
|AD Domain Joined||Active Directory account|
|Hybrid Joined||Active Directory account|
|Azure AD Joined||Azure AD account|
For the company administrators, this distinction of where the user identity resides can be important, but for the end-user, it should make no difference. They’ll simply use the single company credential that they know, regardless of them technically authenticating against AD or AAD thanks to AAD Connect keeping the two in sync. This is how the overloaded term “SSO” comes in to play, and you can read more about SSO to on-premises resources in the docs, but suffice it to say that access to corpnet resources continues to work for AAD users.
But let’s stay with the Devices for now…
Managing Windows devices has traditionally been done with an agent like ConfigMgr, but Windows 10 can also be managed using the Mobile Device Management protocol (MDM). This allows solutions like Intune to manage Windows without the need to install an agent. Today, ConfigMgr and Intune are both components of a single product called Microsoft Endpoint Manager (MEM) which enables management with an Agent and/or MDM. You choose what is right for your needs.
Once managed, the device settings can be configured, configuration state and compliance can be reported on, applications can be installed, software updates can be managed, and the list goes on an on an on.
Group Policy (Active Directory)
Device Management is often coupled with the use of Group Policy Objects (GPOs) and Organizational Units (OUs), but since these are components of Active Directory, the concept of Group Policy is really tied to the identity relationship of the device, and not the management of it. That is to say, GPOs are technically available to Domain Joined (or Hybrid Joined) devices, but not to an Azure AD Joined device.
In practice however, Group Policy settings are typically just a series of Windows Registry Keys, and you can set these values using the management tool of your choosing. You can therefore apply a Group Policy setting without technically using Group Policy itself.
You can look up a policy setting and find the key it configures. You can read the .ADMX files in Notepad from the Windows 10 Administrative Templates which defines the Keys and their possible value. You can even create your own ADMX templates, or download ADMX templates from third parties to use GPO to manage other application settings. Also, because GPO is really just registry keys, technically you don’t need to use Active Directory to apply “Group Policy” settings… just set the registry keys. This is what Active Directory is doing for you, so without AD, you can use agents or scripts, for example.
Agent Based Management (ConfigMgr)
Traditional agent-based management of Windows can be provided by Configuration Manager (ConfigMgr / SCCM) regardless of the Identity relationship of the device. This is because the management agent is simply installed on the device. The agent has complete control of the device because it runs in the SYSTEM context (it essentially is the device). This is regardless of the level of access that the signed-in user has.
Installing the agent is usually done as part of the device provisioning process but it can be done manually by an administrative user on the device, or it can also be done by Active Directory’s Software Installation policies, and a variety of other methods.
MDM Based Management (Intune)
Rather than installing an Agent, Windows 10 can be enrolled into MDM management with Intune.
This Enrollment can be done manually by a user from the Settings app, but devices can Enroll automatically when Azure AD Joining. Similarly, an AD Group Policy can automatically enroll Hybrid Joined devices for Intune management as well.
Co-Management (Agent and MDM)
ConfigMgr and Intune can be used at the same time in what is referred to as Co-Management. There are two paths that a device could take to become co-managed, and they are basically dependent on if the devices are already deployed or if you are deploying new devices.
Existing devices must have established a relationship to Azure AD, usually Hybrid Joined, and then use existing management tools like ConfigMgr to also enroll in Intune.
For new devices, deployment can use the traditional Domain Join/Hybrid Join Operating System Deployment process which installs ConfigMgr which then also enrolls in Intune. But another option exists to deploy using Autopilot, which can also deploy a Hybrid Joined device, but it can also deploy an Azure AD Joined device. In either case, Autopilot will first enroll the device in Intune to manage the device with MDM, and then can install the ConfigMgr agent to establish co-management.
Configuration Manager can also enroll devices into Intune management (if they are Hybrid Joined).
Cloud Management Gateway (CMG)
When managing a device with ConfigMgr, either by itself or when Co-Managed with Intune, the agent must be able to interact with various ConfigMgr infrastructure services. Historically, this meant the device needed to be on the same network as the ConfigMgr servers or use VPN so the agent could interact with the Management Points, Distribution points, etc.
Today, the Cloud Management Gateway (CMG) can be deployed to provide an HTTPS tunnel for the ConfigMgr Agent to access these components. This means the device does not need to be on the same network, nor be on VPN in order to be managed with ConfigMgr or report it’s status.
The CMG uses Azure Cloud Services to host the Virtual Machine that is the Cloud Management Gateway, but communications is secured using certificates that are issued to the devices either from internal PKI, or by self-signed certificates generated by ConfigMgr. Domain Joined (or Hybrid Joined) clients can use Token based Authentication when using ConfigMgr 2002 or later instead of using Client certificates. Azure AD Joined devices have always been able to use Tokens and don’t need to be issued certificates to authenticate with the CMG, but the can use Certificates if that is desired.
To clarify, Intune is not required to use the CMG. More specifically, Co-Management with Intune is not the purpose of CMG. The CMG is for the ConfigMgr Agent. It provides a means for the ConfigMgr Agent to connect to the ConfigMgr services, and it does so without needing to connect the device to the same network where ConfigMgr is located.
If you made it this far, well, thank you. That was a lot to try an summarize in a single post, but hopefully it sheds light on the relationships between a device identity and ways you might manage it.