Cheap advice inline.
On Fri, Oct 28, 2011 at 11:44:25AM -0400, John Tobin wrote:
Folks,
I have openldap up, it supports vsftpd, sshd, and 5 client linux machines
for remote login.
I would like to get tls working. I would support either ldaps [port 636],
or the tls available on port 389, I am aware of the differences in
implementation, and the fact that an administrator effectively has to
make
a decision to support one or the other in most cases.
Currently:
I have slapd running configured for tls under ldap [std port 389].
I am testing it on the slapd machine, with a client on the same machine.
I am pointing to the same cacertificate in slapd.d [cn=config.ldif] and
ldap.conf.
With that in place, and the ldap.conf below:
nightmare:/etc # cat ldap.conf
base dc=dark,dc=net
uri ldap://nightmare.dark.net
# scope sub
# binddn "cn=admin,dc=dark,dc=net"
# bindpw jackie
bind_policy soft
# The user ID attribute (defaults to uid)
pam_login_attribute uid
pam_lookup_policy yes
pam_password exop
nss_schema rfc2307bis
tls_reqcert never
pam_filter objectClass=posixAccount
ldap_version 3
nss_map_attribute uniqueMember uniqueMember
ssl start_tls
tls_cacert /var/lib/ldap/cacert.pem
tls_cert /var/lib/server.crt
tls_key /var/lib/ldap/server.key
I have run ldapsearch:
nightmare:/media # ldapsearch -v -x -H ldap://nightmare.dark.net:389/ -b
"dc=dark,dc=net" -Z
Always test starttls with -ZZ, so if your starttls isn't working the
connection will fail.
ldap_initialize( ldap://nightmare.dark.net:389/??base )
filter: (objectclass=*)
requesting: All userApplication attributes
# extended LDIF
#
# LDAPv3
# base<dc=dark,dc=net> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#
# dark.net
dn: dc=dark,dc=net
dc: dark
o: dark
objectClass: organization
objectClass: dcObject
# admin, dark.net
dn: cn=admin,dc=dark,dc=net
objectClass: organizationalRole
cn: admin
# Default Policy, dark.net
dn: cn=Default Policy,dc=dark,dc=net
objectClass: namedObject
objectClass: pwdPolicy
cn: Default Policy
# People, dark.net
dn: ou=People,dc=dark,dc=net
objectClass: organizationalUnit
ou: People
description: People is used in mapping the /etc/passwd entries
# jtobin, People, dark.net
dn: uid=jtobin,ou=People,dc=dark,dc=net
uid: jtobin
cn: John C. Tobin
objectClass: account
objectClass: posixAccount
objectClass: top
objectClass: shadowAccount
loginShell: /bin/ksh
uidNumber: 5000
gidNumber: 100
homeDirectory: /home/jtobin
gecos: John C. Tobin
# defaultDNS, dark.net
dn: cn=defaultDNS,dc=dark,dc=net
cn: defaultDNS
objectClass: top
objectClass: suseDnsConfiguration
suseDefaultBase: ou=DNS,dc=dark,dc=net
# DNS, dark.net
dn: ou=DNS,dc=dark,dc=net
objectClass: top
objectClass: organizationalUnit
ou: DNS
# search result
search: 3
result: 0 Success
# numResponses: 8
# numEntries: 7
nightmare:~ #
#####
So I am assuming the ldapserver on ldap://nightmare.dark.net:389/ with
tls
works.
[I looked through the message output in /var/log/message and see the
³STARTTLS² and ³TLS established tls_ssf=256²]
I have done a number of similar ldapsearches. This appears to work
correctly.
On the client machine I now do :
nightmare:/media # su - jtobin
su: user jtobin does not exist
nightmare:/media #
/var/log/message - output......
nightmare:/var/log # tail f |grep I tls
Oct 28 11:29:01 nightmare slapd[11118]: conn=1217 op=0 STARTTLS
Oct 28 11:29:01 nightmare worker_nscd: nss-ldap: do_open: do_start_tls
failed:stat=-1
Oct 28 11:29:01 nightmare slapd[11118]: connection_read(14): TLS accept
failure error=-1 id=1217, closing
Oct 28 11:29:01 nightmare slapd[11118]: conn=1217 fd=14 closed (TLS
negotiation failure)
Oct 28 11:29:01 nightmare slapd[11118]: conn=1218 op=0 STARTTLS
Oct 28 11:29:01 nightmare worker_nscd: nss-ldap: do_open: do_start_tls
failed:stat=-1
Augh. If you can stop using nscd all this will be much easier for you. I
personally like nslcd rather than nss-ldap, but each to their own.
If not, restart nscd before you start every troubleshooting round.
Oct 28 11:29:01 nightmare slapd[11118]: connection_read(14): TLS accept
failure error=-1 id=1218, closing
Oct 28 11:29:01 nightmare slapd[11118]: conn=1218 fd=14 closed (TLS
negotiation failure)
First I would test that all the CA certs and server certs in use are
understandable by each other. Does the server cert on the machine running
slapd validate against the CA cert on the machine running ldapsearch? Does
the
server cert on the machine running slapd validate against the CA cert on the
client machine?
openssl verify -CAfile cacert.pem servercert.pem
If the output says "ok" then the actual cert part is fine.
At this point I would crank up the slapd debug level (run it in the
foreground) and match it again your ldap client debug logs. See if you can
reproduce the error above using a client like ldapsearch, using the same
search parameters as the nss-ldap client would use.
[if you want more of the log, I can obviously get it, but these appear to
be the important parts.]
This is probably a configuration error, or a logical / architecture
misunderstanding, ok, I Œm a newbie.
Do I have certificates incorrectly generated? [certificates were
generated
via [1]http://www.openldap.org/faq/data/cache/185.html].
What did I do wrong?
This is running openldap 2.4.26 off of Suse 12.1 milestone 5.
I'm getting a puppetized starttls working with 2.4.26/openssl on debian, but
much the same thing.
Thanks in advance.
tob
References
Visible links
1. http://www.openldap.org/faq/data/cache/185.html