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.
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.
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:
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.
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”.
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”.
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.
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.
You can use the following resources:
Here are some common reasons why Conditional Access may be failing.
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 3rd 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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.