In this post I will cover how you can enable your Windows 7/8.1 and Server 2008 R2/2012/2012 R2 computers to participate in Azure AD conditional access. Domain joined computers must register with Azure AD for meeting device-based conditional access policies like “require domain joined device (hybrid Azure AD)” for protecting access to Office 365, SaaS apps, or on-premises apps published through the Azure AD application proxy.
Both federated and non-federated organizations can register their domain joined computers. Until recently, only federated configurations were able to do it, but now non-federated (i.e. without an on-premises STS like AD FS for authentication to Azure AD) can do it as well via Azure AD Seamless SSO and an up-to-date version of the Windows Installer package (.msi) to support non-Windows 10/Server 2016 device registration.
For more information on how to configure domain joined devices for Azure AD conditional access see how to configure hybrid Azure AD joined devices.
The Windows Installer package (.msi), the task and AutoWorkplaceJoin.exe
You need to deploy the package to your Windows 7/8.1 domain joined computers (for example using System Center Configuration Manager). The package will install a task that you can see in Task Scheduler under Microsoft > Workplace Join.
The task will trigger upon user sign-in to Windows (i.e. “At log on”) (and retry at 1 minute and 5 minutes if registration hasn’t succeeded before) and unlock. The task will trigger if network is available.
When the task triggers, it runs the tool AutoWorkplaceJoin.exe under %SystemRoot%\Microsoft Workplace Join. This tool will do the following:
- Queries AD on-premises to get the tenant domain name to be used for discovery. It does this by querying the AzureAdName value in the keywords attribute of the Service Connection Point (SCP) object in the following location (please note that this is the object that is also used in the Windows 10 case):
CN=62a0ff2e-97b9-4513-943f-0d221bd30080,CN=Device Registration Configuration,CN=Services,[Your Configuration Naming Context]
- Gets the authorization and token URLs plus registration service information (URL and identifier of Azure Device Registration Service or Azure DRS) by sending a request to the discovery end-point in Azure DRS. This allows support for devices in organizations in specific clouds (e.g. government clouds). If the AzureAdName value is contoso.com the request would look as follows:
- Launches a hidden Internet Explorer browser window and navigates to Azure AD requesting an OAuth code to then request an access token to Azure DRS using the information obtained from the discovery payload:
GET https://login.microsoftonline.com/contoso.com/oauth2/authorize ?response_type=code &client_id=dd762716-544d-4aeb-a526-687b73838a22 &resource=urn:ms-drs:enterpriseregistration.windows.net &redirect_uri=ms-app://windows.immersivecontrolpanel/ &domain_hint=contoso.com
- Sends the OAuth code to the token end-point (obtained from discovery) to get an access token to Azure DRS.
- Sends a request to Azure DRS (URL obtained from discovery) with token obtained to perform device registration.
Now, depending on whether the Azure AD configuration is federated, or non-federated with Seamless SSO enabled, the process of obtaining the OAuth code (step #3) will vary.
Authentication for registration using AD FS (federated)
The following illustrates how authentication works in a federated configuration through AD FS when registering the device with Azure AD.
- User signs in to Windows and task runs. A hidden Internet Explorer browser is launched and the OAuth code authentication request is sent to Azure AD.
- Azure AD redirects browser to AD FS via an HTTP 302 Found response. The browser will authenticate to AD FS using Integrated Windows authentication. Given the resource_params parameter passed in the authentication request, a successful Integrated Windows authentication will be treated as a strong one (i.e. multi-factor authentication or MFA). This is to meet the Azure AD policy for device registration which by default requires MFA. The value of the resource_params parameter contains the following value in an encoded string:
Please note that AD FS must have configured a particular issuance transform rule to include in the token the wiaormultiauthn claim. For more information on the claim needed see how to configure hybrid Azure AD joined devices.
- The browser sends the SAML assertion up to Azure AD. Azure AD accepts it as valid for registration as the following claims are present:
- Azure AD authenticates the user with the SAML assertion received and returns the OAuth code to the client. The client goes back to Azure AD to get an access token to Azure DRS passing the OAuth code obtained.
- The client goes to Azure DRS with the access token obtained to do device registration.
Authentication for registration using Azure AD Seamless SSO (non-federated)
The following illustrates how authentication works in a non-federated configuration through Azure AD Seamless SSO when registering the device with Azure AD.
- User signs in to Windows and task runs.
- A hidden Internet Explorer browser is launched and the OAuth code authentication request is sent to Azure AD.
- Azure AD, knowing that Seamless SSO has been enabled, will return an HTTP 401 Unauthorized message with the header WWW-Authenticate as Negotiate, just as any web application using Integrated Windows authentication would do.
- The client will reach out to AD on-premises to get a Kerberos ticket to the Azure AD HTTP Service Principal Name (SPN). It uses the current user context to obtain the token silently.
- The client replays the authentication request to Azure AD but this time with the Kerberos ticket in the Authorization header.
- Azure AD can validate the Kerberos ticket as it has the “service account” secret for the corresponding SPN in AD on-premises. After authentication it will return the OAuth code to the client. The client goes back up to Azure AD with the OAuth code to the token end-point to get an access token to Azure DRS.
- The client goes to Azure DRS with the token obtained to do device registration.
If you have read through the Azure AD Join: What happens behind the scenes and How Domain Join is different in Windows 10 with Azure AD posts you would have learned how device registration works in Windows 10. You will notice that the mechanisms used for registration are very similar:
- The client generates a private/public key pair and sends a Certificate Signing Request with the public key to Azure DRS along with the access token obtained.
- Azure DRS authorizes the token, creates a certificate, create a device object with its the certificate thumbprint associated to it and then returns the certificate to the client.
- The client stores the certificate in the user MY store.
Windows 10 in addition generates a key that will be used to protect the SSO token obtained during user sign-in to Windows (i.e. Primary Refresh Token). This doesn’t happen on the Windows 7/8.1 case. For more information see how SSO works in Windows 10 devices.
After the device has been registered, every request for authentication to an application protected with Azure AD device-based conditional access policies, will trigger device client TLS authentication which will allow the device to present the certificate to Azure AD. Azure AD will look for a corresponding device object and authenticate/authorize it for access appropriately. Please note that Windows 10 doesn’t use client TLS for device authentication. For more information see how SSO works in Windows 10 devices.
Alright, that’s it for this post. Thanks for your interest in bringing your devices to Azure AD for device-based conditional access and other cool capabilities. Please let me know if you have any questions or comments.
See you soon!
Jairo (Twitter: @JairoC_AzureAD)
Great write-up Jairo!!
LikeLiked by 1 person
does this solution work with PTA? Or is it meant for AD FS and Password Sync scenarios only?
Hi Jose, yes it does. It works fine with PTA as well. Please let me know if you find any issues with it.
Does it work with PTA?
I have been trying to get my head over this but doesnt seem to be working.
I have the MSI for non windows 10 devices installed on a windows 7 machine, and the event log gives me the error: Auto workplace error: Error message: Navigation failed upon URI:…..
The registration service could not succesfully authenticate your account.Please make sure you are logged in with your active directory domain account and try again.
i also noticed the following:
Step 3 says:
I logged into the windows 7 Device, launched fiddler and let it sit so that i can capture the re-attempts at minute 1 and 5.
I noticed something:
the get request on my side, does not have a domain_hint.
I tried accessing the url manually via the browser and it takes me to a sign in page and when i manually enter the credentials for the test user, it signs in and shows an empty page.
This is the error from the event viewer on the windows 7 machine
The registration service could not successfully authenticate your account. Please make sure you are logged in with your Active Directory domain account and try again. Registration service authentication url: https://login.microsoftonline.com/12e60d43-9671-4bc1-9e84-30ee5c04fac5/oauth2/authorize?response_type=code&client_id=dd762716-544d-4aeb-a526-687b73838a22&resource=urn:ms-drs:enterpriseregistration.windows.net&redirect_uri=ms-app%3a%2f%2fwindows.immersivecontrolpanel%2f&domain_hint=msspon.onmicrosoft.com&msafed=0&resource_params=eyJQcm9wZXJ0aWVzIjpbeyJLZXkiOiJhY3IiLCJWYWx1ZSI6IndpYW9ybXVsdGlhdXRobiJ9XX0
Wondering if this information helps in finding the problem.
Sorry for spamming your blog… lol
I just got a fix… It was the domain hint that was giving the problem.
When i created the service connection point on the test environment, ,my user logins were not federated to the ad domain name was domain.onmicrosoft.com.
Created a new SCP for domain.com and the hidden IE session routed like it was supposed to with the correct domain hint.
Wow.. that took me hours of looking into event logs!
Hi, i am having the same issues as well. The AzureADName is pointed to domain.onmicrosoft.com when i initialize the domain from the Azure AD Connect. Did you create another SCP for each domain? I was under the impression that pointing the SCP to domain.onmicrosoft.com should be enough.
Does this mean if we have multi domain in a single tenant, we should be creating multiple SCP?
I am not too much of an expert on this, but how is the federation setup for these multiple domains of yours?
Also as per :
“Step 1: Configure service connection point
The service connection point (SCP) object is used by your devices during the registration to discover Azure AD tenant information. In your on-premises Active Directory (AD), the SCP object for the hybrid Azure AD joined devices must exist in the configuration naming context partition of the computer’s forest. “There is only one configuration naming context per forest. In a multi-forest Active Directory configuration, the service connection point must exist in all forests containing domain-joined computers.”
Hi Jairo, quick question! If I enable the AAD option “Require MFA to join devices”, I would expect the scheduled task to fail, but it still works. How is that possible?
Hi Jairo, will down-level device registration fail on step #3 if the user is enforced to setup MFA via AAD Conditional Access policy or AAD Identity Protection? Company has Seamless SSO configured.
Pingback: Conditional access and Windows 7 domain joined devices – More than just ConfigMgr