Fetching emails using oauth stopped working on 10th June

cjohnsonuk

We've been using oauth to fetch emails from M365 now since it was first added to OSTicket.
We initially had problems with the tokens expiring until v18.1 and its been working fine since then up until 2 days ago.
I noticed that the tokens had expire so clicked submit to get a new token at which point I saw the error:
Email Mismatch: Expecting Authorization for ticket@emaildomain.com not username@emaildomain.com

OS ticket has not been changed, nor has the email address settings so I can only conclude that the way MS servers respond has been changed in some way.

I have seen other posts that are similar but not identical (eg https://forum.osticket.com/d/101874-email-mismatch-for-oauth-using-account-with-send-as-permissions suggesting editing the code ) but as ours has worked for all of the period since this ticket was logged despite similarities in email box configuration I don't think this is the same issue and as we have a number of email addresses that are processed the one alternative override in the code change suggestion would not work.

I'm going to continue investigating this but I'm posting it in case others are also having recent email/m365/o365 issues and can add something to this thread.
@KevinTheJedi Thanks for all your responses to the other threads. I'm working my way through them.

KevinTheJedi

cjohnsonuk

So, the very first thing to ask is is the email you are using in osTicket a real email or a shared mailbox/resource email? If a real email this simply means your browser is using a cached microsoft login with your personal email (or whatever email it's complaining about). To remedy this simply login to osTicket in an incognito window and perform the steps from there. This way when it brings you to microsoft it doesn't use a cached login and instead allows you to login as the email you are using in osTicket. Once you do this you shouldn't have issues.

Let me know if it's a shared mailbox and I can tell you those steps as it's pretty lengthy.

Cheers.

cjohnsonuk

2fa had been enabled on all three of these accounts, they are all shared mailboxes. They now have silly long passwords and no 2fa and two are now working. One remaining shared mailbox is still not working. I've confirmed its a shared mailbox. This tick box in the image below would appear to be the obvious thing to check (uncheck) as it relates to the error I'm getting
but if there is a better way of doing this to avoid the issues highlighted in the hints any instructions will be greatly appreciated (I have unchecked it and submitted and got a token but when saving I get an authentication failure )
and if there is a way to keep mfa enabled for direct log in but have OAuth still work with an application password or something that would be great.

Comparing the tokens that are created for the two that work the resource owner in the token is listed as the email address of the shared mail box. For the one that is not working the resource owner is shown as my email address not the shared email box address (hence the need for the unchecking of the strict match box). I'm not sure where the oauth plugin pulls the resource owner information from for us to go and correct it, presumably in O365 somewhere

About my installation
Server Information
osTicket Version v1.18.1 (0375576) — Up to date
Web Server Software Apache/2.4.52
MySQL Version 10.6.18
PHP Version 8.2.20
PHP Extensions
gdlib Used for image manipulation and PDF printing
imap Used for email fetching
xml XML API
xml-dom Used for HTML email processing
json Improves performance creating and processing JSON
mbstring Highly recommended for non western european language content
phar Highly recommended for plugins and language packs
intl Highly recommended for non western european language content
fileinfo Used to detect file types for uploads
zip Used for ticket and task exporting
APCu Improves overall performance
Zend Opcache Improves overall performance
PHP Settings
cgi.fix_pathinfo "1" is recommended if AJAX is not working
date.timezone Europe/London
Database Information and Usage

Space Used 1439.11 MiB
Space for Attachments 617.52 MiB
Timezone BST (Interpreted as Europe/London)

KevinTheJedi

cjohnsonuk

It pulls it from the currently logged in account in O365. So logout of Microsoft from your personal account or simply use an incognito window.

Cheers.

cjohnsonuk

Thats corrected the resource owner. I had seen you post incognito mode elsewhere and had meant to check it but then I got tangled in the process of using the azure portal for adding/ updating the account and it completely slipped my mind. Now I just get an Authentication failed when I click save changes on this particular email configuration so I'll go back to the azure portal and check I've got everything configured correctly.

KevinTheJedi

cjohnsonuk

Then I’m not sure. You will need to check all possible logs on the Microsoft side to see if they give you a reason. You can also compare the working accounts with this account to see if there is anything different between them on both sides (osTicket and Microsoft).

Cheers.

cjohnsonuk

FIxed

The issue turned out to be a step I missed in the documentation

The "Grant Admin consent" instruction listed here

https://docs.osticket.com/en/latest/OAuth2/Microsoft%20Authorization%20Guide.html#:~:text=Now%20you%20will%20need%20to%20grant%20Admin%20Consent%20to%20the%20scopes%20by%20clicking%20the%20Grant%20admin%20consent%20for%20button%20and%20clicking%20Yes%20in%20the%20consent%20popup.

This link was greyed out, I'd presumed that meant it had already been clicked. It turns out that it meant I didn't have permissions to set this. My azure user associated with the ticket email account didn't have permissions. I had to ask the azure manager to click this form me. Once this was done and the token was renewed everything started working as before.

It might be worthwhile adding a note in the manual pages to indicate that if the "grant admin consent" is greyed out the azure administrator should be contacted to carry out this step.

@KevinTheJedi thanks for your support in getting through this.

KevinTheJedi

cjohnsonuk

That should be listed in the upstream Microsoft documentation and is a pretty obvious thing if you are familiar with App Registrations in general (which you should be if you are setting this stuff up). Plus the button itself should say “Grant Admin Consent” which indicates must be an Admin to provide consent.

Cheers.