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

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

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

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

• Now as the user tries to access the proof up page 2FA dialog comes up https://account.activedirectory.windowsazure.com/proofup.asp

• User is asked for SMS confirmation before entering the page

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

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

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.