ramrajone I didn't test with a separate app registration, so I will give that a try. Already have a separate server and instance altogether. Stood up another VM.

    rblake

    I just re-tested my O365 setup in an instance that is getting this same error. When trying my O365 email it worked with no issues. So it definitely seems to be an issue with your MS account(s) specifically. I would have MS look deeper into this rather than saying it's an application issue.

    Cheers.

        KevinTheJedi So it appears that I can't request an app and then approve it for it to work (which is what I had been trying). I have to temporarily assign the osTicket e-mail account with Global Admin and then go through the process and then it works. Just tested on my test environment and will test on production after-hours. Any chance that will be changing as that's a huge pain (and a security risk).

            KevinTheJedi Ok, so I was able to get it to work by assigning global admin to my test e-mail account and using that to log in and consent. It worked fine after doing that. However, I have since removed Global Admin permissions from the user and now I'm getting AUTHENTICATE failed and it's not working. We restrict the ability to consent in our company for security reasons (we're regulated heavily). However, what's interesting is that with the other solution, I am able to consent as the user without the need for global admin. So that's interesting now that I think about it. If you'll note, this is the difference in permissions: https://forum.osticket.com/d/102129-osticket-o365-e-mail-retrieval-sending-stopped-working/33

            EDIT: Using my account to consent on behalf of the account does not work.

                rblake

                Are you sure you are using v1.17.2 and the latest build of the OAuth2 plugin? Download just the OAuth2 plugin from our website, re-install, re-configure, and retest. Also, use a global admin (that's normally a global admin) to test authorization.

                It might be that it's attempting to use the Authorizer's account (admin who consented) to select the mail from.

                Cheers.

                  For anyone stumbling over the post because of the same "cannot select INBOX, is this a valid transport?" error. For me the problem was caused by IMAP simply not being enabled for that Mailbox in O365, after enabling it and waiting about 30-60 Minutes it worked and osTicket could fetch the E-Mails no problem.

                  Hi all,
                  My apologies for going dark over the last few days, had some other pressing projects take up my time and I was able to get Legacy Authentication to work.

                  I thought I had it working but no such luck. When I toggled it back on from using Legacy Authentication, it broke again and gives me the error again.

                  I have IMAP already enabled on the user account and when I check Conditional Access I don't even see any attempts to authenticate with the account. I have added the user as an "Owner" of the osTicket application, which is supposed to give them full control over the configuration.

                  I finally spoke with Microsoft Support and they had me run this in PowerShell:
                  $username = "Sender Email Address"
                  $password = "Password"
                  $sstr = ConvertTo-SecureString -string $password -AsPlainText -Force
                  $cred = New-Object System.Management.Automation.PSCredential -argumentlist $username, $sstr
                  $body = "This is a test email"
                  Send-MailMessage -To "Sender Email Address" -from "Recipient Email Address" -Subject 'Test message' -Body $body -BodyAsHtml -smtpserver smtp.office365.com -usessl -Credential $cred -Port 587

                  They claim that running the above verifies that OAUTH2 is working; however, I believe the PowerShell command only uses SMTP AUTH, which is a legacy protocol and is only working right now because I have legacy authentication enabled until the end of the year.

                  I am running version 0.6. If there's a newer version, I'll get that installed and tested. Just wanted to give you all an update.

                  EDIT: @KevinTheJedi - If you are interested in joining a support call with Microsoft and I, please let me know.

                    rblake

                    Let me go back and ask in your current setup did you authorize as a different account than the email? If so we’ve seen a bug where it’s using the Authorizer's account to attempt to connect to IMAP/POP3 and SMTP. We are working on a patch to address this and I’ll let you know once that’s available.

                    To test this try adding the email as an Application Admin (meaning they are admin only for this app) and consent/authorize as the email itself. If that works then your issue is definitely what I mentioned above.

                    Cheers.

                        @KevinTheJedi Just as a FYI, with the other tool I use, you don't need Application Administrator access to get OAUTH2 to work, you can just log in as that user without any admin rights and it will work.

                          rblake

                          Not sure how as you have to consent to the permissions and I believe you have to be an admin to consent. Is the other registered app a published app or something?

                          Cheers.

                              rblake

                              To give you an update, I was able to replicate the error. We have since addressed the Resource Owner part so that it doesn’t use the authorizer’s account for the auth request instead it uses the real email/alias but we are still getting the same error. We are going to debug deeper on Monday to see what else we are missing. It has to be something small like an option or something.

                              Cheers.

                                KevinTheJedi No, I manually created the app. I also went through the Azure side and did Admin Consent so the account doesn't have to. However, they do require you to log in with the e-mail account used to request a token. Maybe your code is requiring consent whereas if you set it up on the front end in the Azure side and do Admin Consent, it should just work.

                                    rblake

                                    We removed the prompt=consent option in the latest build of the OAuth2 plugin so it should now be up to MS to determine wether to force consent or not.

                                    Cheers.

                                      I deleted the old OAuth2 plugin and installed the new one, and I still couldn't get around the "cannot select INBOX, is this a valid transport?". I made the mailbox holder Global Admin and it successfully updated the email. By being global admin I could provide consent directly as the mailbox without having to approve as another Admin user, which may be the key to having it work.

                                      However, once I removed the global admin rights from the account, email retreival failed.

                                      Added Application Admin role to the mailbox owner and it worked again.