This does work in 1.15.4 so I am with abeermuh, no changes were made to the LDAP IDP (Active Directory) or osTicket apart from migrating to 1.17 including the new LDAP plugin
ldap not enter whit user
Not saying it did just saying to confirm that it’s still returning the appropriate attributes.
Cheers.
Finding out now that the lookup part of the plugin also seems to be having issues for us with 1.17. It no longer finds users when adding new users etc., and we are having to add manually. Would there be a specific log that would be helpful?
I have been unable to replicate this (and other LDAP issues) with OpenLDAP so I’m eventually going to test with Azure AD to see if I can replicate these AD issues. But with that being said we are focusing on other things at the moment so it will take some time before we get to this.
The code is open source allowing you to make any needed changes and if you figure it out you can make a pull request to the main plugin repo where it will be reviewed and potentially merged.
Cheers.
geseronta Finding out now that the lookup part of the plugin also seems to be having issues for us with 1.17. It no longer finds users when adding new users etc., and we are having to add manually. Would there be a specific log that would be helpful?
When the lookups/type aheads for new user and new agent were not working I found it was due to the password for the search user under the "Connection Information" section of the LDAP plugin settings which needed to be re-entered.
I always needed to re-enter that password after an upgrade from 1.16 to 1.17 if I wanted the information look ups to work again.
Those should generally be separate from the login process but certainly worth getting working again.
It is odd you both seem to have a similar problem which not everyone can replicate. Using email address for the login field seems to work for me but I used the code from davidbuzz in place as well.
Cheers.
Well you have fixed some of my problems! Agents can login to /scp using username or username@domain.com (yay). Users can login to /login.php using username or username@domain.com (double yay!).. The one thing that does NOT work for some reason is Agents cannot login to /login.php to post a ticket from the front end, using either username or username@domain.com.
Are others experiencing that behavior as well? Our agents also sometimes posted tickets for themselves that way when remote, so it used to work.
Thanks for the tip on re-entering the password, I figured since LDAP was working the password was still good in there after an upgrade
Sounds like their backends are not set correctly:
Before running that SQL statement you must ensure you have the appropriate Plugin ID and Plugin Instance ID.
Cheers.
It is good to hear you are having some success.
Agents being unable to login with /login.php was one of the first things we found which was fixed by the change to the backend field.
Perhaps as a workaround you might be able to ask Agents to enter a "\" at the front of their username when they need to use that side of things ? I imagine their use is relatively rare.
8 days later
can we change the login form to ask entering just username instead of email until the email login issue resolves for us? Is there anyway to modify this? Please let me know.
I cannot find it. If you could give me the snap of the page you are talking with the path please?
yes, I saw that but there is nothing mentioned as Email or Username to edit.
The Sign-In Page text can be edited to say what you want as it’s displayed above the Sign-In form.
Other than that you’d have to customize the code.
Cheers.
Looks to be on line 26 of the include/client/login.inc.php file.
Thanks, it worked.
Everyone,
I'm still unable to replicate the issues with lookups and logging in with email address. I use OpenLDAP which may be different than AD. I took a look at Azure and I can't setup AD through there (for various reasons) so I would need to setup an entire windows server specifically for AD which I'm unable to do at this time.
For anyone experiencing lookup issues, please try re-entering the password in the ldap plugin config, save changes, and retest.
For anyone experiencing issues with authenticating with email address, do you allow email as alternate login? I see in Azure AD there is a setting to turn this off and on.
Cheers.
Hello there,
I will present my scenario and solution to the issue in case someone has the same situation as me:
Updated from 1.15 to 1.17-rc3. Neither users nor staff were able to login. Accessing from local admin account I was able to reenable ldap plugin and instance but still, the same issue appeared. I managed to solve it copying the "backend" value from the tables ost_staff and ost_user_account from a backup previous to the update. Value in staff was empty "" and users where "ldap.client". Once done logins were restored.
Note that new users (clients) will be created automatically with backend value "ldap.client.p5i3" which is the "official solution". Applying this value to already existing users didn't work for me.
Hope it helps.
I can confirm LDAP lookup wasn't working after upgrading to osTicket v1.17 from v1.10. So, I downgraded from PHP 8.2 to PHP 8.1 to PHP 8.0 and LDAP lookup finally worked again. I had looked with tcpdump and disabled TLS for LDAP. I could see that the searches actually yielded correct results but they didn't show up in osTicket. There weren't any error messages from osTicket, php or Apache.