This is an updated version of an article I released back in 2022. The task is simple – report on the set of Administrative units a given Entra ID user is a member of. Or for all users in the tenant, if you want. We explore how to do this programmatically, via the Graph API or the Graph SDK for PowerShell, and provide samples scripts you can use.
When we last looked at this scenario, we covered the various tools and methods available to fetch AU “membership” for any given user, ranging from the UI to Exchange Online PowerShell to the Graph API. The sample script included with the article only covered direct HTTP Graph API requests, so this time around I am also providing you with a Graph SDK for PowerShell version.
As before, the “raw” Graph API based version of the script uses the client credentials flow and is more suitable for automated scenarios. The Graph SDK for PowerShell version is in turn more suitable for interactive scenarios, where you want to run a quick test or further transform the output. Keep in mind that because it runs in the context of a user, some scenarios will not be addressed. For example, any AU that has its visibility set to HiddenMembership will only be included in the output if the user running the script is also a member of said AU, regardless of which roles and permissions you run the script with.
In contrast, the “raw” version of the script should cover all scenarios, provided you’ve run it with sufficient permissions. This brings me to one of the improvements of the script, namely the reduced permissions requirements. Instead of leveraging the all-encompassing Directory.Read.All scope, the script now leverages the less impactful User.Read.All one. We cannot go “lover” unfortunately, as the User.ReadBasic.All scope is not sufficient for the task at hand. And of course, we will now also need the AdministrativeUnit.Read.All scope in order to cover AU details.
Some other minor improvements have been made to the scripts. The output now contains a column indicating whether the AU is restricted-management one. I also contemplated whether adding column based on the visibility property will help, or potentially create some confusion, and at the end decided to go with it. If you don’t like it, just comment it out 🙂
Since last time we covered this scenario, we have also gotten the soft-delete functionality for Administrative units. This does not directly impact the task at hand, as (soft-)deleting an AU will result in removing the corresponding relationship on the user object, and said AU will simply not be visible in the output. It does however result in the availability of deletedDateTime timestamp for AU objects, should you want to report on that.
And that’s it, a small update, mostly focused in providing a “matching” Graph SDK for PowerShell version of the script from our previous article. Without further ado, here are the links to the (updated) Graph API version of the script, and the Graph SDK for PowerShell one. If you go with the former, don’t forget to prepare an Entra ID app registration with the permissions detailed above, and fill in the “authentication” variables before running the script!
As for running the script(s), if you want the “full picture”, run them without any parameters. If you want to only cover some of the users within the tenant, you can leverage the -UserList parameter and provide a list of UPNs or objectIDs. Below you can find some examples on how to run the scripts:
1 2 3 4 5 6 7 8 | #Run the Graph SDK for PowerShell version of the script against all users. \AU_memberOf_inventoryMG.ps1#Provide a list of users via their identifier.\AU_memberOf_inventory.ps1 -UserList "vasil","user@domain.com" ,"b0a68760-1234-1234-1234-8d1ae78f15dc"#Import the list of users from a CSV file.\AU_memberOf_inventory.ps1 -UserList (Import-Csv .\testtttt.csv).UserPrincipalName |
Output of the scripts will be written to a CSV file in the running directory. As usual, feel free to adjust the scripts to better fit your needs, and hit me up with any comments or suggestions.
P.S. Forgot to mention that you can of course use the same method to report on user’s Group membership, where you can as well leverage the /transitiveMemberOf query. An, with few minor changes, you can use the scripts above to produce a report of AU/Group/role membership for device objects, if needed. Oh well, time for another article/sample script, I suppose.
1 thought on “Reporting on user’s Administrative unit membership in Entra ID”