[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Caching nested groups (member:1.2.840.113556.1.4.1941)

Ryan Hammond wrote:

We have an Active Directory domain with >6000 users and several hundred
groups. The group hierarchy is usually nested 4-5 levels deep.  Queries for
the full set of nested groups for a user take > 10 seconds each.  We have an
app (Nexus OSS) that asks for a user's nested groups on every interaction
(e.g. for each dependency needed to perform a maven build) and does not
perform local caching.

I am trying to implement a slapd + meta + pcache solution that will proxy the
LDAP query, cache the results, and significantly speed up user interactions
with this app.  I have tried many configurations.  I can always proxy the
request, but I haven't yet been able to fully cache the results.  I have had
the most success with the passthru module from
https://github.com/cbueche/openldap-passthru and rwm.  In this configuration,
slapd proxies inbound filters like "(member=CN=my
name,ou=users,dc=some,dc=structure)" and passes that on to AD as
"member:1.2.840.113556.1.4.1941:=CN=my name,ou=userss,dc=some,dc=structure)".
AD returns the group DNs but slapd partially caches the result.  The cached
results are the direct group memberships, not the complete set of nested groups.

Is what I want to do possible?  If so, can someone please point me in the
right direction?
Without actually investigating anything, I'd guess pcache ignores the returned entries because it doesn't know what your extended match filter means. You'll probably need to write some code to enhance the pcache module to make this work. 


Here is what the client sees the first and second time the query is run for a
user that is directly in one group but in many groups via nesting.  (The group
DNs have been obfuscated but in reality they are all unique.)  On the first
run, ldapsearch correctly returns 158 total (nested and direct) groups.  On
the second run, ldapsearch only returns the one direct group.

### RUN 1 ###
ldap_initialize( ldap://127.0.0.1 <http://127.0.0.1> )
filter: (member=cn=Some User,ou=Users,ou=External,dc=some,dc=structure)
requesting: cn
dn: cn=TT-RndGroup-Read,ou=...,ou=External,dc=some,dc=structure
cn: TT-RndGroup-Read

dn: cn=IO-RndGroup-Read,ou=...,ou=External,dc=some,dc=structure
cn: IO-RndGroup-Read

dn: cn=Vi-RndGroup-Read,ou=...,ou=External,dc=some,dc=structure
cn: Vi-RndGroup-Read

dn: cn=SE-RndGroup-Read,ou=...,ou=External,dc=some,dc=structure
cn: SE-RndGroup-Read

<snip 154 more CNs....>

real0m14.167s
user0m0.003s
sys0m0.025s

### RUN 2 ###
ldap_initialize( ldap://127.0.0.1 <http://127.0.0.1> )
filter: (member=cn=Some User,ou=Users,ou=External,dc=some,dc=structure)
requesting: cn
dn: cn=Vi-RndGroup-Read,ou=...,ou=External,dc=some,dc=structure
cn: Vi-RndGroup-Read


real0m4.310s
user0m0.000s
sys0m0.004s

-----------------------------

Thanks,
Ryan



--
  -- Howard Chu
  CTO, Symas Corp.           http://www.symas.com
  Director, Highland Sun     http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/