osTicket O365 E-mail Retrieval & Sending Stopped Working: Page 3

osTicket O365 E-mail Retrieval & Sending Stopped Working

rblake

KevinTheJedi The Quest KACE isn't osTicket, it's an entirely different solution. I'm just saying that this works so I don't see how it can be our environment.

These are the configured permissions for OAUTH2 for KACE:

I added openid to the list of permissions for osTicket, but no joy.

KevinTheJedi

rblake

In my experience, when you add new permissions you have to create a new secret.

Cheers.

rblake

KevinTheJedi Just created a new secret and getting the same error message: cannot select INBOX, is this a valid transport?

Edit: I forgot to mention that I changed the SMTP settings to Basic Authentication (Legacy) and used the username/password and it worked. However, it's still not able to retrieve mail (see above error).

KevinTheJedi

rblake

You really need to get OAuth2 working instead of relying on basic but good it’s working for now.

As for fetching can you try port 995 and POP protocol?

Also, do you have a self signed certificate or something on this server?

Cheers.

rblake

KevinTheJedi I get this when I try POP:

EDIT: I changed to Legacy Auth on IMAP and it pulled down e-mails.

ramrajone

rblake
I had similar issues, the test server was working but the production server would not, so I had done this test and it helped me fix my issue.
If you like to test this, create a new folder within the same server where your current osTicket is installed, for example:
let's say your current install is on: /www/osTicket Then create a folder in it called Test /www/osTicket/Test
Then download a fresh copy of the new osTicket from osticket.com/download version 1.17.2 Go through a setup like it's a new install with a new database and for this Test to keep it live server and Test separate

You can create new app registration for this Test to keep it live server and Test separate

If this works then something else is not right

KevinTheJedi

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.

rblake

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

@KevinTheJedi Did I understand correctly that we don't need to use the e-mail account being used to authorize the OAUTH connection? In other words I could use my account? Or do we still need to use the e-mail account? I know it says in the documentation that you do but I thought I read on the forums that has been fixed with the latest release? I'm running 0.6.

rblake

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

rblake

Not that I know of no. Any Global Admin should be able to consent.

Cheers.

rblake

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.

KevinTheJedi

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.

ramrajone

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

zs_bln

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.

rblake

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.

KevinTheJedi

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.

rblake

KevinTheJedi I tested this already and it does work so that's 100% the bug. Thanks!

rblake

@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.

KevinTheJedi

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.

KevinTheJedi

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.

rblake

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.

« Previous Page Next Page »