Enabling MFA with Conditional Access

Following the previous post about Enabling MFA, imagine that you followed my recommendations about enabling and enforced by using MFA, but now what you want to do is to enable MFA but in a CA policy, with the following PS you can make the conversion from MFA to CA based MFA.

The advantage? More powerful, you can select which services can ask for MFA, the condition of the device, and many other features…

# Sets the MFA requirement state
function Set-MfaState {


Process {
Write-Verbose ("Setting MFA state for user '{0}' to '{1}'." -f $ObjectId, $State)
$Requirements = @()
if ($State -ne "Disabled") {
$Requirement =
$Requirement.RelyingParty = "*"
$Requirement.State = $State
$Requirements += $Requirement

Set-MsolUser -ObjectId $ObjectId -UserPrincipalName $UserPrincipalName `
-StrongAuthenticationRequirements $Requirements

# Disable MFA for all users
Get-MsolUser -All | Set-MfaState -State Disabled



My experience about registering Hybrid Azure AD joined devices

Implementing a Conditional Access scenario in Azure, involves that device Context claims are necessary for ADFS / Azure AD to determine if a device is recognized, managed, compliant, etc. We have to take into account that are used to recognize if its a known device or not.

During my experience registring Hybrid Azure AD Joined devices, I found that in Windows 7, a Workplace Joined machine is per user based and receives a device authentication certificate that is stored in the “Current User” certificate store.


In Windows 10, I found that Azure AD device registration is per machine, so we have detected blank fields in AzureAD (which is normal), I raised a support ticket and they confirm this behavior. In this case, the machine receives a device authentication certificate that is stored in the “Local Machine” certificate store.


During authentication, IE and Edge successfully use this certificate to complete device authentication. Chrome will not touch any certificates in the “Local Machine” certificate store. If using Chrome the device is not recognized, MFA fails, and the user is prompted for a secondary form of authentication.

This appears to be a known issue with alternative browsers without a suitable answer. Without device authentication occurring, a device can not be recognized for the purposes of bypassing MFA with conditional access policies.

Microsoft has provided a plug-in for Google Chrome, that allows it to perform device authentication when using MFA. However, there are a couple caveats to be aware of:

  • The plug-in only works for Chrome and only works with Windows 10 Creators Updates (1703) or newer.
  • The plugin only works for Azure AD conditional access policies.
  • ADFS device based conditional access policies will not work.
  • Relying party trusts in ADFS other than Office 365 will not be able to utilize the plugin due to the previous limitation.

Long story short, Windows 7 device authentication seems to work fine and recognized devices will support device based conditional access policies if you use Chrome. Windows 10 devices using Chrome have limited ability to support device based conditional access policies.

How to backup your Microsoft Authenticator Application

It happened to me, I had configured the Microsoft Authentication app in my phone and then I changed the phone, so the experience to recreate all the MFA accounts, was simply horrible… but now Microsoft Authenticator allows to backup your multi factor accounts and recover them.

It works for both personal and work profiles, the only requirement is to have a Microsoft Account (MSA) to backup your Microsoft Authenticator application; even if you use it from the device work profile. Something important: You can not use Corporate account to backup your Microsoft Authenticator application.

To enable the backup capability, just access the Options menu (the 3 dot shown at the top right of the application) and choose to Turn on backup – or access the Settings and enable the Cloud Backup feature.


It will then automatically use your MSA account



Keep in mind that, once you have enabled the backup for one instance, and try to enable it on the second one, you will be requested if you want to overwrite it if you use the same MSA account

Understanding App Password in Office 365

Multi-Factor Authentication (MFA) in Office 365 has several advantages. Once you enable MFA, it offers a much higher level of security because users can secure their credentials with a second level of authentication, such as:

  1. Call to phone
  2. Text message to phone
  3. Notification through mobile app
  4. Verification code from mobile app or hardware token

An important concept that is not usually clear to people who are new to Office 365 is the concept of App Password, short for application password.

However, the user can run into a problem when a non-browser application is used with O365, such as Outlook. To accommodate such scenarios, Microsoft offers app passwords that are used to essentially bypass the use of MFA for the non-browser applications. Keep in mind that the app password is tied to the user’s account in O365 portal so this password cannot be generated outside of O365 because it’s stored in Azure.

That’s all for now!

Configuring Azure MFA in ADFS: Service Principal was not found

Hi All,

Today I’m back with ADFS, the other day I needed to configure ADFS with Azure MFA for a client. In this case, first I configured the ADFS farm (in my case with WS2016), and then I was ready to configure Azure MFA in the Authentication methods for the Intranet and Extranet.

Why? Because it was a requirement for the project that all internal users use MFA in order to authenticate to O365. Thus we can integrate this with ADFS in a very simple (but tricky) steps. As you know, if you have E1 or E3 licenses, you can use Azure MFA by default, is it not necessary to purchase extra licenses in order to use this service. **First point to take into account

For the record, you will need to use the Connect-MSolService cmdlet, so be sure that you have installed the PowerShell modules in your server

Install-module MSOnline
Install-module AzureAD

Once you have installed this, you need to execute the following commands:

$tenantID = “yourtenant.onmicrosoft.com”
$certbase64 = New-AdfsAzureMfaTenantCertificate -TenantID $tenantID

New-MsolServicePrincipalCredential -AppPrincipalId 981f26a1-7f43-403b-a875-f8b09b8cd720 -Type asymmetric -Usage verify -Value $certBase64
Set-AdfsAzureMfaTenant -TenantId $tenantID -ClientId 981f26a1-7f43-403b-a875-f8b09b8cd720

You can check the info in the following article: https://docs.microsoft.com/es-es/windows-server/identity/ad-fs/operations/configure-ad-fs-and-azure-mfa

But in my case, every time I was executing the command New-MSOLServicePrincipalCredential, I was receiving an error saying: “Principal Service was not found” I double checked if I was Global ADmin in the O365 and Azure subscription and I was!! So… what the hell means that error??

It means that you don’t have registered the SPN for Azure MFA, and to solve this it is very simple, you can purchase a trial of Azure MFA (P1, P2, EMS, o whatever plan where Azure MFA is included) and assign a license to one user, for example in my case, I assigned the license to the test users. It seems that you will not see “Azure Multi-Factor Auth Client” in the list of MSOL Service Principals until you have at least one account with an MFA license on your tenant.

After doing this, I needed to wait a couple of minutes and then I executed again the PS commands that I showed before… and bang!! I was able to register the Azure MFA as authentication method in ADFS Server.

I think that the short history is that using the new ADFS adapter requires MFA licenses. It doesn’t work with an MFA Provider, but MFA licenses can be purchased standalone or the ones included in Azure AD Premium and EMS

That’s all for today!