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.
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:
- So does that mean that Windows PCs can access EXO/SPO without having to enroll in Intune?
- Does it mean Azure AD joined or domain joined?
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:
- Office desktop 2013 and later with modern authentication enabled.
- Windows 7.0 or Windows 8.1
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: http://jairocadena.com/2016/02/01/azure-ad-join-what-happens-behind-the-scenes/
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:
- Does it mean Azure AD joined or domain joined?
- 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!