Preventing NSS from querying LDAP for system users

[Ryan Steele <ryans [at] aweber.com>]

I should preface this post by stating that I originally sent a similar line of 
questioning to Launchpad before realizing
that nss-pam-ldapd had a mailing list, after which I chose to post here upon 
deciding that this was probably the more
appropriate outlet.  I didn't think this would be considered cross-posting, 
given that I was unaware of this mailing
list before sending it to Launchpad (which probably wasn't the right call to 
begin with), but please accept my sincerest
apologies if that is not the case.  Anyways, on to the question...

I see that in version 0.3 and 0.5 respectively, support for the 
nss_initgroups/nss_initgroups_ignoreusers and
bind_policy options were removed from libnss-ldapd. However, without those 
options, I'm not sure how to prevent NSS from
querying LDAP for users which aren't in LDAP, which can cause a lot of trouble 
both when the LDAP server is available,
by inundating it with requests for which it will issue only negative responses, 
and when the LDAP server is unavailable,
where at best, you have brief interruptions while you wait for one of the 
various and sundry timeout option thresholds
to be reached.  The obvious result is that system users lose the ability to 
operate without being hindered by
unsuccessful NSS lookups, which can drive the load up as processes stack up in 
wait time.

Given that these options are no longer available to those of us who wish to use 
libnss-ldapd instead of libnss-ldap or
nssov, what do the package authors/maintainers/other users suggest to 
circumvent or otherwise prevent lookups from being
made for users who exist locally (root, daemon, www-data, et. al.)?  I'm 
looking for a solution that doesn't involve
setting timeouts - I want to exclude network-based lookups from even occurring 
for local and system users.  At the very
least, I'd like to avoid the inevitable delays associated with the typical 
timeout-related thresholds if one or more of
those parameters are the only options that libnss-ldapd users can leverage.

FWIW, I have tweaked my PAM stack (/etc/pam.d/common-*) to ensure that none of 
these issues are PAM-related (since it is
susceptible to the same kinds of issues, or at least was before libpam-ldapd) 
by using options like "pam_succeed_if.so
uid < 2000 ..." and "pam_localuser.so ...", but I know for a fact that the 
issue is NSS-centric, so those are irrelevant
in this context.

It's somewhat of a catch-22 I find myself in.  Without 
libnss-ldapd/libpam-ldapd, I could use the
nss_initgroups_ignoreusers option to prevent system users from being affected 
if the remote LDAP server disappeared
(host or network down), but because the PADL libnss-ldap on Ubuntu 8.04 sent 
about 50% of its queries to LDAP without an
attribute list to filter the LDAP responses (I have slapd output captures to 
prove this), my back-ldap+proxycache
clients couldn't determine whether or not the attributes that were to be 
returned were available in the proxycache
attrset definition. Thusly, proxycache decided it could not cache the response 
and proxied the request out to the remote
LDAP server, which would never succeed if the remote LDAP server was 
unavailable, meaning that LDAP-based users couldn't
really function properly if the LDAP server became unavailable.   On the flip 
side of the coin, libnss-ldapd provides a
list of attributes required for each query in all the NSS queries it issues to 
the remote LDAP server, so proxycache can
always determine whether or not it can answer and cache the responses, and with 
the appropriate proxytemplates defined,
my LDAP-based users can operate at full capacity if the remote LDAP server is 
unavailable.  But without the
nss_initgroups_ignoreusers option at my disposal, and given that proxycache 
cannot store information from system users
(because they obviously don't have any information stored in LDAP), 
local/system users and services either operate
sub-optimally (as they spend a lot of time waiting for NSS lookups to 
complete), or even fail to work entirely if the
remote LDAP server becomes unavailable.

Given those two options, I would regrettably have to choose the former, because 
I would rather have my system services
(webserver, root cronjobs, databases) available so that public-facing services 
like websites and databases aren't
negatively affected if my LDAP servers become unavailable for some reason.  I 
hate having this ultimatum - has anybody
else found an answer to this problem?

For reference, here's my environment:
 * Ubuntu Server 8.04 (Hardy LTS)
 * nss-pam-ldap 0.7.2 (libnss-ldapd + libpam-ldapd)
 * OpenLDAP 2.4.18 (with back-ldap + proxycache clients)

TIA for any insights,
Ryan
--
To unsubscribe send an email to
nss-pam-ldapd-users-unsubscribe@lists.arthurdejong.org or see
http://lists.arthurdejong.org/nss-pam-ldapd-users