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:

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

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:

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:

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!

ADFS 2016: MFA

ADFS 2016 changes the way Multi-Factor Authentication (MFA) is  configured and used. With previous versions of ADFS, MFA Server was downloaded and the ADFS adapter installed to provide MFA for users and applications. With Windows Server 2016, the architecture has changed so that ADFS 2016 is integrated with Azure MFA. This means that the IT admin does not need to install any special software or adapter to get MFA working. In addition, MFA now can be used as a primary method of authentication—users don’t need to enter in their password to get access to resources, they can verify their identity using their phone (call, text) or by using the Microsoft Authenticator app.

Before ADFS 2016 MFA can be used, MFA servers need to be registered on your Azure AD tenant: This following needs to be done for each ADFS server in the farm. There is good documentation on how to get this done here:


In my lab environment, I installed ADFS 2016 and used the Export and Import scripts available in the Windows Server 2016 media to move over the settings from my 2012 R2 server. The scripts are located in the Support\ADFS folder of the OS media. The biggest key to making this work is to make sure you use the same service account.

FYI:You can easily add ADFS 2016 server into an existing 2012 farm seamlessly but I did not choose to go that route.


A certificate needs to be generated on the ADFS server which will be used for authentication against Azure AD.


After a certificate is generated, a new service principal needs to created and the certificate information associated with the service principal. This allows the ADFS servers to authenticate/communicate with the Azure MFA client successfully.

When executing the command to create the service principal ID, you are met with an error saying the end date is an invalid parameter. This seems to be a bug and I was able to get around this by omitting the start and end date altogether.


Now that I have MFA service registered with Azure AD, I can go ahead and enable MFA as an authentication method.  MFA can be used  the primary method of authentication or secondary. Using MFA as a primary method of authentication is great news—this means you don’t have to use your password when logging on to company resources

For my test environment, I’ve setup ADFS with the following configuration:


One of the prerequisites to get Azure MFA to work on-premise is that the “proof-up” or the setup of MFA information needs to happen in Azure AD. This means that multi-factor authentication needs to be enabled for the user. I’ve raised this issue with MS because essentially to use ADFS based Azure MFA you need to turn on Azure AD MFA (more on this later)

Since we’ve enabled both ADFS based Azure MFA and Azure AD MFA, we need a way to prevent double  double MFA prompts (one from Azure and one from ADFS). You will need to change your domain federation settings to the following:

Set-MsolDomainFederationSettings –DomainName -SupportsMFA $false

In addition, you will need to pass the MFA claim from ADFS to Azure AD so it will understand that you have already successfully authenticated via MFA on-premises. This should be added to the Office 365 Relying Party Trust (which is service I’m testing against)

(=> issue(Type = ““, Value = ““);)

**After raising the proof-up question with MS they recommended to use the following for these scenarios:

1) Authenticating to Internal Applications – Internal applications will be able to leverage ADFS based Azure MFA for authentication. This assumes that the user has setup alternate authentication methods in Azure AD. You can send the user the link to set up MFA methods or if they use Office 365 or Microsoft cloud services, they will be forced to go through this setup.

2) Authenticating to Azure AD Applications – For Azure AD applications, Azure AD MFA will provide authentication. This is of course assuming Azure MFA is turned on for the user.

From testing, I was able to use ADFS based MFA for both scenarios and get it to work.  It worked because I went through the initial proof-up setup (Turning on MFA in Azure AD or Setting up alternate authentication methods by going to

User Experience

When a user logs in for the first time to Office 365, they will be met with a prompt to setup MFA (I’ve set the SupportsMFA parameter to false and enabled MFA for the user in Azure AD)



I configured MFA for  my test account to use mobile app notifications. Once you click on “Set up” you will receive a QR code which you can scan using the Microsoft Authenticator app (Work Account). Now when I login to Office 365, I’m redirected to my ADFS server and you will notice an option at the bottom for MFA Authentication:


Once you click on Azure Multi-Factor Authentication, you will have to then use the verification code from the Microsoft Authenticator app to authenticate yourself to Office 365.



  1. MFA as a primary method of authentication helps prevent the use of passwords thereby reducing the chance that the password gets stolen & it improves the experience of users that are trying to login with mobile devices where there’s not much real estate on the keyboard to type in a complex password.
  2. I suspect more documentation on this topic will be published before Windows Server 2016 is available to corporate customers which might explain some of the caveats I’ve run into.
  3. The integration of the cloud services such as the MFA service with the Server OS is a great way to unify the setup and configuration process regardless of if you are hybrid or cloud organization.

Microsoft Intune Per-App VPN for Android

Microsoft Intune currently offers support for per-app VPN on Android if used with Pulse Secure. This functionality has been available for a while on iOS devices where the VPN tunnel is initiated when a user launches an application or hits a URL that’s been defined by the IT Administrator. This is a great way to ensure that mobile applications tunnel back internally to get data.

Recently, while testing out per-app VPN on Android with the Pulse Secure client it appears as though this functionality although published here was not working.

It took a while to realize that the per-app VPN works very differently with Android devices. Here’s the response received from the developer that implemented the feature:

In Android, PerAppVpn works a little different than iOS. It does not launch the VPN automatically when the app is opened, so the customer has to go open the PulseSecure VPN client manually and start the connection first. PulseSecure will then only allow traffic from the specified app(s) in the VPN profile to go through the VPN tunnel.

I’m hoping that this functionality becomes more like the experience on iOS devices because the whole goal is for the device to auto-initiate the VPN without users having to do this. Hopefully this is something that Android for Work can help solve as MDM capabilities are standardized across Android phones.

Publishing OWA with Azure Application Proxy

Azure Application proxy is an exciting technology that’s available with Azure AD Premium. It allows you to publish internal web applications in a simple and secure manner.

Software Prerequisites

The proxy connector is an application that needs to be installed on a Windows Server 2012 R2 or Windows 8.1 + machine. The application itself is a ~4 MB download and even can be installed on the server that you are trying to publish (although I would not recommend this).

Network Requirements

The server that houses the proxy connector only requires outbound access. Specifically the following ports need to be open:




To enable outbound HTTP traffic for security validation.


To enable user authentication against Azure AD (required only for the Connector registration process)

10100 - 10120

To enable LOB HTTP responses sent back to the proxy

9352, 5671

To enable communication between the Connector toward the Azure service for incoming requests.


Optional. To enable better performance for incoming requests.


To enable the Connector bootstrap sequence and to enable Connector automatic update


To enable Connector registration (required only for the Connector registration process)


To enable Connector trust certificate automatic renewal

How it works

The proxy connector makes an outbound connection to the Azure proxy in the cloud thus allowing a bi-directional TCP/IP transmission. Before a user can access the internal web application, the user’s account is authenticated against Azure AD (pre-authentication). Afterwards, if Kerberos authentication is enabled for the applications, the users will experience a single-sign on experience. If not, the user needs to authenticate to the application.

Publishing OWA

To test out the proxy, I’ve decided to publish Exchange 2010 OWA which is hosted in my lab without any external presence. My goal is to allow for a single sign on experience. I will need to do the following to meet this requirement:

1) Enable Kerberos authentication for Outlook Web App.

2) I need to ensure SPN’s and Kerberos Constrained Delegation is properly setup.

Enable Kerberos Authentication for OWA

To do this, logon to the Exchange Management Shell (2010)—>Server Configuration—>Client Access

Go to the OWA virtual directory and edit the properties. Change the authentication method from forms-based authentication to “Integrated Windows Authentication”


Now we need to delegate the server that has the connector installed with the rights to request a Kerberos ticket on behalf of the Exchange server. To achieve this, go Active Directory Users and Computers, and double click on the computer that has the Azure connector installed.

Go to the delegation tab and add the services (HTTP) of the Exchange server that can be delegated.


Configure Azure AD Premium

Create a new application in Azure AD:



PreAuthentication Method: Set to Azure Active Directory.

Translate URL In Headers: Set to No since Exchange needs host headers to be preserved.

Internal Authentication Method: Set to Integrated Windows Authentication (Kerberos). If Kerberos is not possible, the user will have to login to the application.

Internal Application SPN: Provide the SPN for the Exchange server.



Now navigating to the Azure Application Proxy URL yields this:

Sign into the Azure Portal using your AD credentials (UPN and password).


Once successfully authenticated, you will be redirected to OWA page and logged in using Kerberos authentication.



Azure Application Proxy is a great tool to publish internal web applications securely. In most environments, publishing an application wouldn’t involve making changes to the firewall since the proxy connector only needs outbound access.

Any application published via Azure Application Proxy can be added to the Application Portal which the users can access from a single page; if they are logged in they would go directly to the OWA page without the need to be authenticated twice. To take this further, multi-factor authentication can be easily leveraged to add another layer of security. To provide a higher level of availability the connector can be installed on multiple machines. In the case one server is down, the application proxy would continue to work.

Detaching/Attaching SCCM 2012 Database

As part of a recent task to relocate an SCCM database to faster spindles, I went ahead used the detach/attach method to accomplish this. After the database relocation there were no issues until we tried to create a new application. I received the following error:



After checking the logs, I found the following event being reported continuously:


After some digging around, I found a Microsoft KB that addresses this exact problem:

Part of the issue is that when you detach and attach a database ( a perfectly supported SQL action) the trustworthy database flag is turned to off. As a result, SCCM DLL’s are not successfully loaded. After following the steps outlined in the KB article, I was able to create applications without any issues.

Recommendation: Use backup/restore method to relocate the database than using attach/detach.

Failed to Resolve Select Task Sequence...

I was working at a client with SCCM 2012 R2 OSD configuration and I was getting the error “Failed to Resolve Select Task Sequence Dependencies” every time testing the task sequence. I checked for the usual suspects and ensured that all applications and packages were distributed to the Distribution Points.

Initially, I thought the application that was causing the error was corrupted. So I went ahead and refreshed the content (“Update Content” as it’s formally known”). I attempted to run the task sequence again and then noticed that the same error came up referencing a different application. I began to see a pattern and all the applications that were referenced in the error all had version 1.

To increment all application versions, I used the following script that I pieced together from other sources:

Import-Module ‘C:\Program Files (x86)\Microsoft Configuration Manager\bin\ConfigurationManager.psd1’
CD SiteCode:
$applications=Get-CMApplication |Select-Object ApplicationName,LocalizedDisplayName, CIVersion |Where-Object CIVersion -eq “1”
foreach ($app in $applications)
Write-host “Application :” “$app” -ForegroundColor DarkCyan

$dpttypes=Get-CMDeploymentType -ApplicationName $app

foreach ($dpt in $dpttypes)
Write-Host “Deployment Type:” “$dptname” -ForegroundColor DarkGreen
Update-CMDistributionPoint -ApplicationName $app -DeploymentTypeName $dptname
Note: Even after changing all versions to 2, I still had one or two apps needed to be incremented before I could proceed with the TS.

A read operation on a large object failed..

After logging into my SCCM 2012 R2 server and running a report, I was getting an error to check network connectivity to the Report Server. After logging into my SQL 2012 SP2 server, I saw the following error message every time I ran a report:

Log Name: Application
Date: 12/5/2014 10:32:42 PM
Event ID: 7886
Task Category: Server
Level: Error
Keywords: Classic

A read operation on a large object failed while sending data to the client. A common cause for this is if the application is running in READ UNCOMMITTED isolation level. This connection will be terminated.
I checked the database size and initially thought the autogrowth threshold was low. I was still getting the error after adjusting the autogrowth so I then thought it might be an issue with the database itself and ran a DB check.


I had to run these commands couple of times to fix the corruption in the database.