Modern Authentication for External Mail Connections in M-Files

Applications have used Basic Authentication to connect to servers, services, and API endpoints for many years. Basic Authentication simply means the application sends a username and password with every request, and those credentials are also often stored or saved on the device in a configuration or hard-coded in software. Traditionally, Basic Authentication has been enabled by default on most servers or services and is relatively simple to set up.

Simplicity isn't bad, but unfortunately, Basic Authentication makes it easier for attackers to capture user credentials (particularly if the credentials are not protected by Transport Layer Security or TLS), which increases the risk of those stolen credentials being reused against other endpoints or services. Furthermore, the enforcement of multifactor authentication (MFA) is not simple (or in some cases possible) when Basic Authentication is enabled.

Basic Authentication is an outdated industry standard. Threats posed by it have only increased since Microsoft originally announced in September 2019 that they were going to turn it off. There are better and more effective user authentication alternatives.

Microsoft and TEAM IM recommend that customers adopt security strategies such as Zero Trust (Never Trust, Always Verify) or apply real-time assessment policies when users and devices access corporate information. These alternatives allow for intelligent decisions about who is trying to access what, from where, and on which device rather than simply trusting an authentication credential that could be a bad actor impersonating a user.

With these threats and risks in mind, Microsoft has taken steps to improve data security in Exchange Online. Microsoft has removed the ability to use Basic Authentication in Exchange Online for Exchange ActiveSync (EAS), POP, IMAP, Remote PowerShell, Exchange Web Services (EWS), Offline Address Book (OAB), Outlook for Windows, and Mac. They are also disabling SMTP AUTH in all tenants in which it's not being used.

This decision requires customers to move from apps that use Basic Authentication to apps that use Modern Authentication. Modern Authentication (OAuth 2.0 token-based authorization) has additional benefits and improvements that help mitigate the issues in Basic Authentication. For example, OAuth access tokens have a limited usable lifetime and are specific to the applications and resources for which they are issued, so they cannot be reused. Enabling and enforcing multifactor authentication (MFA) is also simple with Modern Authentication.

What this means to M-Files Administrators is that connections to external mail sources using the Generic POP3 service and Generic IMAP4 service must be updated to use Microsoft Exchange Online instead.

To facilitate a more secure Microsoft Exchange Online connection, an App will need to be registered (i.e., created) by an Azure AD administrator in the Office 365 tenant. Fortunately, it takes only a few minutes to register a new App. The App will have the Tenant ID of the Office 365 instance hosting the mail source, the Client ID for the App and the Client Secret (a.k.a. password) for the App.

The App will look something like this in Azure AD:

To register an App, here are the basic instructions provided by M-Files in their Azure Portal Configuration for Microsoft Exchange Online as External Mail Source:

1. Go to Azure Portal.
2. Click Azure Active Directory > App Registrations > New registration.
3. Enter a name for the application.
4. In Supported account types, select Accounts in this organizational directory only (only - Single tenant), unless you have a specific reason to select another option.
5. Click Register.

On the Overview page of the application, note down these values: Application (client) ID and Directory (tenant) ID.

Add the required API permissions for the App as follows:

1. In the navigation area on the left, click API permissions.
2. Click Add a permission > Microsoft Graph > Application permissions.
3. In the search field, enter Mail.
4. Expand Mail and select Mail.ReadWrite.
5. Click Add permissions.
6. Click Grant admin consent for <your directory name>.
7. In the confirmation dialog, click Yes.

Generate the Client Secret (or password) for the App:

1. In the navigation area on the left, click Certificates & secrets.
2. Click New client secret.
3. Enter a description and select an expiration period for the client secret.
4. Click Add.
5. Note down the secret value in the Value column. More importantly note that you WILL NOT be able to view the Client Secret later, so in addition to noting the Value the secret should be saved in your Password Manager so you can access it later if needed. Sample secret: 9Xyo8I29P3W-oaw1.04X1N-a4eolRe~N.e

Configure the External Mail Connection in M-Files Admin

1. The Tenant ID, Client ID and Client Secret are the values you noted down from the App registration.
2. The folder is an email address and mail folder you want to ingest. Note if the folder is inside an Inbox, include Inbox in the path.
3. Select Save in Outlook message format if you want the message format preserved (.msg) and select Separate attachments from the message if you want attachments saved separately from the message itself which will create a Multi-file Document.

The Metadata and Advanced tabs can also be used to further define how the ingested mail is handled in M-Files, but those options are the same for all mail connections (i.e., POP3, IMAP4, Microsoft Exchange Online and Google Mail).

Some customers have encountered Transport Layer Security (TLS) errors during the configuration of the connection (specifically TLS 1.2). TLS 1.2 is a requirement on the M-Files server for the connection. While Microsoft has made TLS 1.2 a default setting on newer Windows servers, additional steps may be needed to enable TLS 1.2 in your environment as highlighted in this Microsoft support article: https://go.microsoft.com/fwlink/?linkid=2161187.