Re: Preventing NSS from querying LDAP for system users

[Arthur de Jong <arthur [at] arthurdejong.org>]

On Fri, 2010-03-12 at 16:51 -0500, Ryan Steele wrote:
> The problem, however, is that now things like sudo don't work when
> LDAP is unavailable.

I have done some tests and if you lower the reconnect_maxsleeptime
option the delay is limited.

I stopped nscd and used sudo as a local user with the LDAP server
unavailable. With reconnect_maxsleeptime set to 3 seconds the delay is 2
to 4 seconds (even lower in some cases).

The reason for this is that nslcd keeps internal state on the
availability of the LDAP server and will only try once for every request
if the LDAP server was down before (and the retry-mechanism has already
timed out there). If there are multiple requests (sudo seems to want to
known the groups the root user is in a couple of times for some reason)
some requests fail faster than the first request.

nscd also seems to cache username to groups lookups in this case so it
should also help when the LDAP server is unavailable.

> Unfortunately, nscd is not a good solution.  It is fraught with many
> problems, and in addition was clearly not designed with security in
> mind (doesn't work with TLS/SSL).

With nss-pam-ldapd there should be no security implications whether nscd
is used or not (as far as I'm aware). There are some problems with nscd
(see e.g. [0] and [1]) but it shouldn't affect your connection to the
LDAP server.

[0] http://arthurdejong.org/nss-pam-ldapd/news.html#20091122
[1] http://sources.redhat.com/bugzilla/show_bug.cgi?id=2132 

Also, nscd is a good solution to lower the load on your LDAP server. It
is a cache for performance, not for off-line operation.

There may be a problem in unreliable setups though: nscd also caches
negative hits which means that if LDAP is unavailable it may cache that
some user (which could exist in LDAP) does not exist.

> Once you start doing this, you're getting in to the realm of "it's
> probably just easier not to use LDAP at all"; [...] can you imagine
> what people would say if you told them you had to install a
> fully-fledged Active Directory Server on every single Windows client?
> People would look at you like you were smoking something.

Apparently slapd can be set up to be really lightweight but I have yet
to do some experimenting with such a set-up.

If you want reliability and the connection to your LDAP server is not
reliable, you need to cache or replicate the data to a point from where
you do have reliable access.

> So again, unless you have some deep philosophical objection to
> re-adding those nss_initgroups_* options, is there a reason that it
> can't be re-added to reduce the sheer volume of requests being made to
> the LDAP servers?

An nss_initgroups_ignoreusers option could be implemented but I don't
think it solves the underlying problem here (it basically hides a
symptom).

Anyway, attached is a patch (against svn but not yet in svn) that
implements this option. Testing and feedback is welcome. There is one
known issue (that I'm going to ignore) is that username comparison is
case insensitive. So if you add a joe to nss_initgroups_ignoreusers and
have a Joe LDAP user, lookups for Joe would not return any LDAP groups.

Note that a special value ALLLOCAL was introduced. This adds all
non-LDAP users to this list (suggestions for a better name are welcome).

-- 
-- arthur - arthur@arthurdejong.org - http://arthurdejong.org --

Attachment: nss-pam-ldapd-implementnss_initgroups_ignoreusers.patch
Description: Text Data

--
To unsubscribe send an email to
nss-pam-ldapd-users-unsubscribe@lists.arthurdejong.org or see
http://lists.arthurdejong.org/nss-pam-ldapd-users