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.
rblake
I had written this post, and was able to get it working using the Application admin, instead of Global admin
https://howtohelpdesk.com/how-to-setup-oauth-on-osticket-using-microsoft-365/#allow-user-Consent
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.
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 I tested this already and it does work so that's 100% the bug. Thanks!
@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.
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.
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.
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.
OK. I re-did the config for the OAuth2 with the mailbox as an application administrator, then removed the role from the user. Mail has fetched properly for the last 2 days, even without the role assigned,
I finally figured it out. So, if you cannot login as the email/shared mailbox itself or do not allow user consent and are required to use Global Admin then:
Once you do this you can go back to osTicket, click Submit in the OAuth2 popup, authorize as the Global Admin, and voila the token will work for the email you are attempting to configure. I was researching endless guides online and they all showed that you have to login as the email itself to authorize. Furthermore they all seem to be under the same consensus that OAuth2 will not work for shared mailboxes but I have found that this is in-fact false. If your Global Admin has Delegate access to the email/shared mailbox it can get a token and act as the email/shared mailbox with no issues. I tested this on my dev O365 with both regular user and shared mailbox and in both instances the above instructions worked without a hitch.
I think the other applications you are using are using a different auth-flow and potentially using the API to fetch/send mail whereas we have to stick to using IMAP/POP3 and SMTP protocols to fetch/send mail. We might add API support in v2.0 but that's a whole separate conversation we have to have internally.
Cheers.
Hello,
osTIcket informations :
version d'osTicket v1.17.2 (8fbc7ee)
Logiciel serveur Web Apache
Version de MySQL 5.7.30
Version PHP 8.0.25
It hosted into a public host, I update from 1.15 last week to this version.
We have Microsoft 365 Business Basic licence
I have the same issue as you, but I don't find solution :
Five days ago, I create the App and follow the guide and it worked, it fetches the emails but it doesn't move into the folder archived (I see it later). And 3 days later, osTicket doesn't fetch the emails, so I remove the plugin & reinstall, and from this moment I have the error "cannot select INBOX, is this a valid transport?".
==> The token seems valid.
We used the auto-fetch, I try with rcron ==> same issue (it works with basic authentification)
I try pop 995, imap 993 ==> same issue
I try to set up a new email with the global admin ==> same issue
I try to delete emails, delete plugins... ==> same issue
I add a new application form azure with openid ==> same issue
Ok, thanks for the info. You seem have exactly the same issue , I have contacted Microsoft and I wait a response...
