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:

1. 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]

2. 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:

   GET https://enterpriseregistration.windows.net/contoso.com/EnrollmentServer/Contract?api-version=1.2

3. 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

4. Sends the OAuth code to the token end-point (obtained from discovery) to get an access token to Azure DRS.
5. 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.

1. 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.
2. 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:

   {"Properties":[{"Key":"acr","Value":"wiaormultiauthn"}]}

   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.

3. The browser sends the SAML assertion up to Azure AD. Azure AD accepts it as valid for registration as the following claims are present:

   http://schemas.microsoft.com/ws/2008/06/identity/authenticationmethod/windows
   http://schemas.microsoft.com/claims/wiaormultiauthn

4. 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.
5. 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.

1. User signs in to Windows and task runs.
2. A hidden Internet Explorer browser is launched and the OAuth code authentication request is sent to Azure AD.
3. 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.
4. 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.
5. The client replays the authentication request to Azure AD but this time with the Kerberos ticket in the Authorization header.
6. 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.
7. The client goes to Azure DRS with the token obtained to do device registration.

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:

1. 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.
2. 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.
3. 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.

Device authentication

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)