For clarification, when you say users we are including agents? And since the TLS tick box is just located in the LDAP section, when connecting to the server, is that just an LDAP server if you define one? If I don't define the LDAP does it use TLS for the AD as well?

LDAP.JPG

Q: For clarification, when you say users we are including agents? A: Well when said Users I meant users (which was short sighted)... but yes in this case it would also include Agents.  So in this case I mean "authentication attempts by Users or Agents" depending on which groups you have the plugin configured to allow.AD is essentially Microsoft's proprietary LDAP implementation.  I would assume that you would put your AD server in the field (we do and use the FQDN for the server). Then that is the server it would use TLS to connect to.

Didn't mean to split hairs on the "users" but I know often times when we are talking about osTicket, there is a difference between Users and Agents, and since you can configure the plugin for both Users and/or Agents, I just wanted to make sure I was understanding :-)Thanks always @[deleted]We will try putting our AD server in there. I know currently we have a separate LDAP server on our network as well, but as I said it will be going away soon so I didn't want to get tied to that only to have it leave.

5 days later

The plugin doesn't seem to work with ldaps on port 636. The checkbox is for the STARTTLS feature, which works on 389 and issues a STARTTLS command after connection. To use straight TLS on port 636 would require changes to the plugin code.   

http://php.net/manual/en/function.ldap-start-tls.phpFirst comment, 12 years ago:"Please note there is a difference between ldaps and start-TLS for ldap.  start-TLS uses port 389, while ldaps uses port 636.  ldaps has been deprecated in favour of start-TLS for ldap.  Both encrypted (start-TLS ldap)  and unencrypted ldap (ldap) run on port 389 concurrently.Errors encountered are generally due to misunderstanding how to implement TLS-encrypted ldap."apparently straight TLS on port 636 was depreciated... like 12 years ago.

We did a test using the domain for the ldap server, and have not gotten any nasty notes from anyone yet about sending unencrypted credentials. But we just did it yesterday afternoon so perhaps there's still time...It doesn't matter to me on which port, or which protocol is used really as long as the authentication is encrypted lol

its possible that jared hit the "PHP Warning:  ldap_start_tls(): Unable to start TLS: Connect error in" issue and decided to handle it later.  I have a plugin I've been working on that his his this wall.  And from what I can tell it requires you to download a cert and put it on the server.  (same url I sent you posts 2 (linux) and 3 (windows) and or create a config file with TLS_REQCERT never.

Populating the LDAP server information with our domain, and checking the Use TLS checkbox seems to have worked. Our Networking Nazis checked their logs and there was no indication that my credentials were sent unencrypted this time. You all can stop searching the deep web for my password now....

I stopped searching a while ago... once I foun.... errr I mean.  Carry on. Nothing to see here. :)

LDAPS is deprecated in OpenLDAP, as it has no formal standard, but it is fully supported in Active Directory, and it may be required in some environments, specifically because of this potential issue, that nothing in basic LDAP prevents clients from authenticating unencrypted.

2 years later

I believe that your correct.

Write a Reply...