Topic: cannot bind to ldap server

[Ghilteras]

hello, I'm trying to use sme server as a ldap server, I need to sync jira, qnap, gmail, svn and pam_nss to use ldap credentials, I can easily populate the tree thanks to the powerful GUI but I have a big problem, anonymous authentication works but I cannot bind as a user, it keeps saying that the credentials are invalid, but only if I try to login from outside the machine, if I do an ldapsearch with a bind username on the local sme everything works. Is there some setting that prevents the authentication for non-local machines? if yes why? most apps need to bind an auth otherwise they won't get the users..

any help would be appreciated

[Daniel B.]

For security reason, LDAP wont accept authentications from the network over an unencrypted connection. You need to either use TLS or SSL on port 636 to be able to bind (or, you can use tunnelling mechanism like ssh or stunnel so the connection will appear to come from localhost and so will be accepted event if LDAP itself is in cleartext).

Regards, Daniel

[Ghilteras]

apantano@apantano-Vostro-3300 ~ $ ldapsearch -x -Z -H ldaps://10.12.4.190/ -b dc=freemind-group,dc=com -D "uid=angelo.pantano,dc=freemind-group,dc=com" -w Eldar@0235 -d1
ldap_url_parse_ext(ldaps://10.12.4.190/)
ldap_create
ldap_url_parse_ext(ldaps://10.12.4.190:636/??base)
ldap_extended_operation_s
ldap_extended_operation
ldap_send_initial_request
ldap_new_connection 1 1 0
ldap_int_open_connection
ldap_connect_to_host: TCP 10.12.4.190:636
ldap_new_socket: 3
ldap_prepare_socket: 3
ldap_connect_to_host: Trying 10.12.4.190:636
ldap_pvt_connect: fd: 3 tm: -1 async: 0
TLS: peer cert untrusted or revoked (0x42)
TLS: can't connect: (unknown error code).
ldap_err2string
ldap_start_tls: Can't contact LDAP server (-1)
   additional info: (unknown error code)
ldap_sasl_bind
ldap_send_initial_request
ldap_send_server_request
ldap_err2string
ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)


should I use a particular certificate?

[Daniel B.]

With only one Z in the option will tell ldapsearch (or any other ldap command) to try to use TLS, but fallback to clear text if it doesn't work. If you want to force TLS, you need to use -ZZ.
And, for this to work, you need to add the certificate of your SME Server in the trust store of the host trying to connect. (the procedure for this will vary depending on the distro)

[Stefano]

[OT] angelo, I guess you are italian, so come to italian forum too, thank you

[CharlieBrady]

TLS: peer cert untrusted or revoked (0x42)
TLS: can't connect: (unknown error code).

http://speeves.erikin.com/2007/01/ldapsearch-tls-and-self-signed.html

[Ghilteras]

[OT] thanks Stefano I'll drop by for sure


[IT] in the end I used TLS_REQCERT never and now I can bind, ldapsearch works now, but not pam_ldap, meaning that if I try to ssh to machine A and A is using sme as ldap server where I created a username it ends up with RESULT tag=97 err=49

i.e.invalid credentials

it's starting to make me feel crazy, with other ldap solutions this pam thing came out so easy, do I need to use a particular client package to achieve ssh through sme ldap (nscd, nslcd)?

[bunkobugsy]

Having the same issues, can confirm that adding to /etc/openldap/ldap.conf "TLS_CACERT /var/service/ldap/ssl/slapd.pem" fixes ldapsearch from localhost.

Also by adding to /etc/openldap/ldap.conf "TLS_REQCERT never" on a remote SME 8.1 server also fixes ldapsearch from that host too (-H ldap://... on 389). I guess that copying slapd.pem over and pointing to it with TLS_CACERT would also work.

However I'm having intermitent failures from osTicket's LDAP auth plugin (using NET_LDAP2.php) running on this second server:

2015-06-21 15:12:03.520518500 conn=7565 op=3 STARTTLS
2015-06-21 15:12:03.520518500 conn=7565 op=3 RESULT oid= err=0 text=
2015-06-21 15:12:03.521617500 TLS: can't accept.
2015-06-21 15:12:03.521618500 TLS: error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 alert unknown ca s3_pkt.c:1092
2015-06-21 15:12:03.521642500 conn=7565 fd=13 closed (TLS negotiation failure)

Am I missing something or these ldap.conf parameters have no effect on mod_php, does the plugin source need LDAPTLS_REQCERT=never added?

Altogether this shouldn't even happen, first server has a valid StartSSL certificate set up, second SME running osTicket has only a self-signed certificate, but that shouldn't matter (TLSVerifyClient=never in slapd.conf).

Did I perhaps bump into this bug https://bugzilla.redhat.com/show_bug.cgi?id=767832 ?
Relevant osTicket LDAP auth fragment is here: https://github.com/osTicket/core-plugins/blob/develop/auth-ldap/authentication.php

Any ideeas are welcome.

[Daniel B.]

Having the same issues, can confirm that adding to /etc/openldap/ldap.conf "TLS_CACERT /var/service/ldap/ssl/slapd.pem" fixes ldapsearch from localhost.

This is not required. Binds from localhost don't require SSL, so there's no need to add this. Just don't enable SSL or TLS in your LDAP client if working over the loopback

Also by adding to /etc/openldap/ldap.conf "TLS_REQCERT never" on a remote SME 8.1 server also fixes ldapsearch from that host too (-H ldap://... on 389). I guess that copying slapd.pem over and pointing to it with TLS_CACERT would also work.

This is very insecure. You should either buy a trusted cert on the server, or add the self signed cert on the client and set TLS_CACERT correctly (or TLS_CACERTDIR)

I have no explantation for an intermittent "unkown CA" error

[bunkobugsy]

Thanks Daniel for your insight. One last question: do these ldap.conf parameters influence at all a ldap bind made from a PHP script?

[Daniel B.]

Yes, but not only PHP (that's why setting TLS_REQCERT never is really a bad idea)

[bunkobugsy]

If ldap is not private access only / all binds are in a lan (w/o eavesdropping).
Will try to look into PHP plugin's sources and maybe find answer there.
Can't explain why PHP sometimes seems to work, but ldapsearch is consistent.
Thanks.

[bunkobugsy]

It can't be this bug, can it? https://bugzilla.redhat.com/show_bug.cgi?id=767832
As far as I see it only affects openldap 2.4.2x but we're only at 2.3.43-28.el5_10