My environment is as follows:
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
No LSB modules are available.
Distributor ID: Debian
Description: Debian GNU/Linux 10 (buster)
Release: 10
Codename: buster
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.
Here is the pull if anyone is interested:
Everyone,
Below is a custom build of the plugin until we make new releases. This has the PHP 8.1 support patches as well as a patch to fix a fatal error included. Just replace your current plugin build with this build (after unzipping of course).
Updated the plugin with this one KevinTheJedi and client authentication works as expected. Thanks
If anyone have same problem whitch is not respolved by build from @"KevinTheJedi" i created separed thread where i am trying to troubleshoot it 
That's because your issue is completely unrelated to this thread. Your issue is with LDAPS not connecting at all. This thread is about LDAP is able to connect but user authentication is not working.
Cheers.
KevinTheJedi OK sorry should i remove the message ?
Sigh, I have a similar issue using the LDAP plugin, inclusive of the one that @KevinTheJedi submitted. I installed it, configured it and it works fine for agent creation, but no matter what, the user accounts get access denied.
OS: AlmaLinux 9.2
OSTicket v1.17.3
Apache: 2.4.53
MySQL: 10.5.16
PHP: 8.1.19
I have all of the recommended extensions installed as well.
I also checked the ost_user_account table and can confirm that the backend is ldap.client.pxxx
Is there anything else I can check to get this to work?
Regards.
Clear the cache/cookies and retest. Have them try a different browser/device. Make sure you restart the webserver and PHP-FPM (if you're running it) to clear any file cache. If you use a shared host ask them if there is anything else you need to do to clear any file cache. Most of the time PHARs are heavily cached so even if you replace the PHAR file it will still serve the cached version.
Other than that look into your logs on the AD server to see if their authentication attempts are actually going through and if they are successful or not.
Cheers.
KevinTheJedi To confirm, I deleted the file and restarted the server before replacing it. I manage the server so I have full access. I see in Event Viewer the successful LDAP authentication on the AD server "An account was successfully logged on."
Will continue to read, but I'm unsure on what else I can do. Is there a way to run OSTicket or the Plugin in a debug mode?
No, you'll need to add debug statements in the code yourself. It does sound like the new plugin is not loading for some reason. Check your logs (general server logs, webserver error logs, PHP error logs, MySQL/MariaDB error logs, osTicket System Logs, Browser Console logs, etc.) for any related errors on User login.
Cheers.
KevinTheJedi Thanks much. Like @eagletech, none of my logs show any related errors.
I'll look into downgrading my PHP version from 8.1.19 to 8.1.17. If that doesn't work, we will have to put the install on pause. What's weird is that agent accounts that use LDAP are fine, it's just the users that do not work.
Yes, and this is due to the user ldap auth code not accounting for latest PHP 8.1 changes which is addressed in the custom build of the plugin I linked above. Here is the relevant pull that's included in the custom build of the plugin:
Cheers.
KevinTheJedi I downgraded to PHP 8.0.28, rebooted the system and ensured that everything else on my machine works (they do). When I tried to login a user, I still got access denied. On a whim, I removed, your plugin, deleted the configuration, restarted the server, and then added the original plugin - now it works. Guess we will stay on PHP 8.0 for a while. Thanks for your assistance, I appreciate it.
Hi, quick question, is there a solution i.e. a new release on the horizon for the LDAP Plugin???
i would lie to use it but i can't downbgrade to a lower php version.
