Testing: Conditional Access: Strong Proof Up for Azure MFA in the cloud

Joosua Santasalo

Joosua Santasalo

Senior Consultant, Digital Identity

September 6, 2018 at 16:03


If there is a single question I’ve received the most times for customers enrolling Conditional Access for MFA use, it’s ”how can we require additional factor for users before they can actually enroll to MFA”

Some consider ”Strong proof up” a situation where initial username/password isn’t strong enough to enroll in MFA – Whereas the standard proof up would be considered single factor =>Meaning, that the attacker can also do the enrolment if the attacker is in possession of the first factor (user credentials).

I am not certain this behavior exists for the old tenants (possibility of doing strong proof up), or Office 365 MFA, but at least in my quite recent dev tenant I was able to configure strong proof up the following way:

  • Please note, that I am using conditional access to require the multi-factor-authentication. I cannot say if the behavior is same when a user has been enabled for MFA in the non-conditional access triggered ”old” MFA portal.
  • Why this works is that when a user is required for 2 FA in CA, the policy triggering pipeline is able to use one of the pre-populated attributes. I am quite certain that this behavior didn’t exist before (Maybe there are some release notes, which I haven’t checked out)
  • I’ve set up the CA for all cloud apps, to ensure that the proof up page isn’t available without first doing 2 FA.
    • Exploring with multiple CA policies and small Azure Function based automation can be used to shift users to other CA policies, once the initial strong proof up has taken place

The Setup

  • I’ve included all users from group ’FloridaIT3’ to be evaluated through this CA Policy

 

StrongProof UP

 

  • Create and Sync new user with mobile number field, and ensure that user will be part of the CA Policy in Azure AD

 

As1

 

connector space

 

  • Set MFA options to one-way-sms (You can add this automation to run with Start-ADSyncSyncCycle with little bit of powershell finessing, to ensure that all newly provisioned users are enabled for the strong proof up)
    • There might be some debate, in light of recent events (Reddit) whether SMS is a good second factor. I still find it adequate when its only used for initial on-boarding, where a user can’t have pre-enrolled OTP generating tokens in Authenticator

 

1 $users = Get-MsolUser -All

2 #Scope the users with filter, or Where {}

3 $scope = $users | where {$_.UserprincipalName -match "jeff"}

4 #Set options for MFA

5 $pf = New-Object -TypeName     Microsoft.Online.Administration.StrongAuthenticationMethod

6 $pf.IsDefault = $true

7 $pf.MethodType = "OneWaySMS"

8

9 foreach ($user in $scope) {

10 Set-MsolUser -UserPrincipalName $user.userPrincipalName -StrongAuthenticationMethods $pf

11 #display result

12 (Get-MsolUser -UserPrincipalName $user.userPrincipalName).StrongAuthenticationMethods }

 

 

Signin

 

  • User is asked for SMS confirmation before entering the page

 

enter code

 

  • We can see that authentication phone is pre-populated upon landing to proof up

 

additional verification

 

Testing with another user included in the same CA, but without setting the one-way-sms in PS results in weak authentication dialog

 

azure

 

If anybody is interested in further testing of this solution, just reach me at Joosua.santasalo@nixu.com.  Whether this is the default behavior in all tenants remains mystery.

 

    Related blogs