Exchange Mailbox Permissions: How to Track & Manage Mailbox Delegation

To manage Exchange mailbox permissions for other users, you will need either the Exchange Admin Center (EAC, formerly known as the Exchange Management Console) or PowerShell. Since 2016, a cross-platform, open source version of PowerShell (PowerShell Core) is available for Windows, macOS and Linux alongside the traditional Windows PowerShell.

Before we look into the different ways of assigning mailbox permissions to another person (generally known as the delegate), let’s go over the three main permission types used in Exchange:

These permissions are non-exclusive, meaning that multiple permission levels can be active at the same time. For example, in order to see incoming messages and respond from the recipient’s email, a delegate would need both the Full Access and Send As permission. If delegates are given both the Send As and Send on Behalf permission, Send As will take priority. Additional Information on these different types is available in Microsoft’s official documentation

To adjust Exchange mailbox permissions using the Exchange Admin Center, navigate to Recipients > Mailboxes on the left-hand side. Here, you can select any mailboxes you want to edit before clicking on Mailbox delegation. Type in the username or email address of the person you want to add as a delegate and select the permission types from the dropdown menu.

Similarly, you can add delegates to groups under Recipients > Groups. Click on a group to bring up the right-hand menu, move to the Settings tab and select the Manage delegates option. Again, you will be prompted to choose the person and permission type you want to add to the group in question.

Many features of the Exchange Admin Center can also be found in the centralized Microsoft 365 Admin Center. In order to access mailbox settings, you need to move to Users > Active users. Next, open the account you want add a new permission to, select the Mail tab on the right and choose Manage mailbox permissions. Here, you can add other accounts to the three permission tiers.

Let’s assume you’re an admin trying to give an employee access to another mailbox or add an entire group to a shared mailbox. To accomplish this task using PowerShell, you first have to connect to Exchange Online PowerShell. Depending on the permission you are trying to set, you will need different commands for the next step.

To add the Full Access permission, you need the cmdlet Add-MailboxPermission with parameters for the recipient mailbox, delegate mailbox and intended permission level. Additionally, -InheritanceType allows you to adjust inheritance settings and -AutoMapping determines if the mailbox is automatically added to the delegates Outlook profile.

In order to give a user the Send As permission, you need the Add-RecipientPermission cmdlet. Note that with this command, the delegate is referred to as the -Trustee rather than the user.

Finally, to add the Send on Behalf permission to another mailbox, use the Set-Mailbox cmdlet with the specifier -GrantSendOnBehalfTo. You can also enable copies of sent messages for the delegate with the boolean -MessageCopyForSendOnBehalfEnabled.

GrantSendOnBehalfTo is a multi-valued property, meaning you can add multiple users at the same time if you separate their accounts with a comma.

Another setting users may be familiar with from Outlook is the ability to delegate access for your own mailbox. In the Outlook interface, this can be found under File > Account Settings > Delegate Access. As you can see from the screenshot below, this option allows users to share far more than just their mailbox: It can control access to a person’s Calendar, Tasks, Notes and Contacts.

Not all these permissions can be easily adjusted by admins, but there are ways to address common use cases such as giving another employee access to your calendar in Outlook. But first, you may have noticed that the Delegate Access feature uses slightly different permission types compared to Exchange mailboxes:

In the technical backend, there are of course even more granular options for determining access, such as the ability to create subfolders, create but not edit items, etc.

Unfortunately, the Exchange Admin Center does not allow admins to give users calendar access for another account (nor notes or tasks for that matter). As a result, PowerShell is your best bet in order to let users see, add or edit calendar entries in another mailbox. For example, this would allow an assistant to send or accept meetings on a manager’s behalf. It could also be used to make a team member’s availability visible to all.

Because the calendar is considered a folder, the cmdlet we need for this task is Set-MailboxFolderPermission. A few differences to look out for compared to our prior example is that you need to specify the :\Calendar folder as part of the -Identity parameter. Also, -AccessRights uses different values with this command.

For example, setting access rights to AvailabilityOnly or FreeBusyTimeOnly allows users to see when the account has bookings in their calendar, without revealing additional information about these events. This is a great way to find convenient time slots for meetings, without giving away sensitive information.

So, it took a few scripts, but you successfully added delegates, assigned Send on Behalf permissions and shared Outlook schedules just as management requested. Unfortunately, that doesn’t mean your job is done. Just as any other permission, mailbox access and delegation in Exchange will have to be reviewed and adjusted as the employees behind these mailboxes switch roles, move to different offices or even leave your company.

Which means you need to keep track of which users have permissions on mailboxes besides their own and which mailboxes have delegation enabled. Which is a problem because the default tools provided by Microsoft make it difficult and time-consuming to piece together all the information you need to get the full picture.

Using the Get-Mailbox and Get-MailboxPermission cmdlets (in combination with the right set of parameters) also makes it possible to check, for example, which mailboxes a specific user has access to or which mailboxes have a delegate with the Full Access permission. You can find some ideas for scripts in this blogpost.

As we’ve already established, PowerShell can be used to figure out which permissions have been assigned for a specific mailbox or folder. In theory, you could then use the EAC to draw connections between Exchange mailboxes and user accounts in Active Directory.

This could be necessary if, for example, you need to figure out the level of access an AD user has in a specific Exchange mailbox or need a list of all mailbox permissions that a specific user account has.

In most organizations, gradual privilege creep leads to users accumulating more access rights than they actually need for their job. Employees are given new permissions for short-term projects or temporary substitutions, while old privileges that are no longer needed are never removed. This applies to Exchange mailbox permissions just as much as it does to file server permissions or third party accounts.

Let’s say a new member joins the sales team and is given full access to several shared mailboxes: for incoming leads, communicating with distributors, etc. So far, so good. They need access to those mailboxes to do their job. But a few months later, they switch to the product team and receive all the access rights associated with their new role. Only nobody remembers to revoke the mailbox permissions they no longer need.

Without a standardized process for user access reviews, people simply forget about old permissions. Or they don’t feel like bothering IT over something that’s not causing any harm, right? Wrong! Outdated permissions should not be taken lightly, as they add to the risk of both employee data theft and cyberattacks. This is also why most security standards now require access rights to be managed following the Principle of Least Privilege.

When it comes to fighting unnecessary permissions, there’s an important distinction to be made between individual users who have been given access to additional mailboxes and shared mailboxes that are managed via groups. While unnecessary permissions assigned to users are far from ideal, at least admins can use PowerShell to figure out who in their organization can access mailboxes besides their own.

With shared mailboxes, it’s not quite as simple. Access to shared mailboxes is typically managed using groups, which adds an extra layer of complexity to permission reporting: You can use PowerShell to see which groups have access to a shared mailbox, but then you need to figure out which users are part of that group. For nested groups several levels deep, compiling a list of users can take some time.

The fact that permissions assigned through groups are not readily transparent means that reporting options for Exchange using the default tools are quite limited. Just as you cannot see which users are assigned to a shared mailbox, you also cannot tell which mailboxes an individual user has access to, only which groups they are a member of.

To get the complete picture and generate a full report of every users effective access level in Exchange Online using the default Microsoft tools, you would have to manually comb through every group on your server.

The reporting limitations for Exchange Online are a bigger problem than you might think. The lack of transparency makes it easy to miss outdated and unnecessary permissions, allowing users to comb through mailboxes they have no business going through. And remember, access to mailboxes, especially Full Access, doesn’t just mean seeing incoming emails. It means access to the entire email history, shared files and attachments, etc.

Aside from the increased risk of data theft and insider threats, excess privileges on the mail server are also a thorny issue when it comes to achieving compliance with standards such as SOX, HIPAA, ISO 27001, the NIST Cybersecurity Framework and so on. Most cybersecurity regulations expect businesses to enforce need-to-know / least privilege access, i.e. to limit access rights for staff to only what is absolutely necessary.

Save yourself the headache of assigning and reviewing Exchange mailbox permissions through PowerShell scripts: tenfold‘s automated Identity and Access Management platform is fully integrated with Microsoft services like Active Directory, Exchange and Exchange Online. Thanks to these out-of-the-box plugins, tenfold allows you to automate and rigorously document any tasks to do with user provisioning and permission management. This includes automatically adding users to the correct security groups, distribution groups and shared mailboxes based on their role and department.

Thanks to its deep integration with the Microsoft ecosystem, tenfold‘s reporting tools provide you with a clear overview of all effective permissions on your mail server, including detailed breakdowns of which users have access to a specific mailbox or folder. No more combing through nested groups! This not only saves time in AD administration, but also boosts Active Directory security.

Additionally, tenfold provides various handy features that address common mailbox problems, such as the ability to set up an Outlook out-of-office message for another user, in case a colleague forgot to set up their automatic response before going on vacation. There is even an option to define auto-filled templates for out-of-office messages in order to set a uniform response.

Problem in Exchange	Solution in tenfold
Mailboxes must be created manually (no provisioning)	User creation is in AD and Exchange is linked and fully automated (automatic provisioning)
Administrators have to go through PowerShell to see access rights	tenfold provides clear and easy-to-read reports on who has access to what
No group breakdown to individual members	tenfold automatically breaks down groups and visualizes group membership
No self-service features	Users can request additional access rights themselves via self-service
No customizable approval workflows	Data owners receive user requests made in the self-service and can confirm or reject them as needed