Since MailStore Version 13 it is now possible for Microsoft 365 customers to tighten up their security by utilising Microsoft’s Modern Authentication integration.
But what changes have been made and how easy is it to convert a MailStore installation over from using Basic Authentication?
Before we begin lets first look at the two modes of Authentication with Microsoft and how they differ.
This is the tried and tested model that most users and admins will be familiar with, and simply consists of verifying access by using a username and password for the session. In MailStore this verification can be used to Sync users via the Directory Services type ‘Microsoft 365 (Basic Authentication)’ or through the use of any ‘Microsoft Exchange’ Archive jobs for single or multiple mailboxes.
In order to give MailStore access the administrator must enter a username and password of a valid Microsoft 365 account or service principle that has the valid rights.
But here lies the weakness…
All that is needed for anyone to connect and gain access is those two details, the username (often a known email address) and the associated password.
In the case of the Multiple Mailbox job in Mailstore if a hacker knows the username and password of an admin account in effect they can access the entire contents of all users mailboxes, so keeping those details both strong and on a ‘need to know basis are extremely important’.
Microsoft knows this and for some time have had a solution to increase security both for basic user authentication by implementing Multifactor Authentication for user access. This is an ever evolving solution from Microsoft and they can add new methods and restrictions for users in different ways depending on whether they are connecting from known ‘Trusted devices or networks’ or not.
You may already be familiar with MFA for user access and this does indeed help users secure their connection, however, when 3rd party applications simulate a client type connection by logging in using the user details requiring MFA is not really option as the MFA method typically is something the application cannot gain access too.
Lets take for example being sent a one time code via SMS text, or using an authentication app to generate the code. The historic way around this was the use of assigned ‘App Passwords’ for each user account which only applications like MailStore should know. However, in effect, we have just circumvented the whole point of using MFA by saying its ok you can still get in with a unique username and password just don’t give it out to users, better but not by much!
Again, Microsoft is well aware of this and actively recommend against the use of App passwords and instead would rather remove basic Authentication method for users and Applications all together, and recommend an entirely new method of authenticating users we refer to as ‘Modern Authentication’
So what is Modern Authentication?
Well, it’s new, that’s a given in the name but fundamentally the main thing we are talking about here in terms of Microsoft authentication is that we no longer allow anything other than users to log into Microsoft using the account credentials, and we can therefore force users to use additional MFA methods to further secure their own access from only known trusted devices and we disable all old ‘App Passwords that may have existed’
So where does this leave the 3rd party applications like MailStore if they can no longer use an App Password?
Well, they are given a completely new method to validate whether the user is valid or not utilising an authorisation mechanism called OAuth 2.0.
This mechanism is based around a trust relationship between the user, application (MailStore) and the identity provider (Microsoft). When a user wishes to log into MailStore, MailStore in effect redirects that user to login to Microsoft but includes a known ID token for them to use as a reference If Microsoft verifies them (after any MFA requirements) they are given a specific URI (URL and verification Token) to return to the Application MailStore, as a final acknowledgement of them being successful.
So how does this change how users log into mailstore?
First, let’s think about how users log into MailStore with simple Basic Authentication.
The user is asked within the MailStore Client or Web client or Outlook addon for both a valid username and password which are given to MailStore over a secured connection.
MailStore takes these details and acts on behalf of the client to simulate a login to Microsoft using those details. If they are valid it can allow the user access.
Simple but ultimately not very secure.
Alternatively, let’s have a look at what’s actually happening when the same user now log into MailStore if they are using Modern Authentication.
Step 1) Send Username
When the user accesses any MailStore features in the Outlook add-in they are asked to enter their MailStore user identification (email address). You may have noticed this is different from previous versions of MailStore that asked for both the username and password on the same screen.
Step 2) Return Sign-in URI of identity Provider
MailStore checks the user against the MailStore user list to see if it is either a Directory Synchronised user that is using modern authentication or indeed a local MailStore integrated user that has a stored local password. In the case that the user is synchronised with Microsoft, it then sends back a Sign-in URI of the identity Provider they should use for the Client
Step 3) Authenticate
The Client then connects to the Identity Provider using the URI that was provided ( Microsoft in our example) which prompts them to Authenticate with that provider as usual. It’s at this stage that they would have to enter any MFA they had set up
note if the user is already logged into a Microsoft account either directly within windows or because they already have a valid web session open then they will not need to log in again. this is the ‘single sign-on’ method
Step 4) Return Redirect URI + ID Token
Once authenticated the Identity Provider matches the user against the Application registered in Azure AD API and provide an ID Token using the application certificate configured. Only the registered Application can use this token. This token along with the Redirect URI for the Application are sent back to the client.
In the case of MailStore the Redirect URI needs to be a valid MailStore server hostname in respect to the client. Typically the fqdn of the server is used e.g http://mailstoreserver.mydomain.com:8462/oidc/signin
Step 5) Send ID Token to Redirect URI
The client then opens a direct HTTPS connection to the URI address provided ID token back to the MailStore Server.
Step 6) Validate ID Token
MailStore takes the ID Token provided by the Client and requests the user information for that token. This user information is provided and is the final verification that the user is allowed access.
Step 7) Mark session as Authenticated
MailStore grants the user access and Marks the session as Authenticated.
The important difference to this method is that at no point does MailStore know the user’s password or MFA details
So what changes need to be made in MailStore?
To save making this blog post any longer (and well done for getting this far!) it would not be good to list all the steps here, but they are all covered in the following MailStore ‘Implementation guide’
If you are Converting a MailStore installation over from Basic Authentication to Modern Authentication
Thease are the main pointers I would advise.
- Stop all existing jobs from running by converting them to ‘Manual’ mode or delete any scheduled jobs you may have configured
- Setup your users first using the new Directory Services method ‘Microsoft 365 (Modern Authentication), the details are in the guide above
- Once your users are synchronising correctly try logging in as one of the users using the MailStore Web interface this will check the verification is working correctly.
- Create new archive jobs using the Email-Servers > Microsoft 365 Type to mirror any existing jobs you have set up using Basic Authentication.
Note these old jobs may continue to work for the time being if Basic authentication is still enabled on your tenant at Microsoft but this will be removed in the future
If you do follow this guide please follow it carefully as there are several steps and it is easy to miss one which will likely cause it to fail, but rest assured if you are having issues our support team is on hand to help at email@example.com