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.

    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.

    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)

      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.

      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.

        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.

        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.

          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.

          Write a Reply...