I'm a huge fan of Azure Automation. If you're an #AzureAD / #M365 Admin and haven't used it before, then this thread is for you
You will need an Azure subscription, but the first 500 minutes/month are free!
Here's an example of how to automate Azure AD device cleanup :)
First, we're going to log into the Azure portal: portal.azure.com
Search for Automation and click on Automation Accounts
Then we'll click Create, pick the sub and resource group (or create one), give it a descriptive name, select a location, and hit Review + Create
If you haven't heard, the MSOnline and AzureAD PowerShell modules are going away at the end of the year
Instead, we are going to use the new Graph SDK PowerShell modules
So let's go under Modules, click Add a Module, browse the gallery, and add Microsoft.Graph.Authentication
Now, the Graph SDK PowerShell modules are a bit... different
There are modules for every scope rather than one large module like we used to have. So we just did the one required for Authentication, and we also need to add the Microsoft.Graph.Identity.DirectoryManagement module
Now, we need to create a Run as account since Automation's Managed Identities only work for Azure resources (AFAIK - please correct me!)
Next up, we need to grant Graph API permissions to managed devices to the Service Principal that was just created by our Automation Account
So let's head over to App registrations and search for the name of our Automation Account
Select the account, then go to API permissions, and click Add a permission
In the Request API permissions dialog, click Microsoft Graph, then select Application permissions
In the filter, we'll search for Device.ReadWrite.All
Expand Device, check the box for Device.ReadWrite.All, then click Add permission
Now click Grant admin consent for the Service Principal to be authorized for your tenant and confirm
The final step is to create our Runbook
Go back to your Automation account, click Runbooks under Process Automation, and then click Create a runbook
Give it a name, select PowerShell for type, and the runtime needs to match modules, so 5.1 if following the images so far
You can test code in the Test pane (add -WhatIf), but first... Apparently Graph is different than AzureADPreview, so we will need one additional step - adding the Service Principal to the Cloud Device Administrator role
Whoops, don't forget to Publish!
Now go to Azure AD - Roles and Administrators, earch for Cloud Device Administrator, click Add assignments, then search for the Service Principal for your Automation Account, and add it.
You should now be able to run with proper permissions!
If we go back to our Automation Account and look at the Runbook we just created, we can manually run this script by clicking Start. This will take us to the job where we can see output.
We can also see the history under Jobs for our Automation Account.
But let's schedule this!
Open your runbook, then click the Link to Schedule button
We want to link a schedule to our runbook, then add a schedule, and then configure it how we want :)
Here's an example of running daily at midnight
And that's really all there is to it!
You are now automating disabling of devices that haven't talked to AAD in 90 days :D
• • •
Missing some Tweet in this thread? You can try to
force a refresh
So you don't enforce MFA on all Azure admin roles? Not really sure where to start?
Looks like Microsoft has added a nice doc (and script in the doc) to help discover and assess your privileged users so you can minimize potential impacts ;)
I think it's great they are pushing more and more content to make the message clear - all admins should be covered by strong authentication / conditional access policies
I am really curious about this though.. Anyone know what this refers to?
By the way, the docs here should be updated with a link to the Azure MFA Wizard (the docs folks are so awesome!)
While doing this setup through the M365 admin center is not required, it sure makes life easier if you don't know the DNS records off the top of your head
So we go under Settings - Domains, and you should see something like the picture below
Check your domain and continue setup
Now I'm going to warn you ahead of time, Microsoft has made some really dumb choices here...
I know it's to make life easier on people, but, well, you'll see :(
OK, so they tell you to add DNS records, and I'm going to hit Advanced Options and get the AAD/Intune records too
I know it's hard to do something that will last 20+ years, and maybe design choices from the 90's weren't the best ideas...
There are foundational issues that need to be addressed. A clean install of windows ruined by its foundation.
The amount of failures I'm seeing are just unacceptable. We can all agree who is mostly to blame, but that won't help fix the years of rot we're looking at.
I do believe this can be fixed, but it's going to require removing old, vulnerable crap and rebuilding with a better base
The bandaid fix approach used over the last 20 years has obviously failed the test of time
It may look OK on the outside, but it's lipstick on a pig. Eventually someone pays for the underlying issues.
In Azure AD, we have a few different types of groups
The main group types are security and Microsoft 365 groups, but in Exchange we also have distribution lists which are mail enabled groups with no security context
Each group also has an assigned and dynamic membership type
Now, before we start creating groups, I need to warn you that Microsoft stupidly believes any user should be able to create groups, both security and M365 types
What you should know is that they can select any email address they want 😱