Re: Preventing NSS from querying LDAP for system users
[
Date Prev][
Date Next]
[
Thread Prev][
Thread Next]
Re: Preventing NSS from querying LDAP for system users
- From: Ryan Steele <ryans [at] aweber.com>
- To: Arthur de Jong <arthur [at] arthurdejong.org>, nss-pam-ldapd-users [at] lists.arthurdejong.org
- Subject: Re: Preventing NSS from querying LDAP for system users
- Date: Sun, 14 Mar 2010 22:21:39 -0400
Ryan Steele wrote:
> I should note two things:
>
> 1. The user passed to nslcd_group_byname doesn't appear to be fetched from
> any configuration files (except perhaps the
> slapd config, which is the only thing I can't alter to test because I need to
> specify the rootdn in that context), so I
> believe I was mistaken in that regard. I'm still not sure why nslcd looks
> for a POSIX group entry for cn=admin, though.
>
> 2. One can circumvent this problem by caching the negative search results
> with proxycache, though I would like to find
> out why it occurs in the first place instead of dealing with it after the
> fact using negative lookup result caching.
Actually, I'm not sure caching negative hits is a good idea in terms of
circumventing the issue, and here's why: if you
take the example where you require that clients make secure connections with a
ssf of 128 bits, and that clients also
must authenticate to be able to see their passwords, you can make either of the
following two sets of queries in a row
and never get any successful results, even though the second query in each set
is perfectly valid:
ldapsearch -x -D 'uid=ryans,ou=Users,dc=example,dc=com' -W -H ldap://localhost
'(uid=ryans)' userPassword
ldapsearch -x -ZZ -D 'uid=ryans,ou=Users,dc=example,dc=com' -W -H
ldap://localhost '(uid=ryans)' userPassword
ldapsearch -x -ZZ -H ldap://localhost '(uid=ryans)' userPassword
ldapsearch -x -ZZ -D 'uid=ryans,ou=Users,dc=example,dc=com' -W -H
ldap://localhost '(uid=ryans)' userPassword
The reason is that the negative search result returned by the first query
matches all subsequent queries which match the
same query template, yielding the following slapd output in both cases for the
first and second query:
SRCH "dc=example,dc=com" 2 0 0 0 0
conn=7 op=1 SRCH base="dc=example,dc=com" scope=2 deref=0 filter="(uid=ryans)"
conn=7 op=1 SRCH attr=userPassword
query template of incoming query = (uid=)
QUERY ANSWERABLE
SRCH "dc=example,dc=com" 2 0 0 0 0
conn=9 op=2 SRCH base="dc=example,dc=com" scope=2 deref=0 filter="(uid=ryans)"
conn=9 op=2 SRCH attr=userPassword
query template of incoming query = (uid=)
QUERY ANSWERABLE
This is one of the prime examples of why caching negative results can be bad -
users can actually cause themselves (and
their administrators) a lot of problems by issuing a single faulty query that
will preclude any subsequent queries from
working until the initial query result is removed from the cache. So, it might
be a good idea after all to figure out
why nslcd_group_byname passes the rootdn as a parameter when credentials are
provided during the sudo invocation.
>
> Ryan Steele wrote:
>> Hey Arthur,
>>
>> Arthur de Jong wrote:
>>> 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).
>> I noticed that when credentials are provided during the sudo process, the
>> function nslcd_group_byname is being called
>> with a parameter I don't understand. Instead of calling it with the group
>> corresponding to the user that
>> nslcd_passwd_byname is being passed (i.e., the user invoking sudo), it seems
>> to call it with the binddn specified in
>> nslcd.conf. This obviously will never work if the LDAP server is
>> disconnected. Shouldn't nslcd_group_byname be called
>> with the primary gid of the user invoking sudo? I could cache the negative
>> FWIW, here is a copy of the nslcd output
>> when credentials are provided to sudo, the relevant output from slapd for
>> the same time period, and relevant parts of
>> nslcd.conf:
>>
>> ## nslcd.conf
>> uri ldap://localhost:389
>> base dc=example,dc=com
>> ldap_version 3
>> binddn cn=nslcdbind,dc=example,dc=com
>> bindpw SECRET
>> timelimit 3
>> bind_timelimit 2
>> reconnect_maxsleeptime 5
>> nss_initgroups_ignoreusers ALLLOCAL
>> <...snip tls stuff...>
>>
>>
>> ## nslcd output
>> nslcd: [04823e] DEBUG: connection from pid=10760 uid=0 gid=2040
>> nslcd: [04823e] DEBUG: nslcd_passwd_byname(ryans)
>> nslcd: [04823e] DEBUG: myldap_search(base="dc=example,dc=com",
>> filter="(&(objectClass=posixAccount)(uid=ryans))")
>> nslcd: [04823e] DEBUG: ldap_result(): end of results
>> nslcd: [465f01] DEBUG: connection from pid=10760 uid=0 gid=2040
>> nslcd: [465f01] DEBUG: nslcd_passwd_byname(ryans)
>> nslcd: [465f01] DEBUG: myldap_search(base="dc=example,dc=com",
>> filter="(&(objectClass=posixAccount)(uid=ryans))")
>> nslcd: [465f01] DEBUG: ldap_result(): end of results
>> nslcd: [24c67e] DEBUG: connection from pid=10760 uid=0 gid=2040
>> nslcd: [24c67e] DEBUG: nslcd_pam_authc("ryans","","sudo","***")
>> nslcd: [24c67e] DEBUG: myldap_search(base="dc=example,dc=com",
>> filter="(&(objectClass=posixAccount)(uid=ryans))")
>> nslcd: [24c67e] DEBUG: ldap_initialize(ldap://localhost:389)
>> nslcd: [24c67e] DEBUG: ldap_set_rebind_proc()
>> nslcd: [24c67e] DEBUG: ldap_set_option(LDAP_OPT_PROTOCOL_VERSION,3)
>> nslcd: [24c67e] DEBUG: ldap_set_option(LDAP_OPT_DEREF,0)
>> nslcd: [24c67e] DEBUG: ldap_set_option(LDAP_OPT_TIMELIMIT,3)
>> nslcd: [24c67e] DEBUG: ldap_set_option(LDAP_OPT_TIMEOUT,3)
>> nslcd: [24c67e] DEBUG: ldap_set_option(LDAP_OPT_NETWORK_TIMEOUT,3)
>> nslcd: [24c67e] DEBUG: ldap_set_option(LDAP_OPT_REFERRALS,LDAP_OPT_ON)
>> nslcd: [24c67e] DEBUG: ldap_set_option(LDAP_OPT_RESTART,LDAP_OPT_ON)
>> nslcd: [24c67e] DEBUG: ldap_start_tls_s()
>> nslcd: [24c67e] DEBUG:
>> ldap_simple_bind_s("uid=ryans,ou=Users,dc=example,dc=com","*****")
>> (uri="ldap://localhost:389")
>> nslcd: [24c67e] connected to LDAP server ldap://localhost:389
>> nslcd: [24c67e] DEBUG:
>> myldap_search(base="uid=ryans,ou=Users,dc=example,dc=com",
>> filter="(objectClass=posixAccount)")
>> nslcd: [24c67e] DEBUG: ldap_unbind()
>> nslcd: [482a97] DEBUG: connection from pid=10760 uid=0 gid=2040
>> nslcd: [482a97] DEBUG: nslcd_passwd_byname(ryans)
>> nslcd: [482a97] DEBUG: myldap_search(base="dc=example,dc=com",
>> filter="(&(objectClass=posixAccount)(uid=ryans))")
>> nslcd: [482a97] DEBUG: ldap_result(): end of results
>> nslcd: [63b9ea] DEBUG: connection from pid=10760 uid=0 gid=2040
>> nslcd: [63b9ea] DEBUG: nslcd_group_byname(admin)
>> nslcd: [63b9ea] DEBUG: myldap_search(base="dc=example,dc=com",
>> filter="(&(objectClass=posixGroup)(cn=nslcdbind))")
>> nslcd: [63b9ea] DEBUG: ldap_result(): end of results
>> nslcd: [884adc] DEBUG: connection from pid=10760 uid=0 gid=2040
>> nslcd: [884adc] DEBUG:
>> nslcd_pam_sess_o("","","sudo","/dev/pts/0","localhost","ryans")
>> nslcd: [ead36b] DEBUG: connection from pid=10760 uid=0 gid=2040
>> nslcd: [ead36b] DEBUG: nslcd_pam_sess_c("","","sudo",12345)
>>
>> ## slapd output
>> SRCH "dc=example,dc=com" 2 0 0 3 0
>> conn=16 op=3 SRCH base="dc=example,dc=com" scope=2 deref=0
>> filter="(&(objectClass=posixAccount)(uid=ryans))"
>> conn=16 op=3 SRCH attr=userPassword cn gidNumber uidNumber loginShell
>> objectClass gecos uid homeDirectory
>> query template of incoming query = (&(objectClass=)(uid=))
>> QUERY ANSWERABLE
>> SRCH "dc=example,dc=com" 2 0 0 3 0
>> conn=13 op=4 SRCH base="dc=example,dc=com" scope=2 deref=0
>> filter="(&(objectClass=posixGroup)(cn=admin))"
>> conn=13 op=4 SRCH attr=cn userPassword memberUid gidNumber uniqueMember
>> query template of incoming query = (&(objectClass=)(cn=))
>> QUERY NOT ANSWERABLE
>> QUERY CACHEABLE
>>
>
--
Ryan Steele ryans@aweber.com
Systems Administrator +1 215-825-2196 x758
AWeber Communications http://www.aweber.com
--
To unsubscribe send an email to
nss-pam-ldapd-users-unsubscribe@lists.arthurdejong.org or see
http://lists.arthurdejong.org/nss-pam-ldapd-users
- Re: Preventing NSS from querying LDAP for system users, (continued)