Device Management in Azure AD is required to ensure the devices connecting to the cloud services are meeting the Company Security and Compliance Standards. If you have On-Premise Active Directory, computers related to that company are joined to that AD and administrators will have control to those AD joined devices like pushing group policies etc.
Joining a Computer to Azure Active Directory is similar to joining a computer to local active directory. Difference is Azure AD is in Cloud and when joining a machine to Azure AD, it provides additional capabilities like Single Sign On experience when accessing the applications and we can restrict access to those devices based on the Azure AD Join status using Azure Conditional Access.
Device Join to Azure Active Directory are three types:
- Hybrid Azure AD Join: Device joined to On-Premise Active Directory and Azure Active Directory.
- Azure AD Join: Device joined directly with Azure AD (not On-Premise AD Domain joined)
- Azure AD Registered (Workplace Join): Device registered with Azure Active Directly like Windows 10 Personal and Mobile Devices.
During the Azure conditional access validation, all the above devices joined to azure are considered as domain joined devices and the respective settings will be applied.
Hybrid Azure AD Join in Windows 10
Windows 10 Device Registration process explained as
- Group Policy pushed to the machine starts the device registration with Azure AD
- Windows Device will query AD to get the information about the Azure AD Tenant
- Windows Device authenticates itself to Azure AD via ADFS to get a token for device registration
- Windows Device generates key pairs used for device registration
- Windows Device registers with Azure AD via Azure Device Registration Service.
Below the detailed explanation on how the Hybrid Azure AD Join works
We need to configure few things for Hybrid Azure AD Join to work properly like AD Connect deployment, Group Policy pushing and ADFS Issuance Transformation Rule etc… those prerequisites configuration steps not explained here. We will assume those are already set and will see the flow on how the Azure AD Join working in Windows 10 Machine.
- Group policy pushed to Windows 10 clients, which creates a task for the device registration to work and the task will be triggered.
- Windows 10 client queries AD (Service Connection Point object) which has the details about the Azure AD tenant to which the client has to connect. Azure AD Connect deployment will create those objects. I have highlighted the path for reference on the diagram.
- Azure AD Tenant information like the Azure AD name and the ID will be sent to Windows 10 Client.
- A hidden Internet browser is launched and the OAuth code authentication request is sent to Azure AD
- Azure AD redirects the client to authenticate with ADFS
- Client will reach ADFS by sending the computer account as identity, using Windows Integrated Authentication. Note: If the device is in Internet, then the authentication will fail because the WAP server will have form based authentication and you won’t know the prompt in hidden browser to authenticate.
- ADFS validates the computer identity with AD
- After the successful authentication, AD send the claim details to ADFS
- ADFS send a token along with 3 claims to Windows client, which the device will sent it to Azure AD for successful authentication
- Client sends the token along with 3 claims about the device received from ADFS to Azure AD
- Azure AD trust the token from ADFS server as it is already integrated and send a final token to Client for Azure Device Registration
- Device creates a Private/Public key pair to be used in a certificate-signing request from Azure DRS, to obtain the certificate that the device will use to authenticate to Azure AD later on. In addition, the task generates a second private/public key pair that is later used to bind the Primary Refresh Token (PRT) to the physical device upon authentication.
- Task send the Certification Signing Request along with final token received from Azure AD to Azure Device Registration Service.
- Azure DRS authorize the token, create a certificate, creates a Device object with its certificate thumbprint and return the certificate to the client.
- Client stores the certificate in the User My Store.
If you see above, the device registration is successful. For the Single Sign-On experience in Windows 10, the Primary Refresh Token will be received from Azure AD.
User sign-in to client using his credential, the Cloud Authentication Provider plug-in in windows client authenticates with Azure AD and ADFS, to obtain the Primary Refresh Token. Cloud Authentication Provider knows the Azure AD and ADFS details from the cache available during the Device Registration. Cloud AP plugin will directly send the credential to ADFS and get the SAML token and present it to Azure AD for authentication, Azure AD authenticates it and build a PRT with both User and Device claims and it will return to Window device.
I hope this is informative and you like it. Please comment for any clarification.