Office 365 allows organizations to delegate administrative privileges in a granular fashion. There is an over-arching “Global Administrator” role, as well as a series of lower privilege roles for specific administrative tasks. A partial list of the admin roles is visible in the user management area of the Office 365 admin portal.
That's not the complete list though. There's several other administrative and non-administrative roles in Office 365. While looking for a complete list, I happen to stumble across some differences between how the old MSOnline PowerShell module reports the list of roles, compared to the new AzureAD PowerShell module. Get-MsolRole returns 30 groups, while Get-AzureADDirectoryRoleTemplate returns 34 groups. I've highlighted the differences in the table below.
It's good practice to review the membership of admin groups on a regular basis, to make sure that only those users who require admin privileges in your tenant actually have them, and nobody else has sneaked in there and been forgotten. It's even better practice to manage privileged access using Azure Privileged Identity Management.
If you're familiar with the Exchange RBAC permissions model you will notice that none of the Exchange RBAC roles are included in that list above. If you want to report on those you can use my RBAC role group membership report script.
You should also be aware that if you're using Get-AzureADDirectoryRole as the equivalent cmdlet to Get-MsolRole, the Get-AzureADDirectoryRole cmdlet only returns roles that have been enabled. It seems that a role becomes enabled when you first add a user to the role, or when an admin enables the role using the Enable-AzureADDirectoryRoleTemplate cmdlet. Since the point of this exercise is to report on membership of Office 365 roles, I'm going to use Get-AzureADDirectoryRole as the basis of a PowerShell script, which will effectively ignore roles that have not been enabled yet.
If you just want to download the reporting script, go to the end of this blog post.
To begin with, let's look at the output of Get-AzureADDirectoryRole for one of my tenants.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
PS C:\> Get-AzureADDirectoryRole ObjectId DisplayName -------- ----------- 1e5b0ce4-381f-4554-93fc-1fdea462c7eb Billing Administrator 32554153-2f11-43f0-aadc-0c3c0e9540c6 CRM Service Administrator 4d7ba3db-b65c-46f8-8fc5-8f5803e7809c Company Administrator 5a12811f-e5d4-4794-b9e7-a604b3881a26 Lync Service Administrator 67780c9d-4aa7-4ff5-986f-c04b07b70546 Power BI Service Administrator 7cbef213-fcb9-43b5-8b65-eee6dd79e2f4 Service Support Administrator 83c85103-dd8e-4d24-bd17-922fc40dd7d4 Directory Readers a75585d4-38b8-4e14-9a40-8f694cb4164f User Account Administrator ad9c6fdb-d8c9-4c57-9b2d-070f75bc30db Helpdesk Administrator daaca1b7-f6f2-4cbb-82e4-f8adcfcdd02e Exchange Service Administrator e58f4d04-b5fc-406b-a2bd-cc114499ac53 SharePoint Service Administrator e7b328f2-2839-400c-ac6a-299c2487aa16 Directory Writers f603a44f-df89-4a46-89b1-aedfe5f52ce8 Directory Synchronization Accounts fde1b62b-4d9d-4a1b-96ca-381266264055 Device Administrators |
To see the membership of a role, such as Company Administrator (which is the same as Global Administrator when you're editing a user's roles in the Office 365 admin portal), we need to run Get-AzureADDirectoryRoleMember and supply the ObjectId.
|
1 2 3 4 5 6 |
PS C:\> Get-AzureADDirectoryRoleMember -ObjectId 4d7ba3db-b65c-46f8-8fc5-8f5803e7809c ObjectId DisplayName UserPrincipalName -------- ----------- ----------------- 8db8b044-b825-4456-b6f7-3994f9296872 Paul Cunningham admin@exchangeserverpro.onmicrosoft.com b2149a88-327c-4f61-afb5-f8a7374f6d28 Paul Cunningham paul_domain#EXT#@exchangeserverpro.onmicrosoft.com |
The standard output looks different depending on the role that you're querying. For example, Directory Readers looks like this.
|
1 2 3 4 5 6 7 8 9 |
PS C:\Scripts> Get-AzureADDirectoryRoleMember -ObjectId 83c85103-dd8e-4d24-bd17-922fc40dd7d4 ObjectId AppId DisplayName -------- ----- ----------- a6bb4c6f-657c-439f-8b52-9ca3dee1b5fd 00000009-0000-0000-c000-000000000000 Microsoft.Azure.AnalysisServices fc7627c0-4b51-4bfc-8ea1-0a9dd14644d2 00000005-0000-0ff1-ce00-000000000000 Microsoft.YammerEnterprise 1b6f4fb3-25c5-43c6-b414-77da6ec221a1 0711fa10-367d-4adb-93fd-123456789000 O365SecureScore c462bdd3-b0e3-4737-9b5a-6939e31dd4e2 2dd1318c-77a5-44df-9bd8-123456788999 CiraSync Contact Management e365650e-697d-498e-bdc9-046e81fe9103 0000001a-0000-0000-c000-000000000000 MicrosoftAzureActiveAuthn |
The properties that are returned are also different, depending on the type of object that is a member of the group. Users have properties such as JobTitle, Mail, and PasswordPolicies. Service principals (such as the Office 365 Secure Score service) have properties such as AppId, Homepage, and Oauth2Permissions. Both types of objects have common properties such as ObjectType and DisplayName though, so reporting on both types of objects together is not too difficult.
For this script I'm going to report on:
- DisplayName
- ObjectType
- AccountEnabled
- UserPrincipalName (for users)
- Homepage (for service principals)
- PasswordPolicies (for users)
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
PS C:\> Get-AzureADDirectoryRoleMember -ObjectId 4d7ba3db-b65c-46f8-8fc5-8f5803e7809c | Select DisplayName,ObjectType,Ac countEnabled,UserPrincipalName,HomePage,PasswordPolicies DisplayName : Paul Cunningham ObjectType : User AccountEnabled : True UserPrincipalName : admin@exchangeserverpro.onmicrosoft.com HomePage : PasswordPolicies : DisablePasswordExpiration DisplayName : Paul Cunningham ObjectType : User AccountEnabled : True UserPrincipalName : paul_domain#EXT#@exchangeserverpro.onmicrosoft.com HomePage : PasswordPolicies : None |
Retrieving that information for the members of an admin group/role is not difficult, as you can see above. To generate a full report it's really just a matter of looping through the roles, collect the desired info, and present it in a readable format for the report. I've chosen to used CSV as the file format. You can then load the CSV into Excel to filter and sort the data as required.
This script, Get-O365AdminGroupsReport.ps1, relies on the AzureAD PowerShell module. If you do not have the module installed the script will throw an error. You can install the AzureAD module from the PowerShell Gallery.
To use the script, simply run the following command and you'll be prompted to authenticate to Azure AD.
|
1 |
PS C:\Scripts> .\Get-O365AdminGroupsReport.ps1 |
To see script progress, use the -Verbose switch.
|
1 |
PS C:\Scripts> .\Get-O365AdminGroupsReport.ps1 -Verbose |
The script will output a CSV file named Office365AdminGroupMembers-ddMMyyyy.csv, where “ddMMyyyy” is the current date (e.g. 17042017). If the file already exists, a unique string of characters is added to the filename.
There are two optional parameters that you can use to change the output behavior:
- ReportFile – You can provide a custom output file name. The file name you specify will be modified with the current date, for example MyReportFileName.csv will become MyReportFileName-ddMMyyyy.csv. If a file of the same name exists, a unique character string will also be appended to the file name.
- Overwrite – Overwrites an existing report file of the same name, instead of appending a unique character string.
You can download Get-O365AdminGroupsReport.ps1 from the TechNet Script Gallery.
Nice script! Can this be automate to email the report once a week?
The script doesn’t have that functionality right now but you are free to customize it to suit your needs.
Hi, I have AzureAD module installed, and the AzureADPreview installed, however I am not being prompted to authenticate, and it goes straight to an error: The AzureAD PowerShell module is not installed on this computer. The location and filename:94 char:5 I am using Windows 10. If I do the manual authentication, $cred = Get-Credential +Connect-MsolService -credential $cred I can run commands to successfully query. I would like to use the script however because it seem more robust.
Connect-MsolService is not a cmdlet in the AzureAD module. Are you sure you have the correct module installed?
There are some issues with this script. It fails to check for the AzureAD module correctly on a fully patched Win10 Pro, even when run in a PS “as administrator” (and I am a local computer admin). I triple verified I had the AzureAD PowerShell module (it is version 1.1.166.0) so I had to disable this check in the script (I can run some commands manually, also proving I have the module and it is working). Next when the script calls for credentials upon running “Connect-AzureAD -ErrorAction Stop” it defaults to a web pop-up version of the credentials gathering which redirects after I enter my username due to ADFS and fails to auth, but I know the ADFS works for login.microsoftonline.com (tested a login and it works, no password typos). So to further edit I added “$cred = Get-Credential” above that line in the script (which then provides the regular windows pop-up style credentials gathering) then edited the call to “Connect-AzureAD -Credential $cred -ErrorAction Stop”. Now the script runs and I get the CSV. By that, it’s clear to me I have the modules required making the first error a boggle.