Automating access to Shared mailboxes in Exchange Online using Entra ID Governance is something that has been on my to-do list for some time. I was recently asked by a colleague if I could find a way to automate that process when a user onboards or moves (department, location change, etc.). When handling access to Shared mailboxes you need to account for Full Access and Send As permissions.
The solution I came up with is based on the Access Packages a user is assigned (granted) in Entra ID Governance entitlement management. That way, whenever a user joins the Finance department, a Custom Extension will run a PowerShell script that will look up in the JSON file what Shared mailboxes the user should have assigned, and what permissions for these mailboxes the user should have. The Custom Extension will also run when a user is removed, to ensure that the user gets properly removed from the Shared mailboxes according to what Access Packages the user currently has assigned.
I have created a PowerShell script that will run on an Azure Automation account with a managed identity enabled, and host the JSON file in my company’s Azure DevOps repo in order to have source control, but also to remove the need to place it on a Hybrid Worker, for example. I have then provided the Automation Account’s managed identity with reader access to the same Azure DevOps repo, saving myself the trouble of having passwords or secrets involved in that process.
Prerequisites
- Azure Automation account (with managed identity enabled)
- Exchange Online PowerShell module installed on the Automation account
- Azure DevOps repository
The JSON file
First off, we are going to focus on the JSON file we are going to use. This is where you need to map what Access Packages should be associated with each Shared mailbox that you want to automate access and permissions for.
You can see the JSON file below. “Identity” is the Shared mailbox’s mail address, and “AccessRights” is what permissions should be granted to said Shared mailbox. You can add multiple permissions like so: [“FullAccess”, “SendAs”]
The PowerShell script
Now that the JSON file is in Azure DevOps, and we have provided the managed identity with reader permissions to access the Azure DevOps repo, we can then begin to set up the PowerShell script.
The first thing to know about this PowerShell script is that it uses the Automation account’s managed identity to access Microsoft Graph to get the user’s information, but also what Access Packages the user has assigned. The Automation account’s managed identity is also used for the Exchange Online operations. The script uses the Microsoft Graph API directly instead of the PowerShell modules, and only uses the Exchange Online PowerShell module. That is because I don’t want the hassle of testing the script again when new Microsoft Graph module versions are released.
You can use this PowerShell script to provide the Automation account with the necessary permissions:Setup-ExchangePermissionsForAzureAutomationAccount.ps1
The following permissions will be set:
- User.Read.All
- EntitlementManagement.Read.All
- Exchange Administrator Entra role
- Exchange.ManageAsApp
With that out of the way, you will need to provide the PowerShell script with the catalog IDs for where the Access Packages are located. This is so that only the Access Packages in these catalogs get processed. You will then need to provide the Azure DevOps information like so:
The complete PowerShell script is here:
You will then need to copy the PowerShell script into a Runbook in your Azure Automation account.
Using the PowerShell script in Entra ID Governance
Now that we have most of the “backend” set up, the next step is to use the PowerShell script with Entra ID Governance. The way we are going to run the PowerShell script is by creating a Custom Extension in Entra ID Governance Lifecycle Workflows, and then adding that Custom Extension to a new Lifecycle Workflow that is based on the Real-time employee change template. We will then create a Custom Extension in each catalog in Entra ID Governance entitlement management. The Custom Extensions in the entitlement management catalog will then trigger the Real-time employee change Lifecycle Workflow via PowerShell. The reason for doing it this way is that if there is a need to add another task in the future, we can just add it to the Lifecycle Workflow instead of altering all the Custom Extensions in the catalogs.
First, let’s start by navigating to the first catalog in entitlement management where we want to trigger the Lifecycle Workflow that will run the Manage Shared Mailboxes script.
Provide the Custom Extension with a name and description of your own choosing.
In the Extension Type, press next – we are not going to change that. In the Extension Configuration we need to select “Launch and Wait” and set the timer to 30 minutes. This is to give the Lifecycle Workflow enough time to complete the task (this can be changed later if necessary).
Before we move on to configuring the Logic App, we need to update the Policy on the Access Package first. Navigate to the Access Package and open the policy. In the Custom extension section, add the Custom Extension you just created to both “When assignment is granted” and “When assignment is removed” stages. That way the Lifecycle Workflow gets triggered both when a user receives the Access Package and when it’s revoked. Since the PowerShell script evaluates the user’s current Access Package assignments and syncs permissions accordingly, both stages call the same Custom Extension – when granted, the script adds the required permissions, and when removed, the script re-evaluates and removes permissions that are no longer needed.
Next up is where you need to provide the Logic App that we will be using to start the PowerShell script in the Automation account.
Finish by selecting “Create a logic app, and wait”, then press Review and Create. The Custom Extension in the catalog has now been created, and we can move over to the Azure Logic App that was created and configure it to start the PowerShell script that will trigger the Lifecycle Workflow. Click on the name of the Logic App in the catalog and navigate to the designer in the Logic App.
Below you can see how the configuration in the Logic App should look. I will not go into greater detail about this in the blog post, but you can read a lot more about it here: How to run PowerShell scripts in Entra ID Governance Lifecycle Workflows
Once this has been set up, we then need to create another Custom Extension, but this time in Entra ID Governance Lifecycle Workflows – Lifecycle workflows
The process of creating a Custom Extension for Lifecycle Workflows is exactly the same. The only difference is that we are now creating it in the Lifecycle Workflows menu instead of in a catalog in entitlement management.
The Logic App configuration should then look like this:
With this setup, shared mailbox permissions are now automatically managed based on Access Package assignments. When a user is granted an Access Package, they’ll get the appropriate mailbox permissions, and when it’s removed, the permissions are revoked. This removes the need for manual mailbox permission management and keeps everything in sync with your governance policies.
For offboarding, you can use this PowerShell script to remove a user from all Shared mailboxes in your offboarding Lifecycle workflow: Exchange_Remove-UserFromSharedMailboxes.ps1