KevinTheJedi
Thanks for the reply.
Unfortunately I am not that knowledgeable in PHP, so I am not sure what would be the best course of action. Maybe you can give me another hint?
Like I said, the same action done for agents is successfull, so I don't think there is a general issue on my web server.
This seems to be an issue for quite a long time, not sure if it's still an active bug or something..
Regards,
Romeo
Maybe this will help?
Cheers.
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 ?
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.
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!
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.
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.
I am having EXACTLY the same issue...
Also tried
KevinTheJedi fix
but no luck...
Failed to load resource: the server responded with a status of 404 (Not Found)
http://192.168.0.133/osTicket/scp/ajax.php/users/select/auth%3Aldap%3ACN%3D****%20*****%2CCN%3DUsers%2CDC%3D****%2CDC%3D****
Decoded:
http://192.168.0.133/osTicket/scp/ajax.php/users/select/auth:ldap:CN=### ###,CN=Users,DC=###,DC=loc
Maybe this helps?
Cheers.
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
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...
@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.
That has already been explained in another post. Essentially, if you didn't install the latest LDAP plugin before upgrading to 1.17.x then the backends for users and agents didn't get updated properly. To rectify this you can run queries in the database to fix the incorrect backends. Please look at the below post:
Cheers.
