just in case, I have also tried by updating the backend for all users with the same value of newly created users, but same error.
ldap not enter whit user
pcjkollmorgen Yes the back end is the same in our case, and not even brand new users can login via email address
We expect the email address to be passed in the mail attribute so if email isn't working I'd investigate your AD connection, setup, etc. to confirm the user's email address is being passed through the mail attribute from AD.
Cheers.
but that is working fine on live environment on OS Ticket older version - means everything is fine from AD and mail attribute side.
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
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.