Good Morning,

We have a working installation of Osticket on a Centos Machine, and we are trying to move it to a RHEL server. Nevertheless, LDAP authentication seems not working and only accounts with local authentication are managing to get in.

The LDAP plugin is active, and the configuration of the plugin is a perfect clone of the one that is working on the Centos machine.

port 10389 is opened on firewall for both TCP and UDP

Ldap is enabled on php

The name of the LDAP server is resolved and the server itself is pingable

The account that I am using to login is the same account with valid credentials that is working on the old Centos machine.

The information about my system provided by OSTicket is the following:

    Here are the settings, I garbled server names because of our security policies, but all the scrambled settings are exactly the same settings that we have on another machine within the same subnet where Osticket is working as it should.

      cgubi
      I am not sure if you have settings as follows:
      Default Domain: should be FQDN
      DNS Server: you should try putting the IP address of DC
      LDAP servers: should be FQDN, I am not sure if you need that port number after if it's the default, you can leave blank
      Search User:domain\user
      Also, LDAP Schema: select it manually instead of Automatically Detect.

      Did you setup fresh or migrate the old database over?
      I would say first try re-entering the password and save changes.

      Thanks for the suggestion @ntozier. This is the error that I get. I am trying to specify a different port for LDAP connections but Osticket is taking the port as part of the server addres, trying to connect on port 389 to the server with the name <servername>:10389

      Nevertheless, this notation is working fine on the current installation.

      Did you setup your ldap server to listen on a custom port (10389)?
      Also as a side note you appear to have two :: in your server IP address., try removing one.

      something like: 192.168.1.1:10389

      8 days later

      There was only one colon, the blur that I used confused somehow the image but there is only one semicolon. I am still missing what is blocking LDAP on the new server, I checked the firewalls and the relevant ports are open.

      Hmmm.
      Does RHEL run SELinux by default? or mod_apache?

      Is this the same port that you used on the old server setting wise?
      My other thought is maybe the Authentication::LDAP and AD plugin was hard coding the port number some how.
      If not, then maybe open the phar, and see \include\plugins\auth-ldap\include\Net\LDAP2.php line 89.

      Change
      'port' => 389,
      to
      'port' => 10389,
      and then remove the :#### from your LDAP Servers field and see if that helps.

        6 days later

        Hi ntozier thanks for your feedback.

        Selinux is "PERMISSIVE", should I disable it?

        I have the plugins packed in phar format, I converted the ldap-phar plugin to zip with the https://phar.scer.io/ conversion tool, then I edited the file, I zipped the folder and converted it back to phar format with the same tool, but after the upload I get this error message: the plugin is "defunct"...

        I would shut it [SELinux] off and see if it fixes the problem.
        If it does then i would look into writing a rule to make things work.

        If the system thinks that the phar isn't there then either the path/folder/phar name is wrong, or the entry in the db is wrong. Take a look at the ost_plugin table. See install_path

          5 days later

          Thanks ntozier i shut down selinux and nothing changed.

          As I said before, I have plugins zipped as phar archives. How would you unpack/edit/repack from command line the phar file for the LDAP plugin?

          Alternatively, as this looks like a bug candidate for the LDAP plugin, who should I contact to submit my case to check if there is something to fix to make the plugin work with non-standard ports?

          Are running suhosin (in your PHP)?

          To unpack the phar see
          https://www.php.net/manual/en/book.phar.php
          see ExtractTo.
          If you dont want to learn that you can google unphar and there are sites online that will do it for you.

          If this was a bug then it would be reported by a lot more people than just you. The only time that I have ever seen this happen is someone mucked with the phar and broke it, or it is not there. But if you want to report bugs to a specific plugin then you would open an issue report at the plugin repo.

          https://github.com/osTicket/osTicket-plugins/issues/new

            Thanks ntozier,

            i did not install suhosin and there is no mention of suhosin in the output of phpinfo.

            I unphared the ldap plugin with https://pmt.nathfreder.dev/ changed the line you mentioned, and then phared back again with the same tool.

            I uploaded the new phar file to the server, gave to the plugin the same ownership and permissions of the other plugins (apache:apache and 7) and restarted httpd service.

            Even so, the plugin looks "defunct-missing".

            Then i found the plugin into the installable one, and installed it.

            I configured the plugin without the port (that was now hardcoded) and I am still getting a bind error.

            remove the installed plugin (from the db if you have to)
            Try installing using the unphared version that you made.

            12 days later

            thanks KevinTheJedi there is an updated .phar package available or should i download the changed files, unpack the plugin, replace the changed files, repack the plugin and check it out?

            Hi KevinTheJedi hi installed the updated version of the plugin and looks like now the plugin is sending the right command, the port is no longer considered part of the server name, but for some reasons the LDAP authentication can't get through:

            This is a summary of the situation:

            SELINUX Disabled:

            # getenforce
            Disabled

            Ldap-related packages installed:

            openldap.x86_64 2.4.44-21.el7_6 @updates
            php-ldap.x86_64 5.6.40-14.el7.remi @remi-php56
            sssd-ldap.x86_64 1.16.4-21.el7_7.1 @updates

            I see now that php-ldap package is coming from the repository for php 5.6, and there is this other package available:

            php71-php-ldap.x86_64 7.1.33-1.el7.remi remi-safe

            These are my questions now, thanks in advance for any feedback:

            Should I install this package for php 7.1 and remove the old one after?
            Should I remove the old ldap package and then install the new one?
            Can I install the php71 package and leave the old one installed?
            How could I test the Ldap connection from command line?
            Which logs should I check for the errors of LDAP connections?

            UPDATE: I installed the package for php71 and the error persists. This is what I got from the installation:

            Installing:
            php71-php-ldap x86_64 7.1.33-6.el7.remi remi-safe 70 k
            Installing for dependencies:
            php71-php-common x86_64 7.1.33-6.el7.remi remi-safe 607 k
            php71-php-json x86_64 7.1.33-6.el7.remi remi-safe 65 k
            php71-runtime x86_64 2.0-1.el7.remi remi-safe 1.1 M

            @cgubi

            Should I install this package for php 7.1 and remove the old one after?
            Should I remove the old ldap package and then install the new one?
            Can I install the php71 package and leave the old one installed?

            I believe you can install without uninstalling the one for php 5.6. Just depends on the distro, etc.

            How could I test the Ldap connection from command line?

            There are many guides online that explain how to do this. The main command line utility I see being used is ldapsearch.

            Which logs should I check for the errors of LDAP connections?

            You should check the LDAP connection logs and/or server logs. You should also look into enabling LDAP Debugging Logs.

            Cheers.