Yes, I did that but that only working for agents but not staff - As I mentioned above, even the new user is not able to signin to create a ticket. It shows blank screen after entering LDAP credentials .

    While trying on different browser, it is showing me this error.

    pcjkollmorgen

    username First Last ldap.p1i3 username@domain.net

    The above person is in osticket.ost_staff and can login as an agent using 'username', but NOT 'username@domain.net'. All agents are setup with ldap.p1i3 backend.

    All of the users in osticket.ost_user_account have the backend set to ldap.client

    Brand new non registered users cannot sign into the client new ticket portal either, so I don't have any working user_account references to look at. (PLus the problem of email address login's not working too). Any suggestions?

    Edit - looks like abeermuh has the same issues that I do, so we are not alone at least!

      It has been resolved - this time I used Php8.0 - previously it was 8.1 on which it was not working.

      furthermore, I did not need to run mysql query to set backend for all users, it worked on its own by default.

      I rolled back to PHP 8.0.24 after reading the above. Partially fixed, now users can login with their username (but NOT email address). Both agents and users still must use username instead of email address or UPN of username@domain.com. With email it throws access denied. Sigh. This is quite an ordeal!

      abeermuh

      A blank screen indicates that there is a PHP error.
      You will want to take a look at the PHP error logs to see what the logged error is.

      I see that after posting that you resolved this by changing to PHP 8.0.
      I haven't tried 8.1 with 1.17 yet.

        I rolled back to PHP 8.0.24 after reading the above. Partially fixed, now users can login with their username (but NOT email address). Both agents and users still must use username instead of email address or UPN of username@domain.com. With email it throws access denied. Sigh. This is quite an ordeal!

        Yes!!! Same issue for me. Do we have any solution on that?

          abeermuh

          Nothing yet - I have another thread open with the email/username issue. I did update the LDAP plugin during the upgrade process. We have people really trained on entering username@domain.com (for things like SSO/365 logins), so this is quite problematic for us.

            yeah, sadly but same issue for me. 🙁 I hope someone can find a solution of it ASAP.

            @abeermuh @geseronta

            And you are both confident the ost_user_account is showing the correct backend value for both older users and user accounts which have never used your osTicket before and have logged in successfully using the username ?

            I would be watching this table carefully using phpmyadmin or similar and seeing if there is anything different happening between these use cases, and also perhaps seeing if you change the username value if that helps or not.

            You could also try davidbuzz's code above to allow the auth process to attempt different backends even if the naming isn't precise.

            Finally, you may also want to consider the third party paid for SAML plugin mentioned here: https://forum.osticket.com/d/93267-sso-saml-plugin-for-osticket-compatible-with-1-9-x-and-1-10-x/21

              Yes, I have verified the backend is same for both users. Even newly logged in user also not able to login via email address.

              Sorry , the backend is with different value but the newly logged in user also not able to login via email that is why I am not changing the backend value for all until it resolves the issue for newly created users.

              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.

              geseronta

              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.

                    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

                          geseronta

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

                          Cheers.

                              KevinTheJedi

                              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?