Re: [ldapext] Summary of group discussion

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

Andrew Findlay wrote:

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.

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.)

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.

Pierangelo's code is already released in OpenLDAP 2.4.5.

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.

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'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/

_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext

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.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~