Plan Device-based Conditional Access on-Premises
This document describes conditional access policies based on devices in a hybrid scenario where the on-premises directories are connected to Microsoft Entra ID using Microsoft Entra Connect.
AD FS and Hybrid conditional access
AD FS provides the on premises component of conditional access policies in a hybrid scenario. When you register devices with Microsoft Entra ID for conditional access to cloud resources, the Microsoft Entra Connect device write-back capability makes device registration information available on premises for AD FS policies to consume and enforce. This way, you have a consistent approach to access control policies for both on premises and cloud resources.
Types of registered devices
There are three kinds of registered devices, all of which are represented as Device objects in Microsoft Entra ID and can be used for conditional access with AD FS on premises as well.
| Description | Add Work or School Account | Microsoft Entra join | Windows 10 Domain Join |
|---|---|---|---|
| Description | Users add their work or school account to their BYOD device interactively. Note: Add Work or School Account is the replacement for Workplace Join in Windows 8/8.1 | Users join their Windows 10 work device to Microsoft Entra ID. | Windows 10 domain joined devices automatically register with Microsoft Entra ID. |
| How users log in to the device | No log in to Windows as the work or school account. Log in using a Microsoft account. | Log in to Windows as the (work or school) account that registered the device. | Log in using AD account. |
| How devices are managed | MDM Policies (with additional Intune enrollment) | MDM Policies (with additional Intune enrollment) | Group Policy, Configuration Manager |
| Microsoft Entra ID Trust type | Workplace joined | Microsoft Entra joined | Domain joined |
| W10 Settings location | Settings > Accounts > Your account > Add a work or school account | Settings > System > About > Join Microsoft Entra ID | Settings > System > About > Join a domain |
| Also available for iOS and Android Devices? | Yes | No | No |
For more information on the different ways to register devices, see also:
- Using Windows devices in your workplace
- Microsoft Entra registered devices
- Microsoft Entra joined devices
How Windows 10 User and Device Sign-on is different from previous versions
For Windows 10 and AD FS 2016, there are some new aspects of device registration and authentication you should know about (especially if you are familiar with device registration and "workplace join" in previous releases).
First, in Windows 10 and AD FS in Windows Server 2016, device registration and authentication is no longer based solely on an X509 user certificate. There is a new and more robust protocol that provides better security and a more seamless user experience. The key differences are that, for Windows 10 Domain Join and Microsoft Entra join, there is an X509 computer certificate and a new credential called a PRT. You can read all about it here and here.
Second, Windows 10 and AD FS 2016 support user authentication using Windows Hello for Business, which you can read about here and here.
AD FS 2016 provides seamless device and user SSO based on both PRT and Passport credentials. Using the steps in this document, you can enable these capabilities and see them work.
Device Access Control Policies
Devices can be used in simple AD FS access control rules such as:
- Allow access only from a registered device
- Require multifactor authentication when a device is not registered
These rules can then be combined with other factors such as network access location and multifactor authentication, creating rich conditional access policies such as:
- Require multifactor authentication for unregistered devices accessing from outside the corporate network, except for members of a particular group or groups
With AD FS 2016, these policies can be configured specifically to require a particular device trust level as well: either authenticated, managed, or compliant.
For more information on configuring AD FS access control policies, see Access control policies in AD FS.
Authenticated devices
Authenticated devices are registered devices that are not enrolled in MDM (Intune and third party MDMs for Windows 10, Intune only for iOS and Android).
Authenticated devices will have the isManaged AD FS claim with value FALSE. (Whereas devices that are not registered at all will lack this claim.) Authenticated devices (and all registered devices) will have the isKnown AD FS claim with value TRUE.
Managed Devices:
Managed devices are registered devices that are enrolled with MDM.
Managed devices will have the isManaged AD FS claim with value TRUE.
Devices compliant (with MDM or Group Policies)
Compliant devices are registered devices that are not only enrolled with MDM but compliant with the MDM policies. (Compliance information originates with the MDM and is written to Microsoft Entra ID.)
Compliant devices will have the isCompliant AD FS claim with value TRUE.
For complete list of AD FS 2016 device and conditional access claims, see Reference.
Reference
Updates and breaking changes - Microsoft identity platform | Microsoft Docs
Complete list of new AD FS 2016 and device claims
https://schemas.microsoft.com/ws/2014/01/identity/claims/anchorclaimtypehttps://schemas.xmlsoap.org/ws/2005/05/identity/Identity_Selector_Interoperability_Profile_V1.5.pdfhttps://schemas.microsoft.com/2014/03/pssohttps://schemas.microsoft.com/2015/09/prthttp://schemas.xmlsoap.org/ws/2005/05/identity/claims/upnhttps://schemas.microsoft.com/ws/2008/06/identity/claims/primarygroupsidhttps://schemas.microsoft.com/ws/2008/06/identity/claims/primarysidhttps://schemas.xmlsoap.org/ws/2005/05/identity/Identity_Selector_Interoperability_Profile_V1.5_Web_Guide.pdfhttps://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountnamehttps://schemas.microsoft.com/ws/2008/06/identity/claims/groupsidhttps://schemas.microsoft.com/2012/01/devicecontext/claims/registrationid/dotnet/api/system.security.claims.claimtypes.windowsdeviceclaimhttps://schemas.microsoft.com/2012/01/devicecontext/claims/identifierhttps://schemas.microsoft.com/2012/01/devicecontext/claims/ostypehttps://schemas.microsoft.com/2012/01/devicecontext/claims/osversionhttps://schemas.microsoft.com/2012/01/devicecontext/claims/ismanagedhttps://schemas.microsoft.com/2012/01/devicecontext/claims/isregistereduser/dotnet/api/system.security.claims.claimtypes.windowsdeviceclaimhttps://schemas.microsoft.com/2014/02/deviceusagetimehttps://schemas.microsoft.com/2014/09/devicecontext/claims/iscomplianthttps://schemas.microsoft.com/2014/09/devicecontext/claims/trusttypehttps://schemas.microsoft.com/claims/authnmethodsreferenceshttps://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-user-agenthttps://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-endpoint-absolute-pathhttps://schemas.microsoft.com/ws/2012/01/insidecorporatenetworkhttps://schemas.microsoft.com/2012/01/requestcontext/claims/client-request-idhttps://schemas.microsoft.com/2012/01/requestcontext/claims/relyingpartytrustidhttps://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-iphttps://schemas.microsoft.com/2014/09/requestcontext/claims/useriphttps://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod