The Exchange Team announced in this blog post a while ago they are offering support for Hybrid Modern Authentication (HMA) for Exchange On-Premises, this includes a new set of updates for Exchange 2013 (CU19) and 2016 (CU8). With this you are now able to use Azure AD issued tokens to authenticate your Exchange servers on-premises, this is a step in the right direction to eliminate any weak legacy authentication methods. Currently this is hard to achieve and not (yet) supported to turn off completely.
Why not Hybrid Modern Authentication?
There are several good reasons for not turning on HMA. Firstly, you really must know all your clients and often, you need to prioritize resolving any issues associated with this before you’re able to turn on HMA. I’m currently going through this challenge in a larger environment, here are a few examples of the issues I have encountered:
- LOB applications can’t perform OAuth
- Applications need to be rewritten to perform HMA, which is time consuming
- Skype for Business dependencies
Note: When you have Skype for Business deployed, you need to be careful and double-check for your clients. The main reason here is that there are vendors, which can’t perform HMA, therefore meaning they would be locked out.
On the other hand, you may want to give your users the option to use this authentication for the following reasons:
- Increase security as you now can use Conditional Access
- Increase end-user experience in terms of authentication as you have the same as in EXO
- State-of-the-art authentication mechanism of applications
- Reduce complexity for application development due to different authentication
In this this post, I will be predominantly focusing on how to make OAuth authentication without enabling Hybrid Modern Authentication.
There are some essential requirements you must meet before you make OAuth available without having HMA enabled:
- Executing your Exchange Hybrid Deployment (you can read more on Paul’s post here)
- Ensure you have read this article on Docs about Hybrid Modern Authentication overview and prerequisites for using it with on-premises Skype for Business and Exchange servers.
- Add all your on-premises namespaces to your Exchange ServicePrincipal in your tenant. You don’t have to enable HMA for this step, you can stop after verifying your virtual directories.
- You have registered two applications in AD. This is because you can’t add the required values to the property identifierUris when using Native application type, which is the preferred one. You can learn more about the types of applications here.
Register an application
When you have completed all the prerequisites, you need to start by registering two applications in Azure AD. For our example, the application needs access to both environments. One will be a Web App/API for Exchange on-premises and a Native one, which includes Exchange online and Exchange on-premises.
First, you need to register the application for the on-premises environment, follow the below steps to do so:
- Create a new app: Azure AD portal > App registrations > New application registration
Note: I usually use https://localhost/ plus a GUID as Sign-On/Redirect ULR/URI. Make sure this is unique! Create a GUID in PowerShell with this command: [System.Guid]::NewGuid()
2. Add EWS permissions: Settings > Required permissions > Add > Select an API
3. Search for Office 365 Exchange Online and select Delegated permissions > Access mailboxes as the signed-in user via Exchange Web Services
4. Add the on-premises namespaces to this app. This is very important as you will later request a token for the endpoint and if the correct URI is not configured you won’t be able to retrieve a token. Here, you need to edit the Manifest and add all your namespaces including a GUID to the property identifierUris. It should look like this:
Now, we can register the second Native app:
5. Create a new app in the Azure AD portal > App registrations > New application registration
6. Add EWS permissions: the steps for Exchange online are the same as described for the first app. But in this case, we also need to add the previous registered one: Settings > Required permissions > Add > Select an API > search for the previously registered app and Select
Note: don’t forget to check the permission!
7. To avoid doing the prompt for consent twice, we now copy the Application ID of the second app and edit the Manifest of the first app again. Add the Application ID to the property knownClientApplications:
Accessing the mailbox
Now that we have configured our applications, we can start using it directly.
Again, you’ll need to ensure you consent:
After consenting you can see the scope in your retrieved AccessToken:
When you have everything configured correctly, you can access your mailbox via EWSEditor using OAuth:
This also works for other protocol like REST. In this case, you need to select the appropriate claims in the permissions.
If you’ve fulfilled all the requirements and followed the above steps, you will now be able to provide your developers and application owners an additional authentication mechanism. The outcome of this is that it increases security and end-user experience at the same time. You can see this as an effective temporary resolution prior to HMA, where you are currently blocked by the reasons discussed in this article.