A Quick Introduction to LDAP

Before we dive into how ADAM works, let's review some core LDAP concepts. If you are coming to LDAP and ADAM from the world of databases, this introduction should get you started with big differences and the key topics.

Most databases store data in a relational way: big rectangular pieces of data (tables) have some relation to each other (such as a customer ID that both tables share).

LDAP, on the other hand, deals with its data in a hierarchical tree. The standard way of thinking about data in LDAP is to think of a tree of LDAP objects, not discrete pieces of data. An example of this tree can be seen in Figure 1.

Figure 1: Customers and Employees in a Tree (adam-heir.cdr)

Each of these objects is just a container for a set of properties that describe it. For example, the “cn=Acme Co.” object can hold a number of properties that describe it, as seen in Figure 2.

Figure 2: Object Properties (adam-object.cdr)

At its heart, LDAP servers do two things:

• Store named objects in a hierarchy.
• Store name/value pairs about objects.

At some point, what you can store and where you can store it in an LDAP store must be dictated. LDAP stores are not simply an amorphous place to put data. You must have rules; these rules are referred to as LDAP schema.

In general, LDAP schema consists of two types of schema: classes and attributes. Class schema dictates the rules about how objects are stored in LDAP, and what attributes can be stored with those objects. Attribute schema dictate the name of a particular piece of data, and what data type is used when stored.

Attribute Schema

Let's start with attribute schema. Some examples of attributes are:

• Address: The street address of an object. The type is string.
• User-Password: The password for an object. The type is a string.
• Is-Defunct: A flag to specify if an object is still is in use. The type is a Boolean flag.

These attributes are typical of most LDAP systems. You might notice that these attributes seem to be biased towards people and companies. That is true; LDAP systems were developed to hold large E-mail and personnel databases. While we can use LDAP for other storage, information about users, customers, and personalization is a natural fit since the data is not volatile by nature.

Attribute Schema typically has the following pieces of information:

• attributeSyntax: The data type for the attribute, stored as an object identifier number.

You may want to learn more about Active Directory Attribute Syntax and get recommendations on what .NET types should map to which LDAP syntax at Attribute Syntax Type Recommendations, both from MSDN.

• isSingleValued: A Boolean value that indicates whether an attribute stores an atomic value or a list of values. By specifying false here, you can store a list of items of the specified type. Be careful not to depend on ordering, though. The order of a multi-valued attribute is random and cannot be depended on.

That is all there is to attribute schema. Let's see how they relate to class schema.

Class Schema

Class Schema are the definitions for a particular class of objects. Typically, class schema are made up of a couple pieces of information:

• subClassOf: Specifies another class schema object that this class inherits from. All classes need to inherit from the class `top' at a minimum.
• possibleSuperiors: Specifies structural limitations as to what class of object can be the parent of this object. For example, Employee objects can exist under Companies, but probably not under a Computer object.
• possibleInferiors: The inverse of possibleSuperiors. It specifies structural limitations as to what class of object can be the child of this object.
• mandatoryAttributes: A list of attributes that must be set for this class's objects to be valid.
• optionalAttributes: A list of attributes that are allowed to be set for this object, but are not required.

The possibleSuperiors and possibleInferiors properties let you limit the structure of objects in the LDAP store by dictating who can contain whom. The mandatoryAttributes and optionalAttributes properties together specify the complete set of data that the objects can contain. Lastly, the subClassOf property specifies which class to inherit these attributes from. So, if you have class A that has postalAddress as a mandatoryAttribute, and you have a class B that is a subclass of A, postalAddress is specified as a mandatory attribute and cannot be changed.

For historical reasons, all objects have a couple of different names in an LDAP store. Luckily, these names are actually related:

• Common Name (cn): In ADAM, all objects need a common name specified: simply the name of an object. This must be unique within a single parent. In other words, if you have a company with employees contained within, each employee must have a unique name. (Another employee under a different company can have that same common name, which should put the John Smiths of the world at ease.)
• Distiguished Name (dn): This is the common name of an object with a list of the containing object and all containing objects. Think of it as as a path to the object. For example, a dn of an employee may be /cn=MSDN/cn=Companies/cn-=Acme Co./cn=Employees/cn=John Smith.
• Relative Distinguished Name (rdn): This is simply the distinguished name relative to a particular object. So, using the earlier example, the rdn of John Smith within the Acme Co.'s object is cn=Employees/cn=John Smith.

Usually, both the dn and rdn are determined for you when you create objects. The common name must be specified when you create new objects. Often, this makes you feel as though you are naming the object twice. Once you create the object with a name of cn=Your Object, you need to set the cn to Your Object.

There are two styles of dns and rdns:

• Path Style: This style is shown top down with slashes to separate elements of the name. For example, cn=MSDN/cn=Users/cn=John Smith.
• Name Style: This style is shown bottom up, with commas to separate elements. For example, cn=John Smith, cn=Users, cn=MSDN.

Both styles are perfectly acceptable, but be aware that ADAM tends to return the Name Style.

Got what LDAP is all about? Let's talk about Microsoft's implementation of LDAP in ADAM.

Next: ' Getting Started with ADAM ' >>






Discuss Making Sense of ADAM   Hi Is it possible to use ADAM to store custom... What happened to the the figures? >>> Post your comment now!





>>> More Using Microsoft Visual Studio Articles          >>> More By Shawn Wildermuth