It looks like the Certificates are not working.
So using the following document http://www.openldap.org/pub/ksoper/OpenLDAP_TLS.html

I have re-create a CA and Public / Private Keys

/etc/openldap/slapd.conf has the following
TLSCipherSuite HIGH:MEDIUM:+SSLv2
TLSCACertificateFile /etc/openldap/cacert.pem
TLSCertificateFile /etc/openldap/servercrt.pem
TLSCertificateKeyFile /etc/openldap/serverkey.pem
TLSVerifyClient demand

When I run the ldap Server in debug mode
/usr/sbin/slapd -d9 -h "ldap:/// ldaps:///"

TLS trace: SSL3 alert read:fatal:unknown CA
TLS trace: SSL_accept:failed in SSLv3 read client certificate A
TLS: can't accept.
TLS: error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 alert unknown ca s3_pkt.c:1053
connection_read(14): TLS accept failure error=-1 id=2, closing

From a new Xterm
openssl s_client -connect localhost:636 -showcerts -state -CAfile /etc/openldap/cacert.pem

CONNECTED(00000003)
SSL_connect:before/connect initialization
SSL_connect:SSLv2/v3 write client hello A
SSL_connect:SSLv3 read server hello A
depth=1 /C=GB/ST=Aberdeen/L=Aberdeen/O=Total/OU=IS/CN=starsky.uk.ad.ep.corp.local
verify return:1
depth=0 /C=GB/ST=Aberdeen/L=Aberdeen/O=Total EP/OU=IS/CN=starsky.uk.ad.ep.corp.local/emailAddress=ldap@starsky.uk.ad.ep.corp.local
verify return:1
SSL_connect:SSLv3 read server certificate A
SSL_connect:SSLv3 read server certificate request A
SSL_connect:SSLv3 read server done A
SSL_connect:SSLv3 write client certificate A
SSL_connect:SSLv3 write client key exchange A
SSL_connect:SSLv3 write change cipher spec A
SSL_connect:SSLv3 write finished A
SSL_connect:SSLv3 flush data
SSL3 alert read:fatal:handshake failure
SSL_connect:failed in SSLv3 read finished A
30008:error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure:s3_pkt.c:1053:SSL alert number 40
30008:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:s23_lib.c:188:

Looks like something is slightly broken on the RedHat 5.3 Server

I had big problems on trying to generate the CA on the server so did it on a RedHat 4.7 Workstation.

 Matt


Buchan Milne <bgmilne@staff.telkomsa.net> wrote on 06/04/2009 10:56:55:

>
> Of course, whether an anonymous bind works or not has nothing to do with how
> much data you are exposing to anonymous binds ...
>
> > I would like to try and disable Simple Binding
>
> What are you trying to achieve? Protect data from anonymous access?
> Or protect
> passwords used in simple binds? Or, protect the data from "sniffing" ?
>

Protect the data from anonymous access and from "Sniffing"

> > But if I select "disallow bind_anon" in slapd.conf file
> > Things start to break like authentication stops working.
> > /var/log/messages
> >
> > Apr  1 15:42:15 apricot sudo[31515]: pam_ldap: error trying to bind
> > (Inappropriate authentication)
> > Apr  1 15:42:18 apricot sudo[31515]: pam_ldap: error trying to bind
> > (Inappropriate authentication)
> > Apr  1 15:42:25 apricot sudo[31515]: pam_ldap: ldap_result Can't contact
> > LDAP server
> >
> > How do I get a Machine to authenticate to Ldap ?
>
> Well, the first question is, why are you using LDAP for authentication if you
> have Kerberos? You have pam_krb5, so why are you bothering with pam_ldap?
>
> > I think the problem lies with nss_ldap ?
>
> With the evicnce you have provided thus far, it's not easy to tell. For
> example, does 'getent passwd user_in_ldap' work? As non-root? As root?
>
> With your /etc/ldap.conf below, you have configured nss_ldap to bind
> anonymously. To bind it non-anonymous, you should add 'binddn', and 'bindpw'
> to /etc/ldap.conf, or rootbinddn to /etc/ldap.conf, and put the password in
> /etc/ldap.secret, see 'man nss_ldap'.
>
> > When I add the following line to /etc/ldap.conf
> >
> > ssl start_tls
>
> Did you setup SSL correctly on the server side?
>
> Have you tested START_TLS with an OpenLDAP client?
>
> > I start to get the following error's
> > Apr  2 14:09:11 bruce vmware-guestd: nss_ldap: reconnecting to LDAP server
> > (sleeping 4 seconds)...
> > Apr  2 14:09:15 bruce vmware-guestd: nss_ldap: reconnecting to LDAP server
> > (sleeping 8 seconds)...
> > Apr  2 14:09:18 bruce nscd: nss_ldap: reconnecting to LDAP server
> > (sleeping 16 seconds)...
> > Apr  2 14:27:06 bruce sshd: pam_ldap: ldap_starttls_s: Operations error
> > Apr  2 14:27:06 bruce sshd(pam_unix)[11233]: authentication failure;
> > logname= uid=0 euid=0 tty=ssh ruser= rhost=apricot.uk.ad.ep.corp.local
> > user=mgarrett
> > Apr  2 14:27:06 bruce sshd[11233]: pam_krb5[11233]: authentication
> > succeeds for'mgarrett' (mgarrett@UK.AD.EP.CORP.LOCAL)
>
> So, pam_krb5 works ...
>
> > /etc/ldap.conf
> >
> > base dc=unix,dc=total
> > bind_timelimit 120
>
> ^^ Too much IMHO, if anything goes wrong, there's no way you'll log in ...
>
> > idle_timelimit 3600
> > ldap_version 3
> > pam_password md5
> > scope sub
> > ssl start_tls
> > timelimit 120
> > tls_cacertdir /etc/openldap/cacerts
>
> Does the CA cert that signed the /etc/openldap/cacerts/cacert.pem onthe LDAP
> server exist in this directory? Did you create the hash symlinks there?
> (alternatively, you could use tls_cacert /path/to/cacert.pem).
>
> Also, where is uri or host? The name you use *must* be the subject CN (or
> subjectAlternateName) on the SSL certificate ...
>
> > tls_checkpeer no
>
> I think the OpenLDAP library has more effect on this than tls_checkpeer ...
> what do you have for 'TLS_REQCERT' in /etc/openldap/ldap.conf ?
>
> > Can any body point me in the right direction
>
> Regards,
> Buchan
 
Registered in England and Wales No.811900          
Registered Office 33 Cavendish Square, London W1G 0PW
This e-mail and any attachments are intended only for the person or entity
to whom it is addressed and may contain confidential or privileged
information.  If you are not the addressee, any disclosure, reproduction,
copying, distribution, or use of this communication is strictly prohibited.
If you are not the intended recipient or person responsible for delivering
this message to the named addressee, please notify us immediately and delete
this e-mail.
It is the responsibility of the addressee to scan this email and any
attachments for computer viruses or other defects.  The sender does not
accept liability for any loss or damage of any nature, however caused,
which may result directly or indirectly from this email or any file attached.