I have osTicket 1.14.2 running on an external website, outside of our domain, and am trying (like many before me) to authenticate via LDAP to our in-house Active Directory.

This is the config of my osTicket server:

And this is my LDAP plugin page:

I am vaguely aware that the php version might be an issue, but I have tried setting the server to differing versions from 5.4 upwards, same effect, Bind failed.

I have tested using the utility LDAP Admin from my home PC, that my username and password are correct, it fails if I try to use SSL or TLS as the server in question doesn't have an external SSL certificate configured in Certificates - Service (Active Directory Domain Services), so prompts with an unverified certificate error, so I understand that's not going to work, but accessing non-secure port 389 authenticates from my home machine fine.

If I remove the .phar plugin and use the auth-ldap/ files from Github, I get a server error 500 when I try to submit my settings. edit apparently I needed the include folder for LDAP2 stuff from the existing .phar to fix that, but the version from github is 0.6.2 compared to 0.6.3 from the osTicket download, so presumably is out of date anyway.

Is the web server inside your network (with the AD server)?
You might want to try specifying a DNS server.
Have you tried using the IP of the AD server?
Are you running anything like mod_security or SELinux on the webserver? I ask because the unable to bind makes me think that perhaps you "can't get there from here". Or that the server rejected it. I have osTicket auth-ing against my internal AD server and it requires TLS. So I'm a little surprised that yours doesn't require it also.

    It's an external website, not on-premises, in theory connecting to on-premises AD, I have a ticket raised with the host to see if there's anything there side blocking outbound LDAP, because even simple PHP test scripts are failing too, so I'm more inclined to believe it's an issue host-side, rather than internally.

    ntozier Thank you, apparently it was a firewall at the webhost side that was preventing it, it now gets past that part, and I get the blessed "LDAP configuration updated successfully", but I still can't log users on, does the "search base" search in OU's below it, if I specify the FQDN ?
    e.g. If the Search base is "DC=microsoft,DC=com" would it find a user in "OU=company1,DC=microsoft,DC=com" ?

    I have added a new user, and he's listed as Active (Registered), and I can log in as him if I drop the @mydomain.local as his username, but it's not working for existing users that were registered when osTicket was hosted on-premises.

      Hmm, apparently, I shouldn't have had user@mydomain.local in the username field, just user, it now logs in as that user, but I have lots and lots of users to edit now 🙁
      Is there a quick way of removing everyone's username from that field ?

      Write a Reply...