ldap not enter whit user : Page 3

ldap not enter whit user

KevinTheJedi

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.

geseronta

KevinTheJedi

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

abeermuh

but that is working fine on live environment on OS Ticket older version - means everything is fine from AD and mail attribute side.

KevinTheJedi

geseronta

Not saying it did just saying to confirm that it’s still returning the appropriate attributes.

Cheers.

geseronta

KevinTheJedi

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?

KevinTheJedi

geseronta

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.

pcjkollmorgen

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.

geseronta

pcjkollmorgen

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

KevinTheJedi

geseronta

Sounds like their backends are not set correctly:

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

Before running that SQL statement you must ensure you have the appropriate Plugin ID and Plugin Instance ID.

Cheers.

pcjkollmorgen

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.

abeermuh

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.

KevinTheJedi

abeermuh

Look at your user pages. There you will be able to edit the page text.

Cheers.

abeermuh

I cannot find it. If you could give me the snap of the page you are talking with the path please?

KevinTheJedi

abeermuh

yes, I saw that but there is nothing mentioned as Email or Username to edit.

KevinTheJedi

abeermuh

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.

pcjkollmorgen

Looks to be on line 26 of the include/client/login.inc.php file.

https://github.com/osTicket/osTicket/blob/cb6766e5e4cdb82bb5e7d7671d41b0a476f61e0a/include/client/login.inc.php#L26

abeermuh

Thanks, it worked.

KevinTheJedi

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.

eratia

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.

eratia

eratia It sopped working after installing theme osticketawesome. Had to "empty" staff's backend value again and update users's to "ldap.client.p5i3". Now it works again.

« Previous Page Next Page »