Active Directory and LDAP

When Microsoft decided to replace the Registry-based account management system in Windows NT with a real time directory service, rather than introducing a proprietary directory service of their own, they chose to adopt LDAP. Even more importantly, from our perspective as administrators, Microsoft chose to deliver their LDAP directory service using two proven technologies.

Extensible Storage Engine (ESE)
DNS-Based Locator System

As I said in my previous post the TLAs were derived as it is in the new directory services like active directory. Microsoft continued the trend and decided to host the Active Directory service into a database, unlike DIT.
This database is made up of tables. For a SQL administrator it would really not very tough to understand what does a table in a database mean? So, active directory database is made up of tables, in which; rows represent objects and columns represent attributes associated with the objects. If you have started thinking that a SQL administrator can now manage active directory then stop imagining wild because, what makes this database different from others is the way the tables inside are managed. A component which manages all these tables is very often known as database engine.
LDAP standards do not define any particular table management technology. For Active Directory table management Microsoft chose to use a proven technology very well known as Extensible Storage Engine (ESE) which had proven its efficiency in earlier versions of Microsoft Exchange Server. Microsoft decided to use ESE over the SQL database engine because SQL engine does not work efficiently with object oriented databases which comply the LDAP structure. On the other hand, ESE engine was primarily developed to handle the object oriented databases.

Though, design and architecture of a LDAP database compliant with LDAP was ready; it was unusable for a normal until he could locate this information repository. They decided to build the entire directory around Domain Naming System (DNS). So when the LDAP client wants to discover the location of the directory services it reaches the location by using DNS queries. This was made possible by using the service locator (SRV). SRV is nothing but a pointer which redirects the clients to a specified service running on a server. If you decide to dig into the DNS architecture and functionality SRV is not really a very simple service component which can be understood real quick but Microsoft made it available by registering them automatically by using dynamic DNS.

I would have really loved to write down some more information in this post about the storage architecture but I am surrounded by some other attacks of my network these days and have to fix them up on priority basis. In the next post let’s have a closer understanding of a LDAP database that runs active directory. I will try to document how does Active Directory information is stored in the database which is run by ESE. Let me promise you that the next post will cover some basic information about the LDAP information model too. Till then keep searching the information around and fill it in your biological database. 😀