LDAP doesnt work after update

pcjkollmorgen

I've been looking at the LDAP issue since your post.

I'm quite sure the issue started at RC4, RC3 was ok and RC and final have a problem.

There is also now further information known about this here: https://forum.osticket.com/d/101553-ldap-not-enter-whit-user/

The password for the LDAP plugin config needs to be re-entered after an upgrade from 1.16 to 1.17 also, however after this is set again, some users are unable to log in. Agents can still log in from /scp, and the couple of LDAP searches (type aheads) used when creating a new ticket and adding a new agent all starting working again fine.

The users login page however works for some people and not others. I initially though it was only blocking my account as it was additionally an agent account, but that looks to not be the case.

We are also starting to use the paid for SAML plugin, so the LDAP side of things isn't a big issue for us currently and we likely will turn it off completely at some point soon.

SirSeba

pcjkollmorgen
When I updated to the newest version today, I also encountered the problem that the Users couldnt login anymore.

The same issue again, users couldnt login in, plugin was reinstalled, settings redone but didnt work.

I got it to work by changing the User Authenthication Method to only LDAP or Active Directory.
Before we had the setting "Every authenthication method is allowed" but that didnt seem to work.

MarkMansveld

We kindof have the same problem.
We upgraded from 1.15.2 to 1.17.0
Upgrade went fine. Agents login through ldap also work.
Users are not able to login via the same method though. They are able to login if we put the domain in front eg <domain>\username. That was not necessary in version 1.15.2

We want the ldap functionality to keep working until we implemented the oauth2 proces.

Any way we can troubleshoot this problem?

KevinTheJedi

MarkMansveld

Please follow the steps in my post here:

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

Cheers.

KevinTheJedi

SirSeba

You need to read the post I linked above. We have a bug where the backend string for Users/Agents weren't updated on upgrade. You will need to manually change the backend via the UI and change it back to LDAP or run the queries I posted in the link above.

Cheers.

AlanF

I recently upgraded two instances of OSTicket to 1.17 1d8b790, PHP 8.1.11, web server IIS/8.5. I am using the LDAP plugin with Microsoft Active Directory.

I am having an issue that was mentioned above where LDAP lookups are not working, although that post said they were working again for that user.

When I try to add a new agent, nothing comes back. When I try to lookup a client while creating a ticket, I get the list of existing clients, but no "remote" clients from LDAP.

I used Chrome developer tools to capture the link that is being called when trying to add a new agent (like "../ajax.php/users/staff?q=john.smith" where john.smith is a valid LDAP account name). When I put that URL in a browser I get a response of "[]"

I'm pretty sure my LDAP is configured correctly. I somehow had 4 instances of all my plugins after the upgrade, so I deleted all instances and the plugin itself, then re-added LDAP and recreated/reconfigured one instance (which had the effect of re-entering the password, which I see was also an issue). The plugin is configured for staff and client authentication.

Is there any other troubleshooting I can do to try to determine if the queries are being sent to LDAP?

KevinTheJedi

AlanF

Check your AD logs for queries.

Cheers.

pcjkollmorgen

@AlanF

Re-enter the password for the LDAP Search User under the Connection information part of the LDAP plugin settings.

The password is not kept during the upgrade up to 1.17.

Cheers.

fragglepete

I found users can't login if running PHP 8.1.11 (latest), but if I downgraded to 8.0.24 then users can log back in again. I'm running on a IIS Server on Server 2022.

Pete

AlanF

The password was re-entered when I uninstalled and reinstalled the plugin and recreated the instance after the upgrade. I get 'Instance Updated Successfully' when making any changes, so I know the password is correct. When the password is wrong I get 'unable to connect any listed LDAP servers'

Unfortunately I don't think our Active Directory server has the query logging turned on. I can see in the Windows Security logs that the user configured in the plugin is connecting to the server each time I click "Save Changes" on the plugin config page and each each time I try to search a username in the 'Add new agent' page.

I've tried variations on the Search Base, but I'm pretty sure it's correct. It is the same one I'm using in another PHP application where I'm searching LDAP using the same string as the DN for the search.

Any suggestions for where else I can look? This used to work pre-upgrade. I can't be 100% sure it didn't break before the upgrade due to something else, but it was working recently and is not working now.

AlanF

Rolled back to PHP 8.0.24 and now the lookup is working for me. I have the same extensions enabled for both versions of PHP (via IIS PHP manager). This worked in both instances of OSTicket that I have running on this server.

Nothing is coming up in the PHP error logs when running under PHP 8.1. It just doesn't return any results.

KevinTheJedi

AlanF

Then we are unsure. Without errors we will be unable to debug adequately. I’m unable to replicate this so it’s even more obscure.

I’ll keep trying to replicate but so far nada.

Cheers.

AlanF

KevinTheJedi

Understood. Is the LDAP query run from PHP? If so, is there any way to get the specific request that's being run from PHP? I was thinking I could try the same request from a custom PHP app and run it against different versions of PHP to see if I get the same results.

Failing that, is there any additional logging that can be turned on in OSTicket? I'm not an expert on PHP... I'll go Google for an answer to this, but do you know if there is a way to increase the logging in PHP.ini and maybe capture something useful?

KevinTheJedi

AlanF

With PHP you either have the error logs or if you’re running FPM then you can enable access logs as well. Other than that you have to manually add debug statements in the code. Im no AD expert but I believe you can access your AD logs to see if a connection is being attempted and what the application is sending (query string, etc.).

Cheers.

AlanF

I'm in way beyond my depth as far as PHP knowledge here, but I was able to trace the code to the point where ajax.users.php, in the function searchStaff() has a line that says:

        foreach (AuthenticationBackend::getSearchDirectories() as $ab) {
            foreach ($ab->search($_REQUEST['q']) as $u)
                $users[] = $u;
        }

I modified that to put 'echo("<pre>"); print_r($ab); echo("</pre>")' after the first foreach statement to see if it would show anything useful. When I went to "http://myserver/osticket/scp/ajax.php/users/staff?q=alan" in a browser, I got two different outputs depending on whether I was running under PHP 8.0 or 8.1. I can match up many of the elements between the two outputs, but they are in a completely different order and some lines in the working one don't appear anywhere in the non-working (PHP 8.1) output.

I was thinking that this points to something in the LDAP plugin being handled differently between the two PHP versions. I found this: https://php.watch/versions/8.1/LDAP-resource which says:

I see that inside the auth-ldap.phar plugin file there are multiple examples of "if (is_resource...)" used. Could that be the source of the problem? Again - I'm stretching way beyond my knowledge level on PHP here, so apologies in advance if I'm not making much sense.

ramrajone

AlanF
It's a bug, it will be fixed in the next release, workaround set the backend via command:
https://forum.osticket.com/d/101842-user-unable-to-login-to-port-via-ldap/3

AlanF

@KevinTheJedi - pinging you on this... is there any chance the "is_resource" backwards compatiblity in PHP 8.1 might be causing the issue?

KevinTheJedi

AlanF

Potentially, I cannot replicate the issue with PHP 8.1 however so doubt it.

Cheers.

TheQuicken

Just adding to this, we had same issue on all our upgrades. Most users could not login.
simply clearing the "ldap.client field in the db allowed Users to log back in.

KevinTheJedi

TheQuicken

The fix is listed here:

https://forum.osticket.com/d/101561-ldap-doesnt-work-after-update/5

Also, this is the cause of the issue:

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

Cheers.