I’m a simple person, and sometimes it just helps to have a checklist to refer to when you’re troubleshooting rather than navigating the sparse pages of docs.microsoft.com. In this blog, I explain the prerequisites for the Hybrid Azure AD Join (HAADJ) + automatic (GPO controlled) Intune MDM enrollment scenario and the process from start to end, as simply and concisely as I can (not easy!) There are no screenshots and it’s not a click-by-click: this is a quick reference for when you’re pulling your hair out wondering what could be stopping you.
Hybrid Azure AD Join Checklist (Prerequisites)
- On-prem Active Directory (obviously)
- Joining computer has a line of sight to a domain controller
- Azure AD Connect
- The OU the computer belongs to must be included in sync scope
- The userCertificate attribute must be included in sync scope
- You must enable HAADJ within Azure AD Connect settings which configures on-prem Active Directory with a Service Connection Point (SCP) per forest
- The SCP properties contain details of your Azure AD tenant, so computers know which to go to
- You can find the SCP in ADSI Edit’s Configuration Naming Context under Services\Device Registration Configuration, under an attribute called keywords.
- You don’t need Seamless SSO configured because when the device becomes HAADJ, Azure AD issues Primary Refresh Tokens (PRTs) for SSO, instead of Seamless SSO’s Windows Integrated Auth
- You don’t need the user to sync to Azure AD for HAADJ as the device registers using a computer object credential, but you will need a synced (licensed) user for Intune
- The Azure AD devices setting Users may join devices to Azure AD can be set to none as the device join to Azure AD is done by the device, not the user. But note this setting may have unintended consequences, such as Azure AD Join during Autopilot.
Intune MDM Enrollment Checklist (Prerequisites)
- Device is Hybrid Azure AD Joined
- Device is Windows 10 1709+
- You may see some information that 1703 works. I have found that although the GPO applies to 1703 and you’ll see the MDM URLs against the device in dsregcmd /status, it doesn’t actually work. When you look in Azure AD, you won’t see a registered MDM, and the device won’t show in Intune either.
- User is synced to Azure AD
- You can sign in with the sAMAccountName or User Logon Name (UPN) as long as the user is properly synced – you don’t need to sign in using the Azure AD address
- User is licensed to Intune
- User is licensed to Azure AD Premium P1 (required for auto-enrollment)
- User is within scope for MDM automatic enrollment, configured in Azure AD > Mobility (MDM and MAM)
- Make sure it’s Intune and not Intune Enrollment if you have the choice
- MDM URLs within Mobility (MDM and MAM) are configured to Intune
- User is within scope to join devices to Azure AD within Azure AD > Devices – Device Settings > Users may join devices to Azure AD
- The number of devices they’re allowed to join, configured in this same page, is also important – if it’s exceeded, they won’t enrol
- The GPO Computer Config\Policies\Admin Templates\Windows Components\MDM\Enable Automatic MDM Enrollment Using Default Azure AD Credentials is scoped to devices using User Credential
- I have never got Device Credential to work with the GPO, testing Windows 10 versions up to 1903, but some report success. I kept getting Device based token is not supported for enrollment type errors in Event Viewer.
- Windows (MDM) is allowed in Intune > Device enrollment – Enrollment restrictions
The Process – Part 1 – Hybrid Azure AD Join
- The computer joins on-prem Active Directory
- The computer retrieves the SCP (tenant) information from Active Directory
- This is achieved by a Task Scheduler entry within \Microsoft\Windows\Workplace Join called Automatic-Device-Join which runs whenever there’s a login.
- You may find this task is disabled on older versions of Windows 10. At least, I found it disabled on Windows 10 version 1511. You need to enable and assign a Group Policy to enable it: Computer Config\Policies\Admin Templates\Windows Components\Device Registration\Register domain joined computers as devices.
- The computer generates its self-signed userCertificate attribute and stores it in Active Directory (and can be found in Active Directory Users & Computers property page in the Attribute Editor tab)
- This step is not required in an ADFS environment
- If the above Task Scheduler entry didn’t run or isn’t enabled, you won’t get a userCertificate, and your computer won’t sync to Azure AD
- The computer begins trying to register with Azure Active Directory and continues to do until it succeeds
- It can only do so after the object has been synced by AAD Connect so may be delayed depending on the sync cycle
- You can force a sync on the AAD Connect server using Import-Module ADSync then Start-ADSyncSyncCycle -PolicyType Delta
- It won’t sync if the userCertificate isn’t yet stored in Active Directory
- It can only do so after the object has been synced by AAD Connect so may be delayed depending on the sync cycle
- Azure AD issues a Primary Refresh Token (PRT) to users who log in for AAD authentication.
- Azure AD issues an MS-Organization-P2P-Access certificate to the local computer (certlm.msc) in AAD Token Issuer\Certificates. This certificate manages two additional certificates in Local Computer\Personal\Certificates and Current User\Personal\Certificates. These are all for facilitating remote desktop (RDP) connections to computers joined to the same tenant.
The device is now Hybrid Azure AD Joined. You can confirm this by looking at the object in the Azure AD devices list or using dsregcmd /status on the client, where AzureAdJoined within Device State is YES and AzureAdPrt within SSO State is YES.
The Process – Part 2 – Intune MDM Enrollment
- At next GPO refresh, the device receives and applies the GPO from Active Directory
- As this could be at the first login, it may happen before the device is HAADJ due to sync cycle and userCertificate timing – in such a case, MDM enrollment will fail (but keep trying; see below)
- The device does not need to reboot for the GPO and subsequent steps to apply
- If you have MFA enabled, users will be prompted via a toaster notification; if you don’t, it’s completely transparent
- A Task Scheduler entry for Schedule created by enrollment for automatically enrolling in MDM from AAD is created to run once every five minutes for one day
- This runs deviceenroller.exe /c /AutoEnrollMDM which then enrols the device into Intune MDM
- The above Task Scheduler entry is removed and replaced by many more for things such as certificate renewal
The device is now Intune MDM enrolled. You can confirm this by going to Settings > Access work or school > [account] > Info and confirming the Management Server Address within Connection info is r.management.microsoft.com. You can also check dsregcmd /status, looking for the appropriate URLs against MdmUrl and MdmtoURL under Device State.