On Monday 06 April 2009 17:58:30 Matthew.GARRETT@external.total.com wrote:
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
Are you trying to use certificate-based client authentication? You didn't say so previously, the client-side configuration didn't support it, and I would suggest that you try and at least get basic server-side SSL working first ...
Did you read the coverage of this option in the documentation?
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
Since you have 'TLSVerifyClient demand', and you didn't supply -cert and/or - key, this should fail.
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