KevinTheJedi
Sorry, still no luck.
I am not having any issues with logins, LDAP and SSO works as expected. Only lookup/type ahead seems to be broken. Tried to re-add the password for the LDAP bind account, still no change.
I decoded the ahaj.php url and it matches the AD distinguishedName field perfectly.
Maybe create an issue on Github ? Would I have better luck there ?

      romeopavel

      You can but it’ll be the same as here with much less responses. Others (including me) have lookup working so something appears to be going on here.

      We have LDAP issues on our todo list but so far I cannot replicate this.

      Cheers.

        5 days later

        Experiencing these same issue here.

        LDAP is able to query and find the user in Active Directory, but cannot generate any of the prefill information. I am seeing the 'same' 404 error in the console in developer mode when clicking the user to generate the prefill.

        It appears to have stopped working for us between October 14th and October 18th. (Osticket upgrade in August, 20 new hires since. 17 of those new hires are prefilling fine, the last 3 since October 18th do not prefill, assuming my help desk hasn't been manually entering the data? 🙃)

        When I initially looked it wasn't even grabbing the remote info (It couldn't find the user). I disabled the plugin, reinstalled, and made a new instance. Now it is finding users, but no prefill.

        @romeopavel - If you happened to have found your resolution it would be greatly appreciated if you could share here. Thank you!

        Otherwise, i'll keep poking around and will post here with my results if I get them. Thanks!

          secretbarker

          404 means not found. Maybe you are having URL rewriting issues or something similar? What specific URL gives you 404?

          Cheers.

            The 404 appears in the console window once you click the user that shows in the lookup window for a user. Osticket never indicates on the 'front-end' that anything is wrong, other than it's not populating the data from Active Directory.

            It only 404's when the user's name lookup has (remote) after it. I'm assuming anything that isn't (remote) is already in the osticket DB. Those users populate fine.

              secretbarker

              Okay I think a pull I made today may resolve this. From your screenshots it appears your URLs are being encoded by your webserver (which is quickly becoming the new norm and good practice) so it’s not matching appropriately. Our regex matching patterns are quite strict and unforgiving. TLDR; when URLs are encoded we don’t decode them properly which fails to match our regex patterns.

              Apply the following patch and see if that helps:

              Cheers.

                  Thanks for the follow-up. Unfortunately, no luck here.

                  New image shows the change to the dispatcher file, and has the full Request URL from the network headers. The console window was truncating the full URL I believe. Let me know if there's anything I can do to assist with troubleshooting. Thank you! Decoding the URL I feel that the path is correct.

                    I did a fresh install yesterday and pulled the 0.6.2 Version from osticket's download page.

                      Nope, but thanks for trying to help...
                      Just to mention, my AD user names are not in the format which used to make problems for some users couple of years ago (Last, First), but in "normal" First Last

                        smfilip

                        Well you are getting URL Not Found which means either rewrite isn’t working properly or like the above post your server is rejecting such URLs with special characters in it.

                        Cheers.

                          I don't know, I use at least 5 other tools that rely on AD reading capability, and all work properly...
                          Never mind, I have spent too much time trying to fix this, I have tried all known patches from a couple of years ago, which means that I am not the only one with the problem, and it never got sorted out properly...
                          I am moving tonight to Zammad, but I hope it will get fixed someday because osticket is a great tool...

                          20 days later

                          @KevinTheJedi I'm now a little more aware of this issue when an LDAP user (remote) is found but clicking on them does not load their details into the new user form.

                          I'm not across all the details but it was explained to me that this is a similar problem to the one which was blocking user logins due to incorrect backend name.

                          More specifically the function getSearchDirectoryBackend in include/class.auth.php has troubles with the 'ldap' vs eg 'ldap.p13i12'

                          Apologies if this isn't very clear.

                            Yes, that is possible as we had already worked around this with a code fix but it is interesting other people are still having the problem.

                            You would have to think they also cannot have users logging in if they haven't fixed up those backend values too.

                            I'm not sure how to wrap my head around the idea that a new user who never had a backend value ever is then having an issue when their details are being loaded to a form but certainly this does all look related.

                            Oh well, if anyone is still having problems with this there are a few things which can be checked for it.