Providing a DS: re:scenarios for Directory Synchronization

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

Once a publicly accesible Directory is in place (regardless of whether
"publicly accessible" means "to employees" or "to the whole world" or
something in between), users will begin to use it (!  A tautology,
perhaps, but worth stating...).

Given that statement, it is worth planning the design of the DIT ahead
of time, including schema, naming schemes, etc.  Prior planning will
go a long way toward eliminating churn in DIT design and DIT layout.

Once users begin taking advantage of the Directory and building applets
to use it, they may begin to rely on certain aspects of DIT design (they
shouldn't, and they shouldn't need to, but they might; be nice to your
users, they pay your salary).  Any churn in DIT layout, schema, or naming,
will affect end-users, possibly more than you had expected.

Note that "layout" and "naming" are the same issue:  DIT structure is
determined by naming rules, which stipulate where any particular
structural object class may appear in the DIT, and how entries of that
OC are to be named.  (Point made to satisfy my inner pedant.)

In message "scenarios for Directory Synchronization", 
'[e-mail]' writes:
>I have beed reading the discussion on Directory Synchronisation with
>lot of interest. Here, I would like to share some of my views.
>I feel that we have been mixing up two scenarios (as defined below).
>We need to first understand the scenario which we are talking about????

To again invoke my inner pedant, there is only one issue:  providing a
Directory service to your users.

The questions that inform any decisions about this issue are:

    Is there a long term strategy for simplifying the provisioning and
    administration of the Directory?  If so, does it involve X.500 or
    some proprietary scheme?

    Once this question has been answered, ask the following questions:

    What is our strategy for synchronizing our current multitude of
    Directory services (be they proprietary email directories or text
    files maintained by each user or something else entirely), and for
    migrating existing systems to the single system we envision for the
    future?

    How are entries to be named and managed in the future Directory?
    Should we begin using this naming strategy now, as a canonical name,
    as we work to synchronize our disparate directories?  What naming
    schemes are human-consumable (and, if possible, human-friendly), and
    likely to be relatively static (i.e.  relatively few name changes as
    email systems come and go, organizational units come and go, etc.)?
    What naming schemes guarantee unique and unambiguous naming of
    users?

(Those last two are very important for email users:  as people move in
an organization, their email addresses may change - especially if their
email addresses contain email router, email domain, email MTA, or
organizational information - yet you still want to ensure that mail goes
to the right people, regardless of changes in email system, or the
addition of like-named employees.)

>
>SCENARIO-1 : Use of a corporate Directory service
>
>Here, X.500 directory service is used as part of Global and corporate
>directory service. Corporate Directory Service is used for lot of 
>corporate requirements, such as:
>
>	* Personnel profiling of an employee
>	* For lookup of Telephone number, Fax Number, E-mail address,
>	  common name, description etc. etc.
>	* For storing sensitive "secure" information such as 
>	   private and public encryption keys etc.
>	* To offer white page and yellow page service for employees and
>	  corporate network
>	* to provide Whois services etc.
>
>In fact, in this case, Directory is a very important corporate resource 
>and one needs to build process and procedures to maintain it very carefully.
>
>SCENARIO-2 : Using X.500 for e-mail address resolution in Global and 
>----------    distributed manner
>
>This scenario is, clearly, a subset of "scenario-1". However, this 
>requires low commitment at organisational and corporate level.

If this subset is to be forever divorced from the superset, then maybe
yes.  Even then I doubt it.

Why?  Because email is "a very important corporate resource and one
needs to build process and procedures to maintain it very carefully",
and if it is not such a thing within your organization now, it will 
likely be so very soon.

Planning an email service, or a directory service for an email service,
or a directory service to aid in tying together multiple email services,
etc., requires just as much planning as a Corporate Directory Service.

>Here, X.500 directory DNs CAN BE generated as a "rule based approach"
>from LAN / legacy Email accounts. This can become part of Directory
>synchronisation mechanism. In this case, X.500 directory is used
>by Email Gateways to resolve LAN / Legacy e-mail addresses to X.400
>or-address OR DN and vice versa. Also, X.500 directory will be used
>by X.400 (1988) MTA and (optionally) by UA for Mail routing etc.

All the more reason to have a sensible, long-term viable, naming scheme:
the better the naming scheme, the easier to isolate and debug problems
in any of these areas.

If "ugly names" are needed, then, if possible, supply them using aliases
to the real entries with the "nice names", and work to remove or enhance
the systems requiring "ugly names" as quickly as possible.

>In my view, Scenario-1 is a long term view of "Directory service"
>and Scenario-2 is a short term view of the X.500 Directory.

Inner pedant writes:  the use of the terms "long term" and "short term"
implies that these approaches are related, in that the short term
approach will eventually evolve into the long term approach.  Will the
evolution be planned, or will it happen willy-nilly, higgledy-piggledy?
If you prefer planned evolution, begin planning now, and make the right,
long term, decisions now.

My gut feeling is that in the near future, as users and administrators
become aware of the need for consistent, widely available directory
services, and for the applications which make use of them, interest in
and deployment of X.500 Directory services will explode.  People just
beginning to look at directory services and directory synchronization
need to be prepared for this.

I justify (or rationalize) this gut feeling with two scenarios:

    1) organizations are in the process of linking their internal mail
    systems, and of linking their systems with those in other
    organizations, and are becoming aware of the nightmares involved;
    given that their expertise is in email, that they recognize
    directory services as important part of this work, and that they
    want to keep things as manageable as possible, they will want to
    implement and make use of as maintenance-free a Directory as
    possible.

    This argues for taking the time to plan the Directory now, spend
    some time getting it right, keeping the churn inside the glass
    house, so that when it gets into user land, it sings, dances, is up
    7/24, and needs only occasional tweaking, never major revamping.

    2) organizations are in the process of evaluating the security of
    their networks and finding them wanting; they are also evaluating
    electronic forms systems, EDI systems, etc., in an effort to cut
    costs by bringing things on-line.  They are realizing that data
    encryption and digital signature technologies can address some and
    perhaps all of their concerns in these areas.  They are also
    realizing that, unless done properly, the key management issues
    involved in properly delivering electronic data security will
    overwhelm any benefit drawn from these systems.

    This argues for a properly setup and deployed Directory which
    supports their key management system and all client applications.
    Given that these concerns are gaining steam, this argues for doing
    the Directory right, right now.

Inner pedant now goes for coffee,

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