whowe-ppd

Did you install the latest build of the LDAP plugin?
Did you install the latest build of the LDAP plugin before upgrading?
Do you see any associated errors in your logs (general server logs, webserver error logs, PHP error logs, MySQL/MariaDB error logs, osTicket System Logs, Browser Console logs, etc.)?

Cheers.

sgriffin

Please read my post above.

Cheers.

Here is a full listing of the error we are getting:

[Tue Jan 24 08:06:18.122972 2023] [php:error] [pid 153559] [client 192.168.231.68:56225] PHP Fatal error: Uncaught Error: Call to a member function dn() on bool in phar:///var/www/html/include/plugins/auth-ldap.phar/authentication.php:390\nStack trace:\n#0 phar:///var/www/html/include/plugins/auth-ldap.phar/authentication.php(225): LDAPAuthentication->lookupAndSync()\n#1 phar:///var/www/html/include/plugins/auth-ldap.phar/authentication.php(479): LDAPAuthentication->authenticate()\n#2 /var/www/html/include/class.auth.php(341): ClientLDAPAuthentication->authenticate()\n#3 /var/www/html/login.php(51): AuthenticationBackend::process()\n#4 {main}\n thrown in phar:///var/www/html/include/plugins/auth-ldap.phar/authentication.php on line 390, referer: https://helpdesk.enablecomp.com/login.php

whowe-ppd

That should be fine. Others have complained about PHP 8.1 so try downgrading to 8.0.

Cheers.

whowe-ppd

I've tried replicating the 8.1 issue repeatedly and cannot replicate the issue so the cause is unknown and I can't debug any further as I cannot replicate the issue. I'm using v1.17.2, PHP 8.1, and OpenLDAP and everything works as expected.

We do have some LDAP plugin patches and such coming which I referenced above so hopefully that will address the issue for you.

Cheers.

I am having the same problem, I am running osTicket 1.17.2 with the LDAP Authentication and Lookup plug-in version 0.6.2. I'm running Ubuntu 22.04 with PHP 8.1. The error is the one that includes "Call to a member function dn() on bool..."

I guess I'm just looking for clarification, I found another thread where it said that the LDAP Authentication plug-in required PHP 8.0 and it also said to look at the documentation. I have searched for official documentation for the plug-in, if I go the docs.osticket.com/en/latest and look at the plugins section, I don't see it listed. Can someone please tell me where to find the official documentation for this plugin?

Also, can someone verify once and for all whether PHP 8.0 is required or should it be working with PHP 8.1? I have the same plugin installed and working on an older osTicket installation and I was able to copy the configuration settings from there so I'm pretty sure I have it configured right.

Thank you

roark

PHP 8.1 should work as I mentioned above. There is no plugin documentation for the ldap plugin.

Cheers.

I installed php8.0, disabled 8.1, and set apache to use 8.0 to no avail. I'll check out the notes linked.

Hello,
I have almost the same problem...
I upgraded OSTicket from version 1.15.2 to version 1.17.2, going from PHP7.3 to PHP8.1 and MySQL/MariaDB version is 10.3.36. My server is a Debian 10 Virtual Machine.
I had previously upgraded my plugins including the LDAP plugin to 0.6.2 (Is it really the lastest version ??) and added a LDAP Search User.
The upgrade is done without problems, the integration of the PHP8.1 Extensions made by myself appears correct after the upgrade (Dashboard > Information looks great with valid sign !).
No errors in the Apache2 logs for example.
I upgraded as a Local (root) account so when I try to reconnect with my AD account I get an "Access denied" message.

I searched the forum and found a solution that works for agents here: https://forum.osticket.com/d/101553-ldap-not-enter-whit-user/66
You have to change the authentication method to "Local", save and change again to "LDAP" and save. After that the agent account can be reconnected by the LDAP method

However my "Standard" users who are not "Agents" still can't connect on their side, they get an "Access denied" message.

I have read many topics in the forum and I can't find any solution, even if I try to change in the database directly in the ost_user_account table the "backend" column by "NULL" and then by "ldap.client" it still doesn't work.

I'm pretty sure it's not a PHP version problem for my installation (between 8.0 or 8.1) because I don't have an error like you and according to the last post from @KevinTheJedi .
However, be aware that you have to completely deactivate/uninstall your old versions of PHP to avoid any problems of extension conflicts between versions.

I'm still looking for a solution but if you have an idea to help me, I'm interested!

Thanks

Wismerhill

You need to do this:

• https://forum.osticket.com/d/101553-ldap-not-enter-whit-user/15

Cheers.

KevinTheJedi
Ok, I was too fast on this topic ... Thanks for telling me where I should look.
Well, now I also get the error of @roark ...

I'm going to look for a solution for this problem in PHP 8.1, if I don't find it I'll try in PHP 8.0 ...

I'll keep you up to date,
Thanks to you anyway @KevinTheJedi !

Hello,
I made the fixes in the php code and I also made the fix you put on GitHub in the plugin.
I re-compiled the plugin, uninstalled the old auth-ldap.phar and put mine instead.
I'm back to php8.1
After re-installing the plugin in OSTicket, I had to redo the database modification because the identifiers in the bakend column changed (I was expecting it).
The update is done, it works correctly for the agents but still not for the users.
This time I have no error in the /var/log/apache2 logs.

I'm still looking for an error somewhere in the logs

roark

You definitely need the php-ldap extension.

Cheers.

Thanks Kevin, it would be nice if it was that easy but php-ldap is installed. Before installing OSTicket on the new server I made sure that all the PHP extensions installed on the older server were also on the new one. I just double checked and it definitely is installed.

roark

I was just answering the question of:

Are there any Ubuntu packages that need to be installed for the LDAP plug-in to work correctly that are not required for OSTicket itself?

We do have a new release coming soon as well as new builds of the LDAP plugin, etc. so stay tuned!

Cheers.

I decided to test PHP 8.0 to see if it would help. The repository I used also installed PHP 8.2 by default so before I installed 8.0 I tried it with 8.2, but still experienced the same error.
However, after installing 8.0.27 and setting Apache to use that version, we are able to authenticate and all seems to be working perfectly now.

sgriffin

I'm revisiting this and would like to know if you can provide a little more information here. I believe the reason I could never replicate this is because I use OpenLDAP and this does not use msad schema. The issue here is solely related to msad schemas.

Anyways, I would like to know what your Use TLS, Search User, Search Base, and LDAP Schema settings are set to. Please post a screenshot and censor any sensitive information.

Cheers.

whowe-ppd

You can paste it here whilst censoring any sensitive info. For the Search User/Search Base I just really need to see the format (ie. cn=xxx,dc=xxx).

Cheers.

whowe-ppd

Also, have you tried applying the patch I referenced above to see if that addresses the issue?

Cheers.

For Search User, set it to a username.

i.e. instead of cn=helpdesk,ou=IT,ou=Users,dc=ourdomain,dc=dom
set it to helpdesk or OURDOMAIN\helpdesk

whowe-ppd

I was finally able to revisit this with a legitimate MSAD server setup on Windows Server 2019. After extensive testing I can finally say without a doubt there should be no issues with User/Agent logins with PHP 8.1, v1.17.3, and latest build of LDAP plugin with correct LDAP settings configured.

If you still have issues check to see if you have more than one instance of the LDAP plugin enabled. If so, disable one of the instances and retest. Also, check to make sure your Search User and Search Base is correct. These two settings are very important. You can find the appropriate Search User string by running the following in a command prompt on the domain controller (this is assuming the administrator's username is Administrator):

dsquery user -name "Administrator"

This should give you something like:

"CN=Administrator,CN=Users,DC=domain,DC=com"

Cheers.