Quantcast
Channel: Practical 365
Viewing all articles
Browse latest Browse all 520

Reporting Office 365 Admin Role Group Members

$
0
0

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.

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.

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.

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.

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)

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.

PS C:\Scripts> .\Get-O365AdminGroupsReport.ps1

To see script progress, use the -Verbose switch.

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.

The post Reporting Office 365 Admin Role Group Members appeared first on Practical 365.

        

Viewing all articles
Browse latest Browse all 520

Trending Articles