I'm trying search my company's AD with ldapsearch. However I always get the error:

ldap_bind: Strong(er) authentication required (8)
        additional info: BindSimple: Transport encryption required.

I tried to use LDAPS in every combination possible, but I can't seem to be able to connect to the server in any other way than just LDAP on the default port.
Weirdly enough I have no issues whatsoever using Active Directory Explorer.

I was thinking that it could be that the firewall isn't configured correctly and blocking the LDAPS (636) Port, but that wouldn't explain Active Directory Explorer working...

Also GitLab seems to be able to connect to it just fine too. Except that it won't authenticate. But that's what I'm trying to debug with ldapsearch too.

That's the command I'm using:

ldapsearch -D "cn=myuser,cn=Users,dc=company,dc=local" -w "<password>" \
    -p 389 -h \
    -b "cn=Users,dc=company,dc=local"

The server is correct, so is the bind_dn (according to Active Directory Explorer) and the corresponding password, I tried using upper an lowercase for the stuff like cn, I tried all possible configurations of using LDAPS (like -H ldaps://, -H ldaps://, -H ldaps:// and the flag -x, so I'm really running out of ideas.

If it's relevant, the AD server is the Active Directory Server on Synology/DSM, which is a linux SAMBA server under the hood.

Any help is greatly apprechiated.


Looks like adding -Y NTLM gets me further.

Now I get:

SASL/NTLM authentication started
ldap_sasl_interactive_bind_s: Invalid credentials (49)
        additional info: SASL:[NTLM]: NT_STATUS_OBJECT_NAME_NOT_FOUND

which is weird, as I know the password is correct.


Now using -Y GSSAPI creates this rather nothing saying error:

SASL/GSSAPI authentication started
ldap_sasl_interactive_bind_s: Local error (-2)
        additional info: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure.  Minor code may provide more information (No Kerberos credentials available (default cache: FILE:/tmp/krb5cc_0))


The parameter -ZZ (-Z too) ends with this error:

ldap_start_tls: Connect error (-11)
        additional info: The TLS connection was non-properly terminated.

Are you sure TLS is even configured in your Active Directory deployment? It is not by default.

Anyhow using LDAPS (default port 636):

ldapsearch -H ldaps://

Using LDAP and enforce StartTLS extended operation to succeed (default port 389):

ldapsearch -H ldap:// -ZZ

Note that OpenLDAP's client utils perform strict TLS hostname check. Therefore the server certificate must contain the DNS name or IP address used with -H in the cert's subjectAltName or CN attribute.

If you want to use SASL with GSSAPI/Kerberos you have to obtain a Kerberos ticket-granting ticket before with kinit.

  • I’m certainly not using LDAPS. I’ve also tried it with the H parameter as you showed it in your second example. That leads me to the same error messages as before. – BrainStone Sep 25 '18 at 13:19
  • You mentioned port 636 which is the default port for LDAPS. Anyhow, did you try to use StartTLS ext.op. instead like described in my 2nd example? – Michael Ströder Sep 25 '18 at 13:22
  • My apologies. On mobile the last parameter was cut off. I will try that. – BrainStone Sep 25 '18 at 13:27
  • Sorry for the late response. I was not at work and unable to test it. Adding the -ZZ parameter yields: The TLS connection was non-properly terminated.. I've added the full error as Edit 3 in the original post. – BrainStone Oct 1 '18 at 10:15
  • I repeat the first sentence of my answer: Are you sure TLS is even configured in your Active Directory deployment? It is not by default. – Michael Ströder Oct 1 '18 at 10:52

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.