What to do with Directory Services

Enterprises, whatever their size and scale, require to
maintain an 'information directory' of some sort. Beginning with simple
information hives like addressbooks to large complicated multi-tiered
distributed hives that describe hardware, configuration of network services,
authentication and authorization data, a  'directory service' has now
become a part of every organization's IT infrastructure.  Apart from
storing personal details about people, a directory is also used to store their
'digital personality'-what applications do they have access to, what
attributes will identify them, mail delivery strategies and public keys of the
user if any.

Directories are now increasingly used to define not just
users but also the services consumed. Most Unix and Windows services are
configured from flat plain-text files or simple one-file databases. Each service
has its own file format and configuration parameters that vary from one product
to another even for the same service. This tradition has come under considerable
stress for several reasons: product specific configuration leads to considerable
challenges during migration. Even migrating a mail service from Sendmail to
qMail or Postfix for example, requires rewriting around 13 configuration files.
And there is no one-to-one correspondence between features and configuration
variables to make the transition smooth. Changing the authenticating platform
from Windows to Unix or the other way round is even more scary. To complicate
matters, service configurations are rarely static. Multiple mail delivery
mechanisms for traveling and other groups who require frequent changes in their
user attributes, frequent changes to application access control and role
management for disparate applications that change periodically, are all part and
parcel of the problem. As configuration files become larger and larger, the
retrieval of per-user configuration parameters from plain-text files begins to
affect performance. A half-way solution adopted by several applications--of
compiling plain text configuration files into read optimized binary db files --
has not eased service administration since each time a new user is added or a
configuration change affected, the administrator has to re-compile the
configuration files and restart or reload the service.

What is required is a solution for storing user
information/configuration that is easy to administer, has little performance
overhead and one that can be accessed by multiple baseline services
(authentication, application access control, user-specific mail delivery and
gateway proxy services) from a common information store. The Lightweight
Directory Access Protocol (LDAP , current version 3) — a simplified descendant
of the traditional X.500 protocol provides exactly this functionality and has
very rapidly become the first choice for enterprise wide user
information/configuration data provision. The chief reasons for this recent rise
in the popularity of LDAP are:

• Reasonably inter-operable LDAP implementations are
  available on all platforms including Windows, where it is referred to as the
  Active Directory.
  

• Information is stored in a format that is optimized for
  reads, with very little protocol overheads. LDAP data retrievals are fast
  and often compensate for WAN latencies
  

• Almost all enterprise grade network services are now
  'LDAP aware.'
  

• The data schema that LDAP uses is inherently flexible
  and scalable unlike the 'rows and columns' schema of conventional
  databases. This means that storing multi-valued parameters such as multiple
  phone numbers and  mail ids) become natural yet structured.
  

• The ease of accommodating unstructured information is
  not at the cost of relationships between the entities — which are enforced
  by a 'tree-like' structure.
  

• While LDAP allows a flexible scheme; there is a fairly
  well respected name-space convention (attributes must have well defined
  names ) that must be certified by the IANA for seamless interoperability.
  

• Large sections of a Directory Information Tree can be
  moved and physically located at remote locations, yet managed from a single
  administrative location. This feature, if properly designed and deployed,
  gives remote locations a significant degree of autonomy to manage and update
  information services and make this information available transparently to
  all other locations as if it were centrally managed.
  

Gurunandan Bhatt