Late last year, Microsoft launched some new capabilities around Conditional Access, specifically for the Windows OS. Previously, Conditional Access policies were primarily focused around mobile devices.

While doing some testing, research and having a few discussions, I decided to dig a big deeper into the following setting that exists for both Exchange Online and SharePoint Online Conditional Access Policies:

Windows must meet the following requirements:

  • Devices must be domain joined or compliant
  • Devices must be domain joined
  • Devices must be compliant


Now on a mobile devices, this is pretty much a no-brainer. You’re either compliant or you’re not, and based on your compliance policies after enrollment, that dictates your access to the relevant resources.

Like so:


However, the context of this new setting, essentially says that compliance isn’t key, however if it is domain joined we’re good. A few questions come to mind:

  1. So does that mean that Windows PCs can access EXO/SPO without having to enroll in Intune?
  2. Does it mean Azure AD joined or domain joined?
  3. If a device isn’t enrolled, how is domain joined known?

Let’s go take a look at the TechNet article here and the flow diagram for Conditional Access


So it appears that the workflow above solves question 1:

Conditional Access policies DO apply to Windows PCs that are NOT enrolled in Intune.

Ok, great! So does it mean Azure AD domain joined or Enterprise PC domain joined?

Unfortunately the docs really aren’t that clear.

Again, let’s reference the TechNet page:

Office desktop applications can access Exchange Online and SharePoint Online on PCs running:

Conditional access to Exchange Online supports devices that run:

  • Windows 8.1 and later (when enrolled with Intune)
  • Windows 7.0 or Windows 8.1 (when domain joined)


  • Devices must be registered with the Azure Active Directory Device Registration Service (AAD DRS).

    Domain joined PCs must be automatically registered with Azure Active Directory through group policy or MSI. The Conditional Access for PCs section in this topic describes all the requirements for enabling conditional access for a PC.

    AAD DRS will be activated automatically for Intune and Office 365 customers. Customers who have already deployed the ADFS Device Registration Service will not see registered devices in their on-premises Active Directory.

Conditional Access for PCs

You can setup conditional access for PCs that run Office desktop applications to access Exchange Online and SharePoint Online for PCs that meet the following requirements:

  • The PC must be running Windows 7.0 or Windows 8.1.
  • The PC must either be domain joined or compliant with the compliance policy.
    In order to be compliant, the PC must be enrolled in Intune and comply with the policies.
    For domain joined PCs, you must set it up to automatically register the device with Azure Active Directory.
  • Office 365 modern authentication must be enabled, and have all the latest Office updates.
    Modern authentication brings Active Directory Authentication Library (ADAL) based sign-in to Office 2013 Windows clients and enables better security like multi-factor authentication, and certificate-based authentication.
  • Setup ADFS claims rules to block non-modern authentication protocols. Step by step instructions are detailed in scenario 3 – block all access to O365 except browser based applications.

Ok, a lot of information here, so let’s digest. Note that Windows 10 really isn’t documented well here!

I want to thank Jairo Cadena for some clarity as well here. Jairo does a great job walking us through the process here as well:

The trust type for AzureAD/AD is not dependent on an MDM and can use:

  • Azure AD Joined
  • Domain Joined
  • Workplace Joined

This attribute is set at registration time via the following methods:

  • Azure AD Join (Windows 10) -> ‘Azure AD Joined’
  • Auto-registration after Domain Join (Windows 7/8.1/10) -> ‘Domain Joined’
  • During Add Work or School Account in Windows 10 or Workplace Join in iOS, Android or Win8.1 personal devices -> ‘Workplace Joined’

It should be noted that compliance can be set by not only Intune but also 3rd party MDMs in Windows 10!

SCCM can also write compliance for domain joined devices.

The policy for ‘device must be domain joined or compliant’ is set to cover the case in which domain joined devices are given access (you trust domain joined devices due to the way these are deployed, already have a trust with AD on-prem, etc.) and non-domain-joined devices are given access only if they are compliant.

So back to our other 2 questions:

  1. Does it mean Azure AD joined or domain joined?
  2. If a device isn’t enrolled, how is domain joined known?

Auto-registration with Azure AD on domain joined devices relies on Integrated Windows Authentication (IWA) via AD FS using the logged-on user account in Windows 7/8.1 or using the computer account in Windows 10. AD FS will issue a claim stating that auth happens using IWA.

For Windows 10 in particular there are three other claims in play.

Also Windows 10 supports auto-registration of DJ devices for password sync’ orgs (non-federated).

I absolutely learned something new today and hopefully so did you! Some fantastic information here on how Conditional Access works behind the scenes and where Intune is really a step ahead of so many other competitors with how they handle Conditional Access. Having the power of Azure Active Directory behind the solution really makes it a step above the rest!

  1. Found a huge gotcha on this. Looks like conditional access has been ignoring the Outlook Desktop Apps until you enable “Modern Auth” on Exchange Online. As soon as I did this all access to Exchange Online was blocked for Outlook and it prompted my Windows 10 test PCs to enroll in Intune. I do not have ADFS but the Windows 10 was logged in “Join with Work Account” and shows up as workplace joined in Azure AD under devices. Here is the kicker, you need Modern Auth enabled for MFA to be understood in Outlook 2016. I am pretty sure no one is testing this stuff, getting really frustrated with a client POC.

    • That would be correct. You should also be able to leverage targeted groups to hit just the users you would like. If you have it set to all users, this would be the expected behavior.

Leave a Reply

Your email address will not be published. Required fields are marked *