Subject: RE: LDAP subentry alignment with X.500 subentry

From: "Lloyd, Alan" <[email-masked]>
Date: Mon, 10 Jul 2000 20:08:01 +1000

No worries - but the real issue to me is an administrative plane in a
directory for schema, collectives, security, aci, etc means that these
entries can be partitioned into their own regime - in that there is
administrative security applied to these entries and they get named
seperately from the "user entry plane"..ie does the ACI on ORG x get its ACI
properties from a management plane of named entries (which have their own
ACI regime - distinct from the user ACI regime ) or are they coupled because
it all exists as one compound entry.

There are five aspects to ACI..that is coupled to the User authentication
process.. these are 
The Operation
The Name Space
The Object Class of the entry
The attribute type/value within OC/entry 
and the Time the operation is allowed.

Given that very strong ACI code (in terms of vetting) can be applied to the
directory operation and name space of the entry and its OC. Having named
subentries for management is a much more trustworthy approach than compound
OCs that exist under a User "named" DIT. In addition if entries are renamed
becuase of business, service and user changes, it may means the ACI
management model has to be recalculated re its security. Whereas the named
entry for management - admin model is still the ACI and schema reference
point in the directory.

Naturally this discussion can be lengthy - but one area that one looks at in
military security - is "seperation of duty" - and how operations that change
one thing affect others.. An explicit "named" management and security
information model  with its own privileges and ACI - to me is much better
than a compound one - that can be accidentally affected by such things a
user information name changes..

I hope this "helps"..

regards alan

-----Original Message-----
From: Rob Byrne - Sun Microsystems [mailto:[email-masked]]
Sent: Monday, July 10, 2000 7:50 PM
To: Lloyd, Alan
Cc: [email-masked]; 'Mark C Smith'; 'Kurt D. Zeilenga';
[email-masked]; [email-masked]; 'Ed Reed'
Subject: Re: LDAP subentry alignment with X.500 subentry

Hi Alan,

Thanks for that...but I think I was not precise enough in my question.

The current proposal for ldapACI does put them in entries but they come with
a
built in scope rule, which can be "subtree".  So, I suppose my question is
rather, "apart from leveraging the scoping rule of subentries what is the
big
plus we get from putting acis into subentries ?".

Thanks,
Rob.

"Lloyd, Alan" wrote:

> The reason for ACI in subentries is that one can support the nested
> directory admin model and make domain based ACI decisions over distributed
> (X.500) DSAs. Whereas entry level ACI - may let a user do operations on
the
> directory using the directory resources only to find they are denied to do
> these at the entry level (and on millions of other entries.. ie entry
level
> ACI is easy to implement - but a rally bad way of working in terms of
system
> level resource protection, large scale protected distributed systems - and
> operationally hard to configure and manage..
>
> ie. configuring entry level ACI for millions of entries - across many
> servers - at the entry level takes time ... This process is also open to
> having errors introduced where back door holes might be the result of
> misconfiguration.
>
> If one adopts admin points and rules based configuration and deals with
> large scale distributed directory entries - then the nested admin model is
> best - simply becuase it does scale and is easier to operate with rules -
> This approach also align with conventional management models used by
> business ie top down. If an entry level aci is used - one must consider
the
> cost to configure and test, the use of directory resource before making
the
> actual ACI decision, the hierarchy of entries, their denials and
permissions
> and any alias derefencing...
>
> as an example - say one has a distributed directory with 250 million
entries
> in it and one wanted to apply a new rule for a new set of users and
business
> services - for each entry... if an entry takes even half a minute to
> configure.. the job will be a life time career...
>
> regards alan
>
> Stephen,
>
> snip
>
> However, I would also like to see a discussion of why we should put acis
> into subentries rather than just store them as ldapACI attributes in
> entries.  What are the pros and cons ?
>
> Cheers,
> Rob.
>
> snip

---

From: "Ed Reed" <[email-masked]>
Date: Thu, 13 Jul 2000 09:43:59 -0600

Kurt - I disagree with your proposal to replace LDAPsubentry with
X.500 subentry, mainly for reasons already expressed on the list:

1) the subtree specifier is omitted because:

   a) it introduces what seems to be a lot of complexity to determining
       which entries a subentry would refer to, 
   b) it introduces what seems to be a lot of complexity to determining
       which subentries apply to a particular entry,
   c) it introduces what seems to be a lot of complex thinking for
       administrators who want to understand how to tell their system
       to do something, and to understand what their system is trying
       to do
   d) the author (me) has not been exposed to many (any) real-world
       problems solved by the subtree specifier which are not or can
       not be as well handled in some other fashion.

2) As Steven Legg pointed out, X.500 vendors who wish to use the
same mechanism to implement subentry and LDAPsubentry may treat
LDAPsubentry as a limited subset (for the most part, see below) of
the X.500 subentry, with an implicit subtree specification.  The
one place I'm aware of that the LDAP subentry is not a proper
subset of the X.500 subentry is that the LDAPsubentry MAY be
nested, whereas the X.500 subentry may not - but that's really
just a structure rule variation, isn't it?

Of those reasons, the first three of 1 are the qualitative reasons.  As for the
fourth - informal conversations I've had with vendors who HAVE implemented
the subentry suggest that it IS complex to implement, it IS hard to
use correctly in operational environments (because of a, b, and c) and
it's NOT widely used.

I've no objection to extending LDAPsubentry at somepoint in the future
to have full X.500 semantic subentry behavior - but I'd rather let those
of you who think it's worth while do the expansion and let the market
place of real-world operations provide the compelling reason the make
that the standard, rather than try to force it on lots of folks who don't
see the need, today.  Or put another way, I have no problem watching
LDAPsubentry attrophy from lack of use if the X.500 subentry is over=
whelmingly adopted by the LDAP community at large.

Ed

=================
Ed Reed
Reed-Matthews, Inc.
+1 801 796 7065
http://www.Reed-Matthews.COM

>>> "Kurt D. Zeilenga" <[email-masked]> 07/03/00 10:25AM >>>
I believe 'LDAPsubentry' should be replaced with with 'subentry' and
defined such that it closely modelled after X.500.

1) subentries should have a subtree specifier such that they are more
useful for specification of ACI subentries.

2) subentries should be visible based upon presence of a subentries control,
not a filter components.  For example:
  (|(&(objectclass=LDAPsubentry)(!(cn=*))(objectclass=*))

Should the subentry be visible or not?   There are reasonable arguments
for both yes and no.

I primarily make these suggestions because I believe these changes would
make subentries within LDAP more usable, in particular, when used in
support of the access control model.

Kurt