Configure Azure MS Graph API
Connect ASM to M365/Exchange Online using MS Graph API
Applicable versions: ASM 10.5.5 and above
MS Graph API has also been provided as a patch to some earlier versions of ASM and vFire Core
Steps to connect ASM to M365 Email Accounts using the MS Graph API
Create an App Registration in Azure Portal
Configure Microsoft Graph API Permissions
Add a Client/Secret and set an Expiry Date
Limit application permissions to a specific Exchange Online Mailbox
Configure ASM - Outgoing Email
Configure ASM - Incoming Email
Test Connectivity
1. Create an App Registration in Azure Portal
You must use an Azure account in the same Microsoft 365 Subscription (Tenant) that you intend to register the app with.
Sign in to the Azure Portal (https://portal.azure.com) using an account with the correct permissions to create an App Registration e.g. an Administrator Account.
Select Azure Entra ID (previously Azure Active Directory)
Under Manage select App Registration
Click on New Registration
In the Register an Application screen enter your application's registration information:
In the Name section, enter an application name that will be displayed to the users.
Select Accounts in any organizational directory option from Supported account types section.
Set the Redirect URI (optional)
Click on Register to create the application.
The app registration will be created and then direct you to the App Registration Overview Page.
On the App Registration Overview screen, hover over Application (client) ID value, and select the Copy to clipboard icon to copy the value as you'll need to specify this in ASM.
Under Manage, select API Permissions and proceed to Step 2.
2. Configure MS Graph API Permissions
Under the Configured Permissions section select Add a Permission
Select Microsoft APIs and then select Microsoft Graph
Select Application Permissions
In the Search field type 'mail'
Expand the options under Mail and enable the following permissions:
Press the Add permissions button to apply the API Permissions
3. Add a Client Secret
In the Azure Portal for the Application Registration create a new Client Secret by going to the Certificates & Secrets Menu:
Under Manage select Certificates & secrets
Select New Client Secret
Add a Name and choose an Expiry Date
The Client Secret Expiry Date can be set by default up to 24 months. Microsoft recommend that you do not set an expiry date higher than this period for Client Secret IDs.
Once the Client Secret ID has expired the ASM Email Accounts configurred will stop connecting to Exchange Online and emails will stop working until a valid Client Secret ID is configured in Azure Portal.
It is the Customers responsibility to track/manage the Client Secret ID's expiry date and renew in order to maintain service continuity.
Press Add
Obtain the Client Secret ID from the Azure Portal by selecting the Copy to clipboard icon, to copy the value as you'll need to specify this in ASM.
4. Limiting application permissions to specific Exchange Online mailboxes
The permissions required for this type of mail service could allow ASM to send and receive email from any mailbox.
In production environments, mailbox permissions should be limited to only allow sending and receiving from the required addresses.
Configuring permissions for Exchange Online mailboxes is beyond the scope of this document but further information is available here:https:
Configure ASM
5. Outgoing Email
Add a new Outgoing Mail server. Instructions on how to do this can be found here:
Copy :
Tenant ID
Client ID
Client Secret
values from Azure Portal and use them to configure the ASM Email Server
6. Incoming Email
Add a new Incoming Mail Server in ASM. Instructions can be found here:
Copy :
Tenant ID
Client ID
Client Secret
values from the Azure Portal App Registration and use them to configure the ASM Incoming Email Server.
7. Test Connectivity
Once Outgoing and Incoming Email has been configured you should test connectivity by using the Test button in the toolbar and then by sending and receiving email via the configured mail servers.
FAQ Resource could not be discovered
This probably means the email address is not spelled correctly. You should double check the spelling of the email domain name. It might also mean that the associated account does not have email enabled.
FAQ Access Denied
This is likely because Azure has not been configured for the correct roles and permission through the API.