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.

                      romeopavel
                      Have you checked that the users are named consistently in Active directory/ LDAP ? It could be that although the usernames (eg samID) is created consistently the user container is not names consistently so when looking for a properties of a container based on username its not finding a match, eg the samid (username) is <firstname><dot><surname> in all cases but the container name is sometimes <firstname><dot><surname> and sometimes set to match full name ie <firsname><space><surname>

                        4 days later

                        pcjkollmorgen
                        We are experiencing the same issue. User details not filled in when selecting a user that is not already in the database.
                        You say that there are some things that van be checked. Can you elaborate? Als you suggest code changes could help. Could you share them?

                        Thanks

                            Duggler

                            You will need to check your logs to see if the URL is being blocked, etc. In another post they said their IIS server was rejecting certain URLs with special characters in it. They had to allow the special character and it started working.

                            Cheers.

                              Duggler
                              Have you checked your /etc/apache2/apache2.conf
                              Are these settings changed from AllowOverride none to AllowOverride all

                              <Directory /var/www/>
                              Options Indexes FollowSymLinks
                              AllowOverride all
                              Require all granted
                              </Directory>