RE: LDAP Access Control

["Miklos, Sue A." <samiklo@missi.ncsc.mil>]

In writing the ISP for access control (ADY 44 and 45 combined in one
document) we've realized that we have to give guidance on the
denyReturnDN, since if you deny the return of a DN, then you also must
agree to put in a valid alias name in any read or search for that
information.  Name is a mandatory element in EntryInformation. 

X.500 permits the DSA to just omit the entry from a search return, but I
don't believe that's true for other operation results.  A suggestion was
made to give the entry an
operational attribute which specifies the name that is to be returned
under these conditions.  An example would be the equivalent of a Public
Affairs Officer's name returned.

I believe that some name 'hiding' is going to be the normal use of
corporate directories as well as the 'black hole' communities.  Products
that make this 'manageable' will be very useful.  

Sandi
>----------
>From: 	Ed Reed[SMTP:ED_REED@novell.com]
>Sent: 	Friday, June 19, 1998 12:23 PM
>To: 	d.w.chadwick@iti.salford.ac.uk; howes@netscape.com;
>ietf-ldapext@netscape.com
>Subject: 	Re: LDAP Access Control
>
>David - a note on disallowing traversal of namespaces....
>
>We see this fairly often in customer requirements for enterprise directories.
> The engineering organization has a portion of the tree which is used for
>test purposes only, but for which it is convenient to have it linked into the
>rest of the namespace for single signon and name resolution purposes.
>However, they run the partitioning, schema management, and other aspects of
>the tree independently.
>
>Now, a high security research project comes along for which they want
>complete anonymity, but again, want to use their user names, etc defined in
>the public parts of the tree as part of their access controls and so forth in
>that portion of the tree.
>
>Note a few interesting things about resolve name operations in distributed
>directories, in this scenario...
>
>If you allow unauthenticated (ie, public) traversal of the namespace, it's
>quite possible to ascertain quite a lot about the organization and its view
>of itself.  If you allow unauthenticated (ie, public) name resolution (for
>initial login, for instance) of objects in the hidden namespace, you AT LEAST
>have to allow visibility to the knowledge references for internal partitions
>within the namespace...which again provides quite a bit of information about
>it.  This would be particularly true in a Microsoft Active Directory Service,
>where each partition is doubling service as an NT domain.
>
>Bottom line is that some customers DO want to be able to create black holes
>in their namespace.  And if you allow it, you have to treat it kind of like
>you do the ability to run without key recovery - if you lose the key, you've
>lost the data, with no recourse.  Same thing applies to the namespace - if
>you create the black hole, and then fail to retain the ability to access and
>manage it, it's lost to you (unless you're willing to go in with database
>pointer editors to remove the blocking ACI - tantamount to key recovery in
>the example before).
>
>Such "fire walls" are certainly going to be necessary if corporate
>directories, like their networks, achieve greater connectivity to the
>outside, hostile world.
>
>Ed
>
>-------------------
>Ed Reed, Technologist
>Group Technology Office
>Novell, Inc.
>+1 801 861 3320
>
>>>> "David Chadwick" <d.w.chadwick@iti.salford.ac.uk> 06/19/1998 01:51:36 >>>
>
>