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

Update 6.May.2019: There is new feature in Conditional Access, which allows creating a different policy for updating security properties, Sd

Please refer to the new user actions policy control <-

If there is 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 enrollment, 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 behavior is same when user has been enabled for MFA in the non-conditional access triggered ”old” MFA portal.
  • Why this works is that when 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 setup 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
Strong

User Assignments

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

assdf

  • 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 good second factor. I still find it adequate when its only used for initial on-boarding, where user can’t have pre-enrolled OTP generating tokens in Authenticator
$users = Get-MsolUser -All
#Scope the users with filter, or Where {}
$scope = $users | where {$_.UserprincipalName -match "jeff"}
#Set options for MFA
$pf = New-Object -TypeName Microsoft.Online.Administration.StrongAuthenticationMethod
$pf.IsDefault = $true
$pf.MethodType = "OneWaySMS"

foreach ($user in $scope) {
Set-MsolUser -UserPrincipalName $user.userPrincipalName -StrongAuthenticationMethods $pf
#display result
(Get-MsolUser -UserPrincipalName $user.userPrincipalName).StrongAuthenticationMethods }

sad

  • User is asked for SMS confirmation before entering the page

asss

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

sadasd

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

Newt

If anybody needs, test and maybe reply me back at this blog. Whether this is the default behavior in all tenants remains mystery.

Br, Joosua

Vastaa

Täytä tietosi alle tai klikkaa kuvaketta kirjautuaksesi sisään:

WordPress.com-logo

Olet kommentoimassa WordPress.com -tilin nimissä. Log Out /  Muuta )

Google photo

Olet kommentoimassa Google -tilin nimissä. Log Out /  Muuta )

Twitter-kuva

Olet kommentoimassa Twitter -tilin nimissä. Log Out /  Muuta )

Facebook-kuva

Olet kommentoimassa Facebook -tilin nimissä. Log Out /  Muuta )

Muodostetaan yhteyttä palveluun %s