X.500 – An Overview and Components

The previous post was just to highlight the limitations of Windows NT 4.0 and the need why an a new version of directory services was required to be introduced in the market which could meet the rapidly growing network infrastructures.
Microsoft successfully rolled out its own product Windows NT4 by launching Active Directory Services.
Active Directory is not the only directory service which existing on this planet. Moreover of all Active Directory originated from the concept of Windows NT and Windows NT domain services were brought into market as an enhancement to the previously available directories.

In this post I am going to shed some light on evolution of directory services which will be backed up by explanation of directory service models and architectures. Following are key points;

Definition of Directory Service.
X.500 Overview and its components
How X.500 works.
Why LADAP and not X.500?
LDAP and its namespace model.

Definition of Directory Service.

A directory service is a distributed store of information about the users of a computer system and the infrastructure that supports that system.

X.500

The purpose behind implementation of X.500 was to create an information repository of people from different locations so that they can share their thoughts, locate each other, discover likes and dislikes, and head towards the brotherhood. The key features of X.500 are as follows:

The information is distributed among many different servers.
Users can submit queries to any server to find information anywhere in the system.
Servers can find information on other servers because they share common knowledge about each other.

X.500 Components

The X.500 architecture became very famous and was very much feasible too. The flexibility to store the information, sorting it out in proper manner, and making it available to end users made a drastic improvements in user experience, with a complex structure though. After all, flexibility can not be achieved without complexities.
To store all the information using this architecture the requirement of naming convention was born. This naming convention is as it is derived into Microsoft’s Active Directory Services too. This naming terminology is known as Three Letter Acronyms or TLA in short. They are as follows:

Information in an X.500 Directory is stored in a Directory Information Base (DIB).
The DIB is divided into pieces that are structured into a hierarchy called a Directory Information Tree (DIT).
Each piece of the DIB is stored on a server called a Directory Service Agent (DSA).
A user who needs information from Active Directory submits queries via an application interface called a Directory User Agent (DUA).
A DUA communicates with a DSA using the Directory Access Protocol (DAP).
One DSA communicates with another using the Directory System Protocol (DSP).
Administrative information exchanged between DSAs is controlled via policies defined by the Directory Operational Binding Management Protocol (DOP).
A single Directory Management Organization (DMO) takes charge of a Directory Management Domain (DMD) that contains one or more DSAs.
Information held by one DSA is replicated to other DSAs in the same DMD using the Directory Information Shadowing Protocol (DISP).

DAP, DSP, DISP, and all other high-level communication protocols in X.500 use OSI networking.

How X.500 works.

I would like to explain it in the form of an example in stead of writing down anything else. The example below illustrates a working transaction on X.500 directory. It will be better enough to understand the basic functionality.

Let’s say that a group of industrialists which belong to the same class of market want form an organization so that they can speed up their business by sharing information among each other. To achieve this they will need a common resource which can handle the storage of information available at every member of the group.
This group is basically in dealing of old cars.
Now, before you try to understand what this example means I will suggest to have a look at the figure first.

The DIB for this dealership directory service includes makes, models, years, vehicle identification numbers, and unbeatable prices. Each dealer is assigned a DMO that controls a DMD. The DIB in each DMD is hosted by at least one DSA, which exchanges administrative information with DSAs in other DMDs using DOP. Dealerships in the same region have individual DSAs that replicate their copy of the DIB between each other via DISP. The pieces of the DIB are joined into a single DIT, the root of which is hosted by a DSA at headquarters.

Why go through all this trouble? Well, if a customer at a dealership in Kankakee wants a cherry-colored Cherokee, the salesperson can sit at a DUA and submit a query to a local DSA via DAP. The DSA would check its copy of the local DIB and if it failed to locate a record, it would use DSP to query other DSAs until it either found a match or exhausted all possibilities. The DUA could then be programmed to suggest alternatives, like a cream-colored Chevelle in Chicago.

The important point to remember about this transaction is that there is no central repository of information. Each local DSA holds its own copy of the DIB. Referral mechanisms are used to distribute queries around the system.

Why LADAP and not X.500?

Several X.500 directory services are available, but few have achieved popularity. The problem with X.500 implementations is the overhead represented by all those protocols. When you get an army of DUAs all talking DAP to DSAs that refer queries to other DSAs using DSP while at the same time mirroring their DIBs to other DSAs in their DMD via DISP, my friend, you’ve got a whole D* a lot may go wrong in the jumble of Ds.

Few brains at the University of Michigan wanted to build a directory service to handle their 100, 000+ students, staff, and faculty. They gave up on the complexities of X.500 and came up with a scheme that retained the X.500 directory structure but gave it a streamlined access protocol based on standard TCP/IP instead of ISO. They also came up with a pared-down referral mechanism, a more flexible security model, and no fixed replication protocol. They called the result the Lightweight Directory Access Protocol, or LDAP. The rest, as they say, is history. The Blue and Maize folks no longer control LDAP development. The current repository of LDAP knowledge is at www.openldap.org.

Alright till yet. Now the actual adventure is to start about Active Directory, LDAP, LDAP model, LDAP namespace, Domains, Forests, OUs and much more. Before that I really need a refreshment . I would have been the university topper if I would have really worked so much hard in my college time. Well, I was never a bright student like the folks who developed todays well known Lightweight Directory Access Protocol.

The next post will cover up very interesting stuff like Domains and Forests and blah blah blah!!!