This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(284.8, 38%, 37%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EET%3C/text%3E%3C/svg%3E)
Hi,
I have a user application that connects to mailboxes via OAuth, around 05:15 UTC Feb 22, all of my users started experiencing errors.
The credentials are able to log in just fine using the "AUTHENTICATE XOAUTH2" method but the subsequent mailbox commands LIST "" "*" or SELECT Inbox fail right away with the response "BAD User is authenticated but not connected."
Our IMAP implementation hasn't changed in years and all of a sudden it affecting them all. Is there something that has changed recently? Right now my users are completely broken.
Some other posts seem to reference IPv6 but I have confirmed I am trying to access from IPv4.
No there hasn't been any structure changes to users. The app I have registered is a Live SDK Application not a Azure Portal Application.
I'm starting to lean towards Microsoft broke something with Live SDK Application OAuth IMAP access.
No changes to the mailbox have occurred. Of worth noting is this application is a Live SDK application not an Azure Portal Application.
Right now I am leaning towards Outlook did something to allow OAuth2 authentication from Live SDK Apps via IMAP but not allow access to the mailbox.
This is a Live SDK App not the newer style of app registered in the Azure Portal
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(105.60000000000001, 1%, 20%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EP%3C/text%3E%3C/svg%3E)
Please check the user permission again. I think, it has something to do with the permissions. You can authenticate but the authorization doesn't work
I am seeing the same behavior on accounts that have been accessing fine for months, and new accounts that are newly authorized. So it doesn't appear to be permission based (unless IMAP access started requiring a new permission)
This appears to be from Outlook IMAP not requiring the "https://outlook.office.com/IMAP.AccessAsUser.All" scope now. All of the existing users have been Authorized using the "wl.imap" scope. Does anyone know what the reason for this might be? And is there any work-around besides re-authorizing ALL of the users?
Since the Outlook Mail REST API is already deprecated, I recommend migrating to the microsoft recommended Graph API in a timely manner.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(124.80000000000001, 48%, 22%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EFF%3C/text%3E%3C/svg%3E)
Hi @edss testt ,
Check out this link for some possible reasons:
https://www.limilabs.com/qa/196/office-365-bad-user-is-authenticated-but-not-connected
Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.
@Faery Fu-MSFT The thread you posted is from 2014. I don't know if it helps in this situation. The TO said the problem happened recently and with no config changes. So I think more and more, that MS disabled something related to the deprecated APIs in the background.
Update on this,
This started working again ~02:00 UTC Feb 23 it appears that MS disabled access using the old scopes but has since re-enabled them (I'm glad because now I don't have to ask ALL our clients to re-auth)
Going forward does anyone know the "correct" scopes we should be requesting from our users to allow IMAP access? Right now we use these 3 "wl.offline_access,wl.imap,wl.emails" but I am leaning towards updating those to the "https://outlook.office.com/IMAP.AccessAsUser.All" as I saw that scope still allowed access during this outage.
Is the user directly assigned to the shared mailbox or did you changed something with the assignment structure of users recently?
As already written, I recommend not using the Outlook Mail REST API (DEPRECATED) anymore or migrating to it.
The clear recommendation is to use the Graph API and the Outlook Mail REST interface.
If the reply was helpful, please don’t forget to upvote or accept it as an answer, thank you.
Hi @edss testt ,
Thanks for your feedback above which shared more information and glad to know that your issue is resolved now! Since our forum has the policy that the question author cannot accept their own answer. They can only accept answers by others, and according to the scenario introduced here: Answering your own questions on Microsoft Q&A
I would make a brief summary of this post so that other forum members could easily find useful information here:
Issue Symptom:
IMAP returning "BAD User is authenticated but not connected."
Solution:
MS disabled access using the old scopes and re-enabled them.
Going forward does anyone know the "correct" scopes we should be requesting from our users to allow IMAP access?
You can refer to this article to learn about scopes and permissions in the identity platform:
Scopes and permissions in the Microsoft identity platform
In addition, we recommend that you post in the Microsoft Graph Mail API for more appropriate assistance.
You could "Accept Answer" for this summary to close this thread, and your action would be helpful to other users who encounter the same issue and read this thread. Thanks for your understanding!