Hello there,

I will present my scenario and solution to the issue in case someone has the same situation as me:

Updated from 1.15 to 1.17-rc3. Neither users nor staff were able to login. Accessing from local admin account I was able to reenable ldap plugin and instance but still, the same issue appeared. I managed to solve it copying the "backend" value from the tables ost_staff and ost_user_account from a backup previous to the update. Value in staff was empty "" and users where "ldap.client". Once done logins were restored.

Note that new users (clients) will be created automatically with backend value "ldap.client.p5i3" which is the "official solution". Applying this value to already existing users didn't work for me.

Hope it helps.

    eratia It sopped working after installing theme osticketawesome. Had to "empty" staff's backend value again and update users's to "ldap.client.p5i3". Now it works again.

      I can confirm LDAP lookup wasn't working after upgrading to osTicket v1.17 from v1.10. So, I downgraded from PHP 8.2 to PHP 8.1 to PHP 8.0 and LDAP lookup finally worked again. I had looked with tcpdump and disabled TLS for LDAP. I could see that the searches actually yielded correct results but they didn't show up in osTicket. There weren't any error messages from osTicket, php or Apache.

      FYI All, Login through email address has been resolved for us now. We deleted the plugin (not file just deleted from osticket GUI) and reinstalled/reconfigured it. After that we had to update the backend value of staff and users on database per already guided above.

      5 days later

      Like many others, I have AD as an LDAP backend for Agents.

      Upgrade from 1.15.6 to 1.16.3 was smooth. Uploaded the files and the appropriate plugin versions. Logged in as an admin user and the upgrader ran. All Good.

      Upgrade from 1.16.3 to 1.17 did not go so well. Uploaded the files and plugins as appropriate. Tried to login with my admin user and got Access Denied. No agent could login. Therefore the upgrader could not run. The DB was still at v1.16.3 (which turns out to be useful)

      I read through this thread and went looking through the database for agents with the LDAP backend and none showed anything in the backend field of their user record in the database.

      My solution was to:
      Downgrade the /usr/share/osticket back to v1.16.3 and login with my admin account.
      Create an extra admin account with Authentication Backend set to Local Authentication.
      Upgrade /usr/share/osticket to v1.17 again
      Login with the local admin account - this time the login succeeded and the upgrader ran.
      Go to Agents, and select each agent in turn, set their Authentication Backend to Local Authentication and SAVE. Then set it to Active Directory or LDAP and SAVE.
      Logout the local admin account, and login with my normal LDAP admin account.
      All good!

      Looking at the database after performing these steps I can now see that there is a value ldap.p2i4 in the backend field of the database record for each agent.

      Edit:
      Just one further update on this which might also help others.

      Having gotten the LDAP authentication working, agents could still only sign in with their username. Sign in by email address was not working.

      I found the root cause of this problem was not having specified the "Search User" and "Password" in the LDAP Connection configuration. It seems that anonymous binding is enough to find users in AD by username but, it cannot find them by their email address. Using a search user with appropriate access allowed agents to login by email address as well as username.

      8 days later

      Update:

      We found the cause of the issue where the backends aren’t updated for users and agents when upgrading. If you run into this issue it means you didn’t upload the latest LDAP plugin before you upgraded.

      Simple solution, make sure you update all of your plugins before upgrading osTicket.

      Cheers.

      3 months later

      Hi there,
      We are completely new to OSTicket, and I'm trying to do all the configs. When I create the instance for LDAP, it shows 'loading' when I save changes after entering our FQDN, and then crashes.

      All other fields are left blank at the moment, only the FQDN is being entered.

      osTicket Version v1.17.2 (8fbc7ee) — Up to date
      Web Server Software Microsoft-IIS/8.5
      MySQL Version 5.1.73
      PHP Version 8.1.12

      The PHP extension for ldap has also been installed & enabled:

      I feel like I might be missing something potentially obvious, but I don't know what that is.

        UrsulaleRoux

        You'll just have to look at your logs to see why. Could be a fatal error, could be your host rejecting the connection, firewall, DNS issues, etc. Without logs or an error it'd be impossible to tell you what's going on.

        Cheers.

          I am having the same issue, with a brand new/fresh install of OSTicket and the plugin. No errors occur (like 404), it just doesn't auto-complete, like my old install (1.12) does.

          I'm looking in the System Logs in the Admin interface, and see no errors at all for it. In fact, no errors period, because it's not in production yet. I can log into SCP just fine, test users can log in just fine on the end-user page. It's just when I go to create a new ticket, and attempt to add user for ticket creation.

            KevinTheJedi

            Hey KevinTheJedi, thank you. Is there a manual way to do it though? I'm not really hip to GIT just yet, though I suppose it'd be good to learn.

                eddiebgood

                Yes, open the files in a text editor or more preferably a code editor and make the changes manually. For the plugin changes you’ll have to unpack the plugin, make the changes manually, and repackage the plugin. There are other posts and guides online that explain how to do this in PHP. There are even websites that can unpack and repackage it for you.

                Cheers.

                  eddiebgood

                  You can also unpack the plugin, make the changes, and leave it unpacked but it requires you to make changes in the database. If you are SQL savvy once the plugin is unpacked you can go to the database, go to the plugin table, remove the .phar from the install_path value for the LDAP plugin, set the isphar value to 0, and the plugin will work as a folder instead of a PHAR file.

                  Cheers.

                    4 months later

                    I've running into this issue and finally stumbled across this thread.

                    @KevinTheJedi I found the recommendations and followed the steps to find the plugin and instance IDs, and ran the UPDATE syntax to set the backend for the users. This fixed almost all of my users, except for 6 users. Even after running this, the backend for the remaining non-working users was set to NULL. Re-running the UPDATE still would not change the backend for those users. I had to modify the UPDATE and specifically call out their usernames to have it update the fields, but it is still not allowing them to login. I did the same for the extras as it was set to NULL as well, setting it to {"browser_lang":"en_US"} like what all of the other users have, which did not help.

                    FYI, the non-working users are getting the HTTP 500 error.

                    Any idea what else I can try?

                      mrudella

                      Check your logs for any related errors as 500 indicates deeper issues. They can also clear their cache/cookies/sessions and retry the login.

                      Cheers.

                        That was one of the first things that I tried during troubleshooting, but it turns out, it was an issue within the database.

                        I took a closer look through the ost_user_account table and found 2 entries for each of the 6 affected users, 1 entry showing the username as their expected (just username) and the other username as their email address. For each of these, the user_id number was the same for both usernames, which I found was odd. After closer examination, I found a few non-affected users who also had 2 entries (as previously described), but the user_id was different.

                        In the Staff/Agent Panel, I took a look at the User Directory and noticed that for all users with the duplicate user_id, if I clicked on their names, I would get the HTTP 500 error. In addition, if I would just hover on their name, the preview window was blank; it would not show the user or notes information.

                        As a test, I deleted the id (not user_id) with the oldest timestamp for the non-working users. Once I did this, everything was fixed and the users were able to log in to create tickets. The majority of these users are also Agents, but they did not have any issues logging into that Staff panel.

                        5 months later

                        I have the same problem but none of the solutions works
                        my user in DB is configured as this

                        select * from ost_user_account;
                        +----+---------+--------+---------------+------+----------+--------+------------------+-----------------------+---------------------+
                        | id | user_id | status | timezone | lang | username | passwd | backend | extra | registered |
                        +----+---------+--------+---------------+------+----------+--------+------------------+-----------------------+---------------------+
                        | 5 | 6 | 9 | Europe/Berlin | NULL | NULL | NULL | ldap.client.p4i3 | {"browser_lang":"it"} | 2023-10-29 00:30:41 |
                        +----+---------+--------+---------------+------+----------+--------+------------------+-----------------------+---------------------+

                        the same user was able to login as Agent but not as client

                          alepensato

                          Are you sure that’s the correct backend? Login as a User that isn’t in osTicket yet via LDAP and then copy their backend value and update all ldap users in db to have that working backend.

                          Cheers.