I would first upgrade osTicket and the plugin. Then I would make a new app registration which you’ve already done and reconfigure the email.
Other than that it seemed to be a microsoft issue last time:
Cheers.
I would first upgrade osTicket and the plugin. Then I would make a new app registration which you’ve already done and reconfigure the email.
Other than that it seemed to be a microsoft issue last time:
Cheers.
Hi
Our system was running without an issue and now authentication is not working with this error. Microsoft side configurations are fine as we been using it for like a year. What could go wrong>?
sachithmuhandiram Same. Almost 2 years of using OAuth this way with no issues, now it's broken.
@KevinTheJedi I upgraded to v1.18.1 and downloaded the latest oauth phar from the website....same issue.
@cmusicfan05 Then it seems Microsoft side issue, right? I had tried graph configurations. But it was also giving the same.
sachithmuhandiram When I look at the logs on the MS side, it shows that it's doing what it's supposed to, but I am not sure.
I went through the directions again, made a new application, gave it the permissions, tried logging in with my admin user (for Office365) and my standard user that I use for incoming/outgoing tickets (not a shared mailbox, we pay for a full user account) and got the same error as the old application.
I have 40+ user accounts on our 365 account so I tried adding other email accounts and received the same error. Also tried opening up every permission possible on the new application. It's 2AM EDT and tickets are piling up...and I don't have an answer for my staff or customers for tomorrow except "don't use it".
We have the same issue on v1.17.5 since last Sunday. We have also tried all the steps mentioned in the previous posts, but no luck. Tickets are piling up....
Have the same issue, I have one instance of 1.17.4 which was fine until Friday. Yet also have another instance of 1.17.4 working absolutely fine. Have recreated the secrets in Azure a number of times and it hasn't solved the issue at present. Little lost at this point.
The Outlook REST API (https://outlook.office.com/api/v2.0/me) has been deprecated for a really long time, and they have been progressively decommissioning those from tenants since March 31th this year.
The replacement for it is the Graph API (https://graph.microsoft.com/v1.0/me), but it cannot be used with the same access token that is used for Outlook IMAP/SMTP/POP. Wrote about it some time ago:
https://forum.osticket.com/d/96893-basic-authentication-retirement-for-legacy-protocols-in-exchange-online/101
This needs to be addressed by either creating a separate access token for Graph calls, or allowing us to skip that API call since its only used for strict email address matching (though completely disabling this from Microsoft provider is not ideal, since it's pretty easy to accidently authorize the wrong mailbox if you are logged on with it).
For now as a quick and dirty workaround I created a "mockup API"/site that returns the JSON:
{"EmailAddress": "mailbox email address here"}
jerer Hi
Can you please explain how you solved this issue?
This is my endpoints. Is there a change ?
Hi, this is just a dirty "hack" to bypass the "User details" API call. This is not a proper fix to this problem, but just something I did temporarily to get things going again. If you do this, make sure you are not logged in to any other mailbox. This bypasses the email address matching so you could accidentally start polling emails from the wrong mailbox. I recommend starting your browser in a new incognito mode just in case.
Create a ".json" file in your osticket folder (or somewhere else) with the content:{"EmailAddress": "set your mailbox email address here"}
Configure that in the "Resource details Endpoint", e.g. https://<your-osticket-host.com>/something.json
(Technically we could use any URL here that returns JSON data, but because the access token is sent to that URL don't use any public ones for security reasons)
Keep the scopes as offline_access https://outlook.office.com/IMAP.AccessAsUser.All https://outlook.office.com/POP.AccessAsUser.All https://outlook.office.com/SMTP.Send
Keep the "Email address attribute" as "EmailAddress".
If you are using multiple mailboxes, I guess you will have to uncheck email address "Strict matching" (again, make sure to logout other mailboxes first). Or you could use multiple json files/php script to handle that.
Yea we are not updating for Graph API until absolutely required because it will require us to completely rework fetching all over again and move it to API calls. This is planned for v2.0 but not for legacy. We have thousands of customers using this with no issues. Simple seems like a Microsoft issue as earlier in the thread it started working again with no changes from our side.
Cheers.
ben_werk
Not everyone is having this issue (yet) because:
But for example when the client secret expires (which is max 2 years) and it needs to be updated, people will be faced with this issue.
That’s not what happened in the referenced thread last time. If they truly decommissioned it then those people would still be broken but it started working again once Microsoft fixed the issue on their end.
Cheers.
I don’t believe they would kill IMAP/POP like that. Graph only supports API calls as far as I’m aware and outlook supports IMAP/POP protocols.
Cheers.
KevinTheJedi
They are not killing Outlook IMAP/SMTP/POP, just the REST APIs.
Go ahead and try to get a graph token from graph then and use it for the imap endpoint. It simply won’t work which is why we used outlook in the first place.
Cheers.
Has anyone found a working, explainable solution to this please???