Re: [ldapext] DBIS - new IETF drafts

[Michael Ströder <[e-mail]>]

Andrew Findlay wrote:
> On Thu, Jan 09, 2014 at 04:48:37PM +0100, Michael Ströder wrote:
> 
>>> Nested groups are very important especially in large enterprises, and really
>>> do assist with data management.
>>
>> I am always getting told this but I have strong doubts about nested groups.
> 
> Groups are usually there to define permissions - the Authorisation
> part of the AAA triple. Allowing nested groups helps to decouple
> individual users from individual permissions. For example:
> 
> 	The Helpdesk group contains a, b, c, d
> 	The SysManagers group contains e, f
> 	The PasswordRestKiosk group contains j, k, l, m
> 	The AccountProvisioning group contains p
> 
> I can now write permission rules like:
> 
> 	Members of Helpdesk, PasswordRestKiosk, AccountProvisioning may set user passwords
> 	Members of SysManagers may set system-account passwords
> 	Members of Helpdesk, AccountProvisioning may change user contact data

What you describe is rather assigning permissions to user groups. IMHO that's
not what people mean when they are talking about nested groups in general.

>> Resolving nested group membership is a big performance cost. I can see this
>> with a MS Sharepoint installation working with a OpenLDAP server. Sharepoint
>> sends many search requests even though nested groups are not used in this
>> deployment.
> 
> That is because there is no standard schema for nested groups, so
> there is no server-side support to make them efficient. [In fact
> many LDAP server implementations do define their own nesting
> schemes, but I don't think any of them are shared with other
> unrelated implementations.]

Ok, let the server internally search all the group membership (like AD does
e.g. with tokenGroups attribute) would make things more effecient.

> You and I started trying to sort this out after the first LDAP
> conference, but the effort got bogged down. Maybe we should dust off
> the drafts and see if anything can be salvaged.

Server-side resolving of nested groups were far beyond our former scope. But
we could try.

> I don't see that it adds much to the work. If the server supports
> nested groups then it is a single query; otherwise it is a series of
> derefs. (I am assuming a simple two-level nesting here as I can see
> many uses for that without making the rules too complex.)

Aha, you're limiting to two levels... ;-)

Ciao, Michael.