Skip to Content.
Sympa Menu

grouper-users - Re: [grouper-users] grouper and openldap

Subject: Grouper Users - Open Discussion List

List archive

Re: [grouper-users] grouper and openldap

Chronological Thread 
  • From: Tom Poage <>
  • To: "" <>
  • Subject: Re: [grouper-users] grouper and openldap
  • Date: Fri, 3 Feb 2017 18:32:56 +0000
  • Accept-language: en-US
  • Authentication-results: spf=none (sender IP is ) ;
  • Ironport-phdr: 9a23:6BMt9B+b9TOSov9uRHKM819IXTAuvvDOBiVQ1KB31u8cTK2v8tzYMVDF4r011RmSDNmdtKsP0rKI+4nbGkU4qa6bt34DdJEeHzQksu4x2zIaPcieFEfgJ+TrZSFpVO5LVVti4m3peRMNQJW2aFLduGC94iAPERvjKwV1Ov71GonPhMiryuy+4ZPebgFHiTanY75+MRq6oRjNusQXnIBvNrs/xhzVr3VSZu9Y33loJVWdnxb94se/4ptu+DlOtvwi6sBNT7z0c7w3QrJEAjsmNXs15NDwuhnYUQSP/HocXX4InRdOHgPI8Qv1Xpb1siv9q+p9xCyXNtD4QLwoRTiv6bpgRRn1gykFKjE56nnahMxugqxGvBKvqR9xw4DWb4+SNfpxYqzTctwBSGpdR8ZRUjBNAoOgY4cRCecKIOZWr5P6p1sLtRawGw6sBObywTFSgX/5x6I63Po8GgzBwAwgEcoOsHPOo9X6KqgfSv21w7XVwjrZcfNW2Cz95JLWfR88vPGBRLR9etffx0koEgPKlFSQqYr9MjOSzuQCrW6b7+59Wu21k24rsQZxoiKgxsoql4LHhZoVx0jZ+Slnw4s5P8C0RFBnbdK+HpZcqTuWO5ZoTs4mW21kpTg2x74ctZKmYiQG1I4rywPdZvCdboSF7RzuWP6MLTp5gH9pYqyziha9/ES6yODwTNS43VJWoidDj9LCrGoC1wbJ5ciCUvZ9/lmu2TKI1w3L8eFEJFw0lbLVJpI7374/ioccvl7dHi/3g0X6lrGZeVg5+uSw6uTnZKvppoOEOoNplA3zMb4iltGhDegkKAQDUXaX9f6h2LH9+UD1WLBKgec3kqndvpDaP8MbpquhDg9J3IYj8xG/AC2p0NsGhnQHMU5Kdw+dgIj3OlHOO+r0AumijFSxiDtr3ezJPqX9ApXRKXjOiLjhfax6605B0Ao808pf64tJCrEaPv3zQFTxucfcDh84KAy03/3nBMtn2oMfX2KPHrGWMLnUsVCW+uIjPfOAa5EItzbgeLAZ4KukgmU+hEcQZ+y0xpYNc1i5GOhrOUOUfSCqj9scWy9esRA5UfTnkhifSjNJfF6zWb4x/Dc2FNjgAIveENODmruEiRu8G9VuYWlJBxjYDXnwcIyLVt8RYy6bPM561DEISO7yGMcayRiyuVqimPJcJe3O93hAuA==
  • Spamdiagnosticmetadata: NSPM
  • Spamdiagnosticoutput: 1:99

Right. Your being author of the LDAP Recipe, I suspected something like this
could be the case. :-)

I haven't used OpenLDAP in several years but, thinking along the lines of the
aphorism "all problems in computer science can be solved by another level of
indirection," a form of 'hashed' storage for large aggregate groups, with a
mechanism to dynamically resolve membership at query time could be fruitful.

Found mention of an OpenLDAP 'dynlist'. If otherwise large static groups are
hashed/broken up (member=a*, member=b*, ...), I wonder if that wouldn't
remedy the issue of managing them with hopefully minimal impact on client
query performance. It appears as if the client may need to be none the wiser
wrt queries.

Just thinking out loud,

> On Feb 3, 2017, at 8:18 AM, Michael R Gettes
> <>
> wrote:
> we have both static group objects and isMemberOf on the user object - so we
> do as you suggest if I am understanding you correctly. The real issue is
> application behavior. There are still many apps operating against static
> group objects. So the need for large groups remains.
> I hope this helps.
> /mrg
>> On Feb 3, 2017, at 11:12 AM, Tom Poage
>> <>
>> wrote:
>> Is it possible in Grouper to 'invert' the solution, making membership a
>> user attribute? Then each user entry might be a member of, say, on the
>> order of 100 groups vs. managing a single 40k entry object.
>> Tom.
>>> On Jan 30, 2017, at 7:50 AM, Michael R Gettes
>>> <>
>>> wrote:
>>> I received only a few replies. Others have run into this limitation of
>>> openldap not being able to support large static group objects. The
>>> problem is really large numbers of multi-valued attributes (not just
>>> group objects). My observation is 5 seconds to update when the group
>>> object becomes greater than 35K-40K members. Apparently, openldap has to
>>> regenerate the member/uniquemember attributes for the entire object each
>>> time. This appears to be a known issue with
>> ...

Archive powered by MHonArc 2.6.19.

Top of Page