Subject: [ldapext] Summary of group discussion

From: Andrew Findlay <[email-masked]>
Date: Mon, 24 Sep 2007 20:43:42 +0100

draft-findlay-ldap-groupofentries-00.txt discussion summary 2007-09-24
======================================================================

On September 17th I introduced an I-D to create an LDAP group class
that was capable of representing an empty group. The initial proposal
was for the smallest possible change from the existing groupOfNames
class.

Most people who joined the discussion on [email-masked] were broadly
in support of allowing empty groups, though some thought that any
changes away from the status quo were doomed to fail.

Howard Chu pointed out that groupOfUniqueNames is even worse than
groupOfNames as the LDAP syntax for the nameAndOptionalUID attribute
type cannot be parsed reliably.

Kurt Zeilenga provided much detailed editorial advice, and posed a
question about how to handle groups where the DSA is unwilling or
unable to return some or all member names.

Luke Howard suggested that the behaviour of nested groups should be
defined. I was initially against an explicit definition, but was soon
persuaded that there could be significant performance and security
problems with ad-hoc nesting. At this point the discussion moved
almost entirely to the consideration of nesting issues.

Pete Rowley wanted an interface to be used by read-only clients to find
out what groups a particular entry is a member of without caring about
how the groups are defined. He suggested a memberOf attribute (presumably
server-maintained) for this purpose. Michael Liben also liked this
approach.

Simo Sorce proposed a control for server-side group expansion, and
Michael Ströder suggested that an extended operation for asking specific
membership questions would be better. Howard Chu suggested that any such
operation would need a depth limit parameter.

Steven Legg proposed directMember and nestedGroups attributes, and
Michael Ströder suggested that these might be a sufficient set to
describe nested groups. I wondered whether nested groups should be split
into those that could in turn have their own nested groups and those
that could not, but Simo Sorce thought that people would never choose
to use the more restrictive case. I was initially against dropping the
original 'member' attribute, but Steven pointed out that having a new
directMember attribute would allow people to define their own group
classes and still take advantage of defined nesting semantics.

Current situation
=================

It seems to me that we now have these threads of development:

1)	A new structural group class that can represent empty groups.
	This could go forward with the existing ambiguous member
	attribute or it could become the basis of a group
	representation with more carefully defined semantics using
	directMember.

2)	A new auxiliary class and one or more attributes to represent
	groups that may contain other groups. For this to make much
	sense it would require the well-defined version of (1).
	
	In (1) and (2) I see the definitions of the attributes being
	the key, and would avoid requiring the use of the object
	classes to obtain the defined semantics.

3)	A new control or extended operation so that a client can ask
	the server to do the heavy lifting involved with nested
	groups.

4)	A new server-maintained attribute called memberOf to give an
	alternative way for clients to ask for membership information.
	AD already has such an attribute, and Pierangelo Masarati
	recently proposed one for OpenLDAP so there may be useful
	existing work to build on.

5)	A document explaining why groupOfUniqueNames,
	uniqueMember and nameAndOptionalUID are bad, possibly leading
	to them being deprecated in the next revision of the core LDAP
	standards.

I am willing to co-ordinate work on (1) and (2). Are there volunteers
to take on the others?

Andrew
-- 
-----------------------------------------------------------------------
|                 From Andrew Findlay, Skills 1st Ltd                 |
| Consultant in large-scale systems, networks, and directory services |
|     http://www.skills-1st.co.uk/                +44 1628 782565     |
-----------------------------------------------------------------------

_______________________________________________
Ldapext mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ldapext

---

From: Howard Chu <[email-masked]>
Date: Mon, 24 Sep 2007 19:01:53 -0700

> 	classes to obtain the defined semantics.

I think you should avoid dwelling on this last point. It just confuses the 
issue. It seems certain that we're defining new attributes, and therefore at 
least a new objectclass is needed to make use of them. Also the notion of 
placing all the semantics solely in the attribute begs the question "is a 
group with no members no longer a group?" (Yes, it's a silly question, but it 
can be easily avoided by not focusing too much on the attribute.)

> 	existing work to build on.

Pierangelo's code is already released in OpenLDAP 2.4.5.

> 	to them being deprecated in the next revision of the core LDAP

I'll write this up.

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

---

From: Ludovic Poitou <[email-masked]>
Date: Tue, 25 Sep 2007 14:39:05 +0200

On Sep 25, 2007, at 4:01 AM, Howard Chu wrote:

> I think you should avoid dwelling on this last point. It just  
> confuses the issue. It seems certain that we're defining new  
> attributes, and therefore at least a new objectclass is needed to  
> make use of them. Also the notion of placing all the semantics  
> solely in the attribute begs the question "is a group with no  
> members no longer a group?" (Yes, it's a silly question, but it can  
> be easily avoided by not focusing too much on the attribute.)
>

Similar functionality is already present in Sun Directory Server 6,  
although the operational attribute is called isMemberOf (because the  
Sun messaging product using the memberOf attribute with a different  
semantic :-( ).

Samba AD schema
( 1.2.840.113556.1.2.102
         NAME 'memberOf'
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
         NO-USER-MODIFICATION )

Sun Delegated Admin
( 1.2.840.113556.1.2.102 NAME 'memberOf' DESC 'Group that the entry  
belongs to' SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )

Note that the memberOf attribute is not defined as Operational and is  
specifically listed as allowed in a number of objectclasses.

Sun isMemberOf
  ( 1.3.6.1.4.1.42.2.27.9.1.792 NAME 'isMemberOf' SYNTAX  
1.3.6.1.4.1.1466.115.121.1.12 NO-USER-MODIFICATION USAGE  
directoryOperation )

IBM defined its own attribute for the same purpose, and has the same  
semantic as Sun's isMemberOf (at least for Static Groups):
attributetypes=( 1.3.18.0.2.4.2244
NAME 'ibm-allGroups'
DESC 'All groups to which an entry belongs. An entry may be a member
directly via member, uniqueMember or memberURL attributes, or
indirectly via ibm-memberGroup attributes. Read-only operational
attribute (not allowed in filter).'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
NO-USER-MODIFICATION
USAGE directoryOperation )
IBMAttributetypes=( 1.3.18.0.2.4.2244
DBNAME( 'allGroups'  'allGroups' )
ACCESS-CLASS normal
LENGTH 1000 )

So, yes, it would be really nice to see some harmonization in that  
space.

Ludovic.

>> 	to them being deprecated in the next revision of the core LDAP

Ludovic Poitou                                    Sun Microsystems Inc.
Software Architect                                   Directory Services
http://blogs.sun.com/Ludo/         Grenoble Engineering Center - France

Sun Microsystems requires the following notice:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
NOTICE:  This email message is for the sole use of the intended
recipient(s) and may contain confidential and privileged information.
Any unauthorized review, use, disclosure or distribution is prohibited.
If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

---

From: Jaimon Jose <[email-masked]>
Date: Wed, 26 Sep 2007 19:29:00 +0530

Andrew,
I didn't have a chance to follow the complete discussion thread.  So,
I'm taking the liberty to comment on the items that you mentioned in
this summary.

> changes away from the status quo were doomed to fail.

I'm in agreement as well.  We already support empty group though its
against the standard.

> almost entirely to the consideration of nesting issues.

Good suggestion.  This is very much needed for interoperability as more
and more vendors supporting nested groups.

> server-maintained) for this purpose. Michael Liben also liked this

This can even be a virtual attribute for which the implementation can be
left to the vendor.  Should this include all sort of membership?  For
eg. static groups, member status through group nesting, dynamic groups...

> operation would need a depth limit parameter.

Our experience shows that there needs to be a server side configuration
as well which can override the client request. If not, a malicious
client can create DoS attacks as the nesting operation is quite
expensive from a server side. A nested group objectclass definition
should also have a depth limit (Already suggested by Howard Chu).  There
should also be a parameter that defines if the server should chain a
request if there are groups from remote servers.

> Current situation

Here is a suggestion:
groupMember
	This attribute value contains the DN of another group.
	( 2.16.840.1.113719.1.1.4.711 NAME 'groupMember'
	   SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )

nestedConfig
	This bitmap contains the configuration options for a nested group.
	( 2.16.840.1.113719.1.1.4.712 NAME 'nestedConfig'
	  SYNTAX 1.3.6.1.4.1.1466.115.121.1.6)

excludedMember
	This attribute value contains the DNs that need to be excluded from
being a member of a group through nested evaluation. Thus, an entry is a
member of a nestedGroup only if it is listed in the member attribute of
any of the group objects in the nested hierarchy and it is not listed in
the excludedMember attribute
	( 2.16.840.1.113719.1.1.4.711 NAME 'excludedMember'
	   SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )

nestedGroupAux
	This auxiliary class defines required attributes to represent groups
that may contain other groups.
	( 2.16.840.1.113719.1.1.6.1.91 NAME 'nestedGroupAux'
	  AUXILIARY
	  MAY ( groupMember $
		excludedMember $
		nestedConfig ) )

> I am willing to co-ordinate work on (1) and (2). Are there volunteers

I can co-ordinate (3) and (4).

--jaimon

---

From: Pete Rowley <[email-masked]>
Date: Wed, 26 Sep 2007 14:13:27 -0700

Jaimon Jose wrote:
>> sFrom [email-masked] Wed Sep 26 17:16:48 2007
Date: Wed, 26 Sep 2007 14:13:27 -0700
From: Pete Rowley <[email-masked]>
To: [email-masked]
Subject: Re: [ldapext] Summary of group discussion
Cc: LDAP Extensions list <[email-masked]>,
	Andrew Findlay <[email-masked]>

This is a cryptographically signed message in MIME format.
> eg. static groups, member status through group nesting, dynamic groups...
I think the memberOf (or isMemberOf) attribute should be regarded as 
authoritative as to membership - that is, if the server recognizes a 
particular class as a group then it should should include the DNs of 
those entries it considers to be the set of members in the value set - 
this is so that clients can free themselves from deep knowledge of 
grouping mechanics. For group types that can be nested this would also 
include derived membership, but I believe that is a matter between the 
group types specification document and the implementation.

-- 
Pete

---

From: Pete Rowley <[email-masked]>
Date: Wed, 26 Sep 2007 14:15:09 -0700

--------------ms060708060407070406030901--

--===============1654172129==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

--===============1654172129==--

---

From: Pete Rowley <[email-masked]>
Date: Wed, 26 Sep 2007 14:15:09 -0700

Ludovic Poitou wrote:
>
> So, yes, it would be really nice to see some harmonization in that space.
Very cool, I agree.

I recently wrote a memberof plugin for FDS that currently supports 
static groups only. Definitely a good idea to standardize this I think.

-- 
Pete

Ludovic Poitou wrote:
>
> So, yes, it would be really nice to see some harmonization in that space.
Very cool, I agree.

I recently wrote a memberof plugin for FDS that currently supports 
static groups only. Definitely a good idea to standardize this I think.

-- 
Pete

---

From: Jaimon Jose <[email-masked]>
Date: Thu, 27 Sep 2007 14:28:14 +0530

> group types specification document and the implementation.

I think there should be a way to read direct membership and membership
through nested group hierarchy.  There is already a proposal to have a
control or extension to achieve this.  This functionality will be
required for management consoles to efficiently display member DNs
(non-group) and member groups.  At the same time, having a separate
attribute to hold member groups will be more convenient to  implement
from both client and server perspective.

While I agree that loop detection while evaluating nested groups is a
server implementation detail, how about, duplicate value elimination.
Should the standard say anything about this?

--jaimon

---

From: Pete Rowley <[email-masked]>
Date: Thu, 27 Sep 2007 11:47:59 -0700

Jaimon Jose wrote:
> through nested group hierarchy.
What purpose would this have in a member entry?
>   There is already a proposal to have a
> (non-group) and member groups.
Management consoles would deal directly with groups entries since they 
do need to understand grouping mechanics.
>   At the same time, having a separate
I don't think it is more convenient for general clients, I think it is 
actually less value due to the requirement to merge the two value sets 
in order to get the group list. The vast majority of clients really 
don't care why an entry is a member of a group, they just want to know 
that it is.
> Should the standard say anything about this?
Hmm, are you thinking I was referring to the group proposal?  I was 
confining my comment to the memberof attribute.

-- 
Pete

---

From: Jaimon Jose <[email-masked]>
Date: Fri, 28 Sep 2007 15:15:02 +0530

> What purpose would this have in a member entry?

This is from an administrative perspective.  Our experience in
implementing dynamic groups and nested groups (yet to be released
eDirectory 8.8.2) in eDirectory is that, Administrators always wanted to
know how an entry becomes member of a group.  They also wanted to know
the direct(static) members of a group and members through nested or
dynamic relationship.  This is because, the hierarchy can be pretty
complex in a deeply nested scenario and administrators will not know who
 gets rights when they make a group as a trustee of an object.

> do need to understand grouping mechanics.

Right.  So, they should be able to read groups entries and non-group
entries.

> don't care why an entry is a member of a group, they just want to know

Clients need not know about this when they just read "member" attribute.
 The server implementation should be such that, unless the request
accompany a control or extension, the result set should contain direct
members and members of the groupMember (member DN of type group - nested
or dynamic) .

--jaimon

---

From: Pete Rowley <[email-masked]>
Date: Fri, 28 Sep 2007 10:38:11 -0700

>  gets rights when they make a group as a trustee of an object.
OK. It seems like this would be useful even for management client thats 
don't fully understand all grouping mechanics.
> members and members of the groupMember (member DN of type group - nested
I prefer more attributes to controls (they are generally more 
universally compatible), but I wonder if there isn't a case here for 
using a control that allows the client to follow the chain of membership 
i.e. ask the question of any group entry "how does this group come to 
call this member a member?", the answer for which is either it doesn't, 
by direct inclusion, or through this list of DN's of other group entries 
(and perhaps a combination of the last two).

-- 
Pete

---

From: Gavin Henry <[email-masked]>
Date: Sun, 30 Sep 2007 00:29:12 +0100

Howard Chu wrote:
> I think you should avoid dwelling on this last point. It just confuses 
> the issue. It seems certain that we're defining new attributes, and 
> therefore at least a new objectclass is needed to make use of them. Also 
> the notion of placing all the semantics solely in the attribute begs the 
> question "is a group with no members no longer a group?" (Yes, it's a 
> silly question, but it can be easily avoided by not focusing too much on 
> the attribute.)
> 

Where would this be linked to/from? Format?

-- 
Kind Regards,

Gavin Henry.
Managing Director.

T +44 (0) 1224 279484
M +44 (0) 7930 323266
F +44 (0) 1224 824887
E [email-masked]

Open Source. Open Solutions(tm).

http://www.suretecsystems.com/