[Date Prev][Date Next] [Chronological] [Thread] [Top]
Re: Ldap is up, trying to get tls working.

To: Juan Miscaro <jmiscaro@gmail.com>, <openldap-technical@openldap.org>
Subject: Re: Ldap is up, trying to get tls working.
From: John Tobin <jtobin@po-box.esu.edu>
Date: Mon, 12 Dec 2011 10:22:21 -0500
In-reply-to: <CADEbCmJ+vnDcnh=OHzgDYEqdnyXkBZJSRdLSFTY2L6DMykmq+A@mail.gmail.com>
Thread-index: Acy44deGiM52I9Lvx0u7c9k9uSqGLg==
Thread-topic: Ldap is up, trying to get tls working.
User-agent: Microsoft-Entourage/12.31.0.110725
Dear Jaun,

Actually I am just getting back to it.
This is finals week. Things will get quiet enough this week that I could
pursue it.

And no, I never got it to work, I had it traced via log entries, and was
going to compare the traces [ldapsearch works with -ZZ, vs. through the ldap
client under linux for nscd or nslcd which fails] and try to do some problem
source identification [What actually is the problem, which code is the
culprit] starting shortly, and going into January.

I am trying to get a handle on whether I should pursue this with nscd or
nslcd. If You have advice there, I am listening. To my knowledge I had nscd
configured correctly when it failed, but I need some more information on
nslcd.

I would very much like a secure [either tls via ldaps, or tls via straight
ldap with tls on] interface, since in the spring some of my networks will
have security classes on them, and to best understand [and illustrate] how
network security works, the instructors will be putting infectious code on
those networks.

FYI I am 2.4.26 openldap on 2 lab networks, ldap is working well in support
of a couple of coordinated projects. All of the machines currently supported
are suse 12.1 milestone 5. Testing is being done on both separate clients
and with the client on the serving machine [both show the same failure at
the moment.].

Why are you interested, and is there anything I can assist you with?

[By the way if any of the broader ldap community has input here, I would
appreciate it.]

Sincerely,
tob



On 12/8/11 9:59 AM, "Juan Miscaro" <jmiscaro@gmail.com> wrote:

> 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?
References:
- Re: Ldap is up, trying to get tls working.
  - From: Juan Miscaro <jmiscaro@gmail.com>
Prev by Date: decoding attrs error
Next by Date: Re: I have no name!
Index(es):
- Chronological
- Thread