Microsoft Graph PowerShell allows you to perform management and administrative tasks to Microsoft 365 and Azure AD through the command line. If you haven’t used it before, when you do, you may notice the initial concept behind running the connect cmdlet and logging in with your admin credentials is similar to what you are used to. However, the issue is that it is not the same… The module is designed to connect to an application in Azure AD which is explicitly consented to specific permissions for Microsoft Graph, either through delegated or application permissions. This poses some security considerations both with Azure AD Applications and how you connect to Microsoft Graph through PowerShell.
In this tutorial, I am going to detail these security considerations and the issues that arise because of this, as well as show you how to use Microsoft Graph PowerShell securely.
Security considerations for Microsoft Graph PowerShell
The default application name is always the same
Once you install the Microsoft Graph PowerShell module and connect to Microsoft Graph with delegate permissions, which will be most common at the start, a common enterprise application will be registered in your tenant called ‘Microsoft Graph Command Line Tools’. The application ID is set to ’14d82eec-204b-4c2f-b7e8-296a70dab67e’ which is consistent across all tenants and if it is recreated in the same tenant. This means that the application is easily identified by good and back actors. As well as this, you don’t event need to specify the default application name, just Connect-MgGraph itself will do.
To consent delegate permissions, you must be a global admin
Connecting to Microsoft Graph with delegate permissions is easy and the process is ‘almost’ exactly what you will be familiar with when using older modules such as the MSOnline and AzureAD modules. However, when you are connecting to the first time, or you haven’t specified a specific permission in the past, you will need to be a Global Admin in your tenant to consent the permissions to the Microsoft Graph Command Line Tools in Azure AD. These permissions are then permanently assigned to the application, not just for the duration of your session.
Permissions only need to be consented to by one admin once, for everyone
Once you connect to Microsoft Graph for the first time you no longer need to specify the permissions again and you will have the same level of access as before, maybe even more so if permissions have built up over time. You can review this by using the Get-MgContext cmdlet or by viewing the application permissions in Azure AD. The issue here is that (especially with 3rd party managed IT providers), permissions to the default app build-up, which may lead to future sessions being heavily over privileged.
Anyone can use the consented permission by default in their user context
The default user assignment setting for the Microsoft Graph Command Line application in Azure AD is to not require user assignment. That means that any user in your environment can use Connect-MgGraph cmdlet in a PowerShell session (Conditional Access permitting) to connect to Microsoft Graph and have programmatic access to the data within their user context. That means that one moment an admin user can make a privileged change using Microsoft Graph, and then other privileged users can programmatically access the same data also. Although this may not seem like an issue, you are helping attackers exfiltrate data very quickly in the event of a compromise.
Overtime sessions will become over privileged
There is no simple way to ‘un-consent’ or remove consented permissions to the app in Azure AD. Your options are to remove the permissions delegated permissions via the legacy Azure AD PowerShell module or delete the app in Azure AD manually (somewhat preferred). However, if you delete and recreate the app, you will need to remember to update the ‘Assignment required’ property to Yes.
Conditional Access kind of works...
You can use conditional access to restrict access to the applications that you use to connect to Microsoft Graph PowerShell with, including the built-in application, but it will not work. You target access to Microsoft Graph with Conditional Access you must select ‘All Cloud Apps’.
How to Secure Microsoft Graph PowerShell Access
Some of the below settings may not completely apply to you or your organisation. However, they should all be understood, as one way or another, implementing them will provide additional security benefits for your tenant. In no particular order, follow the steps below for each recommendation.
Block or limit user application consent
By default, users in your organisation can grant consent for applications permission to view details about their account. I recommend this is locked down so only a minimal amount of information can be consented to. This allows critical application to login with the users account if necessary but reduces the amount of information the application can view. Follow the below steps to only ensure the minimal amount of information can be consented to, this information is classified as ‘low risk’.
1. Login to Microsoft Entra here: https://entra.microsoft.com/
2. Expand Applications and Select Enterprise applications
3. Select Consent and permissions
4. Then on the User consent settings tab, select Allow user consent for apps from verified publishers, for selected permissions (Recommended)
5. On this same page, click Select permissions to classify as low impact
6. On the Low tab, click Add permissions and add the following permissions:
- Profile > View users’ basic profile
- Openid > Sign users in
- Email > View users’ email address
Set the default Microsoft Graph Command Line Tools app to Assignment Required
The ‘Assignment required’ opening for applications in Azure AD ensure they not everyone can connect to your application by default. This will allow you to ensure that only manually defined users/groups will be granted rights to connect to your application and hence access the data that it has been consented to access. Follow the below steps to ensure only specific users can access the default or any custom application with Graph permissions.
1. In Microsoft Entra, select Applications > Enterprise applications
2. Open the Microsoft Graph Command Line Tools Application
3. Click Properties then change Assignment required to Yes.
Minimise the amount of global admins
Review your global admins. Do you have the recommended amount of global admins and are you monitoring administrative tasks? You can also use PIM to control and monitor privileged roles. Follow the below steps to review any active and eligible assignments for the global administrator role.
2. On the All roles tab, select Global Administrator from the roles list
3. Review the Eligible and Active assignments tab then verify if each user still requires global admin access, remove those accounts which do not need Global admin rights
Use custom applications in Azure AD with pre-assigned Microsoft Graph Permissions
By blocking access to the built-in Microsoft Graph Command Line Tools application and creating specific Microsoft Graph Applications with the necessary permissions to complete the task, you are ensuring there are no over-privileged applications in your tenant and that only the necessary personnel can connection to that application.
Follow my detailed guide Here: ‘Connect To Microsoft Graph PowerShell With a Client Secret‘ and follow the steps for creating an application in Azure AD and assigning the relevant permissions.
To the connect to your specific application with the Connect-MgGraph cmdlet, you can use the -ClientId and TenantId parameters.
Connect-Mggraph -ClientId <ClientId> -TenantId <TenantId>Use unique identities to target access with stronger conditional access
If you haven’t already, you should configure new identities (user account) for administrative tasks and these accounts should be locked down heavily with conditional access. The issue with Microsoft Graph PowerShell is that the app cannot be directly targetted with Conditional Access and you must select ‘All Cloud Apps’ to apply additional security for accessing the app. As such you should design your access such as only specific identities should have access at the Azure AD Application level, and then them identities should be targetted with a strong conditional access policy targeting all cloud apps.
Provide admin training to your IT staff
Lastly, it is important that your IT staff are familiar with what is changing regarding administering Microsoft 365 and Azure AD with PowerShell. While some tasks have likely become second nature, changes are happing quickly and vastly, so it is important that you dedicate in-hours training time for your teams.
Summary
In conclusion, there are some overlooked default configurations while using the Microsoft Graph PowerShell application. Bundled in with poor user permission management and the assignment of privileged roles to everyday user accounts, you could have a ticking time bomb that you don’t even know about. The steps detailed in this post will help minimise attacks and privilege escalation paths in your tenant that could be exploited with Microsoft Graph PowerShell.
