Trouble enabling SMTP with Microsoft OAuth2

ajavaid

Hi there,

I've been trying to get a shared mailbox configured to be able to send and receive, with OAuth2 authentication. I have the latest version of the OAuth2 plugin, just downloaded. I have been able to use the plugin to successfully set up SSO and incoming mail, so I'm able to create tickets by sending to it, but I'm getting a "Temporary server error" when trying to enable SMTP. If I respond to a ticket, it'll fall back to sending the response from another email we have set up as the system default (that one's using legacy user/pass auth), "on behalf" of this one.

I have "Strict Matching" disabled, and when authenticating, I am logging in with an M365 account that has full delegated access over the shared mailbox. This seems to work when I press "Submit", as it generated a token, but if I go to enter in the SMTP info (hostname, port number, and enabling it), and then "Save Changes" from there, I receive the error. Did not run into this with the Remote Mailbox settings for inbound.

I tried "Same as Remote Mailbox" as well for the Authentication setting, but it threw the same error. I am using the same registered Entra app for the SSO, inbound, and outbound, in case that's an issue. I've also attached an image of the permissions granted within the app.

Please let me know what other info might be needed to find out what's going on. I hope it's something stupidly easy I missed (I swear I'm going over the documentation carefully!). Thank you.

KevinTheJedi

ajavaid

As you can see from the error, Microsoft is reporting a temporary server error on their end. You should retry in a couple of minutes. If the issue persists you can reach out to Microsoft support.

Cheers.

ajavaid

Hi Kevin,

Thanks for the quick reply- I should have mentioned earlier that I tried this before (on Friday). Thought it might be, you know... a temporary server issue lol. So I worked on some other stuff and am just now coming back to it, but I'm still getting the same error. Could be an issue on their side, but I have my suspicions.

Looking around more, would it be this? My email address attribute in the Remote Mailbox settings is set to "userPrincipalName", but "mail" in the SMTP settings. I remember setting it to the UPN when first configuring the Remote Mailbox settings, but I no longer see the option to change it when I go to the email settings (and I'm not allowed to from this Plugins settings area). I deleted the SMTP instance from Plugins and went through the setup for it again in the email settings- authorization was successful once more, and the token reappeared, but going to hit "Save Changes" gave me the initial error once again. And there wasn't an attribute field to edit in the config. I might just be missing where to make this change from?

KevinTheJedi

ajavaid

Because you never need to change the attribute for Email OAuth2 Authorization; only for User/Agent OAuth2 Authentication. If you get a token that's all you need on the osTicket end. The error is coming directly from Microsoft so I would recommend reaching out to them for further assistance. You could also check to ensure SMTP is enabled on the email account on the microsoft side, see if the user has any policies attached that will prevent smtp, etc.

Cheers.

ajavaid

I got it to work.

I don't know why, but I think it's something to do with the Microsoft 365 role(s) of the login account used. Previous one was a global admin. Authenticating with a different account, which is just a regular user (but still has delegated access to the shared mailbox), gave me no errors, and the emails are coming through fine. I wonder if there's something specific about the initial account I was using that was causing it or if this can be replicated by others with global admin.

ajavaid

For posterity, I actually found this today:

https://techcommunity.microsoft.com/discussions/exchange_general/exchange-smtp-auth-fails-with-451-4-7-0-temporary-server-error-please-try-again-/4345696

Like I suspected, there's something weird with M365 roles and SMTP. Specifically when an account has both global admin and other admin roles assigned, apparently.