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: API permissions > Add a permission > on Microsoft APIs scroll down to Exchange > Delegated permission > on EWS check EWS.AccessAsUser.
3. Make this app visible to other apps by exposing an API:
- Expose an API > next to Application ID URI click on Set
- AAD will auto-generate an ID
- Save > Add a scope
Note: The Scope name is the only field, which requires the specific value: user_impersonate. The other fields can be filled as you want to describe the scope.
Now we can register the second Native app:
5. Create a new app Azure AD portal > App registrations > New application registration
5. Add EWS permissions: the steps for Exchange online is exactly as described for the first app. But in this app we also add the previously registered one: API permissions > Add a permission > APIs my organization uses > search for the previously registered app > select Delegated permissions and check user_impersonation
Note: don’t forget to check the permission.
6. To avoid 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 and add the namespace of the on-premises hosts to the property identifierUris:
Note: You can add multiple namespaces. Make sure you have added all also to Exchange SPN as described in the pre-requisites:
If you missed this on the SPN or in the attribute identifierUris, you will receive an error, when acquiring a token:
AADSTS500011: The resource principal named <resource> was not found in the tenant named <your tenant>. This can happen if the application has not been installed by the administrator of the tenant or consented to by any user in the tenant. You might have sent your authentication request to the wrong tenant.
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.