That should be the process but like I said before not sure if that will address you particular issue.
Cheers.
Active Directory User Authentication Doesn't Work - Agents Do..?
The upgrade appears to go smoothly - but I am right back to Access Denied on the client side. Agent side is fine.
Any errors in any of your logs (general server logs, webserver error logs, PHP error logs, MySQL/MariaDB error logs, osTicket System Logs, Browser Console logs, etc.)?
Cheers.
Server logs are good.
PHP error log is spotless.
Ticket System logs are empty.
MySQL error logs are empty from today.
It doesn't act like there is an error - it just acts like the user isn't supposed to have access. There isn't a stall in the login process - it is immediately reported "access denied." Bizarre.
At this point we are getting recommendations from security analysts to either scrap the ticket system altogether (years of data down the drain) or make it an internal resource only. We can't risk having a tool exposed to the public web that doesn't have a smooth upgrade path. I am just perplexed that this is such a predictable and duplicatable issue for me and you can't create the problem.
Do you have any recommendations of any resources I can turn to?
We have someone running into this same issue and we are debugging there. We will see what we find. Indeed, it is very strange that I’m unable to replicate any issues.
Cheers.
In the meantime you can downgrade to PHP 8.0 and user auth should work. Just super weird I use PHP 8.1 and don’t have any issues.
Cheers.
It's the worst type of problem to have - an inconsistent one. Thanks for the help. We have downgraded to 8.0 and removed access to public web. Will check back to see if you have any further notes.
- Edited
If you have a test environment (with PHP 8.1) to debug with we can walk through the steps of debugging the issue here to maybe speed up the process. You'd first need to un-phar the plugin by cding to your osTicket plugin directory on the webserver (eg. /path/to/osTicket/include/plugins/) and running the following command:
php -r '$phar = new Phar("auth-ldap.phar"); $phar->extractTo("./auth-ldap");'This will create a new folder called auth-ldap/ within your /path/to/osTicket/include/plugins/ folder containing the un-phared contents of the plugin. Once you have this, login to the database, go to the plugin table, find the record for the ldap plugin, set the install_path to plugins/auth-ldap (basically just remove the .phar from the current value), set isphar to 0, and restart the webserver and PHP-FPM (if you're running it) to clear any file cache.
Now you will be running the un-phared plugin and you can add debug statements to the code that will reflect on screen or in your logs.
From here you can open include/plugins/auth-ldap/authentication.php file, go to the authenticate() method, and look for these specific lines.
Under the $r = $c->bind($dn, $password); line and above the if (!PEAR::isError($r)) line add the following statement:
error_log(print_r($r, true));Once you make the changes please save the file, tail the error logs on the webserver, attempt to login as a User via LDAP, and see what gets logged in your error logs. I'm going to bet this will be a PEAR error containing an error from the bind attempt. If you don't see anything being logged then it seems it's not even attempting LDAP auth.
Please note that the log may be put in your webserver error logs or PHP error logs or even the general server logs. It just depends on how you have PHP configured. You can look at your PHP INI file to see where error logs are being stored.
Cheers.
I appreciate you working with me. Last week we were on Spring Break so I had some cycles to spend on this. Unfortunately, I don't have time to spend right at the moment. I will try to get back to you. Thank you!
Thank you for those tips - after debugging this (to some extent), I think the issue might be related to PHP 8.1.0 migrating from ldap resource to LDAP classes. So ldap result is replaced with LDAP\Result and ldap result entry is replaced with LDAP\ResultEntry. The same functions now return objects instead of resources. This seems to be causing issues in parsing search search results where checks using is_resource() are failing.
Am I on the right track here?
That's a good question. I was able to track the LDAP logs and saw the search result being returned, but when the auth-ldap code was trying to convert the search results into Net_LDAP2_Entry objects, it was not able to convert them.
When I added debugs, I got this error from the shiftEntry() method:
" Unable to create connected entry: Parameter $entry needs to be a ldap entry resource! "
When I printed the actual object it was trying to convert, it was of type LDAP\ResultEntry. That is what got me looking at PHP 8.1.
I honestly don't know how its working for you. Sorry I could not help more with the debugging.
BTW, if I try to hack it temporarily and accept the search result as a LDAP\ResultEntry object, I am able to successfully authenticate (the problem was when it was trying to retrieve the DN from the search result).
I also found another minor issue with the configuration.php file in auth-ldap.phar - when we specify a port number in the ldap servers information (as host:port) in the instance detail screen, it assumes the port number is at most 4 digits, I think it needs to be adjusted to allow up to 5 digits.
My environment is as follows:
php --version
PHP 8.1.17 (cli) (built: Apr 9 2023 16:48:03) (NTS)
Copyright (c) The PHP Group
Zend Engine v4.1.17, Copyright (c) Zend Technologies
with Zend OPcache v8.1.17, Copyright (c), by Zend Technologies
lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description: Debian GNU/Linux 10 (buster)
Release: 10
Codename: buster
- Edited
in config.php, line 161 changed to:
if (preg_match('/([^:]+):(\d{1,5})/', $host, $matches))
in authentication.php, line 120 changed to:
if (preg_match('/([^:]+):(\d{1,5})/', $h, $matches))
I'm talking about this part:
BTW, if I try to hack it temporarily and accept the search result as a LDAP\ResultEntry object, I am able to successfully authenticate (the problem was when it was trying to retrieve the DN from the search result).
I'm curious to see what you did to authenticate successfully.
Cheers.
Nevermind...I feel SO stupid right now.. this ENTIRE time I forgot I had already made those changes to convert is_resource() to valid checks and that's why mine has been working... the reason I didn't know about the changes is because I was editing the raw plugin from within my normal core osTicket git not the osTicket-plugin git so it didn't track the plugin changes..
Your comment really helped me by making me question my own sanity and I can't thank you enough lol 
Cheers.
Everyone,
We will have a pull request made and a new build of the plugin released soon that should resolve the user login issue.
Cheers.