[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: Ldap is up, trying to get tls working.
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
>