Azure AD OAuth2 - Mail User Working | User/Agent Not Signing In

ForCom5

Howdy all,

Alright, after hours of scouring the forum, I figured now was a good time to drop the question. First, this is a clean new install running v1.17 (1d8b790) - with URL Rewriting enabled and configured correctly.

First thing, the Mail Fetch user we have is working just fine with AAD. Can fetch/send emails with the same App registration in AAD without issue; was able to do the organizational consent, can renew its own token, it just works. Fancy.

For the authentication side, things get a little more interesting. From the same working instance (properly censored image below):

I checked Graph and AAD as well, the user attributes are correct as well. When a user or agent attempts to log in with OAuth2, the login as far as the App registration is concerned is successful, but then the session is dumped into the main domain helpdesk page with the user not signed in - this applies to the user login and the agent login window - either way the user is dumped back to the main page not signed in.

API permissions just in case I missed anything (all with admin consent granted):

Cheers in advance.

KevinTheJedi

ForCom5

Have them clear all cache, cookies, and sessions and retest. Or use an entirely new browser and test. You can also play around with the authentication backends for the agents under admin panel > agents > agents > click an agents name.

Cheers.

ForCom5

KevinTheJedi
Thanks for the prompt reply - and apologies for my lack of. Posting this end-of (my)-day was a bit of an oversight.

So, we attempted authentication with an agent on an isolated browser instance and confirmed the user could sign in with Local Auth without issue, but the moment they use the AAD OAuth login, it bombs out. That is to say, the app registration shows a successful login, and OSTicket just dumps the session to the main user sign in page - and if I just try to jump to a page an agent would have access to - /scp/index.php for instance - then I'm promptly redirected to sign in at the agent sign in.

Anomalous, no? And of course all the while, the mail fetch user is just chugging along.

KevinTheJedi

ForCom5

I would not try local creds first. Just new incognito/private window and solely test SSO. You can check the User's backend in the database to see what that is set to.

Cheers.

ForCom5

KevinTheJedi

Yep, so we made another user and an agent too, confirmed they're set go go through SSO, but still no dice in an incognito instance. AAD logs in, and then we're back on the main user page. System logs unfortunately don't yield much. Since last update though, we've had to re-enable LDAP to finish the upgrade - because changing the wheels on the car while its moving is fun.

LDAP for users and agents works. It'll authenticate both and create new users once logged in too. Of course, that bears little relation to the OAuth issue, but at least the non-local credential sign-ins work along with user creation. Still super stumped about why it's failing for everyone but the Mail Fetch user.

ForCom5

Alrighty!

It took a year and a day, but I figured out... a (the?) solution. Our single Azure App Registrations for whatever reason, seems to have an issue authenticating the OSTicket mail fetch user and the rest of the userbase - for whatever reason. I found this out by simply creating a second Enterprise Application, giving it all the same configurations as the original, and configuring the plugin for the user/agent auth to look to the new app registration - and it worked.

TL;DR: created a second app registration for user/agent auth.