RE: LDAP subentry alignment with X.500 subentry

["Lloyd, Alan" <Alan.Lloyd@ca.com>]

In addition to Ron's input - which is always spot on .. 

With this issue one has to step back and look at the major issue with LDAP
servers and their lack of distribution - that X.500 already has. When
machines do diffrent things, (eg LDAP servers vs distributed X.500), their
management and control architecture will also be different. Certainly when
one gets into distributed system management, knowledge engineering and
security systems - the management will be very different to that of a single
client-server system . 


As per my last mail re separation of duty - and dedicated control planes (as
per X.500 DSE types, admin and subentry named - ACIand schema objects/object
classes, etc) - If one has a clear management and control  model of
distributed directory space - that deals with schema management,
Authentication levels - tied to ACI regimes, Collective Attributes, Contexts
(time/language), Labels (MLS military security), etc (as per X.500).. then
one can engineer these control planes as distributed, nested administration
points - and write the processing for these as quite distinct processes from
the code that services the normal user access to directory entries - which
of course must be policed by the control regimes. 

Whereas with no control plane agenda or model - and the use of compound
entries, this could lead to all sorts of operational weaknesses (as Ron
describes) and the possible inclusion of weak fragile security and
management code.


When a user binds to a directory with none, simple, strong authentication
that the ACI processing is latched to. Ho do you vet the processing is clean
and trusted comensurate to the authentication  level demanded if it is
scattered through out the User plane processing. In addition - and probably
this is the main distinction between LDAP servers and distributed X.500 with
its distinct Admin area management system - is that these dedicated
management objects for ACI/schema control, etc, can be (and must
be)propagated to subordinate directory systems more cleanly than filtering
partial replicas of user entries - which can be under all sorts of dynamics.
This obviously means that the hierarchy of management control and its
security is effected across the distributed system in a much more trusted
(separated) way.


With the Search issues like Ron describes - as well as embedded attributes
for management control in normal entries - how would one enforce such a
random control process - eg upwards, sidewards and downwards? and dont
forget alias issues ! 

With the X.500 admin point and dedicated ACI and schema type objects the
governance its always downwards - and "always" means it can be built in
trust worthy way. It can be designed to be "predictive" and any resulting
pre processing of ACI when ACI or schema control is changed, can be
propagated across a distributed system - consistently and effectively..

My issue with - and always has been with non distributed LDAP servers -
where one must replicate everything to everywhere - and there is no
distribution and no distributed coherent control plane management model -
does mean that any operational security is bound to be weak and fragile.. 

When one sees a distrubuted directory service to underpin a global
organisation's business infrastructure with PKI, OCSP, DEN, DNS, User
authentication regimes, white, blue, green, yellow pages services,
catalogues - 10s - 100s of millions of role based users - and the need to
support a predictable, high capacity, distributed authentication/ACI model
(to protect the directory service), the X.500 Admin model and subentry ACI
with profiled rules - wins out. 

And when you apply this fundamental processing things to a system do slow
down a little compared to those servers that dont apply ACI or are just a
single server. And its a pitty that ACI and information integrity testing
does not get incuded in some directory test reports we see..

There is a danger in discussing ACI models that by saying X.500 does this
and LDAP servers do that.. that the LDAP server ACI approach will firmly
concrete the role of an LDAP server to be nothing more that a single non
scaleable single ACI regime system. The basics of X.500's nested admin
points, DSEs, knowledge and control planes - is that it works for a single
DSA or as a distributed system - in a way that it can be built - and
trusted.


In discussing this re an ACI attribute or an Admin/Subentry ACI, etc - one
must look at the system model and its distribution requirements and the
ability to do predictable govenance. 


regards alan







-----Original Message-----
From: Ramsay, Ron 
Sent: Tuesday, July 11, 2000 11:14 AM
To: Rob Byrne - Sun Microsystems
Cc: ietf-ldapext@netscape.com
Subject: RE: LDAP subentry alignment with X.500 subentry


Rob,

I can so no purpose either for a general filter in a subentry of for scopes
in entry ACI.

The problem with the former is that, if the filter relates to
telephoneNumber, for example, and the user deletes this attribute from his
entry, the ACI may now behave unpredictably.

The problem with scope in entry ACI is that, when searching below a scoped
entry, how do you determine the applicable ACI. Read all superior entries?

Since you asked for pros and cons, another aspect of entry ACI that is
suboptimal is the cost of applying it. Everyone seems to assume it is free
and yet it has a significant impact on server performance (no figures,
sorry). For example, suppose subtree A contains 10000 entries, 9000 of which
are in subtree B under A. Suppose user X is not authorised to access B.
Because of entry ACI, a search by X of the subtree A will result in all
10000 entries being read for their ACI, whereas the use of prescriptive
(subentry) ACI will mean that at most 1000 entries will be accessed.

Ron.

-----Original Message-----
From: Rob Byrne - Sun Microsystems [mailto:Robert.Byrne@france.Sun.COM]
Sent: Monday, 10 July 2000 19:50
To: Lloyd, Alan
Cc: steven.legg@adacel.com.au; 'Mark C Smith'; 'Kurt D. Zeilenga';
ietf-ldapext@netscape.com; ietf-ldup@imc.org; '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