What is the format of your Search User and Search Base strings? What is the ost_user_account.backend value of the Users unable to login?
Cheers.
Active Directory User Authentication Doesn't Work - Agents Do..?
- Edited
Search User and Search Base fields are empty as they have been for years.
ost_user_account.backend is ldap.client.
*I guess I should add that I HAVE tried adding a search and bind user just to troubleshoot, but it has yielded no difference.
- Edited
That's one problem. You didn't update your plugin before upgrading osTicket. You will need to first update your plugin with the latest build from the website. Next, set the backend for every affected user to ldap.client.p123i123. Replace 123 in each part with the plugin ID and instance ID respectively. You can look at this thread for more info:
This would've happened automatically on upgrade if you updated your plugin first.
Cheers.
I just want to clarify. I have good backups and have had to spin them up several times already. You are telling me that if I go BACK to OSticket\PHP version that is working and update my LDAP plugin first, THEN do the PHP and Osticket updates that I should be able to get this to work? I only asked because I have multiple sites to update. I appreciate the help.
- Edited
That will correct the Users' and Agents' backend but not sure if that will address your issue. For clarity I am using PHP 8.1, v1.17.3, and latest LDAP plugin with a real MSAD server with no issues.
Cheers.
I will give that a try. Thank you!
It appears I am already using LDAP Plugin 0.6.2 on my non-updated server (v1.16.5). Is there a newer version? The version listed in OSticket v1.17.3 is also 0.6.2.
Taking this in steps - for me and maybe others.
- I recovered to Osticket v1.16.3 and PHP 8.0.20. LDAP works splendidly.
- I updated the LDAP plugin by downloading the phar file from the website and copying into the plugin directory. LDAP still works great.
- I update to PHP 8.1.17 and LDAP breaks for users - not agents. I get the Invalid CSRF Token CSRFToken error when I try to login.
Is this normal and a motivation to update to OSticket v1.17.3? Or should I stop now and try to diagnose? (Toggling back to PHP 8.0.20 fixes the issue.)
Well v1.16.3 is old, the latest release in that series is v1.16.6. v1.16.3 is also not compatible with the LDAP plugin build for 1.17.x. So it'd be advisable to upgrade to v1.17.3 (latest stable release) or v1.16.6 (latest maintenance release for 1.16.x series). If you do v1.16.6 then you need to download the latest plugin build from our website specifically for 1.16.x series (there is a dropdown to choose your version when downloading plugins). The same goes for v1.17.3 except you'd need the plugin build for 1.17.x.
Cheers.
Kevin, that is the goal here buddy. I want to get upgraded. I am trying desperately. I have tried several times, but it breaks the LDAP functionality each time.
So, going back to your comment yesterday regarding updating the plugin first.... if I have a working copy at v1.16.3 and I updated that plugin as instructed, it should stand to reason that if I now update OSTicket to V1.17.3 at this point it should solve my LDAP issue? Is my logic sound?
That should be the process but like I said before not sure if that will address you particular issue.
Cheers.
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.