After installing the appropriate PowerShell modules you can connect to the Microsoft Graph with PowerShell using the command:
connect-graph
as shown above. First thing to remember is that this process can’t be completed in the Power ISE, you’ll need to do it elsewhere (here, using Windows terminal). The second thing to note is that you can specific the scope with which you to connect. Thus, in this case, the scope will be Files.ReadWrite.All and Sites.Readwrite.all. The scope is in effect the permissions the current user will be given when they connect to the Microsoft Graph. This allows you to only provide permissions for exactly what you need.
During the connection process you’ll be asked to consent to the permissions just requested, as shown above. If you simply select Accept here, you are just consenting for the current user. However, if you check the Consent in behalf of your organization option you’ll be providing these permissions to ALL users in your tenant! For now, only consent will be granted for the current user. However, be very, very careful consenting for the whole organization as I will illustrate.
You can now happily go off and perform whatever actions you need to using PowerShell for the Microsoft Graph.
With security in mind, I went to have a look at where these permissions just consented to actually appear. You’ll find them by opening the Azure Portal and navigating to Azure Active Directory as shown above. From here, select Enterprise applications from the menu on the left.
From the screen that appears ensure All applications is select from the menu on the left. Then on the right, locate and select Microsoft Graph PowerShell as shown.
From the screen that now appears, select Permissions from the menu on the left as shown. On the right you’ll then be able to select either Admin consent or User consent.
Because the permissions assigned were only for a single user, the User consent item will show these to us as shown above. This list of permissions matches those consented to when connecting to the Microsoft Graph.
The right hand most column in this display, Grant by, has a hyperlink to show the number of users with this assigned permission.
If you select any of these hyperlinks, you’ll see a list of users, on the right, that have been assigned this permission appear on the right as shown above.
Can you see the problem yet? No? Well…….how do you REMOVE or revoke a permission here?
From what I can determine, you can’t remove the permissions via the portal. If you select Review permissions menu option you’ll see a item displayed from the right as shown above. If you select the option This application has more permissions that I want and basically told to use PowerShell to revoke all permissions for this application as well as being provided with the code to do so.
The issue is that even after you disconnect from the Microsoft Graph, having completed any scripting, those consented permissions remain in place i.e. they are NOT rescinded. This means that if the user account with these permissions to the Graph is compromised then that attacker has access to the Microsoft Graph and potentially lots of sensitive areas in a tenant, especially if the permissions have been added to over time. Imagine how much WORSE it gets if permissions were consented tenant wide, rather than to an individual user?
Selecting that little check box in the above Permissions requested dialog, which I see MANY people do without thinking, can really give you a security headache by opening up your Microsoft Graph permissions for EVERY user in the tenant!
Thus, best security practice is going to be to remove these permissions when they are no longer required as well as limiting who has them initially. Personally, I’d remove them after each interaction so I don’t forget and leave a potential attack vector.
To make doing all that a little easier, I have gone out and created a script that you’ll find in my Github repo:
https://github.com/directorcia/Office365/blob/master/graph-adappperm-del.ps1
If you run the script, it will first check whether the Azure AD PowerShell module is loaded. If it is, it will then ask you to login to your tenant. Then it will display a list of all the Azure AD applications in your tenant and allow you to select the ones you want to change (yes, you can select multiple Azure AD apps if you want) as shown above.
In this case, Microsoft Graph PowerShell application is selected.
You’ll then be prompted to select whether you wish to select Admin consent and/or User Consent permissions. You can select both here if you wish by using the CTRL and/or SHIFT key when making selections (i.e. just like when you use Windows Explorer).
If you selected User consent, you’ll then be prompted to select the users you want. Again, multiple selections are available if offered.
You’ll now be prompted to confirm you wish to delete these permissions for these users.
Those permissions will be removed and the script will continue to work through the rest of your selections.
In this case, because there were no Admin consented permissions for this application we receive a notification line as shown in above output.
If you now return and have a look at the permissions for that app in the portal, you should see they have all been removed as shown above.
Leaving users with standing permissions to something as powerful as the Microsoft Graph is not best security practice. It is therefore important to regularly review these and remove what is not required. If you need those permissions again in eth future, after they have been removed, you can always re-consent to them when you next connect to the Microsoft Graph.
CIAOPS 