lists.arthurdejong.org
RSS feed

Re: [nssldap] nss_ldap, tls_key, and nscd

[Date Prev][Date Next] [Thread Prev][Thread Next]

Re: [nssldap] nss_ldap, tls_key, and nscd



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?