LDAP Plugin on osTicket v1.18 with Debian 12 and PHP 8.2.7

[alepensato]

@JediKev
as you suggested I openend a new thread for my issue.
I reinstalled osTicket downloaded form the main site with the LDAP and HTTP Passthru Authentication plugins.
Just in the LDAP new instance therre are a problem with the server row.
It is onny allowed to save it if is in the format ldaps://myserver, if i try to wite it as myserver:636 there are problems

With the format ldaps://myserver I was able to save the configuration, and I was able to search users from my remote directory.

If I try to use my remote user to login into the system, it does not work, and I found this message in the Apache error.log

[Sat Aug 05 11:44:30.344523 2023] [php:error] [pid 1329] [client 194.119.211.197:21359] 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://servicesarea.irib.cnr.it/login.php

[jakkul]

experiencing the same issue on ubuntu 22.04 and php 8.1. Official phar from the downloads page.

[JediKev]

@jakkul

This issue is likely a result of the version of Net_LDAP2 package we use (v2.2.1) not fully supporting PHP 8.2. Their latest official release is v2.2.1 however they do have an unofficial release labeled v2.3.0 that adds PHP 8.2 support.

If you want to remedy this until the next build of the LDAP plugin is released you can either downgrade to PHP 8.1 -or- you can:

• Unpack your existing LDAP plugin

cd /path/to/osTicket/include/plugins/
…
php -d phar.readonly=0 -r '$phar = new Phar("auth-ldap.phar"); $phar->extractTo("./auth-ldap");'

• Move the packaged LDAP plugin (auth-ldap.phar) out of the plugin directory so it doesn’t conflict with the new unpacked version
• Download the latest unofficial release of Net_LDAP2 from their GitHub repo - (v2.3.0)
• Replace your unpacked plugin's Net_LDAP2 package with the one you downloaded
• Login to your database
• Go to the _plugin table
• Find the record for the LDAP plugin
• Remove the .phar from the install_path value
• Set the isphar value to 0
• Restart your web server and/or PHP-FPM

Note:
The next official build of the LDAP plugin will include Net_LDAP2 v2.3.0.

Cheers.

[jakkul]

THANK YOU!

I did just that, no more error on saving the connection settings. (Also it fails when I provide a bad password and I can see the host logging in to the AD in AD logs while saving config).

Unfortunately I cannot log in to OST using ldap passwords. And I do not even see login attempts on the LDAP side. Please notice that I have a very old OST installation that just works with the same settings.

What I have to do is to manually force the user to be an LDAP user (did work with autoselect on the old setup).

[JediKev]

@jakkul

Have you tried setting someone to LDAP and then back to auto-select to test? Also, what are the Agents' backend values in the _staff table?

Cheers.

[jakkul]

1. yes, setting it to LDAP and then back to autoselect does the trick.
2. in the _staff table I can see that logging works for backends null and ldap.p7i4. It does not work for ldap. ldap.p7i4 is what is being set when I set authentication of a particular staff member do LDAP in the UI.
3. regular user logging in does not work. Logging in in LDAP plugin is enabled for both regular reporters and staff members.
4. if i delete a regular user (from the UI with all tickets), I can log in into this user again using LDAP, but all of the tickets for this user are gone.

[JediKev]

@jakkul

So null means “any”, ldap.pXiX is specifically LDAP (“pX” is pluginID and “iX” is instanceID), and ldap is the old-school LDAP backend. Since they have just ldap that means you likely didn’t have the updated plugin in-place before running the upgrader. Regardless, for any Agents you want to use “any” set their backend to null and any you want to restrict to just LDAP set to ldap.p7i4.

As for Users, it’s likely the same scenario. For any with just ldap you’ll want to set their backend to ldap.client.p7i4 and any with null should be able to use “any”. The User backends are stored in the _user_account table.

Cheers.

[jakkul]

oh yes. I see that! Thanks!

So after I migrate the site to the newest version I need to update ost_user_account table column backend and set ldap.client.p7i4 instead of ldap.client. I see that this is what has been added to the user after I've reonboarded an account.

Shouldn't there be an upgrade process for this in the DB upgrade scripts? If you need it maybe I'll help writing a bit?

[JediKev]

@jakkul

It’s already in-place you just need to have the latest build of the plugin installed beforehand.

Cheers.

[jakkul]

ack.

putting in backend = NULL in ost_user_account also seems to do the trick, thanks!