This article is a continuation – i.e. Part 2 – of the article Recommendation – Microsoft 365 authorization concepts – Part 1.
In this article, the following topics are now dealt with to complete the start for understanding an authorization concept:
- Configuration of Exchange online RBAC at Administrative Units level
- Configuration of automatic users, guests and devices to the correct administrative units
- Completion of the authorization matrix – Recommended Microsoft certifications for the respective roles in the matrix
A disclaimer at this point before we continue with the technical part of this article.
The information from the first and second part of this short series is primarily intended as an application example. In addition, the aim is to use the tools provided by Microsoft in such a way that an optimal and granular authorization can be defined and built across an environment.
Particularly with regard to the authorization matrix and the certification matrix, there may be deviations depending on the company. Take these two articles as food for thought and modify and/or extend them to suit your company.
Configuration of Exchange online RBAC at Administrative Units level
To create a custom EXO role and then apply it to an AU, the following steps are required:
- For the creation: Global Administrator authorisation on the corresponding account
- Entra ID Premium subscription (for Administrative Units)
- MS Graph PowerShell Module (Attention the Azure AD PowerShell Module may no longer work depending on when this article is read)
- Exchange Online PowerShell Module
# Connect to MS Graph with PowerShell and the required permissions
Connect-MgGraph -Scopes "Directory.Read.All"
# Show all available Administrative Units
Get-MgDirectoryAdministrativeUnit
# Get the Administrative Unit
$au = Get-MgDirectoryAdministrativeUnit -Filter "DisplayName eq 'Your Administrative Unit Name'"
# Connect to Exchange Online PowerShell:
Connect-ExchangeOnline
## Assign the RBAC Role
# Create a new management scope for the Administrative Unit
New-ManagementScope -Name "Your Scope Name" -RecipientRestrictionFilter "MemberOfGroup -eq '$($au.Id)'"
# Create a new role assignment policy and assign it to the management scope
New-RoleAssignmentPolicy -Name "Your Policy Name" -AssignedRoles "Your Role Name" -CustomRecipientWriteScope "Your Scope Name"
Please replace ‘Your Administrative Unit Name’, ‘Your Scope Name’, ‘Your Policy Name’, and ‘Your Role Name’ with the actual name of your Administrative Unit, the name you want to give to the management scope, the name you want to give to the role assignment policy, and the name of the role you want to assign, respectively.
Configuration of automatic users, guests and devices to the correct administrative units
Once the concept of the administrative units has been created, they can now be created. There are several ways to create them: On the one hand via the Azure Admin Portal or via PowerShell.
The PowerShell variant requires the MS Graph PowerShell module.
Below is a configuration example:
# Connect via MS Graph PowerShell
Connect-MgGraph -Scopes "Directory.ReadWrite.All", "User.ReadWrite.All"
# Create the Administrative Unit
New-MgDirectoryAdministrativeUnit -DisplayName "Your Administrative Unit Name" -Description "Your Administrative Unit Description"
# Get the Administrative Unit
$au = Get-MgDirectoryAdministrativeUnit -Filter "DisplayName eq 'Your Administrative Unit Name'"
#Create a Dynamic Group
$group = New-MgGroup -DisplayName "Your Dynamic Group Name" -Description "Your Dynamic Group Description" -MailEnabled $false -SecurityEnabled $true -MailNickname "YourDynamicGroup" -GroupTypes "DynamicMembership" -MembershipRule "(user.department -eq 'Your Department Name')" -MembershipRuleProcessingState "On"
# Assign the Dynamic Group to the Administrative Unit
Add-MgDirectoryAdministrativeUnitMember -AdministrativeUnitId $au.Id -DirectoryObjectId $group.Id
In this example, a dynamic group has now also been created and assigned to the Administrative Unit. However, regardless of whether an Administrative Unit was created in the Azure Admin Centre or via PowerShell, it is recommended not to assign dynamic groups to an AU.
From my personal experience, it is better to work with expressions under “Dynamic membership rules“. Here are some examples:
| AU Function | Expression example |
| AU for all users and Guests located in Switzerland | (user.country -eq “Switzerland”) or ((user.userType -eq “Guest”) and (user.department -eq “Switzerland”)) |
| AU for all Devices located in Switzerland | (device.deviceCategory -eq “Switzerland”) |
Such expressions must of course be maintained in the Entra ID (for devices in my example in Microsoft Intune). Of course, other expressions can also be used. For example: user.extensionAttributeXX.
Addition to the authorization matrix – Recommended Microsoft certifications for the respective roles in the matrix
The following table with the training and certification options should of course be treated with caution. A lead time must be defined for the introduction in particular so that the relevant administrators can undergo further training.
Conclusion
Here is a brief summary of the two articles on this topic. As already mentioned several times, both articles are application examples or basic information intended to improve understanding of how an authorization concept can be set up and configured.
In my view, it is essential to know a) that the various tools exist and b) how they should be used, especially when it comes to the various tools such as the focus topic of administrative units.
I have not gone into topics such as data classification and DLP in any more depth, as this would otherwise have become too long a series. Following on from this chapter, I have linked to another article on sensitivity labelling. This can also serve as supplementary knowledge.
My aim with these two articles was to give you an understanding of the tools described and to provide a rough guideline for this type of conceptualisation.
I hope I have succeeded in this.
Thank you for visiting my blog… <3
