Exchange Geek's Weblog

I'm a Geek!

LDAP Information Model

Posted by Milind Naphade on 06/04/2008

Continuing the matter of the previous post, this post will contain the information about the LDAP namespace and the LDAP information mode.
For a newbie who always finds it difficult to understand the abbreviations and the terms used in Active Directory explanations ever since, I have tried to explain it in the simplest form with an example that everyone has come across at least once when we were in our school and university days.
As I said in the previous post, the directory database is nothing more than an object oriented database which contains information stored in the form of tables.

To narrow down the scope of the explanation and to simplify the example lets recall that Oak wood cupboard which used to store the books in it (in library off course. Well, being very honest I never used to be a loyal member of any library, so apart from observing and co relating those oak wood cupboards with directory database I never looked at them from any other perspective).
In other words the LDAP information model is somewhat like that old Oak wood cupboard. How? Here is an example.

A directory service may be a bit fancier than the database you use to tally the overtime pay you’ve lost since taking your salaried administrator position a few years back, but the principles of operation are pretty much the same.

Object-Oriented Database

In X.500 terminology, the directory service database is called a Directory Information Base (DIB). If you think of an old-style library card catalog system as a kind of directory service, one of those big oak cabinets with rows of drawers would be a DIB.

The X.500 directory service structure was developed at a time when object-oriented databases represented leading-edge technology. If your only exposure to database technology has been more modern relational databases, the design constraints of an object database can look a little strange.

In an object-oriented database, each record (object) occupies a unique position in a hierarchical namespace. The object’s name and path traces its origins to the top of the namespace, in much the same way that a Daughter of the American Revolution traces her forebears back to the Mayflower. A file system is an example of an object-oriented database.

Object databases consist of big, structured sequential files connected by a set of indexes that are themselves nothing more than big, structured sequential files. This underlying database technology is called Indexed Sequential Access Method, or ISAM. You’ll see this term in the Event log and other reports.

The ESE database engine exposes the flat ISAM structure as a hierarchy of objects. In addition, Microsoft makes extensive use of COM technology by representing Active Directory objects as COM objects via the Active Directory Services Interface (ADSI).

Classes and Attributes
a directory service contains information about specific types of objects, such as User objects, Computer objects, and so forth. These are called object classes. A class is a bundle of attributes with a name.
Attributes and Properties
Attributes are also often called properties. There is a difference between these two terms, but it is so subtle that most reference manuals, including this one, use them interchangeably.

The attributes associated with a particular object class differentiate it from other object classes. For example, User objects have different attributes than Computer objects or IP Security objects. Using a library card catalog as an example, different card formats represent different classes of items. A certain card format is used to record entries for Books. Another format is used for Tapes. The card format for Books would have spaces for Title, Author, ISBN, and so forth. A card for Tapes would have spaces for those entries plus additional spaces for Read-By and Play-Time.

An object class, then, is really nothing more than a bundle of attributes with a name. RFC 2256, “A Summary of the X.500(96) User Schema for use with LDAPv3,” defines 21 classes and 55 attributes for use in a standard LDAP directory service. Active Directory adds quite a few more for a total of about 200 object classes and 1500 attributes.

Classes also define the scope of a directory service database. You would not expect to find cards in a library card catalog representing Off-The-Road Vehicles or Double- Meat Hamburgers. Microsoft engineers defined the initial scope of Active Directory by including a certain set of object classes and attributes. This list can be extended by other applications or by administrators. For example, your organization could create attributes and classes for storing badge numbers and social security numbers in Active Directory.


Sorry, the comment form is closed at this time.

%d bloggers like this: