Re: [nssldap] nss_ldap, tls_key, and nscd
[
Date Prev][
Date Next]
[
Thread Prev][
Thread Next]
Re: [nssldap] nss_ldap, tls_key, and nscd
- From: Howard Wilkinson <howard [at] cohtech.com>
- To: nssldap [at] padl.com
- Cc: Chris Adams <cmadams [at] hiwaay.net>
- Subject: Re: [nssldap] nss_ldap, tls_key, and nscd
- Date: Thu, 20 Aug 2009 09:32:05 +0100
Chris,
I have done something similar but using kerberos based authentication.
This works because all of my users (except the system users like root)
use kerberos authentication via pam_krb5.
I had to provide a kerberos keytab/ccache for the nscd user, which gets
used when the library calls are vectored through ncsd. I provided
similar files using the system keytab for the root user.
This all works with a patched version of nss_ldap-264 - my patches make
kerberos work, work with auto renew, work with server fails over and
work with service discovery.
However, nscd stills fails occasionally because on some machines we have
local instances of the user that exist in the LDAP directory and NSCD
gets corrupt lists somewhere because of this.
Doing a similar task with certificates is not difficult, you just need
to issue a certificate to each user in your directory and get then to
authenticate with it and then make it available via nss_ldap. Again you
may need my patch set which allows the nss_ldap config file location to
be passed in from the environment - thus making it possible to give
different certificates to each instantiation.
My patches have been around for a year and do work, but they need
cleaning up and adopting on the major distributions. I also need to find
the time to fix some of the core LDAP code in nss_ldap as it uses
recursion which breaks if the connection fails mid conversation. I need
to rewrite this to use a list walking structure.
If you can look at this code and use it in either mode I would be happy
to help you get it built on Redhat - I use Fedora - just moved to 11 -
and would do my best to get Fedora and then Redhat to adopt it.
Howard.
Chris Adams wrote:
I'm trying to set up RHEL 5 with OpenLDAP, nss_ldap, and nscd. I
thought I'd try to secure the client<->server communications with TLS,
so I set up a TLS server cert and TLS client cert (both signed by my
CA).
Most things seem to work. I can "getent passwd foo" to get the passwd
entry for user "foo" from LDAP just fine (as root or as a normal user).
However, "getent passwd" (or "getent group") only work as root. As a
normal user, they list the local entries and then hang. Also, bash
~user<TAB> hangs (e.g. at a bash prompt type "cd ~f<TAB>").
I dug into this some, and it appears that nscd (at least on Linux with
glibc) doesn't handle getXXent calls, so they are handled directly in
the calling process (as if nscd was not running). Since I set up my TLS
key to be only readable by root and the nscd user, normal users can't
connect to the LDAP server.
Is there any way around this?
- Re: [nssldap] nss_ldap, tls_key, and nscd, (continued)
- Re: [nssldap] nss_ldap, tls_key, and nscd,
Howard Wilkinson