Did you find a solution for this?
If you can share it in case you have found it.
This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
Greetings!
I have a web app that uses oauth authentication with IMAP/SMTP protocols to access emails in office365/outlook mailboxes. But a few customers had a problem connecting through those protocols Server returns A0003 BAD User is authenticated but not connected after selecting mailbox. I've tested oauth flow with my personal outlook and office365 accounts - and I haven't experienced such error.
Customers that have this problem has a normal mailbox, not shared one. Also SMPT/IMAP options are turned on. The problem began a couple days ago, no changes in oauth flow in my web application were done.
I've did some research on my own but didn't find much. So my questions are :
Hi @Andrii Maslov ,
I have not encountered this issue myself, but have seen some similar cases where this can happen if someone enters a bad password or credentials, or unsuccessful MFA. It will look like there was a successful authentication when there wasn't one.
I found an issue where someone else received this error, and it looks like it can happen due to an incorrect CLI command.
The solution listed in the thread:
proper CLI arguments for imapsync are: --authuser2 "******@domain.tld" --user2 "******@domain.tld" --office2
Before that, the following PowerShell command must be executed: Add-MailboxPermission -identity ******@domain.tld -user ******@domain.tld -accessrights fullaccess -inheritancetype all
Hi @MarileeTurscak,
Thank you for your response.
I'm using xoauth method for authorization with IMAP/SMTP protocols so it's only token passed there, but sign-in process and obtaining access token are successful. I've tried to enter invalid pass myself and it just fails on sing-in with appropriate error message. Also, there are no MFA methods enabled for these users.
Were there some policies introduced, like default Security policy, that can block such access? Customer also says there are no Failure in Sign-in logs.
I myself do not have access to those user's azure/o365 admin portals, so running shell commands isn't option right now.
I can describe whole oauth flow with my app, maybe it has some flaws that you could point out.
Did you find a solution for this?
If you can share it in case you have found it.
Thanks