-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of Craig White Sent: Monday, February 22, 2010 12:23 AM To: CentOS mailing list Subject: Re: [CentOS] LDAP Server Access Problem

On Sun, 2010-02-21 at 22:48 -0700, Paul R. Ganci wrote:

...

Hi All,

I am at my wits end. I have a LDAP server setup on a machine (the names are changed to protect the innocent) example.mydomain.com running CentOS 5.4 and LDAP version 2.3.43-3. If I issue a ldapsearch command while logged onto the LDAP server host I get a valid response back. For example:

...

ldapsearch -x -LLL -H ldaps://example.mydomain.com:636 "(uid=joker)" \ sn uid

dn: uid=joker,ou=People,dc=mydomain,dc=com uid: joker sn: Nicholson

Everything works as expected. However if I try the same command from a remote machine remote.mydomain.com the command just hangs. I can not find a log entry anywhere that indicates something is wrong. I have checked the obvious things I can check. For example I know that port 636 is open:

...

/etc/rc.d/init.d/iptables status | grep 636

110 ACCEPT tcp -- 0.0.0.0/0 208.139.195.124 state NEW,ESTABLISHED tcp dpt:636 111 ACCEPT udp -- 0.0.0.0/0 208.139.195.124 state NEW,ESTABLISHED udp dpt:636

I have enabled access via /etc/hosts.allow:

...

cat /etc/hosts.allow | grep slapd

slapd: ALL

I can see the server running and listening on port 636:

...

netstat -l | grep ldaps

tcp 0 0 *:ldaps *:* LISTEN tcp 0 0 *:ldaps *:* LISTEN

...

ps auxww | grep slapd

ldap 21865 0.0 0.2 467976 5860 ? Ssl 19:54 0:02 /usr/sbin/slapd -h ldap:/// ldaps:/// -u ldap

I am missing something very obvious. Can anyone offer any clues? Thanks.

---

ldap ssl is deprecated but should actually still work.

Do you actually have to specify the port number? I don't think so...

-H ldaps://example.mydomain.com should be sufficient

The preferred method is TLS (via standard -h ldap://example.mydomain.com uri notation)

Note that ldap 'client' applications like ldapsearch use /etc/openldap/ldap.conf so I would suspect that the 'certificates' used by the 2 machines are different.

add -d 256 (or even higher debug level) to the ldapsearch command for debugging - I'm not going to hazard any actual guesses.

Craig

-- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.

---

CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos

-----------------------

I can confirm that indeed ldaps still works fine as I recently implemented such a setup on my network a few months ago (OpenLDAP). Make sure the clocks on both machines are in sync as that will cause problems with the certs for example if cert was generated "in the future". Also, what was your process in creating certificates for your LDAP infrastructure?

Paul R. Ganci wrote:

...

...

Note that ldap 'client' applications like ldapsearch use /etc/openldap/ldap.conf so I would suspect that the 'certificates' used by the 2 machines are different.

This might be the missing piece.

The certificates were generated from a signing request to CAcert. However, while the certificate is installed on the server machine it is not installed on the remote machine. I didn't think that was necessary especially given that the certificate was generated explicitly for example.mydomain.com. I can try this.

I do know that the CAcert root certificate is not accepted by LDAP as coming from a valid certificate root authority. I manage to get around this by explicitly adding CAcert's root certificate to /etc/pki/tls/certs/ca-bundle.crt and adding that path to the /etc/openldap/ldap.conf config. I will try installing the certificate and then adding the path in /etc/openldap/ldap.conf. I probably should have shown the /etc/openldap/ldap.conf file. For the record here it is:

HOST example.mydomain.com BASE dc=mydomain,dc=com URI ldaps://example.mydomain.com:636/ tls_cacertfile /etc/pki/tls/certs/ca-bundle.crt TLS_CACERTDIR /etc/openldap/cacerts

Have to go to work now so will try later. Thanks.

...

...

add -d 256 (or even higher debug level) to the ldapsearch command for debugging - I'm not going to hazard any actual guesses.

Thanks for this suggestion ... should have thought of it myself.

It occurs to me that you can turn off certificate validation by setting the TLS_REQCERT entry in either /etc/openldap/ldap.conf or ${HOME}/.ldaprc. Here's part of my .ldaprc:

TLS_CACERT /etc/pki/tls/certs/ca-bundle.crt TLS_REQCERT never

If you run ldapsearch in with "-d 1" you will see that it is indeed using the server's certificate but is not checking it for validity. I usually use this for testing purposes.

Also, you generally don't want to use both HOST and URI at the same time. It can sometimes confuse issues.

-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of Craig White Sent: Monday, February 22, 2010 6:25 PM To: CentOS mailing list Subject: Re: [CentOS] LDAP Server Access Problem

On Mon, 2010-02-22 at 07:47 -0600, Dan Burkland wrote:

...

I can confirm that indeed ldaps still works fine as I recently

implemented such a setup on my network a few months ago (OpenLDAP).

doing a new setup using methodologies that have already been tagged as deprecated seems to be a really bad idea. Even though it currently works, you can be certain that at some point down the road, it will cease to work... that is what deprecated means.

Craig

-- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.

---

CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos

I am well aware of that, it was my first OpenLDAP setup :) Hopefully sooner rather than later I'll be able to migrate my systems to use TLS over 389 instead of SSL over 636.

On Sun, 2010-02-21 at 23:23 -0700, Craig White wrote:

Note that ldap 'client' applications like ldapsearch use /etc/openldap/ldap.conf so I would suspect that the 'certificates' used by the 2 machines are different.

I thought I would follow up on this problem. I did finally get the ldapsearch to function properly on the remote machine. However, I am puzzled as to what I had to do to get it to work. I originally never setup a certificate for the client as I did not think they were needed. In my /etc/openldap/slapd.conf file I had to set up the LDAP server with the following:

TLSVerifyClient never

I had the initial setup with

TLSVerifyClient allow

According to man slapd.conf:

TLSVerifyClient <level> Specifies what checks to perform on client certificates in an incoming TLS session, if any. The <level> can be specified as one of the following keywords:

never This is the default. slapd will not ask the client for a certificate.

allow The client certificate is requested. If no certificate is provided, the session proceeds normally. If a bad certificate is provided, it will be ignored and the session proceeds normally.

try The client certificate is requested. If no certificate is provided, the session proceeds normally. If a bad certificate is provided, the session is immediately terminated.

demand | hard | true These keywords are all equivalent, for compatibility reasons. The client certificate is requested. If no certificate is provided, or a bad certificate is provided, the session is immediately terminated.

Note that a valid client certificate is required in order to use the SASL EXTERNAL authentication mechanism with a TLS session. As such, a non-default TLSVerifyClient setting must be chosen to enable SASL EXTERNAL authentication.

Note that according to the documentation the original setup should have worked properly. Why doesn't "allow" work?

On Sun, 2010-02-28 at 11:22 -0700, Craig White wrote:

---

do you mean other than the fact that this simply talks about TLS Client and that SSL is deprecated and generally ignored in the documentation?

SSL communication is different than TLS.

With all due respect deprecated doesn't mean broken. While SSL is different than TLS using "TLSVerifyClient allow" works on the server. For that matter so does "TLSVerifyClient demand". In fact if I use the latter configuration and do not provide a client certificate ldap_bind fails as expected. From what I can tell the server certificate is never passed to the client unless "TLSVerifyClient never" as seen from:

ldapsearch -d 1 -x -LLL -H ldaps://incoming.mric.net:636

"(uid=acaplan)" sn uid ldap_create ldap_url_parse_ext(ldaps://incoming.mric.net:636) ldap_bind ldap_simple_bind ldap_sasl_bind ldap_send_initial_request ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP incoming.mric.net:636 ldap_new_socket: 3 ldap_prepare_socket: 3 ldap_connect_to_host: Trying 208.139.195.124:636 ldap_connect_timeout: fd: 3 tm: -1 async: 0 TLS trace: SSL_connect:before/connect initialization TLS trace: SSL_connect:SSLv2/v3 write client hello A TLS trace: SSL_connect:SSLv3 read server hello A TLS certificate verification: depth: 1, err: 0, subject: /O=Root CA/OU=http://www.cacert.org/CN=CA Cert Signing Authority/emailAddress=support@cacert.org, issuer: /O=Root CA/OU=http://www.cacert.org/CN=CA Cert Signing Authority/emailAddress=support@cacert.org TLS certificate verification: depth: 0, err: 0, subject: /CN=incoming.mric.net, issuer: /O=Root CA/OU=http://www.cacert.org/CN=CA Cert Signing Authority/emailAddress=support@cacert.org TLS trace: SSL_connect:SSLv3 read server certificate A

The client requests hangs because the LDAP server is not providing its certificate. I just found it strange that the communication process works fine as long as all the communication occurs on the server. I find it even stranger that the failure mode seems to be that the LDAP server doesn't pass its certificate to the client ... that seems really broke to me whether or not SSL is deprecated.

In any event this is all moot because I am in the process of switching over to TLS.

Thanks to everyone who helped sort this issue.