On October 1st Microsoft states in this doc that they are starting to randomly disable Basic Auth in tenants. They even started to disable it last year for tenants that had not used it. It’s a good thing they are taking this step to make our tenants more secure. The big questions though is, are all organizations ready? Also, are there alternatives for the tasks we use basic auth for?
For the end user, I hope most organizations are using modern auth and MFA because there is no reason to don’t do it. The problem with disabling basic auth is at the IT admin’s end, or at least for this specific use case, I have run into. Today you actually can do most things through Graph API or Exchange PowerShell through certificate-based authentication. The newest preview of Exchange Online PowerShell 2.0.6-preview7 even lets you use managed identity, which is a great step forward.
My use case, setting the sensibility label at the time of or near as possible to group/team creation. I also sometimes set an extension attribute on the unified group to contain the ID of the label used at the time of group/team creation, to be able to automatically set the correct label again if a group/team owner has changed it(this is a story for another day, I would like to lock the label, so owners cant change it). I want to be able to set the sensitivity label automatically when someone uses a team creation order form and chooses the purpose of the team. I don’t want to run an interactive script every now and then to do this. If a task is manual, someone is bound to forget it one day.
First, I always look towards Graph API to see if it’s solvable. Even though the sensibility label is a property of a group, and a group can be created/updated with app rights, exactly this property is something for itself. On the docs of Update Group its states that applying a sensitivity label requires delegated rights:
I have even tried to add the assignedlabel property to the JSON when creating a group with Graph API, even though there’s no trace of it in the docs. I still get hit by app rights not supported.
Then I tried using certificate-based auth through the Exchange PowerShell module. I was able to connect and use commands like get-mailbox,set-mailbox, and get-unifiedgroup. But when testing new or set unifiedgroup I get hit by generic errors that group could not be created or updated at this time. I then tried to use a managed identity with the newest preview version of the PowerShell module and got hit with the same error.
So what do we do? It’s less than 2 weeks until Microsoft starts to choose tenants at random to disable basic auth. Do we set a reminder and run a script multiple times a day manually? Is there a solution that I have not thought about? I’m interested to hear from others if they have the same issue as me and if other scenarios won’t work without basic auth. Yes, there is a “hack” workaround, but that is not something you want to use in production and rely on. You could always create a service account and give it delegated rights. Then get an access token for Graph API, and have a scheduled task that refreshes that token every 40ish minutes. This kinda defeats the purpose of delegated rights and over complicates things.
Let’s hope there is a proper alternative soon, for example allowing to use app rights to update the sensitivity label!
One thought on “Exchange PowerShell without basic auth?”
Used Azure function web hook to do this. Pass it the group and the classification. Crazy you can’t set this during group creation.