Fantastic PowerShell and where to find the CA Rules

Fantastic PowerShell and where to find the CA Rules

Automating your tenant deployment is crucial in preventing human mistakes.

This is one example from my own experience when working in the field 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 fired up a 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 rules created.

That’s odd because I got no error when deploying the first rule with PowerShell. So where is my conditional access rule?  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?

To doublecheck 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!

Somehow a guest account admin@wvdcloud.nl was created within my own company’s tenant.

After removing the user, it instantly worked. The Conditional access rule was created in the tenant it was meant for.  

Conclusion:

Lesson learned: When deploying scripts to multiple tenants from the same deployment device, always make sure you are in the correct tenant! And don’t forget to run clear-azurermcontext or disable auto-caching of tokens: Disable-AzureRmContextAutosave to be sure you are not working with a cached account.

Leave a Reply

Your email address will not be published. Required fields are marked *