Did you also try applying these changes?
Cheers.
Active Directory User Authentication Doesn't Work - Agents Do..?
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 
- Edited
I am still puzzled by this. For a couple years or so we've had a server running Ubuntu 18.0.4 with OSTicket 1.14.2 with the LDAP Authentication and Lookup plug-in version 0.6.2 which works fine. The plug-in is the same version that came with OSTicket 1.17.2 so I would think that matching the same settings should work fine, but I'm still getting the same error. Both servers are virtualized and running on the same Hyper-V server as is the domain controller it is authenticating to. They are all connected to the same virtual switch and the firewall is inactive on all three machines.
I've checked that all the PHP extensions that were installed on the old server were installed on the new one before installing OSTicket so as far as I can tell, the only difference is the version of Ubuntu, and the version of OSTicket. The only thing I can think of is perhaps I'm missing some dependency on the new server that was installed on the old one. 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? Other than that, I'm kind of at a loss. I will continue reading through the various threads to see if I can find anything else that may help.
Thank you
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.
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.
roark
Not to be a total PITA for you -- but an you tell me -- did you just install 8.0.27 and all the same modules that you have for 8.1? To install 8.0.27 is it as easy as specifying 8.0.27?
- Edited
I followed the instructions here (I hope it's OK to paste a link here)...
https://blog[dot]devops[dot]dev/downgrade-php8-1-to-php8-0-or-php7-4-on-ubuntu-22-04-2fab4a6a3be3
When I first added the repository and ran apt-update it upgraded a lot of the 8.1 packages that were already there and also installed 8.2. I tested the plug-in with 8.2 and it still was not working for me so I followed the instructions to install 8.0 and 8.0.27 is what I ended up with. Now, my server has 8.0, 8.1 and 8.2 all installed but 8.0 has been set as the default, and it is working well for us now.
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.
- Edited
Anyone else who is running into the same error can provide the above information as well.
The below pull request addresses the fatal error but I'm wondering if the root issue is elsewhere:
KevinTheJedi Can I DM this to you or do you prefer it here?
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.
So I have the domain filled out and one of the main DCs set as our DNS server -- that same server is set as the LDAP server with port 389. Search user is:
cn=helpdesk,ou=IT,ou=Users,dc=ourdomain,dc=dom
Password is filled in for that user. Serach base is:
ou=Users,dc=ourdomain,dc=dom with Microsoft Active Directory selected for the LDAP schema. I downgraded to 8.0 and it may be working -- but we really need support for 8.1 and higher. Thank you for your assistance.
- Edited
Okay, that all seems fine. At this point the next step involves very extensive debugging which I currently don't have the time for as I'm focusing on other issues. I also currently don't have time to setup a full AD server at the moment.
If you want to unpack your plugin and debug to speed up this process I can provide some debug statements. This will however break user authentication with ldap completely and output debug statements to the browser so you may want to setup a separate test environment if you choose to debug.
Cheers.
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
We're in production so I downgraded to PHP8.0 and all works. If I get some time I'll spin up another instance where we can debug.
2 months later
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.
10 days later
- Edited
We are having the same issue. I've diligently read through all options in this thread. We are running IIS on Server 2019, PHP 8.1.17, and OSticket v1,17,3. Agents can login fine using LDAP authentication. I can even create brand new agents and they can authenticate via LDAP exclusively. Users are not able to at all. I just get Access Denied. I even tried manually creating and registering a user with a password. Access Denied. Really frustrated. Dept of Homeland Security is demanding that we move to PHP 8.1.16 or greater so we don't have a choice on PHP version. Incidentally, I get the same results with 8.1.16 and 8.1.17. Any help appreciated!
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.
- 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.