4 Dec 2019 by Mike Weaver
Inspire: Winning Hearts and Minds
Successful change management requires inspirational leadership. Here’s how to keep your team on track.
For the next article in our “permissions inventory” series, we will cover Azure AD integrated applications. More specifically, this blog will show you how to get a list of: all the Azure AD integrated apps, the users they are assigned to, and the specific permissions they have been granted.
Those of you that have dealt with Azure AD applications are probably aware that there are several “types” we can cover. For the purposes of this article, we will only cover “external” applications, i.e. ones that you do not “own”, but “consume”. If you need more details on this, you can refer to the relevant documentation here.
These applications are represented by the corresponding ServicePrincipal object in your directory, and we have been able to report some basic information around them for a while via the WAAD PowerShell module and the Get-MsolServicePrincipal cmdlet. For example, here’s what we are able to gather about the Cogmotive Reports object:
With the new Azure AD PowerShell module, some additional information is exposed, such as more information about the app publisher. More importantly, we can now obtain a detailed list of permissions required by the application, as well as information on which users in the directory have granted consent to it, including admin consent. This information is surfaced by the Get-AzureADServicePrincipalOAuth2PermissionGrant and Get-AzureADServiceAppRoleAssignment cmdlets, respectively.
For example, this is the list of OAuth permissions required by the Cogmotive Reports application:
So, the application has been granted Admin consent (which is what the “AllPrincipals” value indicates) and can read data from our Azure AD instance. It also has impersonation permissions to the Service Management API, and can read additional data from the Office 365 Management APIs. In case the application had individual consent granted by end users, the ConsentType entry would be shown as “Principal” and we could use the Get-AzureADServiceAppRoleAssignment cmdlet to get the list of users:
Alternatively, we can also use the Get-AzureADServicePrincipalOAuth2PermissionGrant cmdlet:
You can gather more information via the additional Azure AD cmdlets, however for the purposes of the this blog the above examples are enough. They allow us to generate an inventory report listing all the Azure AD integrated applications in our tenant – it’s very similar to the report available as part of the Advanced Security Management or the Cloud App Security suite. Here’s a link to the script file: https://gallery.technet.microsoft.com/Azure-AD-Integrated-44658ec2
As noted above, the script requires the Azure AD PowerShell module (versions above 184.108.40.206), if it fails to detect a compatible version, the script will exit. The script will detect and reuse existing Azure AD PowerShell sessions and prompt for credentials if a valid session is not detected. The output of the script will be dumped into the console host, which might not be desirable if you have a large number of Azure AD applications, or a large number of users that have authorized them. To export the output to a CSV file instead, simply remove the comment mark from the last line.
Here’s what the generated CSV file should look like (with some rearrangements made in order to improve readability):
Of course, if the output doesn’t quite meet your requirements, feel free to make any necessary changes – the idea behind the script is to show you an example of how you can gather this information, with minimal changes made to format the output. For instance, the “raw” OAuth permission values are returned, instead of their more detailed descriptions as found in the documentation.
If you find that scripting this activity is time-consuming, or insufficient for your needs, you can use the Cogmotive Reports application to generate, automate and schedule fully-formatted reports (PDF or .CSV) in a matter of minutes.