When connecting LibraCyber ESG to a Microsoft 365 tenant using the native Microsoft 365 integration (Graph API), the way shared mailboxes are imported and handled has implications for quarantine reports, login experience, and assigned roles.
This document explains the default method and the possible alternative (external mapping script).
Method 1 (Default): Shared Mailboxes Imported as Functional Users
By design, when LibraCyber ESG imports users from Microsoft 365, shared mailboxes are created in ESG as Functional Users. This happens because the Microsoft Graph API does not provide detailed permission data concerning shared mailbox access. Without permissions information, ESG cannot automatically map the shared mailbox to the actual end users who access it.
Functional Users have the following characteristics:
-
They cannot log in to the ESG web portal directly.
-
Their quarantine reports are generated and stored in ESG like normal users, but with limited capabilities (No "View" button).
Emails sent to a shared mailbox that are quarantined in ESG generate a quarantine report for the functional user representing the shared mailbox. An end user who needs to review or release items in that report must:
-
-
Open the quarantine report email from the shared mailbox in their own mailbox.
-
Follow the link to the ESG web portal.
-
Log in using their own user account via Microsoft 365 SSO
-
The end user must have the same ESG roles and permissions that the functional user has in order to act on its quarantine items.
For example, if the shared mailbox (functional user) has Release permissions, the end user must also be permitted to release messages in ESG. If roles do not match, the user may be unable to perform release or manage list actions.
Disadvantages of Default Behavior
-
Separate Quarantine Reports:
-
A quarantine report for their personal mailbox.
-
A quarantine report for the shared mailbox.
-
- No Direct “View” Option: Shared mailbox quarantine items may not show the “View” action in the report in the same way personal mailbox items do.
Method 2: External Mapping Script
There's an alternative way which is to map shared mailboxes to actual user accounts setting up an external script using PowerShell and the ESG API.
Note: This approach can be worth if the number of shared mailboxes to map is big, if you only have few shared mailboxes to map to a couple of users doing it manually.
This can be done by adding the address of the shared mailbox as a "secondary address" to the ESG user which must be able to manage it's quarantine from the "User Management".
The script’s objective is, for each shared mailbox, to identify the users with delegated access and use the ESG API to assign the shared mailbox address as a secondary address on the corresponding user account in ESG. This way, the shared mailbox becomes effectively associated with real user accounts in ESG, rather than being represented as a functional user.
The script does the following steps:
-
Connect to Exchange Online via PowerShell.
- Login with M365 SSO of the admin of the tenant to access the data.
-
Retrieve all shared mailboxes.
-
For each shared mailbox:
-
Obtain mailbox permissions (FullAccess granted to users and groups).
-
For groups, expand the group to its members.
-
-
For each user with permissions to the shared mailbox, add the shared mailbox primary SMTP as a secondary address via the ESG API.
Disadvantages of External Mapping Script
- To keep these mappings updated, you need the script running on a scheduled basis.
- Custom script to be built based on the given template
This example script is provided by LibraCyber as a template and should be customized to fit your tenant and environment: Automatic mapping of Shared Mailbox in M365