Use PowerShell to report on Azure AD Enterprise Application Permissions

Many Microsoft customers are now taking steps to try and modernise and centralise SaaS app identity by using Enterprise Applications within Azure AD to provide authentication, provisioning and reporting services.

This can be done by Administrators by adding applications into the AzureAD tenant and assigning users to them, or by Users (if you let them) who can self-service applications (think the Log in with Facebook / Google buttons). Applications which are added will have certain permissions assigned which will allow said application to be able to access AzureAD properties via the Microsoft Graph API.

These permissions can be as simple as allowing the application to read the users displayname, all the way to having full access to all files which the user can access in Office 365. You can see these permissions in the GUI by logging onto and navigating to Azure Active Directory>Enterprise Applications>Application Name>Permissions, as seen in the screenshot below. We can see that the Adobe Document Cloud application has had Admin consent to have full access to all files the user can access, and to sign in and read user profile. You can see the full range of available permissions in the Microsoft Graph, and what they all mean here.


This GUI feature is great for looking at individual applications, but if you are allowing users to provide consent themselves, or you are making full use of the Enterprise Applications feature, you are likely to have many applications listed here, and checking them one by one using the GUI is not efficient.

As always, PowerShell is able to come to the rescue. If we connect to the AzureAD v2 Powershell module by using Connect-AzureAD, we can export these permissions. Unfortunately, because of the way the data is presented, we need to do a little data massaging to make this possible.

Firstly, we need to get a list of all applications, and this can be done using:

Get-AzureADServicePrincipal | Select DisplayName,Homepage,ObjectID,AppDisplayName,PublisherName,
ServicePrincipalType | Export-Csv c:\reports\azureadsp.csv

This PS command will get a list of all the Service Principals (read: applications) you have configured, however it will not list the permissions. We need another cmdlet for that. The item we are most interested in for the Service Principal is the ObjectID, as this is the value we can use to map the Service Principal to the Permissions.

The next PS command we need is:

Get-AzureADOAuth2PermissionGrant | Select ClientID,Scope,ConsentType | Export-CSV :\oaauthperms.csv

This PS command will get a list of all the permissions granted in AzureAD. The important value here is the ClientID, which refers to the application, and the Scope, which refers to the permission level as described in the Graph Permissions article.

With this data we have two .csv files, and we need to compare the ObjectID from azureadsp.csv with the ClientID from oauthperms.csv. If we find a match, we need to copy the Now I’m no Excel expert, and there are probably better ways of doing this, but this was my method.

I copied the columns from azureadsp.csv into the oauthperms.csv. Let’s say the ObjectID value from azureadsp.csv ended up on row J. I would then create a new column called Application Name, at column A. I then used the INDEX, MATCH formula to look for identical ObjectID and ClientID values, and if a match was found, populate the Application Name.


The formula used looks like this:


Substituting the column names for logical names looks like this:


This gives us a value in Application Name which shows us the application which has been given rights to the Microsoft Graph and can enable us to easily see and filter which permissions have been given to which application. This can be used for management purposes, reporting and security auditing.

Hopefully this is useful for you, and if you think this could be improved upon please let me know in the comments!


Where’s Wally?

Over the last year, has, to my shame, been left in a corner to gather dust. This wasn’t my intention. I enjoy writing, and have thoroughly enjoyed seeing people use this site to find solutions to the problems they have come across during their migrations, deployments and installations. It wasn’t due to a lack of enthusiasm that I went quiet, but due to a couple of things, which I’d like to explain for you now.

For those of you with a keen eye, or who know me personally, you will have noticed that I changed both my name and gender over the last two years. The URL of the website changed too; it used to be, a half-accidental double entendre using the initials of my old name. You’ll still see references to it in older posts. Now it’s probably no surprise to learn that being transgender and going through a gender transition takes a pretty hefty toll on time and energy, and to be honest, I had nothing left to give outside of my normal day to day life. Thankfully, I can say that most of the major change is behind me now, and instead I can enjoy what is ahead of me.

The second reason why has gone quiet, is that I had a fairly significant change in job. For the last year and a half, I have been working at Microsoft as a Premier Field Engineer. It was a big change and my focus has shifted from technical deployment and troubleshooting, to education and assessment. Although being a PFE requires deep technical knowledge of my product areas (Identity, Security and Networking in Office 365), it is also much less hands on. I simply wasn’t seeing the kind of problems I used to write about in my blog. In all honesty, I didn’t know what to write about.

The reason I am writing this post is because I want to try and reinvigorate this site. Whilst I can’t write articles to help the masses fix that one particular error message in that one particular situation, I can still indulge in my love of technology and modern computing.

I plan to write something at least once a month from now on. It may be on a totally random subject, like gaming or a personal IoT project. It might be about the evolution of the modern workplace, or even a classic technical blog on how to fix that big screen of red text. Either way, I want to use this little platform that I’ve carved out for myself in the corner of the internet.

I started because I love writing and I love technology, and that’s why I want it to continue 🙂


P.S. See if you can find Wally. Took me aaaaaaaages.