Re: How to avoid unnecessary LDAP operations?

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

On Tue, 2014-03-25 at 12:44 +0100, Dominique Petitpierre wrote:
> 1) (Ref: conn=1954208 op=1 msgId=2) The search for the dn
>     asks for attributes uid and uidNumber. It is not
>     necessary and no attribute should be requested (by
>     specifying oid "1.1").

The uid attribute is used to update the username passed by PAM to be
correct. The functionality was based on the implementation for template
users in PADL's pam_ldap. In any case requesting this attribute
shouldn't result in much overhead because the search uses it anyway.

The uidNumber attribute value is checked against the nss_min_uid
configuration option. If requesting this attribute has a measurable
impact, I'm willing to accept patches to not request it if nss_min_uid
is not used.

> 2) (Ref: conn=1954209 op=1 msgId=2) After the BIND that
>      checks the password in a second connection a search is
>      performed to obtain the same dn that was used for the
>      BIND.  This search is useless because we know the dn
>      exists since the BIND succeeded.

The search is there because some LDAP servers have been shown to
silently accept the BIND in some circumstances but will only fail at
this search.

This shouldn't have too much impact on performance because the DN was
just looked up anyway to perform the BIND with the specified DN so any
caches should be hot.

> 3) (Ref: conn=1954208 op=2 msgId=3) Once the password
>     checked, a search for ShadowAccount attributes is
>     performed in the first connection.  This is not necessary
>     because there is already all the information in
>     the /etc/shadow file (remember: no LDAP name service) and
>     the password hash is not retrieved from LDAP to be
>     checked locally.  Besides this info is dummy because
>     password expiration etc. is not handled at the Unix level
>     but in a central system of which the LDAP server is part.

While this is technically an authorisation check (and not
authentication) it can only be performed in the authentication phase
because the checks are only relevant if the user provided a password to
this PAM module. So for general operation this is a correct check to
perform.

In your situation (and any situation that does not put shadow
information in LDAP) this is an extra search. If there is an elegant way
to disable this check, I'm willing to accept patches for this.

> 4) (Refs: conn=1954209 op=2 msgId=3, conn=1954208 op=3
>     msgId=4) Both connections issue an ABANDON operation
>     eventhough they got a result from the previous SEARCH
>     request.  This would be necessary only in the case where
>     the search would not return a result before a timeout on
>     the client side. Since this is clearly not the case here
>     (NOTFOUND indicates that there is nothing current to
>     abandon), no ABANDON operation should have been issued.

The abandon is done to flush any remaining results from the search. In
the above cases only one result entry is read from the results. An
alternative would be to keep processing results until we get a
LDAP_RES_SEARCH_RESULT, however that would make the code more
complicated and could slow things down in some cases.

But again, if you can come up with an elegant solution, patches are
welcome ;)

> 5) (Ref: conn=1954209 op=3 msgId=4) The connection used to
>     check the password is closed (UNBIND).  This is expensive
>     (overhead to restart a TCP connection and, in this case,
>     a SSL negociation involving lots of crypto) and not
>     necessary: it can stay open until the next BIND for the
>     next user login (i.e. that connection can also be part of
>     the permanent connections of the pool albeit only usable
>     for checking passwords with BIND operations).

The authentication connection is indeed currently terminated. This could
indeed be part of a separate pool of connections but that would mean
that every thread would generally have two open connections at the same
time (I understand LDAP connections cannot be passed between threads).

Also, I think there may be some issues with rebinding in some scenarios
and LDAP servers so I preferred to keep things simple. Since we are
dealing with authentication which is an important security component,
it's better to be safe than sorry.

> - Is there a way to modify the configurations of nslcd or PAM
>    that would avoid these unnecessary operations?

I don't think there is much that can be done configuration-wise at the
moment.

> - The last point (5) is more like a feature request: It would be nice
>    if one could configure if password checks are done in a permanent
>    connection or not.

Patches welcome ;)

If the LDAP server is a performance bottleneck in your environment, you
could run an LDAP proxy on your machine or even use the nssov overlay
inside the slapd proxy. The overlay also uses the PAM (and NSS) module
of nss-pam-ldapd and provide an alternative for nslcd.

I think they only do the ppolicy checks (not shadow attribute checks)
and should avoid extra searches and pretty efficient binds and
connection pooling. Since nslcd needs to support all kinds of LDAP
servers it has a little more overhead.

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

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