Login behind SSL/TLS not working?

Chain-Devil

Hey all -

We're in the process of FINALLY migrating away from an old server of ours running osTicket 1.10, and I figured we'd march all the way right up to 1.18.2. Might as well get on the latest!

In any case, after much gnashing of teeth, I figured out where I was going wrong, managed to get the database exported and the files correctly overlaid atop our initial install. We also wanted to go ahead and get SSL/TLS running on this instance of osTicket, since "pRoPeR sEcUrItY" is what all you youths and rapscallions are getting into these days. I set up our instance under an apache config file (sanitized), which is set to have our osTicket instance respond to a subdomain (helpdesk.example.com), and automagically redirect to HTTPS.

Trouble is, NOW, when I attempt to log on... it fails. Most of our accounts are LDAP accounts, authenticating against our FreeIPA server - but ONE of our accounts is a local one, for EXACTLY this sort of issue. When we attempt to login to our LDAP accounts, we get "Access denied" (and I've tried both with AND without the auth_ldap.phar file in the include/plugins directory). Even when we attempt to login with our one LOCAL account, I get "Valid CSRF Token Required", which I'd never gotten before with this exact same configuration on previous trial migration runs.

I've even turned off SSL/TLS entirely, and tried to login. It doesn't seem to work.

KevinTheJedi

Chain-Devil

For the Agents with LDAP accounts login to the database, go to the _staff table, and check the backend column values. If they are just ldap then you didn't upgrade with the new LDAP plugin in place beforehand. No worries though as you can fix it manually. To do so you must update all values of ldap to ldap.pXiX where the first X is the LDAP plugin's id from the _plugin table and the second X is the LDAP plugin instance's id from the _plugin_instance table. You should also check the User's to ensure they are good. So check the same column but in the _user_account table and if they are just ldap.client then you can update them to the format of ldap.client.pXiX.

For the local account try clearing the cache/cookies/sessions and reattempting the login. If that doesn’t work and you can get in with an admin account using AD from the above steps then you can manually reset the password and retest to confirm it's not just an incorrect password, etc. If you can't get in with an admin account using AD then you can reset the password by going to a site online and making a bcrypt hashed password (with 8 round entropy), going to the _staff table in the database, and updating the password column with said hash.

Cheers.