Early Directory Technologies

The first directory that comes to mind when you think of early computer systems is the file system directory. The organization of data files and programs into a structure of directories and subdirectories became more important as the size of the available storage grew. When networking PCs became a necessity, the capability to organize users and secure data from inappropriate access led to the concept of logging in to the computer or network, just as had been done with multiuser, mini, and mainframe computers for many years. This made it necessary to create another database (that is, a directory) to keep track of users and security information.

For network administrators and users alike, there is a great need today to quickly locate resources that, in a modern distributed computing environment, can be anywhere from the computer on the user's desk to a file server halfway around the world. So when you're deciding what kinds of information to store in a directory service database, the needs of both the users and the administrators of the system must be taken into consideration.

The Difference Between the Directory and the Directory Service

The first thing you will need to understand about the Active Directory is that it is composed of a database and many different programs that can be used to operate within the database. The term directory is used to describe the underlying database that holds all the information managed by the directory service. The actual information store, the directory, is stored in the Extensible Storage Engine (ESE)ESE is a derivative of Microsoft's oft-used JET engineand a variant of this same technology is also used by Microsoft Exchange Server.

The term directory service refers to the programs that manage the database and allow users and programs to access its data in a meaningful way. After you've created a domain controller in a Windows 2000 or 2003 network, you'll find several new utilities in the Administrative Tools folder, such as the Active Directory Sites and Services Manager and the Active Directory Users and Computers tools. You'll find other tools in this folder, depending on the components you selected when installing the operating system. The Event Viewer application is still present, but now it uses the MMC interface, as do most of the other system management tools.

The directory service consists of the programs and application programming interfacesthe Active Directory Service Interface (ADSI) and the LDAP C lower-level API. These can be used to create additional tools for use with the directory. The directory service offers the network a namespace that can be used to locate objects throughout the network by querying by the object's name or one of its attributes.

The Directory System Agent (DSA) provides the service responsible for performing actual queries and updates to the database. Because applications and APIs make requests to the DSA in a defined fashion, the functions they perform are separated from the actual underlying format of data storage.

Interesting Objects

The Active Directory provides the capability to query a large database that can be used to locate any object, or information about any object, stored in the directory database. To understand how important the Active Directory is in Windows 2000/Server 2003, you should first understand the kinds of data that will be stored in the objects that the directory organizes.

Knowing what kind of data should be a candidate for management by a directory service is not easy. Here, the definition of a directory service gets kind of fuzzy.

It is common to compare directory services to the white and yellow pages of the traditional phone directory. White pages are specific queries in which the input is a person's name and the output is the person's telephone number. Yellow pages have a more general "browsing" capability, with more general input about a subject or concept. This results in a specific output selected by the user from the information found. The Active Directory provides the best of both. You can search for a specific object if you know the name you are looking for (such as a username or computer name), or you can browse for objects by using the data stored in the many attributes that objects can possess. Looking up a username in the Active Directory is sort of like using the white pages of the telephone book.

However, suppose you are a mobile employee. You have just walked into the Atlanta office and you need to print a document. You quickly search the directory to find an object that

• Is a printer

• Is located in the Atlanta branch on the third floor

• Supports color printing

This situation shows that directory services also can be used in a manner similar to the telephone book's Yellow Pages service. You can specify the attributes for an object you want to find, and perform a search of the directory to see whether there are any matches. Or, if you know the name of an object, you can query the database to find that object and then view its properties. This method of querying the database enables you to find something you know a little about, or to find the attributes of an object you already know about. In the latter example, you might know the name of a printer located down the hallway but not be aware of whether it supports duplex-printing. The Active Directory can tell you that, as long as the information has been put into the directory database.

As you can see, the Active Directory stores the traditional kind of information that usually is found on a network computer operating system. What other kinds of objects can you store in the directory? Well, just about anything you can think of, as long as you can express it as a collection of attributes (or features of the object). If you want, it's possible to create objects that represent your stamp collection. You can create objects that represent just about anything. The Active Directory comes with a large number of built-in objects. These are defined in the schema, a concept that is discussed later in this chapter. You can extend the schema to add objects (and attributes) that are particularly useful for your business or situation. However, almost everyone agrees that the information stored in the directory should be interesting or of some practical use.

What Active Directory Delivers

Because the Active Directory is based on industry standards, it can offer many services to a network. The Active Directory provides some very important features to a Windows network, or a heterogeneous network made up of computers using different operating systems:

• A single logon for the entire network. This was present, more or less, in previous versions of Windows, but it can be extended today to incorporate NetWare, Unix, Linux, and other operating systems. For examples, see Part XI.

• A hierarchical structure that organizes objects and tasks into a logical format so that you can quickly and easily locate the information you need. The X.500 hierarchical format has been adopted in the Active Directory.

• An extensible format that enables the directory to encompass new objects as operating systems and management functions evolve. This means that the schema of the directory should be easy to modify. Using MMC snap-ins, this can be a simple chore with the Active Directory. Note, though, that Microsoft has created a schema for the Active Directory that should suffice for most networks, and you should modify the schema only after you become aware of the possible consequences of your changes. Changes to the Active Directory schema are permanent and cannot be undone by any means short of recovering all domain controllers from backups made prior to extending the schema.

• Fault tolerance and a distributed database. You don't need to create numerous domains with primary domain controllers to receive updates and back up domain controllers to "hold the fort" when a PDC isn't available, as was the case with NT. Instead, all domain controllers in a native-mode Active Directory network are peers, and each domain controller in the domain holds a copy of that domain's portion of the Active Directory database. There is no need to "promote" a backup domain controller if a primary one fails, because all domain controllers in a domain are considered to be the same.

• Scalability. Management tasks can now be centralized or distributed as your administrative needs dictate. You can delegate authority over parts of the database (such as a domain or part of a domain) as you see fit.

• Programmability. Application developers and script writers can use many tools to interface with the database.

• Manageable security mechanisms. From the small desktop system to the worldwide enterprise, you can grow the network to one that consists of millions of users.

One of the most important features that large enterprises would like to see is a standards-based implementation so that you do not get locked into a single vendor for all your software needs. Migration tools, both to and from the directory database, are needed until the standards issues settle down and products from different vendors work together as seamlessly as they do in the telephone network.

Evolution of Directory Services from X.500 to LDAP

When you think of standards, the name International Organization for Standardization (ISO) probably comes to mind. After all, the ISO has been involved in efforts for many years to help make the interchange of data between computers less of a proprietary chore and more of a free flow of information. The ISO, along with the International Telecommunications Union (ITU), developed the X.500 group of standards to promulgate a global white pages directory service. Under the umbrella of X.500 there are many standards, which include naming conventions and networking protocols (OSIthe Open Systems Interconnection protocols).

Note

Although many books state that the letters ISO are an abbreviation for International Standards Organization, that is not the case. Instead, the actual name of the organization, in English, was originally International Organization for Standardization. The term ISO was eventually selected by this group because of its root meaning from the original Greek word isos, which translates generally to "equal." This name was chosen because it pretty much indicates standardization, without having to use a particular language to create an acronym. Thus, the ISO works with standards bodies from many different countries, attempting to make technological things "equal" so that they will work together. You can find out more about ISO and its member organizations by visiting www.iso.org/.

However, the OSI networking protocol never did take off as expected, although some vendors implemented parts of it. Digital Equipment Corporation (DEC was absorbed by Compaq Computer Corporation, and Compaq was of course acquired by HP) tried for years to get OSI standards adopted by evolving its own proprietary networking protocolDECnetinto an OSI-compliant protocol and by releasing an operating system (OSF) based on OSI standards. Even today the venerable operating system once called VMS (for Virtual Memory System) has been called OpenVMS for many years because of this attempt to adopt open standards.

While all this discussion of standards was going on in committees and protocols were being discussed, debated, and refined, the Internet took off. And as everyone now knows, it is TCP/IP that glues together the Internet, not OSI. It's funny in a way that standardization came about ad hoc instead of through an orderly process.

But it was not just the lack of interest in OSI network protocols that stifled the acceptance of X.500 proposals. Several other important factors were involved, such as the overhead associated with implementing many of the X.500 protocols. Although X.500 (et. al) does a good job defining protocols, it does not attempt to define standard programming interfaces (APIs, which make it easy for different vendors to write applications that implement the protocols).

Another reason you won't find X.500 standards implemented in many places is its complicated naming scheme. The hierarchical organization of the directory, which can be seen in its naming format, is a good idea, but the long-winded name is not. For example, which of the following would you rather try to remember when sending someone an email message: the X.500 format or the RFC 822 name?

• X.500

  CN=Ono,OU=Studio One,OU=New York,O=mydomain,C=US 

• RFC 822

  [e-mail] 

The X.500 name, in this example, reveals the organization structure of the directory, whereas the RFC 822 name does not. But every user shouldn't have to be fully cognizant of the directory structure in order to use it. If you want to send Ono a message via email, you should not have to know that she works in Studio One (organizational unit=Studio One) and that she is in the company's New York division (organizational unit=New York). You shouldn't have to specify that she is in the United States because you already indicated that she is in New York. And because you can have additional organizational units (OU=) in the directory, the X.500 address actually could have been much, much longer. Note that in the preceding example one container object can contain other container objects before you eventually get to the "leaf" object that is the object containing the attributes you wanted to locate in the first place.

Directory services should make things easier, not more difficult. Microsoft's Active Directory (as well as other LDAP-based directories) uses the hierarchical treelike organization as spelled out by the X.500 standards, but the Active Directory also adapts the Windows NT domain system, by using DNS as a locator service, to the structure. That is, in addition to the standard container types such as OU for organizational unit, and so on, the Active Directory has a DC, or domain component, container object which is defined in the schema that can be used to house domains in the directory. By incorporating domains into the directory, rather than simply discarding the domain concept, Microsoft has made it easier for users of Windows NT 4.0 to interact with or make the migration to Windows 2000, Server 2003, and future versions of Windows. Domains can be imported into the directory when migrating existing Windows NT networks. You can learn more about this in Chapter 56, "Migrating from Windows NT 4.0 to Windows 2000, Windows 2003, and Windows XP."

The overhead associated with other X.500 recommendations also needs to be overcome. Four "wire" (or communication) protocols were defined:

• Directory Access Protocol (DAP)

• Directory System Protocol (DSP)

• Directory Information Shadowing Protocol (DISP)

• Directory Operational Binding Management Protocol (DOP)

These protocols were developed during a time in which PCs did not have sufficient computing power to host such complex protocols and still be capable of performing adequately as a desktop workstation. And mini-computers and mainframe computers used proprietary operating systems that were not easily adaptable to these protocols, nor did it provide a benefit to vendors to adopt an open protocol when the whole purpose of marketing their products was to keep the customer "satisfied" with a single source. The exception of course, mentioned earlier, was Digital Equipment Corporation.

For more information about the history of the X.500 protocols and the development of LDAP, see Appendix D, "The Lightweight Directory Access Protocol."

To reduce the overhead associated with the X.500 directory structure, a new set of Request for Comments (RFCs) was developed to define the Lightweight Directory Access Protocol (LDAP). LDAP is the protocol that Microsoft and many other vendors have chosen to implement to create directory services. LDAP has gone through several refinements via the RFC process, and the Active Directory has been designed to be compatible with both version 2.0 and the newer standard, LDAP version 3.0.

Note

For those interested in some very boring reading, version 2.0 of the Lightweight Directory Access Protocol (LDAP) is defined by RFC 1777.

If that doesn't put you to sleep, try reading up on version 3.0. It has been adopted by most LDAP products, including Microsoft. LDAP version 3 is defined by RFC 2251, "Lightweight Access Directory Protocol V 3," by Wahl, Howes, and Kille. In Appendix D, you'll find a list of additional RFCs that further define aspects of the LDAP protocol.

By using a standard that is being implemented by many other vendors, including Netscape and Novell, the Active Directory can exchange data and queries with other directory service implementations; thus, you won't get stuck in yet another proprietary solution. Of course, this all depends on how Microsoft and other vendors choose to interpret and implement LDAP features as they are standardized and refined.

The Active Directory Schema

If you are familiar with databases that are manipulated using the Structured Query Language (SQL), you might already understand what a schema is. Put simply, it is the definition of the types of things, or objects, you can store in the directory structure. The directory contains many types of objects, such as user accounts, printers, and computer accounts. Each object is made up of attributes that contain the specific data for the object. The schema is the definition of these objects, their attributes. Technically, these templates of objects are called classes. A particular object in the directory is derived from one or more classes defined by the schema, and perhaps tweaked a bit by the addition of new attributes by the network administrator. For C programmers, this is like using a header file to define certain programming objects, creating instances of these objects as needed for your application.

In some directory implementations, the schema is stored as an ordinary ASCII text file, similar to the way some DNS servers store their information. Each time the software that runs the directory is booted up, the schema file is read into memory. One of the drawbacks of using this method is that if you want to make changes to the schema, you usually have to edit the text file and then reload it into the application. The Active Directory avoids this problem by defining the schema of the directory in the directory itself. You can add to the schema just as you do other objects in the directory, and you can disable attributes and most objects in the AD.

Note

The abbreviation ASCII stands for American Standard Code for Information Interchange. This 7-bit code allows for up to 128 character definitions, including alphabetic, numeric, and punctuation and other characters. Unicode and other computer numeric representations have been developed in the past few years to extend a computer's recognition of characters involving languages other than English. For example, see Unicode (which is supported by most modern operating systems) in Appendix B, "Networking Glossary."

Specifically, the Active Directory schema is made up of four types of objects that are used to define the schema:

• Schema container object Each directory instance has at least one schema container object, which is a direct child of the directory root object. The schema container holds the other objects, which describe the object classes and attributes of the directory.

• Class container object This container object holds the object classes that define what kind of objects can be stored in the directory. Class objects define objects that store the actual properties, or attributes, of an object class. You create instances of objects by using the definitions of an object class.

• Property object This type of object is used by the schema to define a particular attribute or property of the object. It references the syntax object.

• Syntax object This object describes a particular syntax that is applied to one or more properties defined by property objects.

Note

An object in a directory database is made up of a number of attributes. Think of this like an address used for a postal letter. An address is made up of a name, street address, state, postal code, and so on, depending on the country. Each of these subcomponents of the "address" object is called a property of the address object. Additionally, the terms property and attribute are used interchangeably throughout this chapter. An attribute or a property of an object is merely a component that makes up the object.