Manage Autopilot with multiple tenants
Came back from New Orleans MMS Jazz conference two week ago, and I think I still have jet lag. But my mind is full of new ideas and knowledge, MMS Jazz is such a great event! In one of our session, we talked about automation, I showed how I use Logic Apps, Azure table storage, Azure key vault, and how to use Intune Graph API application permissions. There are lots of information here, that makes me hard to find a starting point to write this post.
In this post I will only talk about Intune Graph API with application permissions and how to use app authentication, I will write other follow up post later still.
Many of us properly manage multiple tenants, right? Sometimes we want to use one script do multi-tasking, and it’s not very automatic when we have to input our different tenants’ credentials every single time. Intune Graph API was originally support only delegated permission, but since October 2019, it supports application permissions as well. This is long waiting feature for us, at least for me. With application authentication, we no longer need to input user credentials. But of course, we need to remember handle our application client secret securely.
Graph allows two permission models: Delegated permissions and Application permissions. Delegated permissions are used by apps that have a signed-in user present, it checks if the application and user is allowed to use resources, we can image that’s like using a key to open doors with facial scan required. 🙂 In the other hand, application permissions are used by apps that run without a signed-in user present, it doesn’t not required any user credentials. For example, apps that run as background services or daemons.
Intune Graph Application permission for Autopilot
So how do we know what Graph permissions we need when wants to run some actions? We can check from Microsoft documentation and we can also figured this out by our own. Everything you do in Intune portal, there is Graph behind it. Open up your browser, push F12 for developer mode, go to Network tab. Now when you do some actions in Intune, you will see how the network traffic goes and most fun part here is, you can also see what URI Intune is making the Rest API call. As you can see in the below screenshot, when I was checking an imported Autopilot device details, Intune made GET Rest call to https://graph.microsoft.com/beta/deviceManagement/windowsAutopilotDeviceIdentities , now we go to Microsoft doc check about this windowsAutopilotDeviceIdentities, it said prerequisites for app permission is DeviceManagementServiceConfig.ReadWrite.All and DeviceManagementServiceConfig.Read.All
So by using F12, you can almost learn how to use Intune Graph by ourselves, it shows us how to use filter, expand, select and other queries, and how to make a POST call to create new item. I think this is very cool!
CREATE Azure Application
In some of my posts I have described how to create Azure application, for example https://www.scconfigmgr.com/2019/06/29/microsoft-graph-intune-fun-create-flow-connector-for-autopilot/. It’s not that difficult create a new application with proper permissions, and I always recommend create your own application, because that application is under your control, and you can add or remove permissions as you wish.
This time I don’t do step by step create Azure Application from Azure Portal, instead I will use PowerShell, since we are going to use this app for multiple tenants, I will also configure this app to support multi tenants. Here is the script, you only need to change $DisplayName if you wants different application name.
After you run this script, it should create a new Azure application for you, double check if application ID is as same as the output of the script.
IMPORTANT: Save the Application secret output, we will need that for later usage
Now we have created our application and assigned Application permissions, we need to do Admin Consent. By give Admin Consent, we allow this application access our tenants with those permissions that we assigned.
- Let’s open browser in Private mode, use this bellow url, but remember change 10f9be91-4c9b-4427-aa71-143d18abafb5 to your application id that you just created with the PowerShell script.
- Login with your tenants credentials. Example if you have tenant A and tenant B, you will need do this twice and login with tenant A and tenant B credentials. The credential you use need to be Global Administrator
- You will see this popup window after login, notice the first picture shows”unverified“, this is because I was using my tenant name as default Publisher domain name.
- (Optional) If you go to Branding, change publisher domain to your public domain, the Admin Consent popup will shows where this application is coming from, instead of unverified.
- After we click Accept, it will go to https://localhost url, saying page is not found, this is expect. Because we have configured our application reply url is https://localhost, so if we are not hosting any web service locally, this will just us an error. You can configure the Azure application reply url to something else, but must then remember change Admin Consent reply url to the same
How to use this application
Let’s say we have 10 tenants, we have a device that is imported to Autopilot, but we don’t know which tenant this device was imported. Sure we can reinstall the machine and see which tenant it ends up with. But how about let’s try do it in PowerShell and Microsoft Intune Graph way. Here are two scripts with different approach. In both scripts, you need to change $Serial, $Tenants, $AppID and $AppSecret to your own values.
The first script below is using Microsoft.Graph.Intune module
The second script below is not using any module, it use POST call gets access token, then use access token to access Autopilot resources
So I hope after reading this long post, you get some ideas how to use Intune Graph application permission with user authentication. Hopefully you find it useful and get some ides for your automation tasks.
Sandy is an Enterprise Mobility MVP since 2018. She has been working in the IT industry since 2009, primarily dealing with device management solution planning and implementation. Sandy has worked with SCCM, MDT, Group Policy, software packaging, problem solving. Sandy currently works for a large Finnish company with several thousand endpoints as system architect. In 2016, Sandy founded the https://thesccm.com blog and is now a guest blogger on SCConfigMgr.