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 ServiceThe 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 on 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 engine ”and 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 interfaces ”the Active Directory Service Interfaces (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 ObjectsThe 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
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 DeliversBecause 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:
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. From X.500 and DAP to the Lightweight Directory Access ProtocolWhen 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 (OSI ”the Open Systems Interconnection protocols).
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 recently acquired by HP) tried for years to get OSI standards adopted by evolving its own proprietary networking protocol ”DECnet ”into 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?
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 62, "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:
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. 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.
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 SchemaIf 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.
Specifically, the Active Directory schema is made up of four types of objects that are used to define the schema:
|