Re: Ldap is up, trying to get tls working.

[Christopher Wood <christopher_wood@pobox.com>]

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