re:Directroy Synchronization Two

Alan Wong <wong@vancouver.osiware.bc.ca> Fri, 28 July 1995 02:34 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa22773; 27 Jul 95 22:34 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa22769; 27 Jul 95 22:34 EDT
Received: from haig.cs.ucl.ac.uk by CNRI.Reston.VA.US id aa10169; 27 Jul 95 22:34 EDT
Received: from bells.cs.ucl.ac.uk by haig.cs.ucl.ac.uk with local SMTP id <g.06321-0@haig.cs.ucl.ac.uk>; Fri, 28 Jul 1995 00:11:35 +0100
Received: from osison.osiware.bc.ca by bells.cs.ucl.ac.uk with Internet SMTP id <g.00402-0@bells.cs.ucl.ac.uk>; Fri, 28 Jul 1995 00:10:45 +0100
Received: by osison.osiware.bc.ca (4.1/SMI-4.1) id AA16822; Thu, 27 Jul 95 16:10:23 PDT
Date: Thu, 27 Jul 1995 15:47:00 -0700
X400-Trace: ca*infonet*iss; Arrival 27 Jul 95 15:47 PDT Action: Relayed
Priority: urgent
Ua-Content-Id: 950727732
P1-Message-Id: ca*infonet*iss;9507271547481659283
Original-Encoded-Information-Types: IA5-Text
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Alan Wong <wong@vancouver.osiware.bc.ca>
To: awon@vancouver.osiware.bc.ca
Cc: osi-ds@cs.ucl.ac.uk
Message-Id: <950727732*wong@vancouver.osiware.bc.ca>
Subject: re:Directroy Synchronization Two
Importance: High

>In message "Directroy Synchronization Two", 
>'jburgh@PrimeNet.com' 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.

This would result in a very deep and wide DIT, which would be difficult
to maintain and difficult to browse.

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.

Once you've chosen a structure for the tree, simply store the OR address
and other email addressing information as attributes in the user's
entry; your synchronizing DUAs can search for an entry using any mail
address, i.e.  search filter "OR address =
/c=US/admd=ATT/prmd=ACME/s=smith/g=jones", and request the other email
address attributes from each entry matching that filter.  This is
preferable to a programmatic mapping from OR address to DN, is more
flexible, and, in the long term, will be more useful as your various
email clients become X.500 clients.

Note also that this approach does not require that querying DUAs have
special knowledge, i.e.  of the mapping from OR to DN:  they simply ask
for the email addresses of the entry which contains a particular OR
address.

As a final note, you will probably be required to use some sort
of unique identifier to disambiguate DNs.  While this may seem 
a less than satisfactory way of guaranteeting unique DNs, in 
practice it is the only workable approach.  Other solutions involve
sorting users by department, location, etc., and rely on these OU
or L RDN components to provide uniqueness;  there are three problems
with this sort of approach:

    Resulting DITs are constructed arbitrarily and without regard
    for any structure which may be useful for the organization, or
    which may be useful to the organization's users (i.e. DIT
    structure reflects X.500's lack of solution to the problem of
    name uniqueness).

    This approach does not help you when two users in the same department
    have the same name;  this happens frequently enough to cause problems.
    Some organizations solve this by adding arbitrary initials to the
    second user's name, which leads to two problems:  if two long time
    employees with the same name move into the same department, which one
    gets the "Z.", and users generally find arbitrary bureaucratic
    changes to their names insulting.

    This approach does nothing to solve the problem of DN reuse:  if Joe
    Smith leaves the company, and another Joe Smith is hired into the
    same department, how does the system differentiate between them.
    This is especially important if the DN is used in ACLs for various
    protected resources.  (The X.500 unique identifier purports to solve
    this problem and does not; I won't get into the reasons, but it has
    to do with a) the unique identifier being optional, and b) there
    being no way to communicate it in the X.500 protocols, short of
    reading the user's entry.)

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).

> 2.  The Identity Evolution Issue involves standardization of DN
>X.400/SMTP-based E-Mail addresses throughout the ORs.  This is a policy
>related problem and it requires close coordination with the Human
>Relation folks in my organizaiton.  Employee turnover will require
>"daily" attention.  The System Administrators must keep up with the
>personnel changes.  Employees and Supervisors are involved in this
>problem too.

Can you provide more information on this issue?  I do not understand it
from the text above.

>3.  The User Multiple Identity Cross-Leveling Issue involves making sure
>that "Dual Hat" employees, requiring different rights and privileges
>based on their particular roles, get those rights and privileges
>accordingly.  This involves technical and policy related problems.  The
>System Administrators must make sure that the "Dual Hats" obtain
>specific Login Scripts with "unique" characteristics for each role.

I sense that this issue is being overcomplicated:  a user presents their
name (and possibly their cryptographic credentials) to a system, and the
system grants them the permissions associated with their
name/credentials.  The Directory can be used as the storehouse of
permissions, i.e.  you can define attributes held in each user's entry
which define what permissions that user has to a particular system.

On the other hand, I may simply misunderstand the problem you are
trying to solve.

>I've got to make sure that the "Dual Hats" understand and follow
>standard procedures, without abusing their access.  The DUA might be
>able to handle this problem for me.

The problem with expecting users to understand issues and follow 
procedures as you describe above is twofold:  some won't, either
out of ignorance, pig-headedness, or forgetfulness, and some won't
because they know they can compromise the system by ignoring the
procedures (deliberate maliciousness).

>4.  The ADUA Utilization Procedures Issue involves standardizing DN
>creation, modification and deletion procedures.  This involves technical
>and policy related problems too.  Everyone must do everything right the
>first time.  The System Administrators must completely understand ADUA
>functionality and employees must understand their E-Mail
>responsibilities.  I guess I'll be developing standard operating
>procedures for "New" and "Terminated" employees.  I'll probably make the
>supervisors responsible for ensuring that their employees coordinate
>with the System Administrators.

Once you have decided on a tree structure and a name uniqueness
provider, building a DN is relatively straightforward.  The only
questions that then arise are:  where are the unique identifiers
generated and stored?  are terminated users left in the DIT and marked
terminated (and possibly hidden from all but administrative users via
careful application of access control information (ACI))?  who has
permissions to add, modify, and remove, particular attributes, i.e.  OR
addresses, etc.

>5.  The CRL/CKL Procedures Issues involves guaranteeing confidentiality
>of "sensitive" information.  Some of my Users deal with "proprietary"
>information.  We use asynchronous (public/private) key cryptography.
>We're gonna incorporate X.509 Authentication Framework Certificates to
>manage our Public Key Ring.  The System Administrators must issue
>CRL/CKLs whenever employees with access leave the organization or lose
>control of their Private Key.  Employees and Supervisors are also in
>this loop and the distributed directory needs to be updated readily as
>employee access changes.

Sounds like you need an X.500 based certificate management system.  I
won't comment further as anything I say might be construed as an
advertisement for Entrust :->.  (Though you may want to send email to
entrust.sales@entrust.com, or call +1 613 765 5607 for more
information....)

pww

Peter Whittaker      [~~~~~~~~~~~~~~~~~~~~~~~~~~]   X.500 DS Specialist
pww@entrust.com      [                          ]   Nortel Secure Networks
Ph: +1 613 765 2064  [                          ]   P.O. Box 3511, Station C
FAX:+1 613 765 3520  [__________________________]   Ottawa, Canada, K1Y 4H7