@KevinTheJedi Here's the info you requested as I go through the flow of adding the account. Let me know if this isn't what you were looking for and I can gladly upload the correct info. As you can see below, going through those steps takes me back to the OSTicket scp/agent login screen.
Okay yea that doesn't make much sense to me. Is helpdesk@ the email you are trying to configure in osTicket? If so, try clearing your cache/cookies/sessions, setting your Agent Session Timeout in the system to 0 and retest. It seems like it's dropping your authenticated session somehow which is baffling to me if you are running v1.17.2 and the patches I linked above.
Cheers.
KevinTheJedi Yes the helpdesk@ address is the one that we are logging into MS with, the one that will be checking for incoming emails, etc.
I'll give that a shot.
I just tried again after disabling Agent Session Timeout (set to 0) and cleared out all cache for all time in Edge and Chrome.
I logged into the agent panel, setup the mail server info, went to reauthorize. Followed the Microsoft prompts exactly, and it dumps me back out on the agent login screen.
So I decide to log back in once again and repeat the same steps of re-authorization. Just to see if anything changes.
This time, it takes me right back to the correct email window inside the agent panel, but no green banner at the top indicating success. The below screenshot is AFTER I completed the re-authorization process and after it dumps me back in the correct area of the agent panel.
Only Info and IdP Config tabs show up when clicking on the config button. Here's the screenshot.
Okay, then something went wrong. Did you follow the documentation exactly as it is?
Cheers.
Yup, the only thing I didn't follow was when in Azure the instructions state to use http://localhost:8089/osticket.... for the URL redirect. Our firewall is currently blocking 8089 at the moment, but I left it with localhost. I even also used the servers actual NETBIOS name in there http://supportmaster/osticket....
I can definitely blow everything out and start all over, especially if 8089 is a requirement?
I setup a completely new app registration in Azure and did everything all over from scratch, no change.
When I log into osTicket > Email > Email > Oaut2-Microsoft Config > and reentered the Secret ID and App ID, proceed to re-authorize, it brought me back to the agent login page once again. So I logged back in thinking something weird with caching is happening.
Repeat the above steps in osTicket and it brings me back to the Remote Mailbox tab I started off in. No "success" banner at the top and no Token tab in the Config area.
I'm trying to figure out what I'm missing here.
The screenshots in the docs just show examples. Your URLs and such will be different.
Cheers.
Correct. But I wasn't sure with URI redirection if it mattered having localhost vs <servername> or anything besides a TLD of https:// osticket.com / type of URL. This server is an internal company server that has no external WAN facing capabilities since it handles HIPAA related information as part of the help desk.
That’s fine. The redirect happens locally (in the browser) so as long as you can access it locally that’s good. All the URLs do have to match though. As in, the URL you are submitting the popup from, the URL in the email config, and the Redirect URL in the App Registration.
Cheers.
Thanks for the info on the redirect. The URI on osticket, on Azure and what is being accessed in the browser physically from that server are all identical. However I did note that the server osTicket is on has a self signed cert. When using Edge or Chrome to access, they complain about it not being secure and mark out the https, but still state there is a cert there. I take it that wouldn't make any difference?
I'm really scratching my head at this one....
I don't think so.
What you can do is Right Click + Inspect the page, and go to the Network tab before submitting the popup; make sure you select the option to Preserve Logs. Then you can go through the process and when you get redirected to osTicket check the responses from the requests to see if there are any errors being kicked back or something.
Cheers.
Thanks for that info. I've re-ran the authorization process with the Inspect open and preserving the log. Should I be looking in the Headers, Response, Initiator, etc tabs for any particular errors or somewhere specific?
bawalker Response tab
Also when it brings you back to osTicket without the banner try submitting the popup once more to see if you get an error or something.
Cheers.
I am looking at the "name" category and see the moment from where the request url goes from microsoft over to the internal lan server. In fact the request URL is https://supportmaster/osticket/api/auth/oauth2?code=..... There is a status code of 302 (yellow) with no explicit errors.
The next name column item is that it's showing the request URL of https://supportmaster/osTicket/scp/emails.php?id=5 which is when I assume it takes me back to the locally hosted osticket email page where I was at originally. Status code is 200 (green)
From that point it's alot of jqueries, css, and site images logging those. So far I can't find anything explict error wise appearing.
Hmmm, then it should be working. I’m honestly at a loss here. Can you login to the database, go to the email table, copy the ID for the email in question, go to the email_account table, and search for where the email_id is equal to the ID you copied? Once you do that post a screenshot of the records (censor any sensitive info - if any).
Cheers.
@KevinTheJedi I checked the email table and the helpdesk@company.com address is ID 5. When I goto ost_email_account, the email_ID table there indicates ID 5 as well.
See the screenshots below....
