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