If you would like to be notified of when Anderson Patricio releases the next part in this article series please sign up to our MSExchange.org Real Time Article Update newsletter.
If you would like to read the other parts in this article series please go to:
Introduction
It’s time to manage mailboxes in our article series. So far, we covered the delegation process for Contacts, Distribution Groups and Message Flow in our series. We went over the process to create Admin Role Groups, combine Management Roles and customize cmdlets during our series.
In this article, our focus will be the Mailbox and we will create a delegation from scratch. We will only allow specific user(s) that belong to a specific Admin Role Group to manage the mailbox, more precisely the permission to edit but not to remove or create new mailboxes.
Delegating Mailbox administration
In this scenario that is common in large enterprises where a different team manages Active Directory objects and a different team manage the exchange attributes of the objects afterwards.
Some companies require that any new Active Directory object is created outside of Exchange to avoid checking two different sources (Exchange logs and Event Viewer) when identifying who created the accounts.
To start let’s create our new Management Role (Figure 01) using the parent Mail Recipients which basically, has all the cmdlets to manage any existent objects but we won’t be able to create or remove mailboxes because those capabilities are present in a different Management Role (Mail Recipients Creation).
Figure 01
In order to save time, let’s create a new Admin Role Group using Exchange Management Shell and we are going to associate user5 as member, and use the newly management role that we created in the previous step. The cmdlet to do all that is shown in Figure 02.
Figure 02
Now, logged on Exchange Admin Center as user5, we will have something similar to Figure 03 where, the user can see the add button but cannot create anything as most of the properties are not there and they will be grayed out, as shown in Figure 03.
Figure 03
At this point in our article series, we have enough tools in our toolbox to find out why we cannot do that. We can run the cmdlet Get-ManagementRoleEntry _AP_MailboxRO_Mail_Recipients\new* to retrieve all cmdlets (Figure 04) that can create objects. We can check that for the New-Mailbox we only have a single parameter which is EnableRoomMailboxAccount and that does not give us enough power to create a new mailbox.
Figure 04
In order to save some time, we documented all the items and what the user access will be after receiving only the Management Role within the Admin Role Group. The summarized list is here:
- Recipients item: mailboxes, resources, contacts and shared tabs
- Permissions item: Outlook Web App Policies
- Mail Flow item with only Accepted Domains tab
- Mobile tab with Mobile device mailbox policies tab
- Hybrid item containing only setup tab
Our new Management Role was based on Mail Recipients, and that single one has 126 cmdlets. We are going to use a different approach and we will start removing all unnecessary cmdlets that do not fit our requirements (remember that we just want cmdlets related to mailbox management stuff).
Note:
You may be asking yourself, why not remove all the cmdlets like we have done with Contacts in the second article of this series? Well, managing a Mailbox object requires way more cmdlets, so it is easier to remove all that we do not want first.
For each one of the main components that we are going to remove we will be checking all cmdlets available and we will be using the same syntax to remove the same ones afterwards. In order to practice, let’s go over the process to remove Contacts. First, we need to check all cmdlets that exist related to contacts and a good way to find that out is using the following cmdlet:
Get-ManagementRoleEntry _AP_MailboxRO*\*Contact
Now that we know that we are not getting more cmdlets than we need, we can use the following cmdlet to remove all of them. Since a confirmation for all cmdlets is required I suggest typing A which means ALL or otherwise go one by one (typing Y when required).
Get-ManagementRoleEntry _AP_MailboxRO*\*Contact | Remove-ManagementRoleEntry
The entire process of validating and removing those entries can be seen in Figure 05.
Figure 05
Have you got the idea? Great, we can speed up the process and start working on the items as follows:
- OWA Mailbox Policy (that will take care of Permissions item)
- Verifiy:
Get-ManagementRoleEntry _AP_MailboxRO*\*owamailbox* - Remove:
Get-ManagementRoleEntry _AP_MailboxRO*\*owamailbox* | Remove-ManagementRoleEntry -
Hybrid item (that will take care of Hybrid item)
- Verify:
Get-ManagementRoleEntry _AP_MailboxRO*\*hybrid* - Remove:
Get-ManagementRoleEntry _AP_MailboxRO*\*hybrid* | Remove-ManagementRoleEntry -
Accepted Domains (that it will take care of Mail Flow item)
- Remove:
Remove-ManagementRoleEntry _AP_MailboxRO*\Get-AcceptedDomain -
Mobile item
- Remove:
Remove-ManagementRoleEntry _AP_MailboxRO*\Get-MobileDeviceMailboxPolicy
- Remove:
If we measure the number of cmdlets after our cleanup we should end up with 92 entries, in order to get that number you can run Get-ManagementRoleEntry <Name>\* | Measure-Object.
Time for the same user to test it after we removed all the unnecessary cmdlets from his/her Admin Role Group. Remember to make sure that you logoff and log back on, and the results should be similar to Figure 06 where user5 will have only permissions to manage mailboxes.
Note:
The Add button is still available because the permissions of the role allow him to enable a Mailbox Enabled user but not create one from scratch.
Figure 06
Playing with cmdlet properties…
We have been playing with cmdlets and after running a couple of exercises in this article series we can move forward to manage which cmdlet properties we want to expose to any given user using RBAC.
We are going to continue using the same scenario that we have been using (user5) where that user is able to manage all the properties of any given user (Figure 07). Let’s say we want to prevent that Admin Role Group to change both First and Last Name and the ability to hide a mailbox from the Global Address List.
Figure 07
Let’s start with the First and Last Names restriction. PowerShell is easy to understand the syntax, so it is easy to assume that in order to change something we will need cmdlet that uses the verb Set- something, right? So, we know the Management Role that the user is using, so we can narrow down our research to a few cmdlets by running this cmdlet (Figure 08)
Get-ManagementRoleEntry _AP_MailboxRO_Mail_Recipients\Set-*
Figure 08
If that does not help you to find out which cmdlet, we can always search for the parameter itself. A good example in this case is running the cmdlet below, where we perform a search for the LastName parameter and the results are shown in Figure 09.
Get-ManagementRoleEntry _AP_MailboxRO_Mail_Recipients\* -Parameters LastName
Figure 09
Now that we found out the cmdlet (Set-User in our case) we can list all the properties that we have available, and using the following cmdlet we can have such list (Figure 10).
(Get-ManagementRoleEntry _AP_MailboxRO_Mail_Recipients\Set-User).Parameters
Figure 10
In order to remove the cmdlet we can run the following cmdlet (Figure 11), where we list both parameters first while, the last switch of the cmdlet is –RemoveParameter.
Set-ManagementRoleEntry _AP_MailboxRO_Mail_Recipients\Set-User –Parameters FirstName,LastName -RemoveParameter
Figure 11
Time to test, let’s logoff and log back on using user5 and we can try to edit the same user, and now the result should be similar to Figure 12. That is, First name and last Name are not accessible.
Figure 12
In order to remove the ability of the delegated user to hide any given user from the Global Address list we can run the following cmdlet (Figure 13):
Set-ManagementRoleEntry _AP_MailboxRO_Mail_Recipients\Set-Mailbox –Parameters HiddenFromAddressListsEnabled -RemoveParameter
Figure 13
Similar to the previous exercise the user will not have the ability to change it, as follows:
Figure 14
Conclusion
In this article, we customized permissions to allow management of just mailbox objects for a member of the Admin Role Group that we created. We also configured parameters to be removed from the Management Role and the result was some fields and capabilities removed from the administrator.
We have just scratched the surface when the topic is RBAC. We have not used several capabilities available to customize RBAC permissions. However, we raised the bar when the topic is customization for a couple of delegation scenarios nonetheless, everything that we saw here can be used to create complex scenarios.
If you would like to be notified of when Anderson Patricio releases the next part in this article series please sign up to our MSExchange.org Real Time Article Update newsletter.
If you would like to read the other parts in this article series please go to:
