Automating your tenant deployment is crucial in preventing human mistakes. One of the many examples you could automate would be the deployment of the Conditional Access Rules. Looking back at this blog, this blog was the predecessor of the Bug bounty blog I wrote later on. Feel free to read it!

1.Introduction

This is an example from my own experience when doing some nice work with PowerShell and JSON. When automating your Conditional Access deployments as I did, you can run into some very weird situations… So, what did I do?

I was trying to deploy some new conditional access rules to my test tenant. There are of course better methods available now to deploy conditional access rules to your tenant like I am showing in this blog

But at the time of writing the first version of this blog, I was making use of the “https://main.iam.ad.ext.azure.com/api/Policies/” url and Get-AzureRmContext to get the Api Access Token like shown below

login-azurermaccount -Credential $Cred
$context = Get-AzureRmContext
$tenantId = $context.Tenant.Id

$SubscriptionId = $context.Subscription
$cache = $context.TokenCache
$cacheItem = $cache.ReadItems()
$refreshtoken=$cacheItem[$cacheItem.Count -1].refreshtoken
$body = "grant_type=refresh_token&refresh_token=$($refreshToken)&resource=74658136-14ec-4630-ad9b-26e160ff0fc6"
$apiToken = Invoke-RestMethod "https://login.microsoftonline.com/$tenantId/oauth2/token" -Method POST -Body $body -ContentType 'application/x-www-form-urlencoded'

$headersazurerm = @{
'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()
    }

So I deployed the new Conditional access policies to my test tenant… but that’s what I thought I was doing!

2. The Problem

I fired up a new PowerShell session from a special Win10 VM (created for deployments) and logged in with my admin user within the customer (test)tenant WVDCLOUD: admin@wvdcloud.nl. I checked once again if it was the correct user.

Get-AzureRmContext

Yes…I am admin@wvdcloud.nl. Nice… So, I deployed my first conditional access rule to begin testing with.

To check if the rule was created, I opened Intune but there weren’t any new CA rules created!

That’s odd because I got no error when deploying the first rule with PowerShell. So where are my new conditional access rules?  And then I noticed something…the TenantID, it looked really familiar. I opened the tenant for the company I work for. And there it was: a3e3e358- …..

To be sure, I opened my own company’s Intune, and there it was… the Conditional Access rule I deployed!

So, I ran the login-azurermaccount script to login with admin@wvdcloud.nl and ended up within my own company’s tenant and I was able to deploy a conditional access rule to it? What the heck?

3. What went wrong?

To double-check if I was going crazy: first I logged in with my own Deltacom account. Disconnected and logged in again with the wvdcloud.nl account.

 So, I disconnected again. I immediately noticed the difference: 2 Tenants instead of 1!

I guess somehow while testing other stuff, a guest account admin@wvdcloud.nl was created within my own company’s tenant. After removing the guest user, it instantly worked. The Conditional Access rule was created in the tenant it was meant for.  

After doing some “googling” I stumbled upon this command line: Disable-AzureRmContextAutosave to disable auto-caching of tokens

You could also run the clear-azurermcontext when you are done doing some PowerShell stuff.

But looking back at this blog, It feels weird… I guess I was doing the same with Conditional Access as with the MFA Combined Security Information Registration Experience

Conclusion:

Lesson learned: When deploying scripts to multiple tenants from the same deployment device, always make sure you are in the correct tenant!