re:Directroy Synchronization Two

["peter (p.w.) whittaker" <[e-mail]>]

In message "re: re:Directroy Synchronization Two", 
'[e-mail]' writes:
>C=US/A=INTERNET/DDA=ID/pww(a)bnr.ca Wrote:
>| >In message "Directroy Synchronization Two", 
>| >'[e-mail]' writes:
>| >	1.  The OU Hierarchy Issue involves Organizational Department
>| >(OR) leveling and X.400/X.500 Naming Convention Standard development.
>| >This is a policy related problem.  I've got to make sure that the OR's
>| >System Administrators utilize appropriate standards when they develop
>| >Distinguished Names (DN) for the users.  As I synchronize the diverse
>| >system directories, I'll probably have to "Re-Do" some of the DNs to
>| >make sure that they comply with X.400/SMTP-based E-Mail address formats.
>| 
>| I'm wary of the approach you seem to be suggesting:  that an OR address
>| be mapped directly to a DN, so that the resulting DN contains a large
>| number of RDNs.
>
>Peter, I would not consider this to be my first concern:  as far as I'm
>concerned the DIT structure should NOT and NEVER be based on the OR
>address name space simply because addresses do change - our MTA for
>instance allows a user to have multiple ADMD names, a feature our
>customers use when transitioning from one ADMD to another (for cost,
>service reasons...)  - does this imply that they would have to rip their
>DIT appart, change ALL X.509 certificates...?  Secondly, e-mail is only
>a subset of applications that make use of the directory - you shouldn't
>need to know someones email address to look up a postal address, or
>locate a public key certificate.

That was my point.

>The issue of DIT name spaces is an organizational policy issue first and 
>foremost.  Its structure should be based on organizational needs to directory 
>services, not what is imposed by poorly conceived and deployed technologies.

Also my point.

>| It is generally wiser to keep the DIT relatively flat.  When selecting
>| DIT levels to organize or manage user entries, choose those which change
>| less frequently over time, i.e.  if your employees change departments
>| frequently but remain in the same metropolitan area, use location as a
>| means of organizing entries.  The point of this exercise is to build DNs
>| which will change infrequently; this will be especially important if
>| user DNs are to be incorporated into X.509 certificates, as a DN change
>| requires that a new certificate be issued, with the resulting
>| certificate management problems.
>
>Experience has shown that while deep trees are impractical from a user's
>perspective, that very flat and bushy trees blow DUA's away - most DUA's
>simply are not capable to receive and display the content of the
>directory tree (particularly due to limitations of the LDAP protocol),
>the time to receive the data is too long, and DSA admins often limit the
>number of entries they are willing to supply due to performance and
>privacy concerns.  OUs should be limited to 300-400 entries within an
>organizational unit if you plan to employ public domain DUA's -
>commercial implementation (like ours) will overcome this issues to a
>large degree.

There is a contradiction between this paragraph and the statement above
that DIT structure should not be determined by poorly conceived and
deployed technologies.

DIT structure should reflect several things, the two most important of
which are organizational requirements (which will include policies which
dictate that internal organizational structure not be obtainable from
DIT structure) and user requirements, most notably ease of use and ease
of data access.

With regard to poorly conceived and deployed DUA technology, service
controls can be used to limit the amount of data presented to any
particular DUA; as an editorial note, I would say that applications
which need to return and deal with lists of more than a few hundred
users at a time should be re-evaluated from the point of view of
performance engineering, data latency, etc.

Besides, the 1993 X.500/1995 ISO 9564 work incorporates paged results,
which DUAs can use to limit and control the amount of data returned with
any given transaction.  While paged results are available only with DAP,
we are looking at adding support for paged results to LDAP, as part of
the work to incorporate 199[35] Directory work.

>| That said, incorporate some sort of unique identifier into all DNs,
>| one which will be unique to that person, i.e. will not be reused.  At
>| BNR, we use the HRR generated employee number, so that my DN is
>| 
>|     cn=Peter Whittaker + serialNumber=1660747, l=Ottawa, o=BNR, c=CA
>| 
>| This may seem unattractive, but it is workable and problem free (bear in
>| mind that DNs are to human consumable, not user friendly).
>
>I'd say that the jury is still out on this proposal....

Not for long:  the issues of name uniqueness, both with the DIT and as
it applies to the lifetime of name, demand this sort of solution.
Solutions based on arbitrary DIT organization suffer from all of the
problems with DIT layout which you highlight in your comments.

This solution is workable.  My experience with this solution (both in
X.500 applications and other applications which use hierarchical naming)
shows that while users initially find it a bit odd, they get used to it,
and get use to associating the identifier with "problem" users (those
whose names conflict with others) much as they get used to associating
phone numbers with people.

The only issue is that of finding a reliable source of unique
identifiers which are publicly consumable; in NT/BNR, the HRR-generated
employee numbers fit the bill nicely.  Other organizations will of
course have to find there own source(s).

The ITU/ISO had a chance to solve this problem in the 199[35] Directory,
and failed.  I've been pursuing the submission of a defect report on the
use uniqueIdentifier (they are useless as described, and do not fit in
with the "all decisions are made locally" model of the ACDF (Access
Control Decision Function).

pww

Peter Whittaker      [~~~~~~~~~~~~~~~~~~~~~~~~~~]   X.500 DS Specialist
[e-mail]      [                          ]   Nortel Secure Networks
Ph: [phone]  [                          ]   P.O. Box 3511, Station C
FAX:[phone]  [__________________________]   Ottawa, Canada, K1Y 4H7