Configuring the eG Agent to Monitor Microsoft Azure Intune Using Intune REST API
To achieve the above, you need to perform the following broad steps:
-
Register an Application with a Microsoft Entra Tenant;
-
Determine the Tenant ID, the Application (Client) ID and Secret Key value associated with the registered Application;
-
Assign API permissions to the registered Application.
If an Azure Subscription is already monitored in your environment, then you can use the same Application you created for Azure Subscription monitoring to monitor the Microsoft Azure Intune as well. In this case therefore, you would only need to perform step 3 above. Refer to Assigning API Permissions to the Registered Application topic to complete step 3.
On the other hand, if such an Application does not pre-exist, then proceed to create one. For that, you need to follow steps 1 - 3 above. In this case, follow the procedures outlined in all the sub-sections, so that the Microsoft Azure Intune is monitoring-ready.
Registering an Application with Microsoft Entra
A Microsoft Entra Application is a digital identity and some associated configuration, which informs Microsoft Entra about how to treat software which uses that digital identity.
The eG agent can pull performance metrics related to an Azure tenant, its services, and its resources, only if it communicates with a Microsoft Entra tenant as an 'Application' with 'monitoring rights'.
If such an Application pre-exists with the target tenant, then you can configure the eG agent with the access credentials of that application. However, if no such application pre-exists, then first register a new Application with Microsoft Entra and obtain the access tokens that Microsoft Entra issues for that application.
To achieve this, do the following:
-
Login to Microsoft Entra admin center with valid credentials.
-
Figure 382 will then appear. Click on the App Registrations option in the left pane of Figure 382.
-
When Figure 383 appears, click on New registration to begin registering a new app.
-
Figure 384 will then appear.
-
In Figure 384, specify the following:
- The name of the application in the Name text box,
-
Select the type of the account from the Supported account types section.
Supported account types Description Accounts in this organizational directory only
Select this option if you want all user and guest accounts in your directory to use the application or API.
Use this option if your target audience is internal to your organization.
Accounts in any organizational directory
Select this option if you want all users with a work or school account from Microsoft to use this application or API. This includes schools and businesses that use Office 365.
Use this option if your target audience is business or educational customers and to enable multitenancy.
Accounts in any organizational directory and personal Microsoft accounts
Select this option if you want all users with a work or school, or personal Microsoft account to use your application or API. It includes schools and businesses that use Office 365 as well as personal accounts that are used to sign in to services like Xbox and Skype.
Use this option to target the widest set of Microsoft identities and to enable multitenancy.
Personal Microsoft Accounts only
Select this option if you want the application or API to be used by only those users with personal accounts that are used to sign in to services like Xbox and Skype.
-
Then, enter the redirect URl (or reply URL) for your application in the Redirect URl text box (see Figure 385). Typically, you need to provide the base URL of your app. For example, http://localhost:31544 might be the URL for a web app running on your local machine. Users would use this URL to sign in to a web client application. For public client applications, provide the URL used by Microsoft Entra to return token responses. Enter a value specific to your application, such as https://DocApp.com//auth.
-
Clicking the Register button in Figure 385 will create the Application. Then, Figure 386 will appear displaying the Essentials related to the new Application.
-
From the Essentials, you can obtain the Application ID and Directory ID (see Figure 386). Copy the Application ID and the Directory ID and paste them against the Client ID and TENANT ID text boxes while configuring eG tests for the target Azure component.
Obtaining the Client Secret
For the eG agent to obtain metrics from the target Microsoft Azure component, it is necessary to provide the client secret associated with the registered Application. For this, click on the Certificates & secrets option in the left pane of Figure 386. This will invoke Figure 387.
Figure 387 : Creating New Client Secret
Clicking on the New client secret button in the right panel of Figure 387 will invoke Figure 388. Specify the description of the client secret in the Description text box and choose an expiry period from the Expires section as shown in Figure 388.
Figure 388 : Adding the client secret
Clicking the Add button in Figure 388 will display a client secret value in the Value column of Figure 389.
Figure 389 : Generating the client secret value for the application
Note that the Value will disappear once you leave this page, so make sure that you copy the new client secret value in the clipboard by clicking the
icon. Otherwise, you may need to generate a new client secret value. The client secret value has to be specified against the Client password field in the test configuration page.
Assigning API Permissions to the Registered Application
As already mentioned, the eG agent connects to Microsoft Azure Intune as a registered Application, makes REST API calls, and collects metrics from it. Most commonly, the eG agent uses the Microsoft Graph API for metrics collection. To enable this API to pull metrics, you need to grant different 'read' permissions to that API. For granting these permissions to the Microsoft Graph API for the registered Application, do the following:
-
In Figure 389 above, click on the API Permissions option in the left pane. Figure 390 will then appear.
-
As you can see, the registered Application has by default being assigned a Delegated permission; this is the User:Read permission for Microsoft Graph API. Since this permission is not required for monitoring purposes, let us proceed to remove it. For that, first, right-click on the permission listed in the right pane of Figure 390, and select the Remove permission option from the menu that pops out (see Figure 391).
-
A message box will then appear requesting you to confirm the deletion of the default permission. Click on the Yes, remove button in Figure 392 to delete the chosen permission.
Figure 392 : Confirming the deletion of the default permission
-
Next, proceed to assign permissions that the Application needs for pulling metrics from Azure Intune. For this, first click on the Add a permission button in the right pane of Figure 391. Figure 393 will then appear. Click on the Microsoft Graph option in Figure 393 to set permissions for the Microsoft Graph API.
-
Figure 394 will then appear, where you will have to choose the type of permissions you want to add to the API. Click on the Application permissions option in Figure 394.
-
Using Figure 395 that then appears, select the permission that you want to grant to the API. For this, type the text 'user' in the Search text box under Select permissions. Permission groups with names containing the typed text will then be listed hereunder. Keep scrolling down the list of permission groups until the Directory group becomes visible.
Figure 395 : Searching for the permission groups with names containing the text 'Directory'
-
Once you find the Directory group, expand it by clicking on the 'arrow' prefixing it. The individual Directory permissions will be listed therein. Select the Directory.Read.All permission by clicking on the check box corresponding to it (see Figure 395). Then, click on the Add permission button in Figure 395 to assign that permission to the API.
-
Figure 396 will then appear displaying the permission that you just assigned.
Figure 396 : A page displaying the Directory.Read.All permission assigned to the API
-
Next, click on the Grant admin consent for Default Directory button in Figure 396. Figure 397 will appear. Click on the Yes button in Figure 17 to grant consent for the Directory.Read.All permission for all accounts in Default Directory.
Figure 397 : Granting consent for the Directory.Read.All permission for all accounts in Default Directory
-
The Directory.Read.All permission listing will then change as depicted by Figure 398.
Figure 398 : The Directory.Read.All permission listing after granting admin consent
-
Next, using step 4 - 10 above, add the following 'read' permissions as well to the Microsoft Graph API for the registered Application:
-
Group.Read.All
-
AuditLog.Read.All
-
Device.Read.All
-
Application.Read.All
Refer to Figure 399, Figure 400, Figure 401, and Figure 402 to more clearly understand how to assign each of the above permissions.
Figure 399 : Assigning the Group.Read.All permission
Figure 400 : Assigning the AuditLog.Read.All permission
Figure 401 : Assigning the Device.Read.All permission
Figure 402 : Assigning the Application.Read.All permission
Also, note that after adding each permission, you have to click on the Grant admin consent for Default Directory button (like the one you see in Figure 396) to grant consent for that permission for all accounts in the Default Directory.
-
-
Next, you should assign API permissions to read Microsoft Intune application, device configuration and policies. For this, type the text 'device' in the Search text box under Select permissions. Permission groups with names containing the typed text will then be listed hereunder as shown in Figure 403. Keep scrolling down the list of permission groups until the DeviceManagementApps group becomes visible.
Figure 403 : Searching for the permission groups with names containing the text 'Device'
-
Once you find the DeviceManagementApps group, expand it by clicking on the 'arrow' prefixing it. The individual DeviceManagementApps permissions will be listed therein. Select the DeviceManagementApps.Read.All permission by clicking on the check box corresponding to it (see Figure 403). Then, click on the Add permission button in Figure 403 to assign that permission to the API.
-
Next, expand the DeviceManagementConfiguration group by clicking on the 'arrow' prefixing it. The individual DeviceManagementConfiguration permissions will be listed therein. Select the DeviceManagementConfiguration.Read.All permission by clicking on the check box corresponding to it (see Figure 395). Then, click on the Add permission button in Figure 395 to assign that permission to the API.
-
Next, expand the DeviceManagementManagedDevices group by clicking on the 'arrow' prefixing it. The individual DeviceManagementManagedDevices permissions will be listed therein. Select the DeviceManagementManagedDevices.Read.All permission by clicking on the check box corresponding to it (see Figure 403). Then, click on the Add permission button in Figure 403 to assign that permission to the API.
-
Finally, expand the DeviceManagementServiceConfig group by clicking on the 'arrow' prefixing it. The individual DeviceManagementServiceConfig permissions will be listed therein. Select the DeviceManagementServiceConfig.Read.All permission by clicking on the check box corresponding to it (see Figure 404). Then, click on the Add permission button in Figure 404 to assign that permission to the API.

Figure 404 : Searching the DeviceManagementServiceConfig group
-
Figure 405 will then appear displaying the permissions that you just assigned.
Figure 405 : A page displaying the permissions assigned to the API
-
Next, click on the Grant admin consent for Default Directory button for each permission assigned to the API in Figure 405 as discussed in step 9.
-
Once all the permissions are assigned and the admin consent is granted for each permission, Figure 406 will appear.
Figure 406 : A page displaying all the 'read' permissions assigned to the Microsoft Graph API for the registered Application