ADFS, Device Claims & Conditional Access

During a recent EMS POC engagement, my customer asked if there was a way to bypass multi-factor authentication for mobile devices that were registered with Intune/managed by the company. In addition they wanted to be able to get device claims from Windows 10 devices as well so they can determine if the device was being managed by SCCM.

This seems like a pretty reasonable and simple ask until you actually realize the solution entails multiple components to get it properly working.

After some research, I realized I needed ADFS, Azure AD Connect, Azure Device Registration (For Windows devices) and Intune to get this working.

Now for some background..

• Azure Device Registration – As part of Intune enrollment devices are registered to Azure AD using the ADRS service. This allows a record for the device to be created which contains information about the device. ADRS also supports the registration of domain joined computers as well. We’ll be be using this service to register Windows 10 domain joined computers so that Azure AD knows about them.
• ADFS – Since ADFS is where the authentication for the user happens, we can get information about the device and the user. What we are interested in are device claims which give us more information about the device that’s being authenticated.
• Azure AD Connect – Azure AD Connect is a tool used to synchronized your Active Directory to the cloud. It also allows provides a very important feature called Device Write-back. This essentially brings down the objects that are registered to Azure AD to Active Directory so ADFS knows about them.

Azure Device Registration/Azure AD Connect

So how does devices get to Azure AD?

• Well, mobile devices are easy because part of the Intune enrollment process involved the registration of the device to Azure AD.
• Now what about Windows devices (7,8,10)? It turns out there’s a mechanism called Azure Device Registration for Windows domain joined devices. For Windows 8.0 and above, this process is built into the operating system and the feature that’s used is “WorkPlace Join”.

I won’t go into the details of setting this up but it’s outlined here in the following articles:

https://azure.microsoft.com/en-us/documentation/articles/active-directory-azureadjoin-devices-group-policy/

Jairo Cadena has the best article that I can find just in case you are interested in how the device registration works:

https://jairocadena.com/2016/01/18/how-domain-join-is-different-in-windows-10-with-azure-ad/

Device registration will work for BOTH customers that are federated (e.g using ADFS) or that’s just doing password synchronization. The caveat is that the computer object needs to be included in the scope of devices that you are syncing using Azure AD Connect or equivalent. **Update: Windows 7 Azure AD Registration will ONLY work with ADFS

Azure AD Connect is involved because there’s an option in the tool for device write-back. Since Azure AD registers mobile or Windows devices that are not part of the domain, there needs to be a mechanism that brings down the devices from Azure to Active Directory so that ADFS knows about these devices.

The command above will do the following:

1. Assigns the correct permissions for the Azure AD Connect tool to write back the devices in Azure to AD. In Active Directory, you will notice a “RegisteredDevices” OU in Active Directory.

In addition, for domain joined Windows 10 computers the following powershell command needs to be run as well after the Azure Active Directory installation is complete.

When you run this script the following happens:

1. Create an SCP (Service Connection Point)  record in Active Directory that allows Windows devices to know which Azure AD tenant to connect for the device registration to take place.

ADFS Configuration

On the ADFS front, for device registration to work quickly (instantly) you’ll have to configure ADFS so that necessary claims are passed to Azure AD for authentication. You can find more details by following the article I mentioned in the Azure Device Registration section.

More importantly, you will need to enable device authentication. With ADFS 2012, the setting is configured by checking the box below. Device authentication will help yield the device claims we are looking for.

With ADFS 2016, the configuration is moved to a different area and the process in setting this up is much simpler. Device authentication is also associated with device registration. This removes the need to run powershell commands to initialize device registration with ADFS 2012.

Client Testing

So after you get this setup Windows 10 devices that have the anniversary version will automatically register with Azure AD. For older versions of Windows 10, you will need to enable “WorkPlace Join” via group policy.

Windows 8/8.1 also need to have the “WorkPlace Join” GPO enabled.

Windows 7 clients do not have the capability natively however you can install this capability using the following tool:

https://connect.microsoft.com/site1164/program8374

For testing purposes, I setup a sample application that displays all claims. The sample application can be found in the Windows Identity Foundation framework and can be downloaded and setup using this article:

https://blogs.technet.microsoft.com/tangent_thoughts/2015/02/20/install-and-configure-a-simple-net-4-5-sample-federated-application-samapp/

Caveats: I spend countless of hours troubleshooting device authentication with Windows 10 and although there’s no article that says this but from testing it does not seem device claims is supported with ADFS 2012. In a ADFS 2016 environment, I was able to get device claims the way I expected.

Here are the results from a Windows 10 (Anniversary Update) machine logging into the sample claims aware applications:

Now we have information about the device itself such as “IsManaged”, “WorkPlace”, we can use these claims to make authentication decisions.

In terms of the device registration of the particular client in Azure AD, you will find the following:

Example of a Windows 10 device that’s domain joined:

Example of Intune joined device:

Now that we have all this information, we can use ADFS to ensure that domain joined devices and managed devices bypass multi-factor authentication

Making it Work

With ADFS 2016, we can do this with Access Control Policies. This is a simplified way of creating issuance rules without the need for the claims language.

For my Office 365 tenant, I’m going to create the following Access Control policy and then apply the policy to my Office 365 relying party trust.

So essentially any user that logs into Office 365 will get a multi-factor authentication prompt except for devices with the claim “Device Trust Level” being “Managed”.  In my next post, I’ll deep dive into some of the device claims available and what the different values mean.

Now you can take this a step further and use these device claims to enforce conditional access. For example, you can prevent non-managed devices from accessing company resources either in the cloud or on-premise!