Re: Using nss-pam-ldapd in a large environment: Equivalent to 'nss_getgrent_skipmembers yes' to avoid unnecessary lookup flood

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

Am Fri, 17 Apr 2015 20:16:39 +0200
schrieb Arthur de Jong <arthur@arthurdejong.org>: 

> Thanks for the detailed use case. It really makes understanding the
> situation and thinking about a proper solution easier.

Oh, I surpassed a standard of initial requests to the list?
Splendit! ;-) Thanks for the quick response, too. I won't be that
responsive for the coming week, but suggestions will be eventually
investigated.

>   map group memberUid nonexistent
>   map group member ""

That doesn't work out of the box with the version in CentOS 7.1.
Naturally, thats a 0.8.x version (0.8.13) and this doesn't like group
member being an expression. I installed 0.9.5 locally, started the
nslcd from that and used LD_LIBRARY_PATH to load the corresponding
libnss_ldap.so.2 .

With 0.9.5, this indeed empties all groups but also removes the list of
groups a user is member of, besides the primary one. It stays the same
with only the second line.

> but this will also break the group by user lookup. 

Yup.

> 
> Something that may reduce the number of queries in any case is disabling
> nss_nested_groups (should be disabled by default)

I assume we're riding with the default on nss_nested_groups here (not
included in the config) and also, 17000 non-group group members are enough
to slow things down …

> and see if the LDAP
> server supports the deref control (assuming you are using a 0.9 version
> of nss-pam-ldapd). This control allows nslcd to do only one query to the
> LDAP server to expand the member attribute to users with group lookups.

Hm.

nslcd: [7b23c6] <passwd="xxxxxxxxx"> DEBUG: 
ldap_set_option(LDAP_OPT_PROTOCOL_VERSION,3)
nslcd: [7b23c6] <passwd="xxxxxxxxx"> DEBUG: ldap_set_option(LDAP_OPT_DEREF,0)
nslcd: [7b23c6] <passwd="xxxxxxxxx"> DEBUG: 
ldap_set_option(LDAP_OPT_TIMELIMIT,0)
nslcd: [7b23c6] <passwd="xxxxxxxxx"> DEBUG: ldap_set_option(LDAP_OPT_TIMEOUT,0)
nslcd: [7b23c6] <passwd="xxxxxxxxx"> DEBUG: 
ldap_set_option(LDAP_OPT_NETWORK_TIMEOUT,0)
nslcd: [7b23c6] <passwd="xxxxxxxxx"> DEBUG: 
ldap_set_option(LDAP_OPT_REFERRALS,LDAP_OPT_ON)
nslcd: [7b23c6] <passwd="xxxxxxxxx"> DEBUG: 
ldap_set_option(LDAP_OPT_RESTART,LDAP_OPT_ON)

Doesn't look like deref is used. Would this skip the separate request
for each group member and instead return all group information in one
lump? Would definitely speed things up, I guess. But there still is the
idea that it might be preferrable in an organization to allow only "Am
I member of that group?" requests instead of "Give me the list of
people with access to xxx!" 

> Implementing nss_getgrent_skipmembers should not be that difficult.
> Hacking it in for testing should be just commenting out these lines in
> nslcd/group.c:
> 
>   attmap_add_attributes(set, attmap_group_memberUid);
>   attmap_add_attributes(set, attmap_group_member);

Well, since I got a local version installed already … wait for it …
Yes! Commenting out these two yields the same behaviour we have with
nss_ldap and nss_getgrent_skipmembers yes!

Now the time to id the user in a handful of groups with a truckload of
members is only 42 ms, with 14 LDAP searches (calls to
myldap_search()). That seems acceptable, probably a tiny bit quicker
when querying an LDAP cache closer to the client.

This is the same with a hacked 0.8.13, which we are more likely to use
to avoid too much straying from the base distribution for that core
component.

Would that be even less requests if our server offered deref?

> However, having an inconsistency between "which members does this group
> have?" and "which groups have this user as member?" (these are the two
> basic types of queries) may confuse some applications.

Yes. But I have to assume that that confusion is not that prevalent, as
this type of setup is heavily used around here.

> I know nscd gets
> easily confused about these kind of things and OpenSSH is really picky
> about user and group existence.

I don't really intend to bring nscd or sssd into the game (rather some
LDAP cache servers in the same subnet as a group of clients), but the
interplay with OpenSSH is exactly what I am interested in. For sure I
am testing that.

Anyhow, May I suggest to consider including this hack, along with a
configuration setting that's off by default, in a future version of
nslcd? I'll test the behaviour of that setting in conjunction with our
userspace (ssh, batch job server), but as I indicated in the beginning,
not the upcoming week.

Many thanks for the spot-on suggestion! 


Regards,

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/