Subject: [ldapext] groupOfEntries object class proposal

From: Andrew Findlay <[email-masked]>
Date: Mon, 17 Sep 2007 15:33:36 +0100

At the recent LDAP conference in Cologne there was wide support for an
effort to improve some of the commonly-used schema definitions. In
particular, the fact that groupOfNames does not permit an empty group
was felt to be a significant problem.

To address this problem, I have published an I-D proposing a new
objectclass called groupOfEntries. The I-D is appended and is also
available at:

http://www.ietf.org/internet-drafts/draft-findlay-ldap-groupofentries-00.txt

To make adoption as easy as possible, the new object class is
identical to groupOfNames except that it has the ability to
describe empty groups without resorting to tricks and workarounds.

I would like to see this new class used in place of groupOfNames in
new designs, so I propose to ask IETF to consider the draft for the
Standards Track.

Comments and suggestions for improvement are welcome, and should be
sent to the [email-masked] mailing list.

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

Network Working Group                                         A. Findlay
Internet-Draft                                            Skills 1st Ltd
Expires: March 16, 2008                               September 13, 2007

                  The LDAP groupOfEntries object class
                  draft-findlay-ldap-groupofentries-00

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on March 16, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

Abstract

   This memo describes the LDAP groupOfEntries object class which is a
   replacement for the existing groupOfNames class.  The new class
   permits the creation of empty groups.

   If approved as a Standards Track document, this document will update
   RFC4519 [2]

Document Intent

   This document is intended to be, after appropriate review and
   revision, submitted to the RFC Editor as a Standards Track document.
   Distribution of this memo is unlimited.  Technical discussion of this
   document will take place on the IETF LDAP Extensions mailing list
   <[email-masked]>.  Please send editorial comments directly to the
   author <[email-masked]>

1.  Introduction

   A groupOfNames object class has existed since the earliest X.521 [1]
   standard.  It has an identical definition in LDAP (RFC4519 [2]).  The
   class is used to define entries holding DN-valued member attributes,
   each value pointing to an entry that represents a single member of
   the group being described, or to another entry of type groupOfNames.

   groupOfNames is a structural object class, so it is often the only
   class used in the definition of group objects.

   Experience has shown that the definition of groupOfNames causes
   difficulties in practice.  In particular, the fact that 'member' is a
   mandatory attribute means that it is not possible to create an empty
   group or to delete the last member from a group.  This leads to
   artificial tricks such as making every group a member of itself, or
   adding a dummy member to every group when it is created.  These
   tricks in turn make the management of groups more complex and prone
   to error.  Groups are commonly used to control access to resources,
   so management errors can lead to security risks.

   There does not appear to be any good reason for the 'member'
   attribute to be mandatory.  This memo describes a new object class
   called groupOfEntries that is equivalent to groupOfNames in all other
   respects but which makes 'member' an optional attribute.

2.  The existing groupOfNames object class

   RFC4519 [2] contains this definition:

   The 'groupOfNames' object class is the basis of an entry that
   represents a set of named objects including information related to
   the purpose or maintenance of the set.  (Source: X.521 [1])

         ( 2.5.6.9 NAME 'groupOfNames'
            SUP top
            STRUCTURAL
            MUST ( member $
                  cn )
            MAY ( businessCategory $
                  seeAlso $
                  owner $
                  ou $
                  o $
                  description ) )

   The inclusion of 'member' in the 'MUST' section of the definition
   prevents empty groups from being created.

3.  The groupOfEntries object class

   The 'groupOfEntries' object class is the basis of an entry that
   represents a set of named objects including information related to
   the purpose or maintenance of the set.  It should be used in
   preference to the 'groupOfNames' object class.

         ( 1.2.826.0.1.3458854.2.1.1.1 NAME 'groupOfEntries'
            SUP top
            STRUCTURAL
            MUST ( cn )
            MAY ( member $
                  businessCategory $
                  seeAlso $
                  owner $
                  ou $
                  o $
                  description ) )

   This object class allows groups to be empty.  In all other respects
   it behaves like the groupOfNames object class.

   The OID assigned to this object class is delegated by Skills 1st Ltd.

4.  Effect on other documents

   This draft deprecates the use of the groupOfNames object class in
   RFC4519 [2] and replaces it with the groupOfEntries class.

5.  IANA considerations

   It is requested that IANA register upon Standards Action the
   groupOfEntries Object Identifier Descriptor and its associated OID.

6.  Security considerations

   Groups are commonly used to define access permissions to directory
   entries and resources in other services.  Allowing for empty groups
   avoids the risks associated with leaving a dummy placeholder member
   in group entries, so security is improved.

Appendix A.  Acknowledgements

   The author gratefully acknowledges the contributions of Michael
   Stroeder to the first draft of this document.

7.  Informative References

   [1]  "The Directory: Selected Object Classes", ITU-T
        Recommendation X.521, March 1988.

   [2]  "LDAP: Schema for User Applications", RFC 4519, June 2006.

Author's Address

   Andrew Findlay
   Skills 1st Ltd
   2 Cedar Chase
   Taplow
   Maidenhead  SL6 0EU
   GB

   Phone: +44 1628 782565
   Email: [email-masked]
   URI:   http://www.skills-1st.co.uk/

Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   [email-masked].

Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).

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

---

From: Luke Howard <[email-masked]>
Date: Tue, 18 Sep 2007 09:03:25 +1000

Another thing that would be useful might be to define the behaviour of 
nested groups, eg. should the client expand them?

It would make sense to use this object class for rfc2307bis too 
(whenever that is completed :-))

-- Luke

-- 
www.padl.com | www.lukehoward.com

---

From: "Neal-Joslin, Robert (HP-UX Lab R&D)" <[email-masked]>
Date: Mon, 17 Sep 2007 23:21:37 -0000

Hi,

I'm almost always in favor of new and better ways to do things.  And I
agree with the statements submitted.  But I can see a need to play
devil's advocate for this one.  Is there really enough justification to
warrant this proposal?  What is the likelihood of its success, given how
entrenched groupOfNames and groupOfUniqueNames is embedded in the
existing LDAP application/server security space?  This is a very
low-level concept to LDAP, and thus convincing all application/server
developers to revolutionize seems a unlikely scenario.  And I would
argue that it would take a sea-change before it would be successful.
I.E. would this proposal be successful if only 50% or even 75% of
applications/servers support it?

Bob

> -----Original Message-----
> From: Luke Howard [mailto:[email-masked]] 
> Sent: Monday, September 17, 2007 4:03 PM
> To: Andrew Findlay
> Cc: [email-masked]
> Subject: Re: [ldapext] groupOfEntries object class proposal
>

---

From: Luke Howard <[email-masked]>
Date: Tue, 18 Sep 2007 09:29:35 +1000

I suppose another approach would be to redefine groupOfNames with a new OID?

-- Luke

---

From: Howard Chu <[email-masked]>
Date: Mon, 17 Sep 2007 16:59:06 -0700

Neal-Joslin, Robert (HP-UX Lab R&D) wrote:
> existing LDAP application/server security space? 

Ah, you've just hit another hot-button - groupOfUniqueNames is utterly 
pointless. I'm all for eradicating the old stuff and pushing groupOfEntries as 
a standard.

nameAndOptionalUID syntax is inherently broken, it cannot be parsed reliably. 
e.g. - "cn=foo#101" could legitimately be a cn with value "foo#101", there's 
no way to disambiguate it from "cn=foo" with UID "101".

The entire concept behind this syntax is flawed. What do you do if you have a 
"unique" named object with children? What if the children have unique names 
too? There's only provision for one unique ID in the DN, but fundamentally 
there should be the possibility of a unique ID for every RDN in the DN. I.e., 
if this is really what you want, you should have been using multivalued RDNs 
from the get-go.

Probably 99% of LDAP applications never even use the UID portion of a 
nameAndOptionalUID attribute, and the other 1% that use it are broken since 
the syntax is inherently broken.

I'll happily write up a standards track document to deprecate 
groupOfUniqueNames and nameAndOptionalUID syntax.

> This is a very

-- 
   -- 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: "Ramsay, Ron" <[email-masked]>
Date: Tue, 18 Sep 2007 12:44:33 +1000

Why not try to get the appropriate RFC revised to make 'member'
optional?

Even simply making 'member' optional in your own implementations, though
inviting interoperability problems, would seem to have fewer issues than
introducing a new object class. In fact, I think it is common to find
that 'member' is optional inthe field.

-----Original Message-----
From: Neal-Joslin, Robert (HP-UX Lab R&D) [mailto:[email-masked]] 
Sent: Tuesday, 18 September 2007 9:22 AM
To: Luke Howard; Andrew Findlay
Cc: [email-masked]
Subject: RE: [ldapext] groupOfEntries object class proposal

Hi,

Bob

---

From: "Ramsay, Ron" <[email-masked]>
Date: Tue, 18 Sep 2007 12:59:27 +1000

1) The ambiguity is a result of converting the concept to LDAP.
2) I don't think you can use nameAndOptionalUID for naming, certainly
not in the 93 standard. So your comments about children are not really
appropriate. It's sole use may be in the groupOfUniqueNames object where
the UID is acting as a generational qualifier. To fully support it,
though, I think would require a UID attribute in the entry having that
DN. Oh yes, access control is supposed to use it, too. But the qualifier
applies to the DN itself and is making a statement about when THIS DN
was relevant.

-----Original Message-----
From: Howard Chu [mailto:[email-masked]] 
Sent: Tuesday, 18 September 2007 9:59 AM
To: Neal-Joslin, Robert (HP-UX Lab R&D)
Cc: [email-masked]; Luke Howard; Andrew Findlay
Subject: Re: [ldapext] groupOfEntries object class proposal

Ah, you've just hit another hot-button - groupOfUniqueNames is utterly 
pointless. I'm all for eradicating the old stuff and pushing
groupOfEntries as 
a standard.

nameAndOptionalUID syntax is inherently broken, it cannot be parsed
reliably. 
e.g. - "cn=foo#101" could legitimately be a cn with value "foo#101",
there's 
no way to disambiguate it from "cn=foo" with UID "101".

The entire concept behind this syntax is flawed. What do you do if you
have a 
"unique" named object with children? What if the children have unique
names 
too? There's only provision for one unique ID in the DN, but
fundamentally 
there should be the possibility of a unique ID for every RDN in the DN.
I.e., 
if this is really what you want, you should have been using multivalued
RDNs 
from the get-go.

Probably 99% of LDAP applications never even use the UID portion of a 
nameAndOptionalUID attribute, and the other 1% that use it are broken
since 
the syntax is inherently broken.

---

From: Howard Chu <[email-masked]>
Date: Mon, 17 Sep 2007 20:28:51 -0700

> 1) The ambiguity is a result of converting the concept to LDAP.

Granted, but the fact remains that it is unusable in LDAP.

> applies to the DN itself and is making a statement about when THIS DN

It would require the entry to have an x500UniqueIdentifier attribute, yes. So 
far the only standards track schema that uses it is inetOrgPerson.

But you're pointing out a distinction without a difference. If the 
generational qualifier is significant, then it is significant in every context 
where that DN is referenced. E.g.
	cn=bob,o=foo#1 exists
create  cn=my stuff,cn=bob,o=foo

references to "cn=my stuff,cn=bob,o=foo" (and all children of cn=bob,o=foo) 
now depend on that qualifier. If we remove cn=bob,o=foo and come back at a 
later time and create him again, with his child entry
	cn=bob,o=foo#10
	cn=my stuff,cn=bob,o=foo

then there is no way to uniquely reference the "cn=my stuff" child object or 
distinguish it from the previous generation. You cannot separate the relevance 
of "THIS DN" from the uniqueness of its children. If the parent is unique then 
necessarily all of its children are also, but using the nameAndOptionalUID 
syntax doesn't allow this uniqueness to be expressed. The core concept here is 
flawed (yes, in the original X.500 usage as well).

The correct way to handle this is by including the generational qualifier in 
the entry's RDN (making it multivalued), and then you can reference it 
consistently no matter where you need to use it. There is no legitimate use 
for the nameAndOptionalUID syntax at all, in LDAP or X.500.

It's sad, really. They go to the trouble of designing a nice data model with 
consistent naming, then they go and intentionally break it...

---

From: Michael Ströder <[email-masked]>
Date: Tue, 18 Sep 2007 11:40:33 +0200

> I suppose another approach would be to redefine groupOfNames with a new

No! Most applications do not look at the OID.

Ciao, Michael.

---

From: Michael Ströder <[email-masked]>
Date: Tue, 18 Sep 2007 11:44:44 +0200

Neal-Joslin, Robert (HP-UX Lab R&D) wrote:
> What is the likelihood of its success, given how

For those implementations which are not flexible enough this will take
some time. But in my deployments it's simply a matter of configuration.

Note that this draft does not suggest to completely remove groupOfNames
from core schema. The point is just to deprecate its use in newer
deployments.

> I would

web2ldap already supports maintaining groupOfEntries (just
configuration). ;-)

Ciao, Michael.

---

From: Michael Ströder <[email-masked]>
Date: Tue, 18 Sep 2007 11:54:47 +0200

> Why not try to get the appropriate RFC revised to make 'member'

Andrew et al discussed that at LDAPcon. The idea was to stay away from
changing the core LDAPv3 standard specs to avoid too much hassle. IMO
the chance is higher that a new object class specified in a very focused
spec gets easily adopted than all implementors reliably changing an
existing schema element.

> that 'member' is optional inthe field.

Well, LDAP is for good interop. Isn't it?
I'm too often searching for interop bugs because vendors are not
sticking to standards...

Ciao, Michael.

---

From: Neil Dunbar <[email-masked]>
Date: Tue, 18 Sep 2007 11:11:33 +0100

On Tuesday 18 September 2007 00:21:37 Neal-Joslin, Robert (HP-UX Lab R&D) 

> existing LDAP application/server security space?

Well, given that there is already a choice between groupOfUniqueNames and 
groupOfNames, I find that a lot of LDAP apps tend to be parametrised around 
what OC should be considered canonical for the notion of "group". So, in this 
case, sliding in groupOfEntries wouldn't be much of a problem: at least for 
*reading* groups. For creating new ones, that might be irritating. One 
approach might be to sweep periodically and reclassify groupOfNames to 
groupOfEntries within the DIT until apps were writing groupOfEntries 
natively. Since every groupOfNames is also a valid groupOfEntries, you can't 
cause category error by expanding into the superset.

When we shifted to OpenLDAP in HP IT, pretty much all of the Sun ONE groups 
were groupOfUniqueNames - it was a well publicised flag day to shift them 
over to groupOfNames, but I'm pretty sure all apps dealt with the matter 
smoothly. We did some horrible temporary schema hacks before the move, but 
they got tossed as soon as the possibility for group Armageddon had passed 
with very few fatalities.

Cheers,

Neil
-- 
TSL, HP Labs/Office of Strategy and Technology Hewlett-Packard Limited
registered Office:
 Cain Road, Bracknell, Berks
 RG12 1HN                     Registered No: 690597 England

---

From: Andrew Findlay <[email-masked]>
Date: Tue, 18 Sep 2007 12:05:11 +0100

> nested groups, eg. should the client expand them?

A good point, but I would be wary of being too prescriptive here. Some
servers provide an auxiliary object class that causes the groups to
expanded server-side: that would continue to work with groupOfEntries
(though there is a management issue with anything that triggers
server-side tricks). Whether a *client* should expand groups will
depend on why the client wants the group info in the first place, and I
don't think it is necessary to force the issue one way or the other.

It might be worth adding a statement that makes it clear that
a groupOfEntries can have members of *any* type, so nested groups are
explicitly possible. The precise semantics should be defined by the
application schema designer.

> (whenever that is completed :-))

Maybe so, but rfc2307bis is a much more complex issue!

Andrew

---

From: Andrew Findlay <[email-masked]>
Date: Tue, 18 Sep 2007 12:17:27 +0100

> the syntax is inherently broken.

That fits with my experience. I have never yet seen the UID part used,
and no designer who has chosen to use groupOfUniqueNames has ever
given me a good reason for having done so. groupOfUniqueNames also
suffers from the 'no empty groups' problem so it is broken twice over.

> groupOfUniqueNames and nameAndOptionalUID syntax.

Good plan. I had considered doing that in the groupOfEntries draft but
decided that the extra justification required would divert attention
from the main point of that draft.

Andrew

---

From: Andrew Findlay <[email-masked]>
Date: Tue, 18 Sep 2007 12:42:34 +0100

> Why not try to get the appropriate RFC revised to make 'member'

The trouble with changing an existing schema element is that users
would have to synchronise the change across all their clients and
servers. It seems a bad idea to create a situation where each end of a
network connection could be working to a different definition.

> that 'member' is optional inthe field.

That suggests that people are deliberately changing the standard
schema definitions, which is bad because of the interoperability
problems that could be caused.

I never use groupOfNames in my own designs for exactly this reason, so
I always define a new group class that permits empty groups. While
this is an easy thing to do, it appears that many people do not like
to define new classes which leads to nasty hacks and trouble stored up
for the future. I hope that by defining a standard class with the
behaviour that people actually need we can encourage better practices.

Andrew

---

From: "Liben, Michael \(GTI\)" <[email-masked]>
Date: Tue, 18 Sep 2007 09:19:24 -0400

This approach gets my vote. Is it practical? 

-----Original Message-----
From: Neal-Joslin, Robert (HP-UX Lab R&D) [mailto:[email-masked]] 
Sent: Tuesday, 18 September 2007 9:22 AM
To: Luke Howard; Andrew Findlay
Cc: [email-masked]
Subject: RE: [ldapext] groupOfEntries object class proposal

Hi,

Bob

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

This message w/attachments (message) may be privileged, confidential or proprietary, and if you are not an intended recipient, please notify the sender, do not use or share it and delete it. Unless specifically indicated, this message is not an offer to sell or a solicitation of any investment products or other financial product or service, an official confirmation of any transaction, or an official statement of Merrill Lynch. Subject to applicable law, Merrill Lynch may monitor, review and retain e-communications (EC) traveling through its networks/systems. The laws of the country of each sender/recipient may impact the handling of EC, and EC may be archived, supervised and produced in countries other than the country in which you are located. This message cannot be guaranteed to be secure or error-free. This message is subject to terms available at the following link: http://www.ml.com/e-communications_terms/. By messaging with Merrill Lynch you consent to the foregoing.
--------------------------------------------------------

---

From: Andrew Findlay <[email-masked]>
Date: Tue, 18 Sep 2007 15:17:38 +0100

> Why not try to get the appropriate RFC revised to make 'member'

It is clearly *possible* to change the definitions in most existing
LDAP servers. We know that people do it (breaking the standard in the
process). However, I cannot see IETF accepting the re-definition of an
existing class when a cleaner solution is available. (though if the
community *is* prepared to redefine existing things then I have a much
longer list of targets :-))

Adding a new object class to most servers is very easy. I have direct
experience of this with OpenLDAP, IBM Tivoli Directory Server, and
Oracle Internet Directory. In each case I could give you a small file
and simple instructions to add the groupOfEntries class, so
implementors would not have to wait for server suppliers to roll it
into a new release.

People running existing LDAP systems would have a choice: stick with
groupOfNames and its associated workarounds, or switch to
groupOfEntries. IF they choose to switch, they should audit the
searches and writes done by client applications to see whether any
changes are needed.

People designing new systems would also have the same choice, but
adopting groupOfEntries would give them benefits.

Andrew

---

From: Steven Legg <[email-masked]>
Date: Wed, 19 Sep 2007 09:33:00 +1000

Andrew,

> behaviour that people actually need we can encourage better practices.

Instead of defining a specific object class, perhaps all we need is a
*convention* that any entry that contains the member attribute is to
be treated as a group.

Regards,
Steven

---

From: Steven Legg <[email-masked]>
Date: Wed, 19 Sep 2007 09:35:41 +1000

Andrew,

> application schema designer.

The advantage of *not* having nested groups is that it is sufficient
to just read the values of the member attribute to determine group
membership. If there are nested groups, then it is necessary to
read each of the entries named in the values of the member attribute
to see which of them, if any, are themselves groups. That could be
a big performance hit for a group with a large set of members.

If nested groups are to be allowed, then I would rather see the
nested groups listed in a separate attribute, e.g., called nestedGroups,
so that implementations only need to read the entries that really
are nested groups.

Regards,
Steven

---

From: Luke Howard <[email-masked]>
Date: Wed, 19 Sep 2007 09:48:14 +1000

> so that implementations only need to read the entries that really
This is what Novell did with eDirectory (they also have an option where 
nested members are presented as values of member).

AD and rfc2307bis, however, simply have groups listed a values of 
member; the client is responsible for dereferencing and transiting if 
required.

-- Luke

---

From: Andrew Findlay <[email-masked]>
Date: Wed, 19 Sep 2007 09:49:10 +0100

> *convention* that any entry that contains the member attribute is to

It would still need an object class that permits the member attribute.
How would such a convention represent an empty group?

Andrew

---

From: Michael Ströder <[email-masked]>
Date: Wed, 19 Sep 2007 11:34:22 +0200

Changed subject because this is another thing to discuss.

> a big performance hit for a group with a large set of members.

I fully agree. One really has to think twice whether nested groups are
really needed in a particular use-case and worth the performance hit.

> so that implementations only need to read the entries that really

+1

Ciao, Michael.

---

From: Michael Ströder <[email-masked]>
Date: Wed, 19 Sep 2007 11:41:34 +0200

> *convention* that any entry that contains the member attribute is to

My first impression was that this would change the semantics of the
member attribute defined in the core schema and I'd like to stay out of
that business. But RFC 4519 already states something similar:

------------------------------- snip -------------------------------
2.17.  'member'

   The 'member' attribute type contains the distinguished names of
   objects that are on a list or in a group.  Each name is one value of
   this multi-valued attribute.
   (Source: X.520 [X.520])
------------------------------- snip -------------------------------

Hmm, I'm not sure whether some deployments (ab)use 'member' for other
purposes.

Ciao, Michael.

---

From: Michael Ströder <[email-masked]>
Date: Wed, 19 Sep 2007 11:45:30 +0200

> How would such a convention represent an empty group?

I guess Steven meant that it would be sufficient to simply search for

(member=<DN>)

for determining group membership for <DN> instead of

(&(|(objectClass=groupOfNames)(objectClass=groupOfEntries))(member=<DN>))

So one could use any object class for group entries which suits the
deployment needs as long as it permits 'member'.

Ciao, Michael.

---

From: Andrew Findlay <[email-masked]>
Date: Wed, 19 Sep 2007 11:46:44 +0100

> a big performance hit for a group with a large set of members.

Good point. Servers have more options here, but a client dealing with
nested groups has to do a silly amount of work.

> so that implementations only need to read the entries that really

That would be a great improvement in efficiency. There would also need
to be an auxiliary object class to identify groups that might contain
such attributes - nestedGroupObject or perhaps groupOfGroups.
(Or the groupOfEntries class could permit the nestedGroup attribute as
well as the member attribute. I think I would prefer a separate
class.)

> nested members are presented as values of member).

It is certainly more efficient if the server is prepared to do things
like that, but it does require new code so it is less likely to
implemented by all servers. There is also the question of how to
manage such an entry as the client clearly cannot read the member
attributes and send updates based on what it sees.

> member; the client is responsible for dereferencing and transiting if 

There are enough performance problems with LDAP NIS group methods
already! Adding client-side nested groups can only make it worse...

> > so that implementations only need to read the entries that really

It looks as if the nested groups issue needs tackling. Should I expand
this I-D to include it? The consensus seems to be:

1)	groupOfEntries member attributes should not point to groups
	whose members are to be considered part of the group being
	described.
	
	I see no problem with allowing them to point to groups if
	expansion/nesting/inclusion is not required.

2)	There should be a new aux class and attribute to support
	client-side group nesting.

	Servers can support group nesting in more efficient ways and
	some of them already do. Should there be an attempt to
	standardise the schema that supports this?

Andrew

---

From: "Liben, Michael \(GTI\)" <[email-masked]>
Date: Wed, 19 Sep 2007 09:43:45 -0400

The nestedGroup attribute may not add much value. The members of the group would still need to be examined individually to determine if they in turn contain the member attribute.

-----Original Message-----
From: Andrew Findlay [mailto:[email-masked]] 
Sent: Wednesday, September 19, 2007 6:47 AM
To: Steven Legg; Luke Howard; Michael Ströder
Cc: [email-masked]
Subject: [ldapext] Nested group (was: groupOfEntries object class proposal)

	

Andrew

---

From: Andrew Findlay <[email-masked]>
Date: Wed, 19 Sep 2007 15:04:32 +0100

On Wed, Sep 19, 2007 at 09:43:45AM -0400, Liben, Michael (GTI) wrote:

> The nestedGroup attribute may not add much value. The members of the
> group would still need to be examined individually to determine if they
> in turn contain the member attribute.

Only the nestedGroup members would have to be expanded. 'member'
attributes would only point to direct members, so they would not need
to be read.

In a group with 5000 direct members and 25 nested groups the
client could avoid 5000 operations when looking to see if a particular
entry is a member. It would only need to expand the 25 nested groups,
and would not even have to read the direct member entries.

Andrew

---

From: simo <[email-masked]>
Date: Wed, 19 Sep 2007 10:07:00 -0400

> nested groups has to do a silly amount of work.

No, its not a good point, as that happens only if the designer of the
directory decides to use this feature.
If he so decides, he knows the limits and the problems he goes on doing
that and it is his responsibility.

Let's not try to be smarter than necessary, a schema should not be used
to enforce a way to do things.

> well as the member attribute. I think I would prefer a separate

I really don't see any value in using a different attribute.
An apple is always an apple even if you call it orange. If that
attribute is present, the client has to do all the work anyway.
The only difference is that you have to use a more complex filter to
show the members of a group and probably also 2 indexes instead of just
one.

> > nested members are presented as values of member).

Which is bad because at that point the client have no way to tell which
group exactly a user is member of. It is good only for simple
authorization schemes (and was probably done to keep old unix clients
happy).

> attributes and send updates based on what it sees.

exactly, it is just a hack, necessary in some cases, but just an hack.

> already! Adding client-side nested groups can only make it worse...

It's up to you to use nested groups or not. It's not mandatory, and
doing it client side has also benefits.

Suppose I need to check user A is in group A, where group A has 128 sub
groups, with others again.
Now if you do server side resolution at each query of the member
attribute you have to fully unwind all groups every time (sure caching
helps), instead if you are a client, you can stop at the first group you
find containing the user (in case it is group A it is much more
convenient). Also, clients smart enough to understand nested groups, can
probably be smart enough to do some smart caching, and beating the
server a lot less often.

> this I-D to include it? The consensus seems to be:

FWIW I think your original proposal is much simpler, and lets architects
decide what to do without artificial separations of members depending on
the fact they are groups or users.

Also it is more consistent, what if I have an Entry object listed as
emmebr in another that lately is added a groupOfEntries objectclass to?
Should the server go around all other groupOfEntries objects in search
for members to be changed to nestedGroupObject ?

Keeping it just a member make this a non-issue from the consistency PoV.

> 	expansion/nesting/inclusion is not required.

I see no problem, full stop. It's the architect responsibility to find
the right trade-off .

> 	standardise the schema that supports this?

IMHO no.

Simo.

-- 
Simo Sorce
Samba Team GPL Compliance Officer
email: [email-masked]
http://samba.org

---

From: Andrew Findlay <[email-masked]>
Date: Wed, 19 Sep 2007 16:21:41 +0100

> show the members of a group and probably also 2 indexes instead of just

The efficiency gain comes from not having to read the entries of the
direct members just to find out whether they are actually nested
groups or not. This could make a massive difference in cases where a
group has a lot of direct members as well as a few nested groups.

The complexity in determining whether a given DN is a member of
a potentially-nested group is much the same whether we use 'member'
for everything or 'member' and 'nestedGroup', but using the two
different attributes can save a vast number of LDAP operations.
Consider this algorithm:

IsAMember( subjectDN, groupDN ) {
	Match subjectDN against 'member' attribute of group entry:
	stop if it matches, the DN is a member.

	for each nested group {
		if IsAMember( subjectDN, nestedGroupDN )
		then stop, the DN is a member.
	}

	The DN is not a member
}

The first match is a single LDAP search on the basic group entry.

The foreach loop requires one LDAP search on the base, plus:

	If we only use 'member' attributes,
	one LDAP search on each member to find out what it is
	before calling the procedure recursively on each nested group.

	If we separate direct members from nested groups using
	different attributes, we recurse immediately with no extra
	LDAP ops.

Hmm: I think the different-attributes case is actually *simpler* to
code. The algorithm for enumerating members is almost identical.

> authorization schemes (and was probably done to keep old unix clients

This sort of thing has a value in many authorisation cases. Clients
often need to know 'is this user allowed to do X' where the permission
is expressed as membership of a group. Nested groups are extremely
useful in this scenario as you often want one level to classify the
users by roles and a second level to define what each role is allowed
to do. The client just wants a yes/no answer and is not often
interested in which group membership chain actually permitted the
access. If the server supports server-side nesting then a single LDAP
search will answer the question.

> doing it client side has also benefits.

Indeed, and I would not want to stop anyone doing so.

> probably be smart enough to do some smart caching, and beating the

Servers can also take advantage of the fact that group membership
changes a lot less often than it is tested, and pre-calculate it when
entries are added or changed. The server has full knowledge in most
authentication/authorisation scenarios, so it can be *much* more
efficient than a client when doing these tests.

> the fact they are groups or users.

It is simpler and I would not want to complicate it without good
reason, hence this discussion.

> for members to be changed to nestedGroupObject ?

I am not sure that I understand your point there. Remember that
groupOfEntries is a STRUCTURAL class, so it cannot be added to an
existing entry or removed from one.

Andrew

---

From: simo <[email-masked]>
Date: Wed, 19 Sep 2007 12:42:12 -0400

> code. The algorithm for enumerating members is almost identical.

-	for each nested group {
+	for each member {

The algorithm complexity is the same, although, it is true, a client may
require more operations.

Actually I think this problem would be better solved by a control to ask
the server to do the calculations for us (and IIRC there is a control
like that in the AD implementation called ASQ or something like that)
and use a cache, so we have both an efficient way to do it and avoid the
artificial distinction.

> search will answer the question.

Yes, true, a control that allow you to do that would be a good thing,
but it is just convenient, not mandatory, doing the "un-rolling" by
default is what I think is bad.

> Indeed, and I would not want to stop anyone doing so.

No doubt :)

> efficient than a client when doing these tests.

Yep a control would be the right place to do a complex operation like
that, still does not warrant a different attribute imo.

> reason, hence this discussion.

Yep, I was just posting my opinion in favor of simplicity.

> existing entry or removed from one.

AHHH Right, that was the other thing in the back of my mind that kept
bogging me, but I forgot to post about it.

STRUCTURAL classes are often annoying and I think they should be used
only when the object is meant to be incompatible with other ones and/or
embed a unique new concept that should make it naturally incompatible
with other objectClasses.

What is the reasoning for it being STRUCTURAL here?

Simo.

---

From: "Liben, Michael \(GTI\)" <[email-masked]>
Date: Wed, 19 Sep 2007 13:07:13 -0400

This anticipates a reliable mechanism that ensures direct members are not added to the nestedGroups attribute and that nested groups are not inadvertently added to the member attribute. How would the server respond if an object is included in both attributes?

-----Original Message-----
From: simo [mailto:[email-masked]] 
Sent: Wednesday, September 19, 2007 12:42 PM
To: Andrew Findlay
Cc: [email-masked]; Luke Howard; Steven Legg; Michael Ströder
Subject: Re: [ldapext] Nested group (was: groupOfEntries object class proposal)

No doubt :)

Simo.

---

From: Howard Chu <[email-masked]>
Date: Wed, 19 Sep 2007 10:08:06 -0700

> The algorithm complexity is the same, although, it is true, a client may

You're saying "in theory these are the same." That may be true, but in 
practice, your "simplification" creates more work both the client and the 
server. We can do better, therefore we should.
-- 
   -- 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: Andrew Findlay <[email-masked]>
Date: Wed, 19 Sep 2007 18:32:57 +0100

> and use a cache, so we have both an efficient way to do it and avoid the

Server support would certainly be valuable in many cases and a control
sounds like a good way to ask for it. However, I think that is
orthogonal to the question of whether there should be two attributes.

Consider the case of a group giving access to some resource. As the
owner of the resource I have control of the group, so I can give user
X access to it by putting the DN of X's entry into the group as a
member. I might also control another group called Q whose members
should have access to the resource so I add that too. So far so good,
but if there is no distinction between leaf members and nested groups
*in the group entry itself* it would be possible for user X to give
access to my resource to other people by adding member attributes to
his own entry. As the resource owner I would not want that to be
possible. This alone seems like a good reason not to allow nesting via
the 'member' attribute.

> What is the reasoning for it being STRUCTURAL here?

I also avoid structural classes where possible. In this case it seems
reasonable though. A group is a fairly basic concept and if it did not
have a structural class of it own then group objects would have to be
based on something else. The closest I can think of is
organizationalUnit, but that is not really a good model for the common
uses of groups to control authorisation.

A further reason for it being structural is that groupOfNames is
structural. If groupOfEntries is to replace it then this should not
change.

Andrew

---

From: Andrew Findlay <[email-masked]>
Date: Wed, 19 Sep 2007 19:01:27 +0100

On Wed, Sep 19, 2007 at 01:07:13PM -0400, Liben, Michael (GTI) wrote:

> This anticipates a reliable mechanism that ensures direct members
> are not added to the nestedGroups attribute and that nested groups are
> not inadvertently added to the member attribute.

I don't think there needs to be any server-side control on that. There
are many cases in LDAP where the protocol and schema allow the client
to do 'silly' things. If we try to tie things down too hard there is
no room for flexibility. A designer can choose to use ACLs or
structure definitions to apply some measure of control, or can rely on
'business logic' in the update process to do so.

> How would the server respond if an object is included in both attributes?

OK, suppose we have a group A containing nestedGroup B and members B
and C.  B is itself a group containing members D and E.

If server-side nesting/expansion is *not* requested then there is no
issue: it is up the client to interpret the data (though it would be
good to define the algorithm so that client and server get the same
results!).

If server-side support *is* requested, then:

Group expansion of A results in a list of member attributes:
	B C D E

It so happens that one of those DNs is a group. The others could be
anything. I see no problem here.

Now, if C is added to group B as a member, the expansion will find C
twice. The server should suppress the duplicate.

Andrew

---

From: simo <[email-masked]>
Date: Wed, 19 Sep 2007 14:08:35 -0400

> possible. This alone seems like a good reason not to allow nesting via

This is an interesting view, but clashes with the fact that
groupOfEntries is defined STRUCTURAL, so it is not possible for a user
to add this class to its own object (and even if it were possible you
imply that user X has access to his own entry which is usually not true)
and therefore not possible to add members.

If you agree I'd say this is a non issue and would not consider it in
the debate.

> structural. If groupOfEntries is to replace it then this should not

Make sense, I was interested in the reason, and actually the scenario
above is more a reason for keeping groupOfNames structural than a reason
to keep 2 separate attributes.

Simo.

---

From: simo <[email-masked]>
Date: Wed, 19 Sep 2007 14:16:00 -0400

> 'business logic' in the update process to do so.

The problem is that you have a generic "DN" container that is given
specific semanthics. IE nestedGroupObject is supposed to contain only
entries that have groupOfEntries as its STRUCTURAL class, but you do not
enforce it. So it may contain anything. Same for member.

This just means clients have to cope with bad entries.

I think that the problem is caused by artificial separation of members
in 2 classes.

> twice. The server should suppress the duplicate.

The server will always have to suppress duplicates, this is not a
problem.

You will have the same in this perfectly legit scenario:

Group A contains Group B and Group C
Group B has users a, b, c
Group C has users a, d, e

Also another thing servers and clients MUST be aware is that this may
introduce recursion problems

Group A -memberof-> Group B -memberof-> Group A -repeat ad nauseam-|

Nested groups have advantages and issues, but that's not what we are
discussing, we are discussing whether splitting membership in 2
attributes by type is good or not, AFAICT.

Simo.

---

From: simo <[email-masked]>
Date: Wed, 19 Sep 2007 14:27:37 -0400

> server. We can do better, therefore we should.

"Better" depends on the context I guess.
Simo.

---

From: Andrew Findlay <[email-masked]>
Date: Wed, 19 Sep 2007 19:43:04 +0100

> and therefore not possible to add members.

That depends on whether the expansion rule incudes a check on the
objectclass of the nested groups. I was expecting it to work with any
entry that contains member attributes, in order to allow for a mix of
groupOfEntries and other group-like things that have been given an aux
class to permit members (e.g. organizationalUnit might sometimes get
this).

Perhaps my example was not general enough anyway. Maybe user X is in
some part of the tree controlled by different administrators. I am
prepared to grant access to my resource to that one user, but I dont
want one of 'their' admins replacing the user entry with a group that
gets expanded. This is like X.509 certificate authorities: they will
give you a cert for your own ID but not one that allows you to certify
others. We are talking about control and trust here, and trust is not
always transitive.

Andrew

---

From: Howard Chu <[email-masked]>
Date: Wed, 19 Sep 2007 11:48:34 -0700

> enforce it. So it may contain anything. Same for member.

As usual, garbage-in-garbage-out. You can probably implement enforcement in 
the server, but that doesn't need to be mandated in the specification. There 
are plenty of standards track schema elements that use a very general syntax, 
but whose description says a value of a particular form is expected.

Also, even if the server doesn't enforce the semantics, the end result is a 
benign failure. I.e., if someone puts the DN of a groupOfEntries into the 
member attribute of a group, the worst that can happen is that those group 
members will not get the privilege that group membership was intended to 
convey. You cannot introduce a security breach here by accidentally giving 
privilege to a larger member set than intended. Likewise, the worst that can 
happen by putting the DN of a non-group entry into a nestedGroup attribute is 
that that specific user will not have his intended privilege.

On the other hand, by throwing everything together into a single member 
attribute, you can accidentally nest groups together and there is no obvious 
audit trail that will highlight your mistake. Compartmentalization here is a 
good thing, from a security standpoint.

---

From: Howard Chu <[email-masked]>
Date: Wed, 19 Sep 2007 11:56:30 -0700

Liben, Michael (GTI) wrote:
> This anticipates a reliable mechanism that ensures direct members are not
added to the nestedGroups attribute and that nested groups are not
inadvertently added to the member attribute. How would the server respond if
an object is included in both attributes?

Actually that's not a requirement. A group can legitimately be a user in LDAP. 
It may be perfectly valid for a group object to appear in both the member and 
nestedGroup attribute. It would be meaningless for a non-group object to 
appear in the nestedGroup attribute. Whether that should be rejected or 
silently ignored is an open question, but pretty trivial either way.
-- 
   -- 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: "Liben, Michael \(GTI\)" <[email-masked]>
Date: Wed, 19 Sep 2007 15:01:34 -0400

In Active Directory, Microsoft maintains 'back link' attributes. One of
these is memberOf. When an object is added or removed from a group, a
process runs that updates the back link attribute on the object. If the
member object is moved or deleted, another process updates the group's
member attribute accordingly. 

Clients still have to evaluate all of the members to determine a nested
resultant set of members. However, clients can easily view all the
groups to which an object is a member, walking up the tree instead of
downward.

---

From: Howard Chu <[email-masked]>
Date: Wed, 19 Sep 2007 12:04:57 -0700

> orthogonal to the question of whether there should be two attributes.

Digressing down this path briefly... Such a control should probably have a 
depth/recursion limit as a parameter. Servers would have to be smart about how 
this control is propagated in a distributed environment, e.g. if certain 
nestedGroup DNs reside on remote servers. (Though in practice, just as with 
search limits, clients will probably most often ask for "unlimited" and leave 
it up to the server to restrict it.)
-- 
   -- 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: simo <[email-masked]>
Date: Wed, 19 Sep 2007 15:27:25 -0400

> good thing, from a security standpoint.

While I agree with the general concept, I don't with the specific
example. If you accidentally put a group into the member attribute you
can as well put it accidentally into the nestedGroup one as well.
I don't see why one should me more probable than the other.

Simo.

---

From: simo <[email-masked]>
Date: Wed, 19 Sep 2007 15:32:34 -0400

> others. We are talking about control and trust here, and trust is not

Sorry but I see a fault here as well.
Once you add, as a member, a user controlled by a foreign entity your
security is already screwed if you don't trust that entity.
If you trust it then you trust they will not try to use their power to
exploit your system.
That said, this example makes much more sense.

Simo.

---

From: "Neal-Joslin, Robert (HP-UX Lab R&D)" <[email-masked]>
Date: Wed, 19 Sep 2007 19:39:18 -0000

> that that specific user will not have his intended privilege.

What?  It seems to me you are assuming how the security policy makes
use of the group (only for granting of privledge).  Membership in a
group can also (and is) used by a security policy to DENY access.
This is one reason I brought up my original concern.

---

From: Pete Rowley <[email-masked]>
Date: Wed, 19 Sep 2007 12:23:05 -0700

Howard Chu wrote:
> Also, even if the server doesn't enforce the semantics, the end result 
> is a benign failure. I.e., if someone puts the DN of a groupOfEntries 
> into the member attribute of a group, the worst that can happen is 
> that those group members will not get the privilege that group 
> membership was intended to convey. You cannot introduce a security 
> breach here by accidentally giving privilege to a larger member set 
> than intended. Likewise, the worst that can happen by putting the DN 
> of a non-group entry into a nestedGroup attribute is that that 
> specific user will not have his intended privilege.
>
Any divergence from the intended membership and the derived membership 
of a group used for security purposes can introduce a security breach. 
Any access control mechanism that allows an explicit denial of  
privilege would be an issue.

-- 
Pete

---

From: Howard Chu <[email-masked]>
Date: Wed, 19 Sep 2007 12:50:12 -0700

> privilege would be an issue.

Right, point taken, thanks.
-- 
   -- 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: Andrew Findlay <[email-masked]>
Date: Wed, 19 Sep 2007 22:03:10 +0100

> If you trust it then you trust they will not try to use their power to

True, but the separation of attributes can limit how much of my
resource a malicious admin can give away.

Howard's suggestion of a limit on the 'expand groups' control leads to
another idea: split the nestedGroup attribute into two again:

	nestedGroupOfEntries
		The group entry that we point to can only contain
		leaf-nodes

	nestedRecursiveGroup
		The group entry that we point to may contain further
		nested groups as well as leaf-nodes.

That would give a structural way to limit the nesting of groups.
The expansion algorithm is now slightly larger, but not exactly
complex.

> That said, this example makes much more sense.

Thanks. The discussion is certainly helping me to clarify some ideas.

Andrew

---

From: simo <[email-masked]>
Date: Wed, 19 Sep 2007 18:27:53 -0400

> resource a malicious admin can give away.

How? The malicious admin has already full access to the resources he can
have access to, he does not need more. The "malicious" one, will never
add other entries, as you would spot them monitoring the system, he will
just use the one "you" gave access to, to not make you suspect.

> 		nested groups as well as leaf-nodes.

Why not also:

nestedRecursiveGroupTwoLevels
nestedRecursiveGroupOnlyThirdLevelButNotFirstOrSecond
SCNR :-)

Seriously, this may seem a good idea on the paper, but what people will
use in the end is always nestedRecursiveGroup as soon as they get burned
with the limitation of nestedGroupOfEntries.
So you will effectively gain nothing, except adding complexity.

I don't think we should be in the business of deciding policies, just
providing generic mechanisms that architects can use. They will add the
policies they think they need on top.

Simo.

---

From: Pete Rowley <[email-masked]>
Date: Wed, 19 Sep 2007 16:46:46 -0700

> was felt to be a significant problem.
So the discussion about this highlights the basic issues around the 
current approach to grouping. Fundamentally there are two classes of 
user for a grouping mechanism 1) those who need to know how to build and 
generally administer groups 2) those who need to use groups but care not 
a whit how they came to be. Currently, every time a new group type is 
invented both classes need to understand all the ins and outs of the new 
group type and they must agree on what those ins and outs mean.

This is broken. Non-administrative clients should be able to write to a 
single group interface once and forever after be left to get on with 
clientship.  Innovation for the first class of user is then left to 
prosper without hindrance, without client breakage, and without chickens 
and eggs. There is a suitable way to do this: the memberof attribute, if 
populated it will supply all the needs of the second class of user both 
now and into the future, it even solves some of sticky performance 
problems around gathering suitable attribute values from each memberof 
the group. It is also agnostic to method of attaining membership, 
membership simply is.

Agreeing on something like this will allow the conversation to move 
forward on the mechanisms of group membership without requiring clients 
and servers to be modified every time a new method is developed. It 
allows for both proprietary and custom grouping mechanisms without 
stepping on toes or requiring IETF sanction to be generally useful and 
so reduces the barrier to adoption. Most of all, it is a stable platform 
for interoperability for at least the second class of user.

-- 
Pete

---

From: Howard Chu <[email-masked]>
Date: Wed, 19 Sep 2007 17:16:33 -0700

> the group. It is also agnostic to method of attaining membership, 

Ah, if only it were so easy. But will memberOf expand for recursions? If user 
A is a member of a group B that is nested in group C, will it list only group 
B or both group B and group C? Attacking the problem from the opposite 
direction doesn't actually eliminate the question of whether and how nesting 
should be handled. All of the same ambiguities still exist.
-- 
   -- 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: Steven Legg <[email-masked]>
Date: Thu, 20 Sep 2007 10:38:56 +1000

Andrew,

> How would such a convention represent an empty group?

I stated it badly. What I meant was: any entry of an object class that
permits the member attribute is to be treated as a group. An empty group
is an entry of an object class where the member attribute is defined to
be optional, and the member attribute does not currently appear in the
entry. The convention could also be extended object classes where the
member attribute is permitted by a content rule.

Regards,
Steven

---

From: Kurt Zeilenga <[email-masked]>
Date: Wed, 19 Sep 2007 14:19:57 +0100

X.501:
> The definition of information objects such as object classes,  
> attribute types, matching rules and name forms which have been  
> registered (i.e., assigned a name of type object identifier) are  
> static and cannot be modified. Changes to the semantics of such  
> information objects require the assignment of new object identifiers.

BCP 118 [RFC 4512]:
>    Published schema elements SHALL NOT be redefined.  Replacement  
> schema
>    elements (new OIDs, new NAMEs) SHOULD be defined as needed.

-- Kurt

---

From: Kurt Zeilenga <[email-masked]>
Date: Wed, 19 Sep 2007 14:20:02 +0100

Andrew,

Glad to see you following through on this.

 > The LDAP groupOfEntries object class

I don't like the name of the class.  It's not a group of entrys, but  
a group of names of objects (entries), in particular a group of  
distinguished names.  I suggest the class be named 'groupOfDNs'.

> Abstract
>
>    This memo describes the LDAP groupOfEntries object class

I suggest:
	This memo describes the LDAP/X.500 'groupOfEntries' object class...

> which is a
>    replacement for the existing groupOfNames class.

I rather the I-D say:
	... for representing groups.  The new class is introduced as an  
alternative to the 'groupOfNames' class.

I dislike any language that suggests this new class deprecates the  
groupOfNames.   I rather the I-D propose an alternative to  
groupOfNames, and leave the choice of which group class to use to  
directory applications (preferable stated in an applicability  
statement).

> The new class

I suggest:
	Unlike 'groupOfNames', 'groupOfEntries' can represent a group whose  
membership is empty.

>    If approved as a Standards Track document, this document will  
> update RFC4519 [2]

I recommend this I-D propose an extension, not an update any document  
(e.g., RFC 4519) which is part of the LDAP technical specification  
[RFC 4510].  In particular, I recommend this I-D not "update" RFC  
4519.  That is, I recommend this sentence be stricken.

(Editorial note: no citations should be used within the Abstract of  
the document.)

> 1.  Introduction

I think the Introduction doesn't stand well be itself.  That is, it  
seems to rely on information provided in the Abstract.  I suggest the  
Introduction start by restating (in new words, with cites), and  
expanding upon, the Abstract.

>    standard.  It has an identical definition in LDAP (RFC4519 [2]).

I suggest the second sentence read:
	An LDAP [RFC4510] description [RFC4512] for this class is provided  
in RFC 4519 [RFC4519].

I suggest you then include the LDAP description:
	That description is:
		      ( 2.5.6.9 NAME 'groupOfNames' SUP top STRUCTURAL
			MUST ( member $ cn )
			MAY ( businessCategory $ seeAlso $ owner $ ou $ o $ description ) )

> The

I suggest
	The class is used to represent groups of names.

>    the group being described, or to another entry of type  

Suggest:
	Each group object may contain a 'member' [X.520][RFC4519] attribute  
whose values are name members.  Each value is a distinguished name of  
an object.  The entity represented by the named object is consider a  
member of group.  If the member attribute is not present in the  
object, the group membership is empty.

Which raises an interesting question which the I-D needs to address:  
how does a DUA determine reading a group returned without any member  
attribute determine whether the group is empty or wether the DSA was  
unwilling (or unable) to provide the membership?  The DSA could, I  
guess, return member without its values to represent the group was  
non-empty and only return the entry less the member attribute if the  
entry didn't contain member.  However, this is likely problematic.  I  
think this needs further list discussion.

>    so management errors can lead to security risks.

Yes.  For instance, if one adds the empty DN to a group is  
problematic as the empty DN is often used to represent anonymous  
users, hence adding an empty DN to member implies anonymous users are  
members of the group.

> 2.  The existing groupOfNames object class

I would fold this section into the Introduction.
>    the purpose or maintenance of the set.  (Source: X.521 [1])

I now notice this description is bit off.  The X.521 description is  
better: "The Group Of Names object class is used to define entries  
representing an unordered set of names which represent individual  
objects or other groups of names."  I rather include the X.521 text  
(early in the Introduction).

> 3.  The groupOfEntries object class

I rather the description of this class instead be a rewording of the  
X.521 groupOfNames description.
>    preference to the 'groupOfNames' object class.

I think the last sentence should be stricken (see above).
>    RFC4519 [2] and replaces it with the groupOfEntries class.

I think this section should be stricken (see above).

I suggest adding a section here addressing the 'interesting question'  
I raised above.

There should also be a section discussing nested group semantics.   
This needs further discussion I think. From [email-masked] Wed Sep 19 21:23:02 2007
From: Kurt Zeilenga <[email-masked]>
Subject: Re: [ldapext] groupOfEntries object class proposal
Date: Wed, 19 Sep 2007 14:19:57 +0100
To: "Ramsay, Ron" <[email-masked]>
Cc: [email-masked], Andrew Findlay <[email-masked]>

-- Kurt

---

From: Kurt Zeilenga <[email-masked]>
Date: Wed, 19 Sep 2007 18:37:56 -0700

On Sep 18, 2007, at 12:03 AM, Luke Howard wrote:

> Another thing that would be useful might be to define the behaviour  
> of nested groups, eg. should the client expand them?

The entity making use of the group should do the expansion.  If a DSA  
is using them in access controls, then it should expand them.  If a  
DUA is using them for its purposes, it should expand them.  That is,  
same semantics/expectations as groupOfNames nested groups.

If there is desire to introduce a group class with a different  
semantic/expectations, I think it should be proposed separately.

-- Kurt

---

From: Steven Legg <[email-masked]>
Date: Thu, 20 Sep 2007 12:43:48 +1000

> that and it is his responsibility.

But how does a directory client know that the directory administrator is
using nested groups in the member attribute ? It would have to read the
entries listed in the member attribute to find out, so it incurs the
overhead even if nested groups are not being used. On the other hand,
the presence of a nestedGroup attribute is a dead giveaway, and also
limits the amount work the client has to do when nested groups are
being used.

Regards,
Steven

---

From: Steven Legg <[email-masked]>
Date: Thu, 20 Sep 2007 13:06:44 +1000

Andrew,

Andrew Findlay wrote:
> this I-D to include it?

I think that would be a good idea.

 > The consensus seems to be:
> 

It is okay to restrict the interpretation of the member attribute
as an attribute of the groupOfEntries object class, but if we
consider a group as being any entry of an object class that
permits a member attribute (and/or the nestedGroup attribute),
then restricting the interpretation of the member attribute in the
more general context will conflict with some current deployments.
If we are going to allow a variety of object classes to define groups,
then we should define a new attribute, e.g., called directMember, to
replace the member attribute.

Regards,
Steven

---

From: Luke Howard <[email-masked]>
Date: Thu, 20 Sep 2007 14:44:59 +1000

> member attribute accordingly. 
This isn't quite correct. Linked references are maintained in a separate 
table in the DIB, and returned dynamically at search time. The 
background process you're referring to handles references (linked or 
not) to entries in non-local partitions.

-- Luke

---

From: Michael Ströder <[email-masked]>
Date: Thu, 20 Sep 2007 10:00:09 +0200

Andrew Findlay wrote:
> 
> It looks as if the nested groups issue needs tackling.

Which is IMO out of scope.

> Should I expand this I-D to include it?

-1

+1

But the client MAY do expansion of nested groups.

> 	standardise the schema that supports this?

The nested group thing should be defined in a separate draft defining a
separate AUXILIARY object class.

Ciao, Michael.

---

From: Michael Ströder <[email-masked]>
Date: Thu, 20 Sep 2007 10:34:11 +0200

Michael,

please keep citations for reference.

Liben, Michael (GTI) wrote:
>> [..discussion about separate attribute for nested groups..]
> This anticipates a reliable mechanism that ensures direct members are
> not added to the nestedGroups attribute and that nested groups are

Good point. But note that this is a pertinent problem with many
attributes where additional constraints are defined in a specification
but cannot be enforced by most server implementations.

> How would the server
> respond if an object is included in both attributes?

If the server can detect this I'd think 'constraintViolation' would be
appropriate.

Ciao, Michael.

---

From: Michael Ströder <[email-masked]>
Date: Thu, 20 Sep 2007 10:34:11 +0200

Michael,

Ciao, Michael.

---

From: Michael Ströder <[email-masked]>
Date: Thu, 20 Sep 2007 10:35:58 +0200

simo wrote:
> the server to do the calculations for us

Or better an extended operation?
Some query like "Is user X member of the groups A, B and C with
resolving nested groups?"

> bogging me, but I forgot to post about it.

I'd like to keep two separate threads with different subjects. 1. for
discussing directly the draft itself and 2. discussing ways for defining
nested groups. Whether the new group object class should be STRUCTURAL
should be discussed under 1, please.

Ciao, Michael.

F0
	for [email-masked]; Thu, 20 Sep 2007 04:36:18 -0400
Date: Thu, 20 Sep 2007 10:35:58 +0200
From: =?ISO-8859-1?Q?Michael_Str=F6der?= <[email-masked]>
To: simo <[email-masked]>
Subject: Re: [ldapext] Nested group
Cc: [email-masked]

simo wrote:
> the server to do the calculations for us

Or better an extended operation?
Some query like "Is user X member of the groups A, B and C with
resolving nested groups?"

> bogging me, but I forgot to post about it.

I'd like to keep two separate threads with different subjects. 1. for
discussing directly the draft itself and 2. discussing ways for defining
nested groups. Whether the new group object class should be STRUCTURAL
should be discussed under 1, please.

Ciao, Michael.

---

From: Michael Ströder <[email-masked]>
Date: Thu, 20 Sep 2007 10:44:42 +0200

> I think that the problem is caused by artificial separation of members

NACK. Looking at the constraint enforcing in some server implementations
I'd guess having two separate attributes makes it easier to define and
enforce such constraints.

Ciao, Michael.

---

From: Michael Ströder <[email-masked]>
Date: Thu, 20 Sep 2007 10:54:11 +0200

> replace the member attribute.

Steven, so the whole thing would boil down to define two new attributes
'directMember' and 'nestedGroup' with a clear specification how to
interprete them?

Ciao, Michael.

---

From: Peter Gietz <[email-masked]>
Date: Thu, 20 Sep 2007 19:09:57 +0200

> application schema designer.
Yes this sound very good to me (+1).
> Maybe so, but rfc2307bis is a much more complex issue!
Yes but work on finishing that would really help a lot. @Luke: please 
find some time for that, you will help the whole LDAP world, even more 
than you already did with RFC2307. I am sure a new draft from you will 
revive discussion and eventually lead to  consensus.

Cheers,

Peter

-- 
_______________________________________________________________________

Peter Gietz (CEO)
DAASI International GmbH                   phone: +49 7071 2970334
Wilhelmstr. 106                            Fax:   +49 7071 295114
D-72074 Tübingen                           mail:  [email-masked]
Germany                                    Web:   www.daasi.de

DAASI International GmbH, Tübingen
Geschäftsführer Peter Gietz, Amtsgericht Stuttgart HRB 382175

Directory Applications for Advanced Security and Information Management
_______________________________________________________________________

---

From: Pete Rowley <[email-masked]>
Date: Thu, 20 Sep 2007 11:30:34 -0700

Howard Chu wrote:
>> user for a grouping mechanism 1) those who need to know how to build 
>> and generally administer groups 2) those who need to use groups but 
>> care not a whit how they came to be. Currently, every time a new 
>> group type is invented both classes need to understand all the ins 
>> and outs of the new group type and they must agree on what those ins 
>> and outs mean.
>>
>> This is broken. Non-administrative clients should be able to write to 
>> a single group interface once and forever after be left to get on 
>> with clientship.  Innovation for the first class of user is then left 
>> to prosper without hindrance, without client breakage, and without 
>> chickens and eggs. There is a suitable way to do this: the memberof 
>> attribute, if populated it will supply all the needs of the second 
>> class of user both now and into the future, it even solves some of 
>> sticky performance problems around gathering suitable attribute 
>> values from each memberof the group. It is also agnostic to method of 
>> attaining membership, membership simply is.
>
> Ah, if only it were so easy. But will memberOf expand for recursions? 
> If user A is a member of a group B that is nested in group C, will it 
> list only group B or both group B and group C? Attacking the problem 
> from the opposite direction doesn't actually eliminate the question of 
> whether and how nesting should be handled. All of the same ambiguities 
> still exist.
Nesting of membership is a design detail of a particular grouping 
mechanism, it has no bearing on memberof since if a group is not listed 
in memberof, it the entry is not a member. This actually a supporting 
point in that the set of non-management clients don't need to care.

-- 
Pete

---

From: Steven Legg <[email-masked]>
Date: Tue, 25 Sep 2007 10:14:18 +1000

Michael,

> 'directMember' and 'nestedGroup' with a clear specification how to

Yes. Any object class that permits the directMember and/or nestedGroup
attributes defines a group. These attributes would always have the same
effects regardless of the object class. One or more classes that include
either or both of the attributes could be defined as a convenience for
users that don't want to create their own classes.

Regards,
Steven