Hi All,

I seem to have one specific user who is no longer able to log into OSTicket.

We switched login system from manually entered credentials authenticated from Active directory by the LDAP plugin to to using IIS authentication pass through using the passthrough plugin, I'm not sure if this is related, possibly not.

This specific user is able to see the main landing page but clicking the Sign In link which would automatically sign in using IIS passthrough authentication just results in an HTTP 500 Server error from login.php.

I've looked at the IIS logs and there's nothing of particular interest - it just confirms that the users browser (Chrome or Edge) is responding to the initial 401 challenge correctly by providing AD credentials on the following request, but the server returns the HTTP 500 error for login.php even with the correct credentials provided.

I have system logs set to Debug in OSTicket, but there are no log entries for this user trying to log in (there are for other users) so it seems login.php is crashing before anything gets logged in the OSTicket log.

So I have no useful log events to go on. What I've also noticed which makes me think it's unrelated to the switch in authentication method is that if I as an Agent/Admin (my login has both roles) try to click on the user in the User Directory page, I also get an HTTP 500 Server error instead of viewing their past tickets. I don't get an error for any other user's profile.

I can however go into my normal ticket view and see their tickets, so the tickets all seem to be intact.

It almost seems like their user profile on OSTicket has become corrupted somehow. So does anyone have any thoughts on how I might fix this ?

This particular user has a lot of open tickets which I can't afford to lose - if I delete the user and choose not to delete their tickets, when they try to log in next and get auto-created, will a "new" user with the same email address and login automatically reconnect to the existing tickets or would they remain orphaned ?

I tried to test this with a dummy account with one ticket open however I found that when I tried to remove that user without removing the tickets I got an error message and was only able to delete the user if I chose to delete their tickets as well, which isn't what I want to do.

Is there anything I can check for in the users database tables that might be causing it to crash ?

I'm running version v1.16.3 (e148727) on IIS 10 on Windows Server 2019 with MariaDB 10.6.7 and PHP 8.0.18.

  • KevinTheJedi replied to this.

  • DBMandrake

    It seems like you have duplicate User records. Maybe duplicate ost_user records, duplicate ost_user_email records, and/or duplicate ost_user_account records. You need to figure out which one and delete the duplicate records.

    Maybe there was an older bug or server issue that caused this to happen. I do know that pre-MySQL 8.0.x the auto_index was stored in memory so if you restarted MySQL it would lose the position and potentially reuse IDs, etc. In MySQL 8.0.x and above they started saving the auto_index to disk which would persist after restarts, etc.

    Cheers.

      DBMandrake

      You need to check your error logs (general server logs, webserver error logs, PHP error logs, MySQL/MariaDB error logs, osTicket System Logs, Browser Console logs, etc.) for any related errors.

      Cheers.

          First thing I would do is check their account.
          In the UI go to Agent panel -> Users. Click on Manage Access and confirm their Username is right (and that its not locked). Next I would open a SQL browser (such as MySQL Workbench, or HeidiSQL, or if hosted Cpanel -> myphpadmin). Take a look at the user_account table ( is your table prefix, the default is ost_). Find their account. See what their backend is set to.

          Alternatively you could run a query like:
          SELECT * FROM ost_user_account WHERE username = 'theirusername';

          backend should NOT be ldap.client if you aren't using LDAP anymore.
          Any backend is no value in the field.

          Idea: If its one User (not an Agent)... you could create a new user, change the ownership of all the tickets to the new user. Delete the old user account. Re-create it, have them log in. Once you confirm it works move the tickets back.

            Hi,

            ntozier First thing I would do is check their account.
            In the UI go to Agent panel -> Users. Click on Manage Access and confirm their Username is right (and that its not locked).

            Unfortunately as I noted in my post I, as an Agent/Admin cannot view that users page in Agent Panel->Users, clicking on that specific user gives me an HTTP 500 Server error... all other users are fine.

            ntozier Next I would open a SQL browser (such as MySQL Workbench, or HeidiSQL, or if hosted Cpanel -> myphpadmin). Take a look at the user_account table ( is your table prefix, the default is ost_). Find their account. See what their backend is set to.

            Alternatively you could run a query like:
            SELECT * FROM ost_user_account WHERE username = 'theirusername';

            backend should NOT be ldap.client if you aren't using LDAP anymore.

            I am still using LDAP. The account details are still pulled from Active Directory via the LDAP Authentication and Lookup plugin as before.

            All the HTTP Passthru Authentication plugin does is allow the users browser to automatically authenticate against active directory instead of having to manually enter the account details. LDAP is also still used to allow auto-completion of users in tickets.

            OSTicket account creation is set to on demand. (Registration required ticked, Registration method public)

            So I don't think that's the issue. Remember all other user accounts are fine and all are configured the same way.

            ntozier Idea: If its one User (not an Agent)... you could create a new user, change the ownership of all the tickets to the new user. Delete the old user account. Re-create it, have them log in. Once you confirm it works move the tickets back.

            This does sound like a workable way to resolve it but I'd still like to try to understand what went wrong though.

                  KevinTheJedi

                  KevinTheJedi You need to check your error logs (general server logs, webserver error logs, PHP error logs, MySQL/MariaDB error logs, osTicket System Logs, Browser Console logs, etc.) for any related errors.

                  Hi,

                  I've already looked at "general server logs" (event viewer on windows....) Webserver logs (IIS log - just confirms that the server is returning an HTTP 500 error but doesn't say why) OSTicket logs, (no log entries at all pertaining to the user) Browser console logs, (Nothing useful, just the HTTP 500 error)

                  An HTTP 500 error would usually be a script execution error, eg a bug in the php script is causing it to crash.

                  The only log that might provide a bit more insight would be a PHP log, I'll have to see if I can find where it is set to log to or indeed if logging is even enabled for PHP.

                      Here's something that may be related in the PHP log:

                      [28-Jul-2022 14:50:29 UTC] PHP Warning:  PHP Startup: Invalid library (appears to be a Zend Extension, try loading using zend_extension=php_opcache.dll from php.ini) in Unknown on line 0
[28-Jul-2022 14:50:29 UTC] PHP Warning:  PHP Startup: Unable to load dynamic library 'php_gd2.dll' (tried: C:\Program Files\PHP\v8.0.18\ext\php_gd2.dll (The specified module could not be found), C:\Program Files\PHP\v8.0.18\ext\php_php_gd2.dll.dll (The specified module could not be found)) in Unknown on line 0
[28-Jul-2022 14:50:29 UTC] PHP Warning:  PHP Startup: Unable to load dynamic library 'php_xmlrpc.dll' (tried: C:\Program Files\PHP\v8.0.18\ext\php_xmlrpc.dll (The specified module could not be found), C:\Program Files\PHP\v8.0.18\ext\php_php_xmlrpc.dll.dll (The specified module could not be found)) in Unknown on line 0
[28-Jul-2022 14:50:30 UTC] PHP Fatal error:  Uncaught ObjectNotUnique: One object was expected; however multiple objects in the database matched the query. In fact, there are 2 matching objects. in E:\inetpub\osticket\include\class.orm.php:1364
Stack trace:
#0 E:\inetpub\osticket\include\class.orm.php(606): QuerySet->one()
#1 E:\inetpub\osticket\include\class.user.php(681): VerySimpleModel::lookup()
#2 E:\inetpub\osticket\include\class.ticket.php(3990): User::lookupByEmail()
#3 E:\inetpub\osticket\include\class.ticket.php(4179): Ticket::filterTicketData()
#4 E:\inetpub\osticket\include\class.mailfetch.php(905): Ticket::create()
#5 E:\inetpub\osticket\include\class.mailfetch.php(955): MailFetcher->createTicket()
#6 E:\inetpub\osticket\include\class.mailfetch.php(1035): MailFetcher->fetchEmails()
#7 E:\inetpub\osticket\include\class.cron.php(25): MailFetcher::run()
#8 E:\inetpub\osticket\include\class.cron.php(111): Cron::MailFetcher()
#9 E:\inetpub\osticket\include\api.cron.php(19): Cron::run()
#10 E:\inetpub\osticket\include\api.cron.php(40): CronApiController->run()
#11 E:\inetpub\osticket\api\cron.php(23): LocalCronApiController::call()
#12 {main}
  thrown in E:\inetpub\osticket\include\class.orm.php on line 1364
[28-Jul-2022 14:51:29 UTC] PHP Warning:  PHP Startup: Invalid library (appears to be a Zend Extension, try loading using zend_extension=php_opcache.dll from php.ini) in Unknown on line 0
[28-Jul-2022 14:51:29 UTC] PHP Warning:  PHP Startup: Unable to load dynamic library 'php_gd2.dll' (tried: C:\Program Files\PHP\v8.0.18\ext\php_gd2.dll (The specified module could not be found), C:\Program Files\PHP\v8.0.18\ext\php_php_gd2.dll.dll (The specified module could not be found)) in Unknown on line 0
[28-Jul-2022 14:51:29 UTC] PHP Warning:  PHP Startup: Unable to load dynamic library 'php_xmlrpc.dll' (tried: C:\Program Files\PHP\v8.0.18\ext\php_xmlrpc.dll (The specified module could not be found), C:\Program Files\PHP\v8.0.18\ext\php_php_xmlrpc.dll.dll (The specified module could not be found)) in Unknown on line 0

                      Ignore the stuff about unable to load dynamic module etc - that seems to be occurring for all queries so I need to look into that, (not sure why I'm getting those errors when the modules are installed and OSTicket config verifies they are working....) however the "Uncaught ObjectNotUnique" exception seems like it could be related.

                        DBMandrake

                        It seems like you have duplicate User records. Maybe duplicate ost_user records, duplicate ost_user_email records, and/or duplicate ost_user_account records. You need to figure out which one and delete the duplicate records.

                        Maybe there was an older bug or server issue that caused this to happen. I do know that pre-MySQL 8.0.x the auto_index was stored in memory so if you restarted MySQL it would lose the position and potentially reuse IDs, etc. In MySQL 8.0.x and above they started saving the auto_index to disk which would persist after restarts, etc.

                        Cheers.

                            KevinTheJedi

                            KevinTheJedi It seems like you have duplicate User records. Maybe duplicate ost_user records, duplicate ost_user_email records, and/or duplicate ost_user_account records. You need to figure out which one and delete the duplicate records.

                            Maybe there was an older bug or server issue that caused this to happen. I do know that pre-MySQL 8.0.x the auto_index was stored in memory so if you restarted MySQL it would lose the position and potentially reuse IDs, etc. In MySQL 8.0.x and above they started saving the auto_index to disk which would persist after restarts, etc.

                            It does look like there are duplicates in the osticket_user_account table:

                            The user in question is circled - same user_id for both but different id. The older one is a full email address which was presumably created when I was using ldap only, while the username only one was created since I switched to http passthrough. (Since the browser provides that as domain\user)

                            What I don't understand is why nobody else was affected, or why the extra field was NULL as well. There is a mix of people who registered prior to turning on http passthrough authentication and those who registered after that who are not having issues.

                            I've deleted the second row (id 29) from the database and I can now access the user through the Agent->Users page so I assume this will fix the problem for the user as well, although I won't know until they're back at work.

                            Their tickets seem to be intact and still correctly linked to the user account.

                            I'll keep an eye on this to see if it happens again. I did switch back and forth quite a bit from ldap only to ldap+http passthrough recently as I had a number of issues getting passthrough working to my satisfaction, but it will stay on now. As you can see not many users are registered - most are creating and interacting with tickets via email and aren't actually using the portal interface as I haven't published its address yet.

                            Thanks for pointing me in the right direction.

                                A quick follow up - deleting ID 29 did not work because next time the user tried to log in (using http passthrough authentication) a duplicate was created again.

                                So this time I deleted the ldap.client entry ID 24 and they are now successfully logging in.

                                What I don't understand is why other users who still have ldap.client entries are able to log in and why they don't also don't get duplicates created....

                                a month later

                                Another follow up for this issue!

                                It turns out if you switch from LDAP authentication to HTTP passthrough without deleting the rows in this table containing ldap.client, not only can those users not log into the web interface, it will trigger a crash when OSTicket tries to import their email tickets, resulting in their email tickets not being imported!

                                So if you switch authentication type from LDAP to HTTP passthrough on an existing system you MUST delete all rows from ost_user_account containing ldap.client in the backend field of you will have problems...

                                Write a Reply...