Whatever has been posted till yet was not really so much useful if you consider its application in the real life as the old X.500 architecture and all other things are being rolled out slowly out of the technologies. Most of the messaging technologies have started adopting the SMTP as a standard for mail flow over the internet as well as within the organization too. Microsoft Exchange Server 2007 is one of the initiatives to it.
Anyways, that will take time to get the old technologies out of date, all the matter posted till yet was just to let everyone understand the foundation of AD and how it evolved from an X.500 architecture to today’s real world active directory.
Now starts the actual adventures life of Active Directory that we use as a day to day practice to create users, delete them, modify the user rights, and whatever you can imagine. Yet, before getting in depth of Active Directory and later Exchange Servers I still would like to shed some light on the LDAP namespace structure and how it has been utilized very smartly in design of Active Directory. So, let’s have a look at the LDAP namespace structure which is strictly followed by Microsoft Active Directory Service.
Directory Service has two significant features and those are it is spread across the servers and then the second one is; it allows user to access the information by querying anyone of the servers it is spread across. To get it working, effectively defining a namespace in which each object can be location can be quickly determined. The namespace is structured as follows and contains many new abbreviations in it. They are as follows:
• Common Names
As we discussed in the previous posts active directory stores the information in the form of objects and the objects have their own attributes which describe them. For example, a user Dave is stored as an object in active directory database and this object has attributes like his logon name, password, phone number, address, and many others.
When LDAP client needs to locate the information about user Dave it simply passes a query to the active directory to search the phone number of user Dave. This query is always in the form of a distinguished name of the object and contains an attribute which the LDAP client wants to see.
A search for information about Tom Jones could be phrased in a couple of ways:
• You can search for attributes in Tom’s User object. “Give me the Department attribute for cn=Tom Jones, cn=Users, dc=Company, dc=com.”
• You can search for attributes that end up including Tom’s object.” Give me all User objects with a Department attribute equal to Finance.”
In either case, LDAP can find Tom’s object because the name assigned to the object describes its place in the LDAP namespace.
• Distinguished Names
A name that includes an object’s entire path to the root of the LDAP namespace is called its distinguished name, or DN. An example DN for a user named CSantana whose object is stored in the cn=Users container in a domain named Company.com would be cn=CSantana, cn=Users, dc=Company, dc=com.
An identifying characteristic of LDAP distinguished names is their little-endian path syntax. As you read from left to right, you travel up the directory tree. This contrasts to file system paths, which run down the tree as you read from left to right.
• Relative Distinguished Names
An object name without a path, or a partial path, is called a relative distinguished name, or RDN. The common name cn=CSantana is an example of an RDN. So is cn=CSantana, cn=Users. The RDN serves the same purpose as a path fragment in a filename. It is a convenient navigational shortcut.
Two objects can have the same RDN, but LDAP has a rule that no two objects can have the same DN. This makes sense if you think of the object-oriented nature of the database. Two objects with the same DN would try to occupy the same row in the database table