Operation Fortune: Ruse de MFA

This blog will be about some MFA, some Conditional Access, and some activity in the Sign-in reports that could make a fool out of you. This time it took some time before I understood the “why”. So I guess I am the fool in this blog.

1.Migrating from user based MFA to Conditional Access

Let’s start with why you need to migrate to Conditional Access when you are still using user-enforced MFA. Of course, this isn’t anything new on the horizon but I need to tell it first before we can take a look at what made me look like a fool.

Moving your MFA enforcement to Conditional Access is the best practice as you want to have everything in a single pane of glass. You really don’t want to open a second page and scroll through all those users to find out if they are MFA enabled!

And that’s not all because when using Conditional Access to enforce MFA you can be sure all of your users will be enforced to use MFA. But that’s not all, you can even configure it when they are prompted for MFA. Isn’t that nice?

So let’s take a look at how the migration plan looks like

1. Changing the per-user MFA setting to disabled
2. Creating the Conditional Access Rule

To start migrating we first need to make sure we have disabled the old school legacy MFA for each user. So let’s open the old legacy MFA page to ditch the old MFA!

Multi-factor authentication (windowsazure.com)

When you want to just disable it for everyone, just select the users and click on disable to turn off the MFA enforcement.

Of course, you could also do a bulk update, to do so you will need a CSV. But why use a CSV when you can also make sure MFA enforcement is going to be disabled for all users with the use of PowerShell?

function Set-MfaState {

    [CmdletBinding()]
    param(
        [Parameter(ValueFromPipelineByPropertyName = $True)]
        $ObjectId,
        [Parameter(ValueFromPipelineByPropertyName = $True)]
        $UserPrincipalName,
        [ValidateSet("Disabled", "Enabled", "Enforced")]
        $State
    )

    Process {
        Write-Verbose ("Setting MFA state for user '{0}' to '{1}'." -f $ObjectId, $State)
        $Requirements = @()
        if ($State -ne "Disabled") {
            $Requirement =
            [Microsoft.Online.Administration.StrongAuthenticationRequirement]::new()
            $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

2. The Conditional Access Rule

Now we have made sure we have disabled the per-user MFA, we still need to create a simple Conditional Access Rule to enable the MFA enforcement again. Luckily it isn’t that hard.

• Target all of your users / exclude the dedicated MFA_Exclusion_group (break glass)
• Target the Office 365 or just All Cloud Apps when you want to make sure your users will be prompted for MFA for every cloud app
• Configure the control access enforcement to only grant access when the MFA requirement is met

Nothing more… but what about the conditions? Do we need any conditions?

3. Long live the Compliant Devices

So we just enforced MFA to be used every time on each cloud app. But what about your Azure Ad Joined devices? A lot of IT pros are making sure the devices are compliant by setting up some nice compliance policies. Some of these compliance policies are making use of Device Health Attestation. If you want to read more about DHA, please read my blog

Device Health Attestation Flow | DHA | TPM | PCR | AIK (call4cloud.nl)

But here comes the most man-made mistake since the beginning of time!

A lot of IT pros are afraid, that their users will be sick and tired of entering their MFA each time on their compliant device so they Exclude the Compliant Devices from the MFA Conditional Access rule.

And that’s a very bad thing in my opinion. Why? Let me explain. On an Azure Ad joined device, you have got something called the “Primary Refresh Token/PRT”.

Of course, I already did multiple blogs about the fabulous PRT, so if you want to know more about it please read them.

When we are making use of Windows Hello (WHfB) we are also making use of MFA when logging in to our devices (yes it is MFA!, even though I loved the MFA Authenticator option more).

When logging in with WHfB, the PRT will be updated with this MFA claim. This MFA claim just indicates that the user who logged in completed the MFA process. This PRT will be used to enable SSO to resources that are requiring MFA.

So why exclude Compliant Devices? As they have built-in MFA functionality added to the PRT.

That’s not even all. When we are excluding compliant devices for MFA, we are also making a very big hole in our defense. Again let me explain. In a normal situation (when you don’t exclude compliant devices!), a user just logs in with his WHfB pin and has SSO and it satisfies the MFA requirement.

But what happens when you excluded compliant devices and some “attacker” steals just one of the many compliant devices you have? The attacker could just login with a normal user and a phished password and because you excluded the compliant devices from MFA prompts, he could just skip the Windows Hello enrollment and open everything without even being prompted for MFA! That doesn’t sound safe to me?

So please remember that the PRT contains the needed MFA claim when using WHfB on compliant devices. You really don’t need to exclude compliant devices to kill the MFA prompt fatigue issue.

4. Sign-in Reports

Like always just configuring stuff and not monitoring is bad, very bad. So shall we take a look at what the sign-in reports normally would look like first? Because how can you monitor if you don’t know the correct settings, you need to monitor?

And of course the “Authentication Details”

So everything is fine? Right? A nice report in which we can determine if the end-user is using Windows Hello and passed the MFA requirements. So we know what to look for when something looks different.

5.What made me look like a Fool

So, we are using Azure AD joined machines and use WHfB to log on. Somehow the requirement for these logons has been reported as single-factor authentication, in the Azure AD Sign-in logs.

Luckily I am not the only one questioning that sign-in report because there are other IT pros with the same questions about the “Authentication Requirement” as shown below.

Intune: Mobile Device Management (reddit.com)

At first, you would expect the Authentication Requirement to be ”Multi-Factor Authentication” when requiring MFA with Conditional Access….right?

So what’s the difference between those two requirements? Maybe, just like me, you got the feeling that there was something wrong when looking at the MFA authentication requirement.

Because when users are logging in with only a password you will also end up with that same single factor authentication requirement notification in the sign-in log.

This part of the report only indicates the MFA requirement… Do you remember the first part of the blog in which I pointed out the old-school per-user based MFA?

So let’s summarize it.

*When you have disabled per-user MFA. You will NOT BE required to have MFA, so single-factor it is.

*When you have disabled per-user MFA and you are using Windows Hello, you are making use of the “Strong Windows Hello Authentication”

*When you have enforced per-user MFA, you will BE required to have MFA, so multi-factor it is.

*When you have enforced per-user MFA and you are using Windows Hello, the MFA requirement is already satisfied by the claim in the token

So I guess you now know what the Sign-In report will tell you when you have disabled the per-user MFA and you are using conditional access. It will just show you the Single-Factor requirement. Just start looking at the “additional and authentication details“, they will give you the required information.

Conclusion

First I need to thank Joey Verlinden | LinkedIn to come up with the question about the Sign-In report. I was already writing multiple blogs about Conditional Access, the sign-in report was a nice addition to this one.

To finish this blog, don’t rely on trust, don’t exclude compliant devices because they are compliant!