LDAP Plugin stopped working after migration to PHP 7.4.30

[mprudek]

Hi, I'm deeply sorry for opening an issue for this but I wasn't able to google up relevant info elsewhere.

In the last hours, I migrated our older osTicket installation to newer PHP version (7.0.33 -> 7.4.30, basically Debian 9.13 -> Debian 11.4) and osTicket version . The database migration and all other stuff went well. The only thing that seems to stop working is the LDAP Plugin.

When trying to use ldap login, the login screen just hangs like this:

and the following lines appear in the log:

[Sat Sep 03 14:11:07.898212 2022] [php7:error] [pid 787] [client 10.22.2.11:43876] PHP Fatal error:
Uncaught Error: Call to a member function rootDse() on null in phar:///var/www/ticket.example.com/include/plugins/auth-ldap.phar/authentication.php:262\nStack trace:\n#0
phar:///var/www/ticket.example.com/include/plugins/auth-ldap.phar/authentication.php(193): LDAPAuthentication->getSchema()\n#1
phar:///var/www/ticket.example.com/include/plugins/auth-ldap.phar/authentication.php(430): LDAPAuthentication->authenticate()\n#2
/var/www/ticket.example.com/include/class.auth.php(249): StaffLDAPAuthentication->authenticate()\n#3
/var/www/ticket.example.com/scp/login.php(71): AuthenticationBackend::process()\n#4 {main}\n  thrown in
phar:///var/www/ticket.example.com/include/plugins/auth-ldap.phar/authentication.php on line 262, referer:
https://ticket.example.com/scp/login.php

(I replaced the real domain with ticket.example.com)

My OpenLDAP installation logs this (started with slapd -d 1 -h "ldap:/// ldaps:/// ldapi:///"):

631361b9 slap_listener_activate(7): 
631361b9 >>> slap_listener(ldap:///)
631361b9 connection_get(15): got connid=1002
631361b9 connection_read(15): checking for input on id=1002
ber_get_next
ber_get_next: tag 0x30 len 12 contents:
631361b9 op tag 0x60, time 1662214585
ber_get_next
631361b9 conn=1002 op=0 do_bind
ber_scanf fmt ({imt) ber:
ber_scanf fmt (m}) ber:
631361b9 >>> dnPrettyNormal: <>
631361b9 <<< dnPrettyNormal: <>, <>
631361b9 do_bind: version=3 dn="" method=128
631361b9 send_ldap_result: conn=1002 op=0 p=3
631361b9 send_ldap_response: msgid=1 tag=97 err=48
ber_flush2: 39 bytes to sd 15
631361b9 do_bind: v3 anonymous bind
631361b9 connection_get(15): got connid=1002
631361b9 connection_read(15): checking for input on id=1002
ber_get_next
ber_get_next: tag 0x30 len 5 contents:
631361b9 op tag 0x42, time 1662214585
ber_get_next
631361b9 ber_get_next on fd 15 failed errno=0 (Success)
631361b9 conn=1002 op=1 do_unbind
631361b9 connection_close: conn=1002 sd=15

My overall settings look like this:

And the ldap settings is the following:

I would be highly thankful for any suggestion/insight or other ways how to debug this.

[mprudek]

Yet to fully confirm, but it seems that with Debian 10.12 & 7.3.31 it all work like a charm.

[gramakri]

Hit this issue with PHP 8.1 . Given that PHP 7.4 is EOL by now, is there a fix for this?

[gramakri]

Just found this thread which says 8.0 is supported. So, I will give that a try.

[JediKev]

@gramakri

PHP 8.0 and 8.1 are both fully supported (with 1.16.5 and 1.17.2) and work perfectly in my instance with LDAP. Of course I have all the latest patches applied (for core code and plugins), etc. so you may either need to apply all the recent patches or wait for next release and next builds of plugins to retest.

Cheers.

[gramakri]

@JediKev I am on 1.17.2 as well. osTicket itself works but when it hits LDAP code paths it breaks. I do use the build from the website and not source from this repo.

The changes in https://github.com/osTicket/osTicket-plugins/commits/develop/auth-ldap are from Feb 2022. Is the plugin build on the website even older than that?

[JediKev]

@gramakri

Some patches have not been merged yet. You will need to look at the open and closed pull requests for both core code and plugins. Here are a few related ones I know off the top of my head:

• session: Regenerate Session Id osTicket#6379
• session: Collab View Ticket osTicket#6385
• issue: LDAP Multi-Instance Fatal Error osTicket#6403
• session: User Logged Out osTicket#6434
• ldap: Staff Authentication Backend ID #255

Cheers.

[gramakri]

@JediKev I checked the situation again now with osTicket 1.117.3 which I assume has all the fixes for 8.1.

Still get an error:

PHP Fatal error:  Uncaught Error: Call to a member function dn() on bool in phar:///app/pkg/plugins/auth-ldap.phar/authentication.php:246\nStack trace:
#0 phar:///app/pkg/plugins/auth-ldap.phar/authentication.php(430): LDAPAuthentication->authenticate()\n#1 /app/code/upload/include/class.auth.php(341): StaffLDAPAuthentication->authenticate()
#2 /app/code/upload/scp/login.php(71): AuthenticationBackend::process()\n
 {main}
  thrown in phar:///app/pkg/plugins/auth-ldap.phar/authentication.php on line 246, referer: xx

[gramakri]

I can confirm that PHP 8.0 works. There is some bug in PHP 8.1 code path with the ldap plugin.

[alepensato]

I am running the v1.18 (724de45) with PHP 8.2.7 and the autentication does not works. I was able only to search and find the users form my remote ldap, but they was unable to sign in. I wasted 3days to try to solve all of these problems. OSTicket is not fully stable/compatible with PHP 8.2 , tha was the minimal in Debian 12

[JediKev]

@alepensato

The bugs mentioned in this thread have been resolved (References) so your issue will be something different. So far we’ve had no other reports of issues with LDAP but I will run some tests to make double sure that 8.2 causes no issues. If you have any relevant errors please share them. Also, if you haven’t done so already, please make sure you install the latest build of the LDAP plugin for v1.18 from our website.

For the users that cannot authenticate, have they tried different browsers (even incognito) and if so is the issue the same across all? If so, please login to the database, go to the _user table, find an affected user, and copy their id. Then go to the _user_account table, search for user_id = x (where x is the id you copied), and see if the backend column value is set to ldap.client.pXiX (the Xs will be numbers in your case). If the column value is set to simply ldap.client then that will be the cause.

Let me know if the above is the case and I can provide a link to instructions on how to address that.

Cheers.

[alepensato]

@JediKev
Hello, actually I have not any user able to login, so i can use the sql reference in the _user_account table changing the backend value.

All the osticket stuffs has been downloaded from the main site.
Actually I have a VM running Debian 11.7 with php 7.4 where i installed Librebooking where ldap authentication works.

Current OSTicket releases does not support php7.4, but only php 8.x.
I created another VM with Debian 12 and PHP 8.2 where i installed osticket but there are problem with LDAP auth.

In next days I will restart all on this VM and I will give you some feedback

The better solution for me is have all working on a single system where i can run osticket and librebooking.
I am working on all of these stuffs since the 1 Aug night

[JediKev]

@alepensato

At this point it would be best for you to open a discussion on the Forum until we determine if this is an actual bug or not. That way we aren’t flooding this (unrelated) Issue with back and forth.

Cheers.