@rgonig2

We tried to debug this by checking osTicket code. osTickets shows (defunct — missing) message when phar class is missing or phar files does not have executable permission.

We could replicate this error message in manual installation ( i.e Without Softaculous ) when we kept non executable permission to auth-ldap.phar.

There are few things which needs to be checked :
1. Is Phar installed correctly ? You can check phar configuration in phpinfo.
2. Is auth-ldap.phar present and has executable permission ?

    softaculous @ntozier so, still working though this issue with my institution cPanel admins and support. We've got the plugin working (not defunct missing, can access settings for the plugin) in our dev environment, but we're still trying to figure out how the hell we actually got there since it just turned up that way when I came back to work after the weekend.

    My hunch (considering the installations at this point are identical between our dev and prod environments) is that it's a service running on the server causing this issue.

    However, in attempting to debug, we found another issue which may warrant it's own request in Git. When the plugin is installed correctly, but configuration (bind details, account credentials, etc...) and a user who is set to be authenticated through the plugin attempts to login, raw user credentials are present in the stack trace error generated (only occurs PHP 7.1 and up, as lower PHP versions do not include stack trace in error logs):

      @rgonig2

      Maybe I'm missing something...what is the issue with the un-hashed passwords? That they appear in the logs? That's a PHP thing, it logs the function called and everything passed to it.

      Here is an excerpt from a dev on PHP's issue tracker:

      you shouldn't enable display_errors in production so this shouldn't have any security impact on your site (and secondly, an attacker shouldn't be able to use those credentials to connect to your database from remotely, but that is not in the scope of this question), but hiding the password by default would be a PITA (Pain In The Ass) for those people who are using the error reporting to track down problems like a configuration error, where the connaction fails, because for some reason a wrong password is used.

      So in theory this is good as the errors aren't displayed to users, no one should be able to access your server logs, and sometimes the credentials are necessary when debugging.

      Cheers.

        KevinTheJedi I may be misunderstanding my institutions issue with it. I'll ask and see what I can figure out.

          @awstech did you ever have any further luck with this? Making some progress at my institution but it's coming slowly.

          KevinTheJedi That quote is from a bug report for PDO which reveals the database connection information in the stack trace, which then gets logged. In that context, there's no harm having the password in the log (as long as the log is only available to the site owner and display_errors is off), since the site owner already knows the correct password for the database connection. In the auth-ldap context, the passwords of all users are being revealed to the website owner. That would be bad even if the accounts were local to osTicket, but when the accounts in question are ldap accounts that are used for access to many other services, it is not safe to allow those passwords to be revealed to the owner of the website. Stack traces are only printed to the log for unhandled exceptions. Resolving the problem should be a simple matter of implementing exception handling.

              Fixed!!!!

              Workaround was to unphar auth-ldap.phar, point the database to the folder, and set isphar=0. Honestly, still not entirely sure what the issue is in the first place...Dunno if the workound hints at that.

              Sounds like phar is disabled on the machine in php.

              @rgonig2

              That quote is from a bug report for PDO which reveals the database connection information in the stack trace, which then gets logged. In that context, there's no harm having the password in the log (as long as the log is only available to the site owner and display_errors is off), since the site owner already knows the correct password for the database connection. In the auth-ldap context, the passwords of all users are being revealed to the website owner. That would be bad even if the accounts were local to osTicket, but when the accounts in question are ldap accounts that are used for access to many other services, it is not safe to allow those passwords to be revealed to the owner of the website. Stack traces are only printed to the log for unhandled exceptions. Resolving the problem should be a simple matter of implementing exception handling.

              Thank you for the suggestion. I will add this to the list of requested features for future versions.

              Cheers.

              On the link that you provided...
              Look at Configure Command section.
              about 60% of the way down you will spot '--disable-phar'

              (Yes I know it says later in the Phar section that it is enabled... but passing that at commandline should disable it)

                ntozier Ah, okay. I did notice that but saw that the plugin enabled later and assumed that meant it ended in an enabled state

                  3 years later

                  The same problem happened to me, changed the ownership after copying from root to www-data, I am able to configure.
                  sudo chown www-data:www-data auth-ldap.phar
                  sudo chmod 777 auth-ldap.phar

                  2 years later

                  Same here I just changed Chown for storage-fs.pfar is the plugin started to work. ¸

                  I use MC (Midnight Commander)

                  Write a Reply...