Enhancing Email Security: configuring SMTP Using EWS OAuth 2.0

Securing email communications is paramount, especially if you work with any US Federal clients. With the deprecation of Basic Authentication by Microsoft, transitioning to OAuth 2.0 for Exchange Web Services (EWS) is essential for maintaining robust security. This guide outlines the steps to configure SMTP using EWS OAuth 2.0, ensuring your email system is both secure and efficient.

Why OAuth 2.0?

OAuth 2.0 is a modern authentication protocol that provides enhanced security compared to traditional username/password methods. It leverages tokens for authentication, reducing the risk of credential theft and unauthorized access. This method is particularly crucial for organizations using Microsoft 365, as Basic Authentication is no longer supported.

Steps to Configure SMTP Using EWS OAuth 2.0

Register Your Application in Azure Active Directory
- Navigate to the Azure Entra ID admin center and log in.
- Select App Registrations and click New Registration.
- Provide a friendly name for your app and configure the necessary settings, including the Redirect URI.
- For example, SolarWinds Email with a Redirect URI of “login.microsoftonline.com/.../nativeclient”
Configure App-Only Authentication (Optional)
- Modify the application manifest to include the required resource access.
- Grant admin consent for the application to access necessary permissions.
Set Up OAuth in the SolarWinds Platform Web Console
- Go to Settings > All Settings > Manage SMTP Servers.
- Click ADD SMTP SERVER and select EWS OAuth 2.0.
- Enter the Application (Client ID), Directory (Tenant ID), and Client Secret obtained from Azure Active Directory.

Important Security Warning

If you use the EWS or Microsoft Graph Mail.Send feature, be aware that it allows the Orion platform to send emails as any user. To restrict this capability to specific mailboxes or users, you need to create an Application Access Policy using the PowerShell command New-ApplicationAccessPolicy (Microsoft, 2023). This ensures that only authorized users or mailboxes can send emails through the platform, enhancing your security posture. You can test this by trying to send as a mailbox not explicitly named in the policy. This will give an error message similar to “Blocked by tenant configured AppOnly AccessPolicy settings.” In the Orion platform, you will just see a test failed message through the GUI.

Additional Security Measures

To further enhance the security of your email system, consider implementing the following measures:

Multi-Factor Authentication (MFA): Enforce MFA for all users accessing the email system. This adds an extra layer of security by requiring a second form of verification.
Conditional Access Policies: Use Azure Active Directory Conditional Access to define policies that control how and when users can access your email system.
Regular Audits and Monitoring: Regularly audit access logs and monitor for any suspicious activities. Implement automated alerts for potential security breaches.

Conclusion

Transitioning to OAuth 2.0 for SMTP configuration not only aligns with Microsoft’s security standards but also significantly enhances the protection of your email communications. By following the steps outlined above and incorporating additional security measures, you can ensure a secure and reliable email system for your organization.

More details…

Create a Security Group

To use the New-ApplicationAccessPolicy you first need to create a security group whose members will be the mailboxes the Enterprise App will Send As.

You will then need to have the Application (Client) ID to apply the command. Before you run the command, you will need to be connected to Exchange Online.

New-ApplicationAccessPolicy -AppId < Application (Client) ID> -PolicyScopeGroupId SCISendEmailSolarWinds@foobar.com -AccessRight RestrictAccess -Description "Restrict SolarWinds EMAIL app to members of distribution group SCI Send Email SolarWinds."

Once you have all this set up you can run a test while connected to Exchange Online using the following:
Test-ApplicationAccessPolicy -Identity user1.expect.to.work@foobar.com -AppId <Application (Client) ID>

Result:

AppId             : <Application (Client) ID>
Mailbox           : user1.expect.to.work
MailboxId         : 88888888-9999-cccc-bbbb-fffffffddfff
MailboxSid        : S-1-2-34-567890101-1121314151-6171819202-1222324
AccessCheckResult : Granted

Test-ApplicationAccessPolicy -Identity user2.expect.to.fail@foobar.com -AppId <Application (Client) ID>

Result:

AppId             : <Application (Client) ID>
Mailbox           : user1.expect.to.fail
MailboxId         : 88888888-9999-cccc-aaaa-eeeeeeeddeee
MailboxSid        : S-1-2-34-567890202-1222324252-6272829303-1323334
AccessCheckResult : Denied

This write up is based on the following references:

Find more posts tagged with

ews

smtp

Entra ID

Hybrid Cloud Observability

Client Secret

modern authentication

Comments

tomiannelli

I also have a script that will use the Send-MgUserMail PowerShell command that will demonstrate the policy is working as you expect.

SteveK

I want to say @tomiannelli is spot on about this. I was actually just about to do a write up for the exact same thing. As always I like the disclaimer of mileage will vary by environment, so please test yourself.

We are looking to see what applications could be shifted over to OAUTH for general security reasons. I started to test out SolarWinds documentation and was a bit shocked that I could impersonate any user in our tenant. That is a major concern and I could only imagine how it could be exploited.

We stumbled on the same solution, but I focused on the Entra/365 side instead of an onprem ad side. So the only thing that was different is with Entra, you will want to make a mail enabled security group. You can then add the team managing SolarWinds as owners to the security group (being an owner did not pull them into scope for being a Sender from SolarWinds). Then you can either add the user(s) or shared mailbox(es) as members to the group.

Then as you showed in the Microsoft documentation you could run:

Connect-ExchangeOnline
$MESGroup = Read-Host "Provide the FQDN of the mail enabled security group"
$AppID = Read-Host "Provide the application id"
$PolicyDesc = Read-Host "Provide a description for the application access policy"
New-ApplicationAccessPolicy -AppID $AppID -PolicyScopeGroupID $MESGroup -AccessRight RestricAccess -Description $PolicyDesc

I'm kind of surprised with the shift in focus on security, that SolarWinds would not have already had something in their documentation for this. To me this is just as bad as your monitoring account being a domain admin.