search

osTicket / osTicket-plugins

Core plugins for osTicket (v1.8+)
GNU General Public License v2.0
148 stars 160 forks source link

LDAP Plugin stopped working after migration to PHP 7.4.30 #233

Open mprudek opened 1 year ago

mprudek commented 1 year ago

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:

image 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: image And the ldap settings is the following: image

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

mprudek commented 1 year ago

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

gramakri commented 1 year ago

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

gramakri commented 1 year ago

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

JediKev commented 1 year ago

@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 commented 1 year ago

@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 commented 1 year ago

@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:

Cheers.

gramakri commented 1 year ago

@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 commented 1 year ago

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

alepensato commented 1 year ago

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 commented 1 year ago

@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 commented 1 year ago

@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 commented 1 year ago

@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.