Last Updated on December 27, 2021 by rudyooms

This blog will be about setting up the combined MFA security information registration experience and while configuring it with PowerShell, I will show you how I ended up enabling it/or disabling it in the wrong tenant. Yes, you are reading it correctly!

While I am showing you what got me the bug bounty, I will also show you some parts of our own tenant Deployment script.

I will divide this blog into 3 parts:

1. The combined security information registration experience
2. One PowerShell script to rule them all
3. The Problem itself

1.The Combined Security Information Registration Experience

Of course, this feature is GA for some time now…  When this option is enabled it will definitely increase the end-user experience when they need to configure MFA. I will show you in the next parts why I am showing you this!

Luckily, it’s enabled by default for all new Azure AD tenants, but the old ones… not quite yet.

If you want to change this in the GUI, you can open portal.azure.com –> Users –> User Settings –> User Feature Previews and select ALL

So, go open portal.azure.com and start enabling this for all your tenants!

2.  One PowerShell Script to rule them all

When a new customer (with nothing configured in Microsoft 365 until now) is being rolled out, we are using our superb PowerShell script which literally configures the whole tenant with only one script! No additional applications/registrations are needed.  Everything is PowerShell automated, except the Apple MDM certificate / Google Play Store connection / Microsoft Store connection parts.  

This PowerShell script will make sure all credentials have to be entered only once and will call upon all other PowerShell scripts which are needed to configure the tenant.

I’m very very glad, I am not doing this all on my own… I have created the basic configs and my colleague (Pieter Abresch –> no LinkedIn) is putting all the pieces together.

But a part was still missing. You can guess which part: combined security information registration experience aka convergedUXV2FeatureValue

3.The Problem itself

So we still needed to add this part to the script. When you need to know what each button does, open Fiddler.

I started Fiddler to look up which setting and which uri I needed. After changing the setting in Azure I got the correct url and the setting.

URL: https://main.iam.ad.ext.azure.com/api/Directories/FeatureSettingsProperties

SETTING: ‘{“convergedUXV2FeatureValue”:”2″}’

This is the script I was using to change the MFA setting. Please beware the main.iam.ad.ext.azure.com is not a supported API to script against! But it does work 😛

login-azurermaccount

$context = Get-AzureRmContext
$tenantId = $context.Tenant.Id
$refreshToken = @($context.TokenCache.ReadItems() | where {$_.tenantId -eq $tenantId -and $_.ExpiresOn -gt (Get-Date)})[0].RefreshToken
$body = "grant_type=refresh_token&refresh_token=$($refreshToken)&resource=74658136-14ec-4630-ad9b-26e160ff0fc6"
$apiToken = Invoke-RestMethod "https://login.windows.net/$tenantId/oauth2/token" -Method POST -Body $body -ContentType 'application/x-www-form-urlencoded'

$header = @{
'Authorization' = 'Bearer ' + $apiToken.access_token
'Content-Type' = 'application/json'
    'X-Requested-With'= 'XMLHttpRequest'
    'x-ms-client-request-id'= [guid]::NewGuid()
    'x-ms-correlation-id' = [guid]::NewGuid()
    }
$url = "https://main.iam.ad.ext.azure.com/api/Directories/FeatureSettingsProperties"
$contentpart1 = '{"convergedUXV2FeatureValue":"2"}'
$content = $contentpart1
Invoke-RestMethod –Uri $url –Headers $header –Method Put -Body $content -ErrorAction Stop

But nothing happened, no error, nothing. Some time ago I experienced almost the same thing when I was deploying some Conditional Access rules.

So, I almost forgot this persistent credential problem.

To be sure there were no cached credentials left, I made sure it was cleared.

Set-AzureRmContext -Context ([Microsoft.Azure.Commands.Profile.Models.PSAzureContext]::new())

But even after clearing the cache, it still didn’t work!

Because we are using a dedicated Windows 10 VM to enrol customers I decided to install a new Windows 10 Virtual machine to be 100% sure there were no other cached credentials or other misconfigured settings. After the VM was installed, I installed the azure-rm module to begin testing.

After the required module was installed, I opened a new PowerShell session and copy/pasted the PowerShell script and logged in with my test tenant credentials.

Just like in the other blog I wrote, the tenant id was again not the one corresponding with the wvdcloud tenant itself.

Looking back at the tenant Id in the PowerShell script, It was of course our own production tenant.

This happens because the admin from the test tenant is also a guest inside our own tenant and when you are requesting the tenant id through a AzureRM PowerShell script, sometimes it will show you the tenant id in which you are invited as a guest user. You could also just change the tenant id in the script is self instead of finding it automatically.

To be 100% sure, I was logging in into our own Production tenant, I opened the azure ad sign in log.

As shown above, I created a PowerShell session into our own tenant… nothing fancy you might think.

But why on earth can I change this setting when I am just a guest???

When you are putting all the pieces together.

• I logged in with admin@wvdcloud.nl
• I ended up creating a PowerShell connection to our own Deltacom tenant (IP whitelisted in CA rules to allow PowerShell connections to our tenant)
• I changed a setting in another completly different tenant as guest user. I was expecting a 403 error

I wanted to know if I could also change some other settings. I tried almost everything, luckily only the “combined security information registration experience” could be changed. (so far as I have seen)

Okay, maybe I totally screwed something over, so I reversed it. I invited rudy@deltacom.nl in the wvdcloud tenant and tested the same PowerShell script

I created a youtube video to watch:

And to be 100% sure I talked to a good friend and also fellow MVP Jan Bakker and tested the same thing within his tenant… you can guess the outcome 🙂

Conclusion:

The combined security information registration experience is a great improvement but why on earth could a guest user change this setting when using PowerShell???