Huge permissions overhaul and reduction, a nice case of practice what you preach we finally got around to 🙂

Huge permissions overhaul and reduction, a nice case of practice what you preach we finally got around to 🙂

The IMDS service allows retrieving tokens for e.g. the Graph API, assuming your managed identity has permissions for it.
But what if you forgot to assign permissions? If you already requested a token, you’ll have to wait an hour because IMDS caches its responses, and there is no documented way to bypass the IMDS cache.
By digging into some old MS modules, I accidentally discovered an undocumented parameter you can add to our IMDS call, which immediately mints a new token. Imagine my surprise, no idea why this isn’t documented as it is useful in all kinds of rollout or escalation scenario’s!
Anyway, to bypass the cache, add bypass_cache=true to your GET params! Example:
http://169.254.169.254/metadata/identity/oauth2/token?api-version=2019-08-01&resource=$($resource)&bypass_cache=true
Offboarding has always been an interesting case, and one I rarely see customers do 100% right. The will is there, often focused on keeping access to data or reclaiming licenses.
But execution is a whole different world. Automation for onboarding often exists, offboarding rarely, and if it exists, it is usually still triggered manually, and more often than not only for managed accounts (admins, guests, service accounts etc are totally forgotten), and then what is actually done upon offboarding?
Microsoft Graph has an option to subscribe to changes, specifically for user objects. This means we can listen to deactivation, idle (x days inactive) or deletion events and act accordingly. E.g. unshare onedrive, notify a manager of flows and powerapps or teams the user still owns, reclaim licenses, disable upon inactve, etc etc.
So I co-wrote a little PowerShell solution, of course perfectly based on best practises around MI auth, least privileges and assume breach.

It lets you configure WHAT (loads of things, expandable) to do WHEN (inactive, delete, deactivate), and runs at almost no cost in your own azure subscription, as usual, open source and a oneliner to install: https://github.com/jflieben/M365AutoRevocate
A nicer installer!

And more changes:

Using PSPublishModule to load the Exo module has finally solved this error:
Get-EXOMailbox: Could not load file or assembly 'Microsoft.OData.Core, Version=7.22.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'. The located assembly's manifest definition does not match the assembly reference. (0x80131040)
Get the PS runbooks / installer here: https://github.com/jflieben/DriftMaester
Or if you already run it, it’ll automatically update tomorrow 🙂