LDAP Plugin on osTicket v1.18 with Debian 12 and PHP 8.2.7

KevinTheJedi

Can you add a DNS server to the config and retest?

Cheers.

KevinTheJedi

What does the lower half of your plugin config look like? Do you have any other plugins installed? If so, do you have those updated to the latest?

Cheers.

KevinTheJedi

alepensato

Also, are you able to look at the logs on the LDAP server to see why the connection is borking? Are all your AD attributes standard? Are the attributes in English?

Cheers.

KevinTheJedi

alepensato

Can you set your LDAP Schema in the plugin config to "Microsoft Active Directory" instead of "Automatically Detect"?

Here are the attributes for msad and posix (2307):

https://github.com/osTicket/osTicket-plugins/blob/develop/auth-ldap/authentication.php#L28

Also, can you add the port to the LDAP Servers value?

Cheers.

KevinTheJedi

alepensato

It looks like it’s posix schema as you have mail and uid attributes. Are you using username or email address to login? Does the user exist in osTicket already? If so, are they registered or set to Guest?

Cheers.

KevinTheJedi

alepensato

Also, are you required to use LDAPS? Can you at least try non SSL (eg. hostingservice.src.cnr.it:389) just to see if that works?

Cheers.

KevinTheJedi

alepensato

I just tested normal LDAP with an osTicket instance running PHP 8.2 and it works fine. Your issue might be due to LDAPS specifically. We do not have an LDAPS instance nor do we have time to look into this at the moment. If you find anything helpful in the AD logs or server logs please let us know.

Cheers.

KevinTheJedi

alepensato

Then its likely that something isn’t configured correctly; either in the plugin config or at the database level.

You will need to provide screenshots of the relevant user records in the _user_account table. If you’re talking about agents then a screenshot of the _staff table with the relevant staff records. I am mainly interested in the username column values as well as the backend column values.

Cheers.

KevinTheJedi

alepensato

So you don't have a staff record..? That doesn't make sense.

Cheers.

KevinTheJedi

alepensato

Okay so backend is NULL which means this Agent can use whatever authentication they want (ie. Local Auth or LDAP Auth). The username is SuperAdmin and the email is sysadmin@irib.cnr.it. Do these values match your AD credentials? If not that’s the issue. Agents MUST be created BEFORE they can login via LDAP. Make sure you set the Agents username and email address to their AD username and email address. Also, LDAP usernames CANNOT be strictly numbers. They have to have some sort of alphabetic characters.

Cheers.

KevinTheJedi

alepensato

Users should be able to login without being created first as they are considered pre-authorized users. However, like I said, their usernames cannot be fully numeric; they have to be alpha-numeric. Also, make sure you try from an Incognito window to avoid session issues.

Cheers.

KevinTheJedi

alepensato

Yea all it's saying is there is no _search (ie. LDAP\Result) instead it's a boolean (false). This means the search for the User likely failed or returned empty results.

You really need to contact your AD administrators and have them look into the logs to see why it's failing.

Cheers.

KevinTheJedi

alepensato

Do you mean you created the user and then you were able to login?

Cheers.

KevinTheJedi

alepensato

You can login as a User if you create the Agent or you can login as an Agent when you add the Agent?

Cheers.

KevinTheJedi

alepensato

Maybe I check user auth in the plugin config, save, re-enable it, save again, and retest. If that doesn’t work then please contact your AD admin.

Cheers.

rblake

Hi @alepensato,
The fact that you can find users with the LDAP query and log in as an operator tells me that it's working as it should. If you go into your Admin Panel -> Manage -> Plugins -> HTTP Passthru Authentication -> Instances -> Make sure that both Enable authentication of staff members & Enable authentication and discovery of clients is checked. Let us know if this resolves your issue.

KevinTheJedi

rblake

That's a good point. I would've assumed they enabled in both places but hey, can't assume anything.

Cheers.

rblake

And this is a Windows Active Directory domain? If so, LDAP Schema should be Active Directory. You should also put in just hostingservice.src.cnr.it for the LDAP servers and check Use TLS. Just be sure that they use TLS over port 389.

Granted, if it's Active Directory, both Search User and Search Base should end with DC=hostingservice,DC=src,DC=cnr,DC=it. You can pull the distingushedName by enabling Extended Attributes under View menu in Active Directory Users and Computers, then go down the tree and right click, choose Properties, and you should see a tab that says "Attribute Editor." This works for both OU and specific users.

Make sure your Search Base encompasses everyone.

rblake

Do you have any access to the system? Are you able to use an LDAP browser against it (Softerra has a good one)?

You'll want to make sure you are using the correct values for search user and, especially, search base. Based on my quick Google searching, even Posix-enabled LDAP uses DC= at the end so I'm thinking you might have invalid information, which is causing the query issues. The only way to know is to validate by checking.

If you aren't able to validate, you'll need to get in contact with a colleague who can.

rblake

alepensato I don't disagree there. Presuming there isn't anything wrong with the overall configuration, it has to be with the search base.

When you looked at the LDAP query results from your search, did you see all users or only some?

What if you re-ran the same search but changed the search base to what you have set in osTicket, do you get less users?

Are any other operator-level users able to be set up and log in? Could it be possible that you set a local username and password for your account and osTicket is just working off your locally stored credentials and not against LDAP? You could always change your LDAP password and see if you're still able to log in with the new credentials to ensure that it is properly querying against LDAP. Of course you could also do a packet capture and other things, but changing your password would likely be the easiest testing method.