Azure AD Mailbag: Frequent questions about using device-based Conditional Access for remote work

This post has been republished via RSS; it originally appeared at: Azure Active Directory Identity Blog articles.

Greetings! We're back with another mailbag, this time focusing on your common questions regarding device-based Conditional Access scenarios. We’ve heard from so many of you over the past few months on new challenges you’ve faced keeping your remote workforce secure, and that Conditional Access has been a key component to achieve the right control. We’ve received some great feedback on our last Conditional Access best practices blog, so if you’re still working through finetuning your Conditional Access policies in your environment, go check that out and come back here where Teppei will help you deep dive on how to better secure your device access.

---

Hi there,

I’m Teppei Yamashita from the Azure Active Directory (Azure AD) Get-To-Production team and also a part of Azure AD Devices team. Lately, we’re seeing more customers implementing device-based Conditional Access (a way of configuring Conditional Access policy) and Hybrid Azure AD Join to enable secure remote work. Our Azure AD Devices team would like to share best practices and tips that we’ve assembled while working closely with customers.

Question 1: Why is device-based Conditional Access and hybrid Azure AD join important?

These capabilities help IT and security admins make sure that every access request to the applications connected to Azure AD are coming from trusted devices. Hybrid Azure AD joined devices are “trusted devices” as it’s assumed that the control is enforced using management solutions such as Configuration Manager or Group Policy. It’s a great way to extend existing on-premises investment to the cloud.

Question 2: How do I configure a device to be hybrid Azure AD joined?

There are differences in prerequisites depending on the authentication methods (federated or cloud authentication) in your environment. To configure a device as hybrid Azure AD joined, please refer to the following tutorials:

• Configure hybrid Azure Active Directory join for managed domains - commonly referred to as Sync Join
• Configure hybrid Azure Active Directory join for federated domains - commonly referred to as Federated Join
• Controlled validation of hybrid Azure AD join helps those organizations who want to do a controlled validation of hybrid Azure AD join before enabling it across their entire organization all at once.
  
  

Question 3: How do I configure device-based Conditional Access?

There are 2 types of “Grant” controls to enable device-based Conditional Access.

Require Hybrid Azure AD joined device 

In your Conditional Access policy, you can select Require Hybrid Azure AD joined device to state that the selected cloud apps can only be accessed using a hybrid Azure AD joined device. For more information, please refer to this document.

Require a device to be marked as compliant 

For better security, we recommend every organization to consider the option Require a device to be marked as compliant. This will require devices to be compliant with the Mobile Device Management (ie. Intune) policies. For more information, please refer to this document.

Question 4: How does the hybrid Azure AD join registration process work? Does it work over VPN?

The hybrid Azure AD join registration process requires devices to be on corporate network. It also works over VPN but there are some caveats to that. We’ve heard customers needing assistance with troubleshooting the hybrid Azure AD join registration process under remote work circumstances. Here’s a breakdown of what’s happening ‘under the hood’ during the registration process.

Cloud authentication environment (using Azure AD password hash sync or pass-through authentication)

This registration flow is also known as “Sync Join”.

1. Windows 10 discovers SCP record upon user logging on to the device.
   
   1. The device first tries to retrieve tenant information from client-side SCP in registry [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\CDJ\AAD]. For more information, please refer to this document.
   2. If it fails, the device communicates with on-premises Active Directory to get tenant information form Service Connection Point (SCP). To verify SCP, please refer to this document.
      
      Note: We recommend enabling SCP in the Active Directory and only using client-side SCP for initial validation.
      
      
2. Windows 10 tries to communicate with Azure AD under the system context to authenticate itself against Azure AD.
   
   You can verify if the device can access Microsoft resources under the system account by using the Test Device Registration Connectivity script.
   
   
3. Windows 10 generates self-signed certificate and store it under the computer object in on-premises Active Directory. This requires line-of-sight to Domain Controller.
   
   
4. Device object that has certificate gets synchronized to Azure AD via Azure AD Connect. Sync cycle is every 30 minutes by default, but it depends on configuration of Azure AD Connect. For more information, please refer to this document.
   
   
5. At this stage, you should be able to see the subject device in “Pending” state under Device blade of Azure Portal.
   
   
6. At the next user login to Windows 10, the registration will be completed.
   
   Note: if you're on VPN and logoff/login terminates the domain connectivity, you can trigger registration manually:

Issue a dsregcmd /join locally on admin prompt or remotely via PSExec to your PC

For example: PsExec -s \\win10client01 cmd, dsregcmd /join

Federated domain environment (using AD FS or other WS-Fed/WS-Trust capable IdPs)

This registration flow is also known as “Federated Join”.

1. Windows 10 discovers SCP record upon user logging in to the device.
   
   1. The device first tries to retrieve tenant information from client-side SCP in registry [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\CDJ\AAD]. For more information, please refer to this document.
   2. If it fails, the device communicates with on-premises Active Directory to get tenant information form Service Connection Point (SCP). To verify SCP, please refer to this document.
      
      Note: We recommend enabling SCP in the Active Directory and only using client-side SCP for initial validation.
      
      
2. Windows 10 tries to communicate with Azure AD under the system context and get redirected back to WindowsTransport endpoint of Federation service such as ADFS to authenticate itself. This process needs to be done on corporate network and it works over VPN.
   
   Warning: Both adfs/services/trust/2005/windowstransport and adfs/services/trust/13/windowstransport should be enabled as intranet facing endpoints only and must NOT be exposed as extranet facing endpoints.
   
   Note: If you're using a 3^rd party identity provider, please check with them about supporting hybrid Azure AD join.
   
   

3. If #2 fails for some reasons, and if your device is on Windows 10 1803 update or above, it will fall back to registration flow described under steps #3-5 above Sync Join flow.
   
   Note: If you don’t have Azure AD Connect setup to sync your devices, your registration doesn’t fall back to the Sync Join flow. So, we recommend that you sync devices through Azure AD Connect regardless of your environment. For more information, please refer to this document.
   
   

4. If there are any connectivity related issues to AD FS, the device registration is re-initiated at the next user login to Windows 10 to complete the registration. 

    

   Note: if your VPN requires additional authentication and logoff/logon terminates the domain connectivity, you can trigger device registration manually by running the following command remotely via PSExec to the user's device.
   For example: PsExec -s \\win10client01 cmd, dsregcmd /join

Tips: If you have issues with enabling VPN for remote users, we also recommend you consider Azure AD join instead of hybrid Azure AD join. This option is especially good for new Windows 10 devices. There are several considerations, for example, device management for Azure AD joined devices are provided via MDM (Mobile Device Management) like Intune instead of Group Policy. To decide if this model fits with your organization, refer to this Azure AD join planning guide.

Question 5: Can I use Sync Join in a federated environment?

Yes, you can. However, Sync Join can be slower than Federated Join as the device object needs to be synchronized from Active Directory to Azure AD. To use Sync Join in Federated environment, we recommend you use a default domain name (i.e. contoso.onmicrosoft.com) as SCP record.

Question 6: How do I check if devices are properly hybrid Azure AD joined?

You can use the following resources:

• Verify registration with Hybrid Azure AD join in managed environments
• Verify registration with Hybrid Azure AD join in federated environments

Question 7: I’m getting blocked by Conditional Access saying my device is not domain joined even though my device is properly hybrid Azure AD joined. 

Here are some common reasons why Conditional Access may be failing.

1. There’s no Azure AD PRT on the device.

You need to make sure that the device has Azure AD Primary Refresh Token (PRT). To learn more about PRT, see this document.

To verify if you have Azure AD PRT, you can run “dsregcmd /status” command on the device and verify if “AzureAdPrt” equals “YES” (see below for a valid AzureADPrt section of dsregcmd output)

If AzureAdPrt is NO, check the following:

a. You have a federated environment with AD FS, and it’s unreachable from your users’ home networks. In this case, ensure that your usernamemixed endpoints are accessible from the extranet. If your AD FS is behind a VPN, make sure that the users connect to the VPN and re-login to the device. For more information, please refer to this document.

b. The device’s TPM is faulty and cannot authenticate the device. Check tpm.msc to see if the state of TPM is Ready. If not, run dsregcmd /leave and let the device re-join to Azure AD. Then, try again. For more information, please refer to this document.

c. You’re using a 3^rd party identity provider, which does not support WS-Trust protocol. As described in our docs, hybrid Azure AD join devices cannot work in this case. Please work with your Identity provider for support.

2. Users are using Chrome browser without the Windows 10 Accounts  or Office extension Chrome does not automatically use the PRT on AAD joined or hybrid AAD joined devices. As a result, any device-based Conditional Access policies will fail with “Unregistered device” error. To use Chrome browser correctly, you must install the “Windows 10 Accounts” or Office extension to the users’ Chrome browser via SCCM or Intune.

If it’s not possible to push the extension remotely, notify users to manually install one of the above extensions to access applications behind device-based Conditional Access. For more information, please refer to this document.

3. The device was correctly hybrid Azure AD joined, but it was inadvertently deleted or disabled, either due to sync changes in Azure AD Connect or from the Azure portal. If this happens, the device object is no longer recognized as a fully joined device even though the AzureAdJoined and PRT status show up as valid on the device.

To fix this issue, run dsregcmd /leave on the affected devices and let them rejoin to Azure AD. For more information, please refer to this document.

Note: if your devices are on Windows 10 1809 update, with VPN / Cloud Proxy and see issues with AzureAdPrt state or any app with SSO problem (outlook not connecting to mailbox even though you had PRT) please make sure you have this patch KB4554354 or April cumulative update KB4549949 to prevent PRT failures on those machines. 

We hope you find this information helpful as you enable secure remote work for your employees. Please let us know via Twitter (@AzureAD) or comment below if you have any other questions or ideas.