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.

            alepensato

            Try deleting a _user_account record associated with a user you can test with and try logging in after that.

            Cheers.

              I deleted it, and now i have only a record in ost_user, but i was unable to login

              MariaDB [osticketarea]> select * from ost_user;
              +----+--------+------------------+--------+--------------------+---------------------+---------------------+
              | id | org_id | default_email_id | status | name | created | updated |
              +----+--------+------------------+--------+--------------------+---------------------+---------------------+
              | 7 | 0 | 7 | 0 | ALESSANDRO PENSATO | 2023-10-29 10:31:42 | 2023-10-29 10:31:42 |
              +----+--------+------------------+--------+--------------------+---------------------+---------------------+

              What does mean status values??? where is a reference to match value with description?

                alepensato

                The only possible value for _user.status would be this:

                As far as where to find the description, you just have to look at the codebase and figure it out.

                As far as the user not being able to login, have you cleared your cookies/cache for the site? Have you tried Incognito/Private/InPrivate window? Have you ensured your LDAP Plugin has Client Authentication enabled?

                Cheers.

                    KevinTheJedi
                    I tried with different browser, computer, reinstalled osticket on brand new vmachine etc etc, ldap auth is enabled for staff ad for client, but it not works

                        alepensato

                        Any specific errors? Do you see the auth attempt in the AD logs? Do you have User Registration enabled in your osTicket settings (Admin Panel > Settings > Users > Registration Method)?

                        Cheers.

                          I do not have access to the LDAP log, but i see that the same user with same logn data can login as Aggent but not as client.

                          Client registration mode does not change the matter, in any case, I have to manually add add user because the registration is not automatic.

                            alepensato

                            It should be once they login and they don’t exist or don’t have an account yet. Seems to me like you either don’t have LDAP config configured properly for Users or something is going on with your LDAP config. Are you certain you are using the latest LDAP Plugin build and v1.18.1?

                            Cheers.

                              Yes osticket is updated, as i wrote i also reinstalled osticked many time and used 1.17 and 1.18



                                alepensato

                                Did you install in Italian or just add the language pack afterwards? Can you test on an install that wasn’t installed with Italian language (just default English)?

                                Cheers.

                                    KevinTheJedi
                                    I used the packages downloaded from the site with the italian language pack and the ldap plugin.
                                    probably i tried this way but i do not remember

                                      KevinTheJedi
                                      I reinstalled alla on a fresk vmachine, without the italian plugin. after basic osticket setup I enabled the ldap plugind and if i try to login as client, it not work and i get Access denied message and this php message
                                      PHP Fatal error: Uncaught TypeError: ldap_free_result(): Argument #1 ($result) must be of type LDAP\\Result, bool given in phar:///var/www/html/include/plugins/auth-ldap.phar/include/Net/LDAP2/Search.php:501\nStack trace:\n#0 phar:///var/www/html/include/plugins/auth-ldap.phar/include/Net/LDAP2/Search.php(501): ldap_free_result()\n#1 /var/www/html/include/pear/PEAR.php(755): Net_LDAP2_Search->_Net_LDAP2_Search()\n#2 [internal function]: _PEAR_call_destructors()\n#3 {main}\n thrown in phar:///var/www/html/include/plugins/auth-ldap.phar/include/Net/LDAP2/Search.php on line 501, referer: http://