Monday, January 24, 2022

Operation Fortune: Ruse de MFA

Must read

avatar
Rudy Oomshttps://call4cloud.nl/
Rudy is a Modern workplace architect and currently working for a company in the Netherlands, called Deltacom Steenbergen. He has been working in IT since he was 16 years old. Within these years, he gained a lot of experience in different kinds of expertise. I guess like most of you, he started working with active directory environments. In June 2021 he received the MVP status in the category Enterprise Mobility for the first time. The multi-tenant PowerShell scripted Deltacom-Cloud environment is one of his creations.

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.

Im A Fool GIFs | Tenor

I will divide this blog into multiple parts

  1. Migrating from User Based MFA to Conditional Access
  2. The Conditional Access rule
  3. Long Live Compliant devices?
  4. Sign-In reports
  5. What made me look like a fool

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 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 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

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?

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!

Big Mistake Arnold Schwarzenegger GIF - Big Mistake Arnold Schwarzenegger  Thats A Big Mistake - Discover & Share GIFs

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”.

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 while 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.

Like always just configuring stuff and not monitoring is bad, very bad. So shall we take a look at how 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?

Afbeelding met tekst  Automatisch gegenereerde beschrijving

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.

So, we are using Azure AD joined machines and use WHfB to log on. Somehow the requirement for these logons have 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?

Afbeelding met tekst  Automatisch gegenereerde beschrijving

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.

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!

Trust Noone GIFs - Get the best GIF on GIPHY

More articles

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Latest articles