- New Features in Windows Server 2003
- Limitations of Classic NT Security
- Directory Service Components
- Brief History of Directory Services
- 500 Overview
- LDAP Information Model
- LDAP Namespace Structure
- Active Directory Namespace Structure
- Active Directory Schema
- Active Directory Support Files
- Active Directory Utilities
- Bulk Imports and Exports
- Moving Forward
This chapter is from the book
This chapter is from the book
This chapter is from the book
X.500 Overview
A directory service is a distributed store of information about the users of a computer system and the infrastructure that supports that system.
The goal of X.500 was to cut through the babble of competing information repositories to define a single place where users from all nations could go to locate each other, learn about each other, discover common likes and dislikes, and eventually communicate freely to find a path to universal peace and brotherhood and the dawning of the Age of Aquarius. The key features of an X.500 directory service are as follows:
-
The information is distributed among many different servers.
-
Users can submit queries to any server to find information anywhere in the system.
-
Servers can find information on other servers because they share common knowledge about each other.
X.500 Components
The magic of X.500 comes from the flexible way it compartmentalizes and distributes information. This flexibility comes at the cost of complexity, though—not the least of which is a thicket of nomenclature rife with obscure computing jargon and Three Letter Acronyms (TLAs). These X.500 acronyms crop up quite a bit in Active Directory documentation, so it pays to give them a Quick Run Through (QRT). Refer to Figure 6.2 for a roadmap. Here are the X/500 TLAs:
-
Information in an X.500 Directory is stored in a Directory Information Base (DIB).
-
The DIB is divided into pieces that are structured into a hierarchy called a Directory Information Tree (DIT).
-
Each piece of the DIB is stored on a server called a Directory Service Agent (DSA).
-
A user who needs information from Active Directory submits queries via an application interface called a Directory User Agent (DUA).
-
A DUA communicates with a DSA using the Directory Access Protocol (DAP).
-
One DSA communicates with another using the Directory System Protocol (DSP).
-
Administrative information exchanged between DSAs is controlled via policies defined by the Directory Operational Binding Management Protocol (DOP).
-
A single Directory Management Organization (DMO) takes charge of a Directory Management Domain (DMD) that contains one or more DSAs.
-
Information held by one DSA is replicated to other DSAs in the same DMD using the Directory Information Shadowing Protocol (DISP).
)
Figure 6.2. X.500 components and their communication protocols.
DAP, DSP, DISP, and all other high-level communication protocols in X.500 use OSI networking as defined in ITU Recommendation X.200/OSI-EIU Standard 7498.
X.500 Transaction Example
Here's an example of how these X.500 components tie together (see Figure 6.3). Let's say that the secondhand car dealers in America get together and decide to form an association. They want a directory service to store information about vehicles available for sale at each member's showroom.
)
Figure 6.3. Diagram of an example X.500 communication scheme.
The DIB for this dealership directory service includes makes, models, years, vehicle identification numbers, and unbeatable prices. Each dealer is assigned a DMO that controls a DMD. The DIB in each DMD is hosted by at least one DSA, which exchanges administrative information with DSAs in other DMDs using DOP. Dealerships in the same region have individual DSAs that replicate their copy of the DIB between each other via DISP. The pieces of the DIB are joined into a single DIT, the root of which is hosted by a DSA at headquarters.
Why go through all this trouble? Well, if a customer at a dealership in Kankakee wants a cherry-colored Cherokee, the salesperson can sit at a DUA and submit a query to a local DSA via DAP. The DSA would check its copy of the local DIB and if it failed to locate a record, it would use DSP to query other DSAs until it either found a match or exhausted all possibilities. The DUA could then be programmed to suggest alternatives, like a cream-colored Chevelle in Chicago.
The important point to remember about this transaction is that there is no central repository of information. Each local DSA holds its own copy of the DIB. Referral mechanisms are used to distribute queries around the system.
Why LDAP Instead of X.500?
Several pedigreed X.500 directory services are commercially available, but few have achieved widespread popularity. The problem with pristine X.500 implementations is the overhead represented by all those protocols. When you get an army of DUAs all talking DAP to DSAs that refer queries to other DSAs using DSP while at the same time mirroring their DIBs to other DSAs in their DMD via DISP, my friend, you've got a whole D* lot to go wrong.
In the early 90s, a few bright folks at the University of Michigan wanted to build a directory service to handle their 100,000+ students, staff, and faculty. They gave up on the complexities of X.500 and came up with a scheme that retained the X.500 directory structure but gave it a streamlined access protocol based on standard TCP/IP instead of ISO. They also came up with a pared-down referral mechanism, a more flexible security model, and no fixed replication protocol. They called the result the Lightweight Directory Access Protocol, or LDAP. The rest, as they say, is history. The Blue and Maize folks no longer control LDAP development. The current repository of LDAP knowledge is at www.openldap.org.
Active Directory and LDAP
When Microsoft decided to replace the clumsy Registry-based account management system in classic NT with a true directory service, rather than devise 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)
At its heart, a directory service database is made up of tables with rows representing objects of interest and columns representing attributes of those objects. What sets different databases apart is the way the tables are managed. This table manager is often called a database engine.
The LDAP standards do not stipulate a particular table management technology. For the Active Directory table manager, Microsoft used a revved-up version of the Extensible Storage Engine (ESE) first introduced with Exchange. Microsoft chose ESE over the SQL Server database engine because a SQL engine does not work efficiently with the object-oriented structure of an LDAP directory. The ESE engine, on the other hand, was primarily designed as an object-oriented database.
DNS-Based Locator System
Users cannot take advantage of the information in a directory service if they cannot find the servers hosting the information. Microsoft chose to build its LDAP directory service around the Domain Name System (DNS). When an LDAP client needs to find a server hosting a directory service, it does so by querying DNS. This enabled Microsoft to use new features in DNS to simplify the search.
For example, Microsoft took advantage of the relatively new service locator (SRV) record type to put pointers in DNS to indicate the names of servers hosting LDAP and Kerberos services. SRV records have a relatively complex structure, but Microsoft was able to avoid typographical errors by registering them automatically using Dynamic DNS.