M365 basic AUTH deprecation & OAUTH 2.0 support
With Microsoft's ending support for Basic AUTH in Oct 2022, is the configuration for using your own mail server going to support OAUTH for continued use of our own mail servers?
Answers
-
Bumping my own post. It seems others with M365 are seeing the same errors. For those who have access to admin notifications, M365 admins have been getting notifications that basic auth is being turned off randomly for periods of time to identify and alert us of accounts using basic auth.
Workarounds are going to stop working in Oct 22, leaving all M365 connected servers unusable with servicecamp's current configuration options.
A month without even a simple acknowledgement Teamviewer/servicecamp is aware of this upcoming deadline is concerning. Give us a roadmap please, if the roadmap is no more M365 support, I'd rather know now then when email stops and it's a zero day emergency for no reason other than poor vendor communication to its customers.
0 -
I reported this before the summer to them and got an an answer that they would support this.
I found this withing the own smtp server today but I have checked what it means, sorry screenshoot is in swedish.
0 -
Having the same problem as you but no resolution yet.
The link above is only a possibility to copy your other settings and not a solution for Office/Microsoft 365.
0 -
So ... today 24th October ... Using our Office365 Exchange server does not work anymore!
We are gettin' the following error:
Incoming connection failed with the following error:
LOGIN failed.
Not connected. No email resource at: {outlook.office365.com:993/imap/ssl/novalidate-cert}INBOX
0 -
Bump
Same problem.
We had the problem back in june/july 2022 and we got in touch with support saying we had to set AllowBasicAuthImap to true because they use IMAP for authentication.
So we did and got it working again - we read up on Microsoft being in the process of deprecating authentication methods and we informed them of this. We got the reply their dev team knows about it and was looking into it.
Fast forward to now, same problem again and still no fix.
0 -
oAuth2 support is here now
0 -
I try to configure it,
but it asks for information that I don't know where to get:
Username* :
Tenant Id*
Client ID*
Client Secrets*
Can you help me ?
0 -
You have to create an app in AAD. From there you can get the tenant id and the client id directly.
In the app you can create a client secret and thats where you get that information from. You also have to add IMAP and POP3 permissions to the app, else it will complain about a missing microservice.
But that also doesn't seem to be enough, because I'm missing the callback URL for the app. In some way servicecamp has to receive the actual login token from M365, but without a callback URL this doesn't seem to work and the authentication fails. I have seen no documentation for that.
My current workaround is using davmail (also creates the app with a working callback URL to your davmail server) with login credentials. So basically servicecamp connects to davmail with the user credentials and the davmails tunnels that via OAUTH to M365. This seems to work without any problems for more than half a year now, but is also to be considered a dirty workaround. I would prefer to skip davmail and use OAUTH directly.
0 -
Hi All, I ran into the same issue, with lots of trouble, finally got it to work.
First off, follow the Microsoft link below;
Then watch this youtube to explain the powershell stuff in more detail;
0 -
Still having this same issue. Have contacted Microsoft support and they have confirmed that the issue is no on our Azures end. There is a problem with the Service Camp configuration.
However can you please advise the exact steps you took from the links information. It isn't clear on the microsoft websites which steps you can take as they offer multiple options.
0
