Re: Using nss-pam-ldapd in a large environment, Part 2: Denial of Service due to open connections

[Thomas Orgis <thomas.orgis [at] uni-hamburg.de>]

Am Wed, 08 Jul 2015 00:01:38 +0200
schrieb Arthur de Jong <arthur@arthurdejong.org>:

> This was originally mostly because OpenLDAP client libraries did not
> support sharing of connections across threads. nss_ldap, from which nss
> -pam-ldapd was forked, had all kinds of locking constructs to work
> around this limitation (with bad performance and complexity as a
> result).

Well, there is one simple fact: I'm starting to cause performance
problems with the whole infrastructure because of deploying
nss-pam-ldapd instead of nss_ldap like everyone else (actually not sure
what SLES 12 brings). From some point on, the system doesn't get better
if every client demands more attention.

I hope you are not offended when I conclude that there is quite some
tuning of nss-pam-ldapd needed to make it a good match for large
installations.

> > [socat hack]
> Looks doable for some configurations. It is not really usable in
> general because some functions in nslcd check whether the connecting
> user is root (probably don't run socat as root).

What kind of operations need root? That would be nice to know. I guess
it is not relevant to us right now, because we just need lookup of IDs
and group membership.

But if LDAP enters more of our clusters, we would like to know what is
broken when using this kind of shielding from too many clients.

> Another option is to look into nssov. You should be able to combine it
> with caching in slapd or use other replication mechanisms.

Yes, I hoped to get away without replicating/caching the server. I'm
duplicating enough infrastructure already with the HPC systems. After
all, it has no trouble with the actual queries, which are rather
intermittend (when computing jobs start/stop).

If we really hit a wall with to many actual queries, yes replication or
at least activation of sssd, I guess, will be in order.

> There is idle_timelimit that closes connections when they are not used.
> It is disabled by default because there may be trade-offs between the
> cost of setting up new connections (e.g. when using SSL) and the cost
> of keeping idle connections open.

That could be something to consider. But it still would mean that a big
computing job results in a burst of concurrent connections that again
might trigger a threshold to mitigate DoS attacks. The approach with
socat will buffer this burst on the intermediate node. And since such a
burst consists of the same query just repeated some 100 times, caching
on that node would make mighty sense. If performance is an issue.

One issue on the side, I might have forgotten it and it is very, very
late: Where is the equivalent to nss_initgroups_ignoreusers in nslcd?
Somehow I would like to stop LDAP queries triggered to look up
secondary groups of the root user. Actually, I would like to avoid any
bothering nslcd for the root user (and other system accounts), but I
don't see the option to do that selectively in nsswitch.conf.


Alrighty then,

Thomas

-- 
Dr. Thomas Orgis
Universität Hamburg
RRZ / Zentrale Dienste / HPC
Schlüterstr. 70
20146 Hamburg
Tel.: 040/42838 8826
Fax: 040/428 38 6270

Attachment: smime.p7s
Description: S/MIME cryptographic signature

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