• Home
  • About
  • Blog
  • Books
  • Training
  • Subscribe
  • Advertise
  • Contact
    • Email
    • Facebook
    • Twitter
    • RSS

Practical 365

  • Office 365
  • Exchange 2019
  • Exchange 2016
  • Exchange 2013
  • Hybrid
  • Certificates
  • PowerShell
  • Migration
You are here: Home / Security / Reporting Office 365 Admin Role Group Members

Reporting Office 365 Admin Role Group Members

April 17, 2017 by Paul Cunningham 5 Comments

Share235
Share40
Tweet
+13
Shares 278

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.

Paul Cunningham

Paul is a Microsoft MVP for Office Servers and Services. He works as a consultant, writer, and trainer specializing in Office 365 and Exchange Server. Paul is a co-author of Office 365 for IT Pros and several other books, and is also a Pluralsight author.

Share235
Share40
Tweet
+13
Shares 278

Security Admin Groups, Azure Active Directory, PowerShell, RBAC, Scripts

Comments

  1. David says

    July 11, 2017 at 5:07 am

    Nice script! Can this be automate to email the report once a week?

    Reply
    • Paul Cunningham says

      July 11, 2017 at 11:57 am

      The script doesn’t have that functionality right now but you are free to customize it to suit your needs.

      Reply
  2. Jay Fox says

    December 13, 2017 at 7:50 am

    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.

    Reply
    • Paul Cunningham says

      December 13, 2017 at 11:02 am

      Connect-MsolService is not a cmdlet in the AzureAD module. Are you sure you have the correct module installed?

      Reply
  3. David says

    January 23, 2018 at 3:12 am

    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.

    Reply

Leave a Reply Cancel reply

Recent Articles

  • You Can Stop Deploying Exchange Server 2013 Now
  • Automating New User Account On-boarding Using SharePoint Online, Flow, and PowerApps
  • March 2018 Updates Released for Exchange Server
  • Securing Administrator Access with Privileged Identity Management for Azure Active Directory
  • The Junkings will Continue Until Morale Improves
Practical 365

Popular Articles

Microsoft Recommending Non-Expiring Passwords to Office 365 CustomersMicrosoft Recommending Non-Expiring Passwords to Office 365 Customers
PowerShell Scripts for Office 365PowerShell Scripts for Office 365
MeetEasier Helps Your Users Find Available Meeting RoomsMeetEasier Helps Your Users Find Available Meeting Rooms
PowerShell: Listing Azure AD/Office 365 User Accounts with Directory Sync StatusPowerShell: Listing Azure AD/Office 365 User Accounts with Directory Sync Status
First Steps: Configuring Exchange Online ProtectionFirst Steps: Configuring Exchange Online Protection

eBooks and Training

  • Office 365 for IT Pros
  • Exchange Server Troubleshooting Companion
  • Migrating to Exchange Server 2016
  • Exchange 2016 Exam 70-345
  • Managing Exchange Mailboxes and Distribution Groups in PowerShell
  • Exchange 2013 Boot Camp
  • Exchange 2010 Boot Camp

Recommended Resources

  • Office 365 Books
  • Exchange Server Books
  • Exchange PowerShell Scripts
  • Exchange Analyzer
  • Exchange 2010 to 2013 Migration
  • Exchange 2003 to 2010 Migration
  • Exchange 2007 to 2010 Migration
  • Digicert SSL Certificates

About This Site

Practical 365 is a leading site for Office 365 and Exchange Server news, tips and tutorials, run by Paul Cunningham, Microsoft MVP, author, speaker, and consultant. Read more...

To stay up to date:
  • Subscribe to the email newsletter
  • Follow @Practical365 on Twitter
  • Like us on Facebook
  • Write for Us

Copyright © 2018 LockLAN Systems Pty Ltd · Disclosure · Privacy Policy · Advertise
PO BOX 7002, Hemmant, Queensland 4174 · ABN: 25 121 101 255

We are an Authorized DigiCert™ SSL Partner.