Access Control, Administrative Areas, Replication and Distribution

["Albert Langer" <Albert.Langer@Directory-Designs.org>]

Following links highlight serious problems that can arise from
not not working out access control together with replication
carefully enough.

Microsoft unable to supply a fix for more than a year due to
having to fundamentally redesign Active Directory to fix it:

http://www.nwfusion.com/archive/2001/117574_02-26-2001.html

http://www.microsoft.com/windows2000/news/bulletins/multivalrep.asp

Similar issues can arise with replication of administrative
policy etc.

Workarounds like Microsoft proposes are simply bizarre and
negate the point of a directory. The description of their
proposed future fix also looks like just a kludge.

Workarounds like notifications to directory administrators
are also unworkable in the long run. Changes to access
control information (including group membership) are
increasingly made directly by end users and their
applications - such delegation being one of the main
advantages of large scale directory deployment.

In order to satisfy the currently recognized requirement for
replication of access controls to work it will be necessary
to actually implement both:

1) preservation of atomic operations

2) preservations of the sequence between access control
related changes and changes to affected entries

as specified in the current LDUP requirements draft.

This will still not eliminate all possible anomalies,
even together with profile advice on avoiding situations
where changes are frequently made before previous changes
have fully replicated.

I therefore believe it is essential to add:

3) automatic notification to the DUA that made a change
when that change is revoked as a result of a conflicting
atomic operation.

The current requirement for notification to
administrators ensures that an architecture
capable of being extended to also meet item 3)
will not need complete redesign to provide
that extension.

Therefore I do not think it is necessary to oppose the
current requirements draft at IETF final call, although
it would certainly be better if this requirement was
recognized now.

However I would be opposed to adoption of
any architecture that did not actually implement
item 3 and am putting that on the record now.

Some work will be necessary to actually
standardize notification mechanisms - eg by
email to the address given in DUA entries or
via LCUP. It would be better if that work was
started earlier rather than later.

(Other objections to the meaningless requirements
concerning "model 1" and "model 3" likewise don't
really matter precisely because they are meaningless,
though it would obviously be better to not include
meaningless requirements. Ditto for the unhelpful
examples which obscure the reasons for needing
multi-master replication.)

On item 2, there is no practical way to achieve
it without implementing delivery of change reports from
each originator DSA to each other DSA in exactly the
same sequence as generated by the originator. This
follows from the fact that an ACI change can affect
an entire subtree, even leaving aside the fact that
group membership can be from other parts of the DIT
entirely. It is also necessary for minimizing restarts
of replication sessions and use of full instead of
incremental replication.

Similar considerations may apply to administrative
areas - perhaps with more problematic implications
due to administration points being at the
intersection between replicated areas. Single
master replication (with failover) may well be
essential for administrative points (and acceptable
due to not needing the same fault tolerance and
local availability of changeable copies as for
other changes).

Even namespace management is currently unclear.
How is a modifyDN operation actually performed
between different replicated areas within a
single "Naming Context"?

Changes from different originator DSAs would of
course still be interleaved arbitrarily due to
replication schedules and replication network links.

As far as I can see items 1 and 2 can only be
achieved by some method similar to the "tree"
proposed in my MDCR draft (expired). That is
because each DSA has to converge on the same
serialized sequence of atomic operations and
that sequence has to be consistent with the
sequence in which changes were originally made
at each originator DSA. Since the operations
form a tree in reality, I cannot see any way
to avoid modelling that tree within the
conflict resolution protocol. There simply
isn't any actual total ordering available.

If there are any other ideas for meeting the
proposed requirements, or if anyone believes
that URP can meet them, it would be useful to
provide an outline before the next LDUP
requirements last call, so that there is time
to think about it and avoid confusion during
discussion.

Concerning replication of admin policy and
Ed's sub-entry draft I am not clear on the
intended function of the paragraph about
X.500. If the intention is simply to refer
to the X.500 standards as the basis for
expected future work on standardization of
LDAP administrative areas and their
relation to replication, I believe that is
a very good idea.

What should follow from that is promptly
taking up the proposals for liasion put
forward by an X.500 working group and
doing detailed analysis on whether and
how it maps to the sub-entry and replication
proposals.

Certainly the paragraph cannot actually
substitute for that work. Defining any
simplified subset requires very detailed
work similar to the original LDAP standards.

It is unclear to me whether the sub-entry
draft is adequate for supporting appropriate
administrative areas and replicating them.
That could only be determined by actually
doing the detailed analysis and mapping.

It may turn out that the full
"chop specification" with lower bounds
as well as a base entry is necessary
when taking into account the knowledge
needed for distribution and replication.

Administrative areas for some purposes
such as access control may well need to
be nestable rather than partitions.

This needs a close inspection of the
X.501 (2000) standard referenced by Ed,
which is available from:

ftp://ftp.bull.com/OSIdirectory/4thEditionTexts/

As background reading I would strongly
recommend David Chadwick's online book on
earlier versions:

http://www.salford.ac.uk/its024/Version.Web/Contents.htm

Section 11 of chapter 2 actually succeeds in making the administrative
framework intelligible!

BTW I believe adopting an access control model incompatible with
X.500 and omitting the concept of a Directory Access Control
Domain applying only to a subset of entry types is a mistake.

Interoperability can best be facilitated by
simplifying existing standards where possible, not by adopting
"options" for different fundamental models. Such options conflict
with well known internet architectural principles.

Both administrative areas and access controls are more within
LDAP-EXT than LDUP since they are just as important without
replication. Liaison with replication work in LDUP and with
the X.500 people themselves is clearly essential.

These two areas relate closely to a third area - directory
distribution - including operational bindings between DSAs
(and replicated areas) within the global DIT.

Lack of clarify about the interoperability issues arising
in connection with that is hindering progress on other issues.
A global internet scalable directory service really requires
that this be dealt with first - and fortunately much of the
work has already been done for it in X.500 as was the case
with the original LDAP access standards as a compatible
"Lightweight" substitute for X.500 DAP.

LDAP was possible without having to do the work on
access controls, replication, administrative boundaries
or distribution because it was just an "Access Protocol".

In standardizing replication it has become obvious that
standardization of access controls, and administrative
areas is closely related. In moving into these areas
IETF is going far beyond issues for an "Access Protocol"
and needs to take an architecturally coherent approach
based on the X.500 standards. Distribution and then
administrative areas is really the foundation for the
others and needs serious work now in conjunction with
the liason project alredy setup from the X.500 side.

Who is doing that work?