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>

                      MarkMansveld

                      Sure, but before I share the code somewhere, can you first confirmed you have fixed up the backend values ?

                      As per from Kevin here:
                      https://forum.osticket.com/d/101553-ldap-not-enter-whit-user/15

                      Find a working user (usually a newly added user) and copy their backend value (eg. ldap.client.p123i123). Then you need to run a query like:

                      UPDATE ost_user_account SET backend = 'ldap.client.p123i123' WHERE backend = 'ldap.client';

                      For agents do the same thing but the query will look like:

                      UPDATE ost_staff SET backend = 'ldap.p123i123' WHERE backend = 'ldap';

                      The only thing I can think of current is that it actually uses the staff LDAP backend value when it does the user search and again at the form loading time.

                      The code we implemented cheats a little in that it relaxes the requirement on the backend value. This could be a problem if we had multiple instances of the LDAP plugin however this seems like a relatively unlikely scenario.

                        2 months later

                        I was having exactly the same problem after updating to the latest osTicket version and LDAP plugin and I found where the problem was.

                        In the file: ajax.users.php, inside the function

                        function addRemoteUser($bk, $id) {
$bk was "ldap" instead of "ldap.p33i11" (in my case)
If I just add $bk="ldap.p33i11"; it works fine.

                        I don't know where it gets the "ldap" from, all the users and staff have the correct .p33i11 (in my case). I even created a database dump to look for "ldap" or 'ldap' and I didn't find any results.

                        I would like to solve it in a proper way. It only happens with remote users.

                        Edit:

                        I think here is where the problem starts, inside the file authentication.php of the auth-ldap plugin:

                        class StaffLDAPAuthentication extends StaffAuthenticationBackend
        implements AuthDirectorySearch {

    static $name = /* trans */ "Active Directory or LDAP";
   static $id = "ldap";          <------------------------

                        Edit2:

                        I know where the strange .p33i11 comes from, is .p<plugin_id>i<instance_id>

                        I think the main problem is the auth-ldap plugin hasn't been updated to support plugin instances. ;-)

                          Write a Reply...