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

[Juan Miscaro <jmiscaro@gmail.com>]

On 1 November 2011 11:53, John Tobin <jtobin@po-box.esu.edu> wrote:
> Certificates verify.
> That's a neat tool, put that information somewhere useful.
> I had been trying to prove that the certificates were good for a long time.
>
> I changed from nscd, to nslcd by installing via yast, nss-pam-ldapd
>
> That wasn't too bad.
>
> I configured nslcd with:
>
> Uri ldap://nightmare.dark.net:389/
>
> Base "dc=dark,dc=net"
>
> Ssl start_tls
> Tls_req never
> Tls_cacertfile /var/lib/ldap/cacert.pem
>
> Tls_cert    /var/lib/ldap/server.pem
> Tls_key    Â/var/lib/ldap/server.key
>
> Ldapsearch still works .... With -ZZ
>
> But su - jtobin
> Gets the same error message this time from kdeinit:
>
> nightmare:/var/log # tail -f messages |grep tls
> Nov Â1 11:48:11 nightmare kdeinit4: nss-ldap: do_open: do_start_tls
> failed:stat=-1
> Nov Â1 11:48:11 nightmare kdeinit4: nss-ldap: do_open: do_start_tls
> failed:stat=-1
>
> I guess I am wondering if I configured something wrong....
> Why am I seeing nss-ldap in here...
>
> I installed nslcd, configured it, and didn't change any thing in ldap.conf
> or nsswitch.conf, should anything else be changed?
>
> tob
>
>
> nighttrain:~ johntobin$
>
>
>
>
>
>
>
> On 10/28/11 12:08 PM, "Christopher Wood" <christopher_wood@pobox.com> wrote:
>
>> 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
>>
>
>



Did you ever get this to work?

-- 
/jm