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

    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.

      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.

        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.

          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.

          FYI All, Login through email address has been resolved for us now. We deleted the plugin (not file just deleted from osticket GUI) and reinstalled/reconfigured it. After that we had to update the backend value of staff and users on database per already guided above.

          5 days later

          Like many others, I have AD as an LDAP backend for Agents.

          Upgrade from 1.15.6 to 1.16.3 was smooth. Uploaded the files and the appropriate plugin versions. Logged in as an admin user and the upgrader ran. All Good.

          Upgrade from 1.16.3 to 1.17 did not go so well. Uploaded the files and plugins as appropriate. Tried to login with my admin user and got Access Denied. No agent could login. Therefore the upgrader could not run. The DB was still at v1.16.3 (which turns out to be useful)

          I read through this thread and went looking through the database for agents with the LDAP backend and none showed anything in the backend field of their user record in the database.

          My solution was to:
          Downgrade the /usr/share/osticket back to v1.16.3 and login with my admin account.
          Create an extra admin account with Authentication Backend set to Local Authentication.
          Upgrade /usr/share/osticket to v1.17 again
          Login with the local admin account - this time the login succeeded and the upgrader ran.
          Go to Agents, and select each agent in turn, set their Authentication Backend to Local Authentication and SAVE. Then set it to Active Directory or LDAP and SAVE.
          Logout the local admin account, and login with my normal LDAP admin account.
          All good!

          Looking at the database after performing these steps I can now see that there is a value ldap.p2i4 in the backend field of the database record for each agent.

          Edit:
          Just one further update on this which might also help others.

          Having gotten the LDAP authentication working, agents could still only sign in with their username. Sign in by email address was not working.

          I found the root cause of this problem was not having specified the "Search User" and "Password" in the LDAP Connection configuration. It seems that anonymous binding is enough to find users in AD by username but, it cannot find them by their email address. Using a search user with appropriate access allowed agents to login by email address as well as username.

          8 days later

          Update:

          We found the cause of the issue where the backends aren’t updated for users and agents when upgrading. If you run into this issue it means you didn’t upload the latest LDAP plugin before you upgraded.

          Simple solution, make sure you update all of your plugins before upgrading osTicket.

          Cheers.

          3 months later

          Hi there,
          We are completely new to OSTicket, and I'm trying to do all the configs. When I create the instance for LDAP, it shows 'loading' when I save changes after entering our FQDN, and then crashes.

          All other fields are left blank at the moment, only the FQDN is being entered.

          osTicket Version v1.17.2 (8fbc7ee) — Up to date
          Web Server Software Microsoft-IIS/8.5
          MySQL Version 5.1.73
          PHP Version 8.1.12

          The PHP extension for ldap has also been installed & enabled:

          I feel like I might be missing something potentially obvious, but I don't know what that is.

            UrsulaleRoux

            You'll just have to look at your logs to see why. Could be a fatal error, could be your host rejecting the connection, firewall, DNS issues, etc. Without logs or an error it'd be impossible to tell you what's going on.

            Cheers.

              I am having the same issue, with a brand new/fresh install of OSTicket and the plugin. No errors occur (like 404), it just doesn't auto-complete, like my old install (1.12) does.

              I'm looking in the System Logs in the Admin interface, and see no errors at all for it. In fact, no errors period, because it's not in production yet. I can log into SCP just fine, test users can log in just fine on the end-user page. It's just when I go to create a new ticket, and attempt to add user for ticket creation.

                KevinTheJedi

                Hey KevinTheJedi, thank you. Is there a manual way to do it though? I'm not really hip to GIT just yet, though I suppose it'd be good to learn.

                    eddiebgood

                    Yes, open the files in a text editor or more preferably a code editor and make the changes manually. For the plugin changes you’ll have to unpack the plugin, make the changes manually, and repackage the plugin. There are other posts and guides online that explain how to do this in PHP. There are even websites that can unpack and repackage it for you.

                    Cheers.

                      eddiebgood

                      You can also unpack the plugin, make the changes, and leave it unpacked but it requires you to make changes in the database. If you are SQL savvy once the plugin is unpacked you can go to the database, go to the plugin table, remove the .phar from the install_path value for the LDAP plugin, set the isphar value to 0, and the plugin will work as a folder instead of a PHAR file.

                      Cheers.