nss_ldap, tls_key, and nscd

[Chris Adams]

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?
--
Chris Adams <cmadams@...>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.

[Howard Chu]

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?

Not using nss_ldap. Use nss-ldapd or OpenLDAP's nssov instead.

--
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/

[guillomovitch]

Chris Adams a écrit :
> 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.
It seems a bit overkill for me to also us a certificate on client side.
Especially as nss only deals with public informations generally... Do
you really fear someone on your network stealing uid/login mappings ?


--
BOFH excuse #354:

Chewing gum on /dev/sd3c

[guillomovitch]

Wolfe, Patrick a écrit :
> No, no, there's no client side certificate, just a server certificate.  But the CA certificate needs to be copied to a file on each client, so the client can verify that nobody is spoofing the openldap server.
The original post spoke of two certificates, and the problem was the
file perms of the client key...

--
BOFH excuse #438:

sticky bit has come loose

[Chris Adams]

Once upon a time, Howard Chu <hyc@...> said:

> 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?
>
> Not using nss_ldap. Use nss-ldapd or OpenLDAP's nssov instead.

Hmm.  Well, my servers are RHEL 5 (and some still RHEL 4), so I need to
try to use nss_ldap if at all possible.

I guess lots of other people are using nss_ldap; how do you control
access to the LDAP server(s)?  Just using IP-based filters (host
firewalls, router ACLs, etc.)?
--
Chris Adams <cmadams@...>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.

[Howard Chu]

Chris Adams wrote:
> Once upon a time, Howard Chu<hyc@...>  said:
>> Chris Adams wrote:
>>> Is there any way around this?
>>
>> Not using nss_ldap. Use nss-ldapd or OpenLDAP's nssov instead.

> Hmm.  Well, my servers are RHEL 5 (and some still RHEL 4), so I need to
> try to use nss_ldap if at all possible.

Why? Those other packages will also work perfectly well on RHEL.

> I guess lots of other people are using nss_ldap; how do you control
> access to the LDAP server(s)?  Just using IP-based filters (host
> firewalls, router ACLs, etc.)?

You're asking the wrong question. The point of using a distributed directory
is to make information widely accessible. As such, if you don't want
information to be accessible, it probably doesn't belong in a directory in the
first place.

As for information used by nss-ldap - Guillaume asked a good question - what
information are you exposing here that needs to be protected? Usernames and id
numbers are public information already. User passwords should never be exposed
via nss-ldap; there is no legitimate use for that. Authentication (and
authorization) should be performed at the server. I.e., use pam_ldap and
configure it to Bind to LDAP in order to handle authentication.

--
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/

[Chris Adams]

Once upon a time, Howard Chu <hyc@...> said:

> Chris Adams wrote:
> >Once upon a time, Howard Chu<hyc@...>  said:
> >>Chris Adams wrote:
> >>>Is there any way around this?
> >>
> >>Not using nss_ldap. Use nss-ldapd or OpenLDAP's nssov instead.
>
> >Hmm.  Well, my servers are RHEL 5 (and some still RHEL 4), so I need to
> >try to use nss_ldap if at all possible.
>
> Why? Those other packages will also work perfectly well on RHEL.

nss_ldap is _included_ in RHEL, so Red Hat packages it, maintains it,
tracks security and bug issues, etc.

> >I guess lots of other people are using nss_ldap; how do you control
> >access to the LDAP server(s)?  Just using IP-based filters (host
> >firewalls, router ACLs, etc.)?
>
> You're asking the wrong question. The point of using a distributed
> directory is to make information widely accessible. As such, if you don't
> want information to be accessible, it probably doesn't belong in a
> directory in the first place.
>
> As for information used by nss-ldap - Guillaume asked a good question -
> what information are you exposing here that needs to be protected?
> Usernames and id numbers are public information already.

Currently, they are only "public" to the limited number of people that
can access the systems.  These are systems that are providing various
Internet services; they aren't behind any firewalls or such.  Right now,
the Internet can't tell the valid users from the invalid (which is one
level of security).  If the directory services are feeding users,
groups, and IDs to the Internet, that's a lot of information that is not
otherwise public.

--
Chris Adams <cmadams@...>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.

[guillomovitch]

Chris Adams a écrit :
> I guess lots of other people are using nss_ldap; how do you control
> access to the LDAP server(s)?  Just using IP-based filters (host
> firewalls, router ACLs, etc.)?
We use router ACLs to make LDAP server unaccessible from outside.

For nss, I used unencrypted anonymous connection for a long time, and
recently switched to autenticated connections over tls, with a trivial
passord, but only in order to distinguish nss traffic (the most
inportant one) more easily on server side.

--
BOFH excuse #154:

You can tune a file system, but you can't tune a fish (from most tunefs
man pages)

[Howard Chu]

Chris Adams wrote:

> Once upon a time, Howard Chu<hyc@...>  said:
>> Chris Adams wrote:
>>> Once upon a time, Howard Chu<hyc@...>   said:
>>>> Chris Adams wrote:
>>>>> Is there any way around this?
>>>>
>>>> Not using nss_ldap. Use nss-ldapd or OpenLDAP's nssov instead.
>>
>>> Hmm.  Well, my servers are RHEL 5 (and some still RHEL 4), so I need to
>>> try to use nss_ldap if at all possible.
>>
>> Why? Those other packages will also work perfectly well on RHEL.
>
> nss_ldap is _included_ in RHEL, so Red Hat packages it, maintains it,
> tracks security and bug issues, etc.

Ah, great. So you can just ask RHEL about this problem and they'll solve it
for you. Cool.

> Currently, they are only "public" to the limited number of people that
> can access the systems.  These are systems that are providing various
> Internet services; they aren't behind any firewalls or such.  Right now,
> the Internet can't tell the valid users from the invalid (which is one
> level of security).  If the directory services are feeding users,
> groups, and IDs to the Internet, that's a lot of information that is not
> otherwise public.

If you have private information on a machine residing on a public network, you
have bigger problems than just "how does nss-ldap connect to my server."
Private data should be behind a firewall. At the very least you need a router
that rejects packets with bogus source addresses. (I.e., drops externally
generated packets whose source addresses match internal network numbers.) Once
that's in place, you can use tcp_wrappers on the LDAP server if you want
finer-grained host access control.

--
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/

[Howard Wilkinson]

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?
>