CHAPTER 30. Using the Active Directory Service

SOME OF THE MAIN TOPICS IN THIS CHAPTER ARE

---

Early Directory Technologies 556

Objects and Attributes 562

What Is a Domain Tree? What Is a Forest? 564

The Active Directory and Dynamic DNS 567

Active Directory Service Interfaces (ADSI) 571

The Active Directory Schema 573

Finding Objects in the Active Directory 581

The Active Directory Service and Windows Server 2003 585

New Active Directory Features in Windows Server 2003 585

In Chapter 37, “Windows 2000 and Windows Server 2003 User and Computer Management Utilities,” you will find a lengthy overview of using the Active Directory for basic functions, as the title of that chapter suggests. In this chapter you will learn more about how the Active Directory is structured, and how to manage the directory itself. The Active Directory, especially in Windows Server 2003, plays an important role in any Windows-based network.

If you have a heterogeneous network composed of Windows and other operating systems, see Part XI, “Migration and Integration,” to learn how the Active Directory can be used in this type of network.

The Active Directory was introduced by Microsoft with Windows 2000. The Active Directory is an LDAP-based directory service that enables you to store information about user accounts, domains, and resource objects in the same place for easy management. And because LDAP (see Appendix D, “The Lightweight Directory Access Protocol”) is a standard embraced by a large number of vendors, from Novell to Netscape, it is possible to enable networks that use different directory services to interact with each other. This can be an important factor when integrating two networks, or when migrating from one type of network to another.

The Active Directory can be installed on a Windows network when you migrate from Windows NT 4.0 to Windows 2000 Server, or Windows Server 2003. The examples in this chapter are based on Windows Server 2003, which incorporates many new features. However, the concepts are basically the same, though the windows and dialog boxes may look a little different if you are using an earlier version of Windows.

When you upgrade from Windows NT, domains become container units within the directory. Additionally, the nature of trust relationships between domains changes. There are many other subtle differences you will notice, but for the most part you will find it easier to manage network users and resources using the Microsoft Management Console (MMC) snap-ins to perform routine tasks. Other snap-ins can be installed in the MMC to allow you to perform more complicated functions, such as modifying the schema.

The only information stored in the Windows NT 4.0 SAM (security accounts manager) database is user and computer accounts, along with some security information, such as trust relationships between domains. Information about printers, file shares, and other resources is scattered here and there in separate databases and is managed by separate utilities. Administering network resources using multiple utilities with disjointed interfaces can become quite a nightmare in a large network. This disjointed method of administration has created a situation in which many upgraded their networks to Windows NT 4.0, but also adopted Novell Directory Services on the same network. Adding NDS to a Windows NT 4.0 network can solve a lot of problems by giving you a single place to administer many kinds of resources. The Active Directory consolidates information from these different sources into a single database, and provides you with a simpler management interface.

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 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 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 (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 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?

X.500

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

RFC 822

[email protected]

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.

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.

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.

Objects and Attributes

For the most part, an object is nothing more than a collection of specific pieces of information about the object. For example, an object that represents a user account contains attributes that hold information about the particular user. When you create user accounts in the Active Directory, you supply the same information that you did when you created user accounts using the User Manager for Domains in previous Windows versions, as well as a great deal of other information. Chapter 37 details the information you can store about a user, for instance. The Active Directory contains objects that can be used to store information about everything from user accounts to printers to the actual schema of the Active Directory itself.

However, the Active Directory can be used to store almost any kind of information you want. It’s just a matter of finding the correct object (or creating a new object class) and then entering the data for instances of the object.

From the discussion of X.500 names earlier in this chapter, remember the term “organizational unit (OU),” as it is represented in the X.500 naming scheme. An organizational unit is an object in the directory that holds or contains other objects. For example, in the Active Directory, a domain is a container object. It holds other objects, some of which are container objects also, such as the Users object. The Users object holds the actual individual user accounts. It is in these instances of the User object that the attributes will be found that contain the data for each user in the domain.

Attributes are simply the fine-grained details of the data stored in an object. Each attribute for an object holds a specific kind of data, and thus has a specific syntax associated with it. An attribute that is used to hold a person’s name would have a syntax that requires a text string. The syntax would define a minimum and maximum length for the string. An attribute that represents a numeric value would have a syntax that specifies the minimum and maximum value of the number that can be stored in the object.

When a new class of objects is defined, you have the capability to create two particular types of attributes: required or optional. If an attribute is of the required type, each object you create of the particular object class must have some value defined for the required attribute. However, there can be other attributes you might want to define for the User object class that do not apply to all users. For example, you might want to keep a list of the names of the user’s spouse and children. However, not all users will necessarily have a spouse or offspring, so this kind of attribute could be created as an optional attribute.

Standard Objects in the Active Directory

The Active Directory comes with two sets of standard objects: container and leaf. Container objects hold other objects in the directory. Leaf objects are the endpoints in a directory tree that contain specific attributes about a directory object entry. In other words, the leaf objects contain the actual data (attributes) that the Active Directory stores, whereas container objects group these leaf objects, such as individual users or printers, into meaningful groups.

Note that a container object also can contain other container objects, as well as leaf objects. This makes it possible to create subdivisions in the directory that model your business or administrative needs. Using the uniform Microsoft Management Console (MMC) interface, container objects appear as folders in a tree.

What Objects Are Included in the Active Directory?

These are the standard container objects you are most likely to encounter during day-to-day system management chores:

Namespaces

Country

Locality

Organization

Organizational Unit

Domain

Computer

And these are the standard leaf objects that are provided:

User

Group

Alias

Service

Print Queue

Print Device

Print Job

File Service

File Share

Session

Resource

These built-in object classes provide most of the functionality a network will need when using the Active Directory to manage users, computers, and resources. This is not a complete listing, however, of all the objects you’ll find in the Active Directory. There are many, many more. And if you need the capability to store still other types of objects, you can modify the schema by using the Active Directory Schema Manager Snap-In.

The Directory Namespace

Two types of names can be used to identify an object in the directory. The first is called the distinguished name (DN) and the second is the relative distinguished name (RDN). The relative distinguished name is just a value of a particular attribute of the object. For example, for user objects, the RDN is the common name (CN) of the object. So for the user object that holds account information for user Luke Kurtis, the RDN for the object would be Luke Kurtis. In the Active Directory there can be more than one Luke Kurtis, so there needs to be a method for telling them apart. The distinguished name is that method.

A distinguished name consists of the RDN of the object, plus all the RDNs of every object that precedes it in the directory. Referring to the X.500 address format, it quickly becomes apparent that the DN of an object not only uniquely identifies the object in the directory, but also reveals its location in the hierarchy.

The example given earlier showing how X.500 defines an object name shows the structure of a distinguished name:

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

Here the RDN of the user object is the common name Ono. But the object Ono is located in the container object named Studio One, which is located in the container object called New York, which is located in the container object called mydomain, and so on. Although there can be more than one Ono object in the directory, there can be only one object with the RDN of Ono that is located in the Studio One department in New York for this domain in the United States. If another Ono comes to work in that department, she will have to use a different name! There is an easier way around this, of course. When assigning usernames to employees, many companies already use a combination of letters rather than an employee’s full name. For example, John Doe might be assigned a username of doej, using the last name plus the first letter of the first name. If another John Doe is hired, a variation on this can be performed by assigning the new employee the username doej2.

However, another distinct Ono might work in the manufacturing department in the same organization. For example,

CN=Ono,OU=Manufacturing,OU=New York,O=mydomain,C=US

is a perfectly legal distinguished name and can reside in the same directory database as the first Ono.

What Is a Domain Tree? What Is a Forest?

The Active Directory gives you one single enterprise-wide namespace. This namespace is used for user accounts, resource objects, application configuration information, and so on. What you decide to store in the directory, beyond the default objects set up by the installation process, is up to you. The namespace can be global, provided you organize your domains into a domain tree.

A domain tree is nothing more than a method of organizing the domains in your enterprise into a structure so that they all share a common directory schema and a contiguous namespace. Although a domain tree is a structure formed by a collection of domains, a forest is a collection of domain trees. The namespace in the forest does not have to be contiguous, as it does in the tree, so a forest can be used to link disparate domain trees in the organization so that trust relationships still can be used to allow a single user logon in the network.

To understand what a domain tree or a forest is, you must know what it is replacing in the Windows NT networking scheme.

Domain Models—May They Rest in Peace

In Windows NT, the domain was used to group users and resources with a common security policy to simplify administrative tasks. In large organizations, a single domain was not sufficient to hold all the users and resources, and was not an efficient method of administering user rights and privileges or resource protections. Because of this, multiple domains were created and linked in what is termed a trust relationship. This trust relationship allowed users from one domain to be granted access rights to resources in another trusting domain.

A trust relationship in earlier versions of Windows NT could be a one-way or a two-way relationship. In a one-way trust relationship, one domain would trust the users that had been authenticated by another domain. The administrator in the trusting domain could grant users (or groups of users) from the trusted domain access rights in the local trusting domain. In a two-way trust relationship, the relationship existed in both directions. The trust relationship is not transitive. That is, if domain A has a trust relationship that allows its users to be assigned rights in domain B, and if domain B has a trust relationship that allows its users to be assigned rights to resources in domain C, a user in domain A cannot be granted rights in domain C by use of these trust relationships. That would require that domain A establish a separate trust relationship with domain C.

The way domains were organized into user or resource domains, and how the trust relationships were set up, led to the development of several domain models that could be used, depending on the size of your enterprise and the methods used to administer them. These were the single domain, multiple domain, master domain, and multiple-master domain models.

Because the domain essentially was the boundary for the security accounts manager (SAM) database, you had two basic choices. You could put all your user accounts into a single master domain, and then grant them access rights to objects in resource domains, or you could put users into separate domains, depending on your organization, and maintain a complicated set of trust relationships and administrative policies.

The headache associated with managing multiple trust relationships—and moving users to and fro when reorganizations occurred—is one of the major drawbacks of the SAM-based domain models.

Partitioning the Active Directory into Domains

When you install Windows Server and create a new domain, you are given several choices that decide how the domain will fit into an Active Directory tree. You can create a new forest or become part of an existing forest and create a new tree, making this new domain the first domain in the new tree. Or you can make the new domain a child domain in a domain tree that already exists in the forest.

Each domain in the domain tree is a security boundary in the Active Directory, just as it is in previous versions of Windows NT. However, you no longer have to create one- or two-way trust relationships between domains for users to be granted access rights and privileges in other domains that are in the same domain tree.

When a Windows domain joins a domain tree, a two-way transitive trust relationship, based on the Kerberos security authentication method, is automatically established between the child domain and its parent domain in the tree. Because the trust relationship is transitive (two-way), there is no need to manually configure additional trust relationships with other domains that exist in the domain tree. This means that after your domain is created and joined to a domain tree, your users can be granted access rights to resources in any other domain in the tree without the need to further create a complicated set of trust relationships with other domains.

Each domain in the tree holds the portion of the Active Directory database that represents the objects found in that domain. However, the namespace is contiguous throughout the tree. Each domain controller in the domain holds a complete replica of the directory for that domain. And, to help reduce network traffic and administrative overhead, you can create additional replicas of the domain’s portion of the directory and place it close to users in other domains that frequently access the resources in your domain. You only need to create an additional domain controller. This may seem similar to the primary domain controller/backup domain controller mechanism that Windows NT 4.0 uses. However, you no longer have to promote a backup domain controller (a BDC) to become a primary domain controller should the PDC fail. Instead, any peer domain controller can handle all authentication requests, and other Active Directory requests, within a domain, without operator intervention.

A Domain Is Still a Domain

The domain in Windows Server is still a security boundary, just like it was in Windows NT. Domain administrators can still take command and exert their authority over all users and resources in the domain. From that perspective, nothing has changed.

However, the management of your relationships with other domains is now much easier. The twoway transitive trust relationships are set up automatically, so you don’t have to coordinate managing this with other administrators throughout the network. If you upgrade from a previous version of Windows NT, all your groups and users are migrated into the Active Directory under your same domain. You can manage them as you always have, although there are new tools (using the MMC interface) that are used instead.

For more information about how to manage users (and computers) in the Active Directory, see Chapter 37.

Active Directory Trees and Forests

As discussed earlier in this section, a domain tree is a collection of domains that have a contiguous namespace, whereas trees in a forest can have a noncontiguous namespace. Contiguous namespace means that the object in each child domain in the tree has the name of its parent domains prefixed to its distinguished name. This also means that the names used to identify each child domain will have the names of the parents prefixed. Figure 30.1 shows an example of a domain tree. The domain tree starts at the top and flows down the tree, rather than from the bottom up.

Figure 30.1. A domain tree is a contiguous namespace.

In this domain tree, the most senior parent in the tree is the acme.com domain. Beneath that are three child domains, nj.acme.com, ny.acme.com, and tx.acme.com. Under the New York child domain, you can see a sales domain (sales.ny.acme.com) and another domain called export.ny.acme.com. This tree could be further expanded by adding additional child domains to any of the domains in the tree. The way you construct the fully qualified domain name for a domain positions it in the tree structure.

In the best of all possible worlds, each enterprise would have exactly one domain tree and one large contiguous namespace. However, in this rapid-paced business world, nothing remains the same for long, including business organizational units. Corporate mergers and acquisitions, for example, can bring in large numbers of users and resources that must be incorporated quickly into the network structure. In this situation, it might not be possible to easily include the acquired assets into the naming structure.

However, you can still join two disparate domain trees. You can’t put them into the same tree because the naming for all objects would not be contiguous. You can, however, join domain trees into a structure called a forest.

A forest is like a domain tree, but the namespace does not have to be contiguous throughout the forest. The directory schema is still common for all domains, and you can establish trust relationships between the trees. Users can still use a single logon to access resources in domains that reside in different domain trees (see Figure 30.2).

Figure 30.2. Domain trees with disjointed namespaces can exist in a forest.

The Active Directory and Dynamic DNS

DNS, or the Domain Name System, is the most widely used network address/name translation service in the world, and is used on the Internet. This service was created many years ago when the first DARPA network, the predecessor of today’s Internet, experienced rapid growing pains and needed a distributed naming service that could be used to locate the address of any server in the network.

You can read more about the Domain Name System (DNS) in Chapter 29, “Network Name Resolution.”

The Internet has grown so large in the past years that, without a distributed naming service, it would be almost impossible to keep track of all nodes in the network, much less the services they offer. DNS has evolved to contain many types of records that can be used to translate names to addresses. These include not only names of servers or workstations on the Net, but also services, such as the World Wide Web and email.

Dynamic DNS

Administering a large number of computers in a network can be quite a chore. Moving a computer from one network subnet to another used to require that the administrator manually reconfigure the DNS servers in the enterprise so that he or she could accurately translate the computer’s name to its correct address. With the advent of mobile computing and the proliferation of laptops that are here today, gone tomorrow, reconfiguring network addresses can become a full-time job on a large network.

The Dynamic Host Configuration Protocol (DHCP) solves part of this problem by allowing a computer to request a network address, along with other configuration information, when it boots into the network. However, this doesn’t completely solve the problems that arise as the result of mobile computing. After the client computer has obtained network address and configuration information, how does it communicate that information to other computers so that they can locate it on the network?

You can read more about DHCP in Chapter 28, “BOOTP and Dynamic Host Configuration Protocol (DHCP).”

In early versions of Windows NT, the Windows Internet Naming Service (WINS) was the answer to this problem. After a computer boots, it can contact a WINS server, which acts very much like a dynamic DNS server. It accepts registrations from clients and stores or updates their information so that other computers can query the database to find the client’s network address.

In Windows Server, you still can use the WINS service, which might be helpful for legacy Windows clients if you have a mixed network of Windows 2000 and earlier Windows NT computers. However, Windows 2000 Server and Windows Server 2003 come with an updated version of Microsoft’s DNS, which includes the capability to dynamically update the DNS database. In fact, DNS is the method that clients in all Windows Server networks use to locate domain controllers.

How the Active Directory Uses DNS

The Active Directory uses DNS to keep track of domain controllers. DNS is used as a locator service as well as a name/address translation service. Remember that the Active Directory provides a service to its users through the LDAP protocol. Services can be recorded in DNS through Service Resource Records (SRV RRs), and this is how the Active Directory uses DNS.

An SRV RR record consists of data in this format:

service name.protocol.domain

Because the Active Directory uses LDAP, a resource record for this service would look like this:

LDAP.TCP.twoinc.com

Because the DNS that is provided with Windows is a dynamic DNS, there is no associated administrative work when you add domain controllers to your network. Each domain controller automatically contacts a DNS server and provides it with the necessary information to register its name, its address, and the services it offers. Each domain controller also checks back at frequent intervals to be sure that the information is accurate and will make changes to the DNS information as changes are made on the server.

One thing to note about the use of DNS as a locator service is that you do not have to use Microsoft’s own DNS server to have an Active Directory–enabled network. The DNS product you use, however, must support SRV records, because this is how domain controllers advertise themselves to the network. The DNS server you use does not have to use dynamic DNS functions, however. This just makes the DNS administrator’s life a lot easier in a rapidly changing environment.

Using Sites to Manage Large Enterprises

In Windows 2000/2003 a site is nothing more than a collection of well-connected computers that exist on an IP subnet, and that usually are located close to each other geographically. The grouping of computers into sites is done to make replication fast and efficient. It is not a concept that relates to managing or administering users, resources, or network security. The following are two important things to remember about a site, as used by Windows:

A domain can have computers in more than one site.

A site can contain computers from more than one domain.

Windows Server uses only domain controllers to hold the Active Directory database. There is no longer a primary domain controller that controls writing or modifying directory information and backup domain controllers that provide a read-only service to users and computers. In Windows, all domain controllers can receive updates to the database, and the changes then are replicated to all other domain controllers that participate in the directory tree.

The Knowledge Consistency Checker service is run on every domain controller, and it is this service that establishes connections with other domain controllers within the site to be sure that directory replication can occur. Although the administrator can configure connections manually, the consistency checker will automatically establish new connections when it determines that there is a hole in the replication topology within a site.

The administrative tool that is used to control how servers participate in directory replication is the Active Directory Sites and Services Manager. This MMC snap-in allows you to

Add new sites and subnets and associate a site name with a subnet

Show all the sites that exist throughout the enterprise

Show all the servers that are contained in each site

Create and display the links between servers and the links between sites, including the protocols that are used for replication

Show the timing values used to schedule replication

Manage subnets

Directory Replication

LDAP v3.0 is the current LDAP Internet standard. For the Windows implementation of directory services, Microsoft uses a proprietary method called multimaster replication, because there is not yet a standard method for replication between LDAP directory servers. However, RFC 3384 is an informational RFC that does specify requirements for replication of LDAP information. Time will tell whether an Internet standard is developed, and whether Microsoft adopts it.

In Windows NT, primary domain controllers (PDCs) were responsible for updates to the directory database (the old SAM). Additions or modifications to the database were made on the PDC and at regular intervals replicated to backup domain controllers throughout the network. The most obvious disadvantage this system has is that without a PDC, no changes can be made to the database. When a PDC becomes unavailable, because of its own failure or possible network link failure, users still can log on because they can be authenticated by a BDC. However, if you have a large enterprise, perhaps a global one, it is almost necessary to have a PDC at every geographical site where frequent changes occur, or to have an extremely good network infrastructure.

Using the Active Directory, any domain controller can receive updates or additions to the Active Directory database. These changes are propagated to other domain controllers based on update sequence numbers (USNs). The USN is a 64-bit number used by the Active Directory to determine which updates are the most recent. In addition to the server’s USN, each property (or attribute) in the database has its own property version number. These two numbers are used by multimaster replication to ensure that updates are correctly applied throughout the enterprise.

Because all replicas of the directory database can be written to, it is possible that a change can be made before a previous change has been fully replicated throughout the enterprise. Some directory databases use timestamps to determine which update is the most recent. This method requires that every server be tightly synchronized with all other servers with respect to the correct time. Windows 2000 does provide a time service that can be used to synchronize servers, but with one exception: The timestamp is not the method used to determine which is the correct update to apply to a directory update message.

Each server in a network has its own USN, which it advances when it makes an update to the directory. Each server also stores a table of USNs—the highest USN it has received during previous replications from each server in the network. When replication starts, a server requests from other servers only those changes that have a higher USN than the one it has stored for each server during previous replication sessions. This minimizes the amount of information that needs to be exchanged between servers during the replication procedure. Because each server knows exactly which changes it has received from every other server in the network, replication between servers is efficient.

This method also allows a server to recover quickly when it crashes or some other failure, such as a network failure, occurs. All it must do is request updates that are greater than the USN it has stored for the other servers in the network. This means that a full replication between servers is not necessary in the event of a catastrophe.

Property version numbers come into play when a specific attribute is modified on more than one replica of the database within a short period, before the replication service can update the change on all nodes. Remember that with the Active Directory’s distributed nature, each domain controller holds a writable copy of the directory database. A property version number is incremented only on the server on which the change is actually made. It is not incremented on a server that is receiving it as an update.

The only time a timestamp is used during multimaster replication is when a collision occurs. This happens when a server receives an update message from another server, and although the property version numbers are the same, the contents of the attribute are not. In this case, and only in this case, the timestamp on the update is used. If the update message has a timestamp later than the value stored with the property, the update is applied to the data; otherwise, it is discarded.

Summarizing the Directory Data Using the Global Catalog

The Active Directory is scalable to millions of objects. The directory is partitioned into domains, because it would be very difficult to store a complete copy of the entire directory database on a single server. Of course, with the advances being made in CPU speed and storage capabilities, this might be possible in the future, but for now it is not practical.

One of the assumptions behind the partitioning of the directory is the fact that most queries that are made to the directory are for local information. Users generally want to locate a printer or another resource that is near them. Occasionally, it might be desirable to locate a printer that resides in a different geographical location, but for the most part, queries are for local resources.

To satisfy a query for information that cannot be found in the local portion of the Active Directory, it is necessary to query every other partition of the directory until the information is found. This too can be an impractical method. In a large enterprise, moderate use of this type of query, whereby the entire database is searched, could cause significant network and CPU resource consumption.

The global catalog is the answer that Microsoft has implemented to solve this problem. The global catalog is a subset of the entire directory. It holds entries for every object that exists in all partitions of the directory, but it contains only selected attributes for each object. If your query cannot be satisfied by querying the global catalog, the query will have to be resolved by searching a portion of, or possibly the entire, directory database.

Active Directory Service Interfaces (ADSI)

To make it easy to directory-enable any application, Microsoft has provided Active Directory Service Interfaces (ADSI). ADSI is a collection of several interfaces that can be used to access the Active Directory from within executable application programs. Programmers might want to use ADSI instead of the LDAP C API because ADSI makes it possible to write an application that can access directory services from multiple providers. If the directory service provider has designed its directory service product to be compliant with at least version 2.0 of LDAP, ADSI should be capable of providing an interface into the directory. The current version of ADSI is 2.5, and it is included with Windows 2000/2003.

In addition to providing access to Microsoft directory products, such as Exchange Server 5.5, ADSI has been tested by Microsoft against the following:

Netscape Directory Server 1.0

University of Michigan’s SLAPD Server

Novell’s LDAP-enabled NDS product

ADSI provides an interface that allows all the functionality of the LDAP C API, but does so in a manner that is easier to understand and write code for. Another reason for using ADSI in application development is that ADSI can be used by many higher-level programming languages, including Microsoft Visual BASIC, Perl, Rexx, and C or C++.

ADSI uses the Component Object Model (COM) interface to allow programmers to access and manipulate the underlying directory objects found in multiple directory services. A program written using ADSI should function correctly with any directory service for which ADSI has a provider interface.

Directory-Aware Application Programming

ADSI is one of the features of Microsoft’s development of Active Directory Services that might benefit large enterprises the greatest. If the Active Directory were limited to specific types of objects or attributes that could be stored in the directory, and if only programs supplied by Microsoft were able to access and manipulate the directory store, there wouldn’t be much to say about Active Directory beyond its being a major improvement in the administration of Windows servers and clients.

However, if it’s properly employed, using ADSI to incorporate application program configuration information into the directory database along with other types of data can produce real cost benefits in a large network. For example:

Many applications use similar configuration information that is duplicated in each application’s specific configuration data file (or, possibly Registry entries). Information about computers and locales can be stored in the directory, along with other configuration information, and shared by many applications.

Shared information that already is stored in the directory can be shared by ADSI-aware applications. User information already is stored in user objects in the Active Directory. By extending this object and adding attributes, you can create a customized user object that can be used by applications unique to your environment. Eliminating redundant resources of information also can help ensure a greater accuracy in your database because data must be updated only once in a single location.

Applications that depend on central configuration databases found on servers in the network can benefit from reduced downtime. If a server that contains configuration data files goes offline, clients must wait for the server to return to working order. If the clients use the Active Directory, replicas of the directory can be configured so that the loss of a server no longer is a point of failure.

Applications can “publish” themselves in the Active Directory, listing the services that they can give to clients and the information needed to use the service. In a volatile network in which users move frequently, reconfiguring applications can be simplified by having the application programmed to locate the information it needs for the new locale.

Many types of applications can benefit from using the Active Directory. Human resource departments and security departments can share a common user database resource by storing information in the directory. System management products can be written to access the information already contained in directory user and computer objects.

Now It’s Just Domain Controllers and Member Servers

When you create a domain controller for a Windows server, you are no longer required to do so during the installation of the operating system, which was the case with Windows NT. And to make things even easier, you no longer must create primary and backup domain controllers. In Windows Server, no distinction is made as to primary or backup domain controllers. Instead, each domain controller in a domain (and there can be as many as you need) holds a complete copy of the domain’s partition of the Active Directory. Updates can be made at any domain controller, and updates are propagated using multimaster replication to all other domain controllers in the domain.

Remember that in the Active Directory domain, names are expressed as DNS-style names. That is, instead of naming a domain acme, for example, it is now named acme.com, which is a DNS-style name. When you create a tree of domains in the Active Directory, you must use a hierarchical DNS naming scheme so that you maintain a contiguous namespace.

Each domain in the tree is a subdomain of the topmost domain. The domain tree provides a two-way transitive trust relationship between all domains that exist in the tree. Inheritance of security rights flows downward from the top of the tree, so you can assign users administrative access rights and permissions at a single point in the tree, and therefore grant them the same rights for child objects farther down the tree.

When you have a network that is composed of disparate namespaces, you can create separate trees and group them into a forest. Recall that a forest is a collection of domain trees. In this type of organization, each domain tree represents a contiguous namespace, but other disjointed namespaces are in the network. A domain forest is used in a similar manner to a domain tree, in that users can still be granted access rights in domains that are contained in other domain trees. The main difference between a domain tree and a forest is the disjointed namespaces.

The Active Directory Schema

The schema in the Active Directory is stored in the directory. The schema comes preconfigured with the types of objects that you need in order to set up a Windows server and manage a network of computers. However, the Active Directory is flexible and extensible in that you can modify the existing objects to use new attributes, or you can create new object classes that contain almost any kind of information.

In addition to the typical objects that you will use to manage the directory and user and network resources, the directory contains hundreds of other objects that are used for many of the applications that interact with it.

The directory should not be thought of as simply a glorified user database. You can create objects that are used by application programs. Sharing information between different applications can become much easier if the same configuration database is being used. Rather than having a conversion utility of some sort to transfer information between different applications, they now can be written, using the application programming interfaces provided for the Active Directory, to store that information in the directory database.

Modifying the Active Directory Schema

You can add objects or attributes to store data in the directory that is shared by different applications so that you do not need duplicate databases scattered around that get out of sync with constant updating. Extending the schema to include additional employee information, such as vacation schedules, sick time, and pay rates, can allow payroll applications to share the same data with other employee management software. The accounting and legal departments always can be sure they are working with the same set of data if there are no duplicate databases being used that can become unsynchronized because of an application failure or a simple user error.

The MMC snap-in that you use to examine or modify the schema is called the Active Directory Schema Snap-In. Unlike other MMC snap-in tools, such as the Active Directory Computers and Users Management Snap-Ins, this one is not found under the Administrative Tools option in the Start menu, by default. The reasoning behind that is simple: Tools that are used to add or modify user or computer accounts probably will be used frequently by the network administrator. Making changes to the schema probably will be performed only on rare occasions, such as when a new object or attribute is needed by the development of a new directory-aware application.

In just about every book or article you read about modifying the Windows Registry, you are cautioned that making changes can be a dangerous thing. One little mistake in a Registry edit can render a server unbootable. You should take editing the Active Directory Schema just as seriously. First, look through the directory to see whether an object class already exists that you can use before you begin creating new object classes (or attributes for that matter) on-the-fly.

Installing Administration Tools

After you’ve installed Windows 2000 Server (or Advanced Server), or versions of Windows Server 2003, you can install, using the same source CD, the Windows Administration Tools. To install these additional tools, you must be logged in to the server as an administrator.

When you are ready to install the additional tools from the Windows Server 2003 CD, follow these steps:

1. Insert the Windows Server 2003 source CD into your computer’s CD-ROM drive. When the autorun Microsoft Windows Server 2004 CD window appears onscreen, click Perform Additional Tasks and then Browse This CD.

2. In the next window, you will see a list of folders that exist on the CD. Double-click the I386 folder.

3. In the I386 folder, double-click Adminpak.msi. The Windows 2003 Administration Tools Setup Wizard appears. Click Next.

4. The wizard copies the required files to your hard drive, and then displays an informational window telling you that the tools were successfully installed. Click Finish.

After you’ve installed the additional tools, you can run the Microsoft Management Console and add the Active Directory Schema Snap-In.

Adding the Active Directory Schema Snap-In to the MMC

Adding snap-ins to the MMC is simple. For Windows 2000 Server and Windows Server 2003, simply click Start, Run, and then enter mmc /a in the Open: field. Note that there is a space after mmc before the /a switch. Click OK.

When the MMC Console screen appears (shown in Figure 30.3), with only the Console Root in the left pane, use the following steps:

Figure 30.3. You’ll need to add a snap-in to the empty MMC.

1. Click once on the File menu at the top of the MMC. From the menu that appears, select Add/Remove Snap-In. The Add/Remove Snap-In dialog box appears.

2. Click the Add button in this dialog box and the Add Standalone Snap-In dialog box (see Figure 30.4) appears, listing all the types of snap-ins available for your use.

Figure 30.4. Select the Active Directory Schema Snap-In to add to the console.

3. Select Active Directory Schema and click the Add button.

4. The Add/Remove Snap-In dialog box reappears, but now you’ll see that the Active Directory Schema Snap-In appears in the dialog box. Click the Close button. When the MMC reappears, you’ll see that the Active Directory Schema Snap-In is now available under the Console Root, ready for you to use (see Figure 30.5).

Figure 30.5. The MMC console now has the Active Directory Snap-In installed and ready to use.

You can now start using the snap-in. However, if you think you might want to use it again soon, click on File and then Save. This saves the console as a tool in the Administrative Tools folder so that you won’t have to go through all this trouble again. Note that the default filename is Console1.msc. It would probably be more helpful to choose a name such as Modify Schema.msc so that you will recognize this new MMC snap-in utility in the future.

Before You Use the Active Directory Schema Master

Before you begin to use the Active Directory Schema Snap-In, you should be aware of two important concepts. First, remember that a domain tree exists in a forest. The forest can contain a single domain tree, which is a single contiguous namespace, or it can contain multiple domain trees. Throughout a forest, however, a single domain controller is in charge of making changes to the schema that is shared by the forest. This domain controller is known as the Schema master domain controller. You can connect to this domain controller to make changes to the schema, or you can enable any domain controller to be the schema master.

Second, each object in the schema is uniquely identified by an object identifier, which is nothing more than a dotted-decimal number issued by some naming authority. Each attribute in the directory also is uniquely identified by an identifier. If you are operating in an environment where you will only use the Active Directory for internal network use and will never need to interact with any other LDAP/X.500 directory, you can more or less create your own object identifiers. However, consider what happens if your business acquires another business and you both use directory-based networking systems. To import or export information from one directory to another, or simply to join a domain tree from another business you’ve acquired, all your object IDs must be unique, and you should obtain them from a responsible source.

In the United States, the registration authority for this is the American National Standards Institute (ANSI). Other countries have an equivalent registration authority. The national registration authority issues the root object IDs for an enterprise. To obtain unique object IDs from Microsoft, refer to http://msdn.microsoft.com/library/en-us/netdir/ad/obtaining_an_object_identifier_from_microsoft.asp?frame=true.

Using the Active Directory Schema Snap-In

Using the Active Directory Schema Snap-In is not complicated. Being sure that you know how objects and attributes are related to each other—and the organization of your domain tree and the forest in which it resides—can, however, be quite complicated. You’ll probably remember that in the movie The Wizard of Oz, there’s a sign on the Yellow Brick Road that says “I’d go back if I were you.” Don’t proceed unless you fully understand the changes you are about to make. Because the schema applies to the entire forest—that is, to every domain tree and every domain in every domain tree—you can potentially not only render a single computer nonfunctional, but make the entire network unusable if you are not sure about the changes you are going to make.

When you are ready to make modifications to the schema, you must be logged in using an account that is a member of the Schema Admins group.

For more information about how to place a user account into a group, see Chapter 37.

To begin, right-click Active Directory Schema in the MMC console that you created. From the menu that appears, click The Schema May Be Modified on This Domain Controller. This makes this domain controller the schema master.

Double-click on Active Directory Schema in the left pane of the MMC and you’ll see that the schema has two folders under it: Classes and Attributes (see Figure 30.6).

Figure 30.6. You can expand the tree structure to show the classes that currently exist in the Active Directory.

If you double-click on Classes, the tree structure will expand to show you the classes that already exist in the Active Directory (also shown in Figure 30.6). Many of these have unfamiliar names and should be an indication to you of how complex the Active Directory really is and why you should educate yourself thoroughly before making any changes to it.

Likewise, if you double-click on the Attributes folder, you’ll get a display of all the attributes available in the Active Directory (see Figure 30.7). In this figure, you can see that the attribute named accountExpires, which can be used, for example, in a user account object, has a syntax of Large Integer. Other attributes have different syntaxes, as shown in this figure.

Figure 30.7. The list of attributes that make up objects can be displayed using this snap-in.

You can view the details about a particular object or attribute by double-clicking on it or by right-clicking and selecting Properties from the pop-up menu. For example, Figure 30.8 shows the Properties sheet for the OrganizationalPerson object class. This is the object type that is used to store user accounts in the Active Directory. Notice that there are no mandatory attributes for this object, but there are a large number of optional attributes.

Figure 30.8. The Properties sheet shows the attributes for this object.

In Figure 30.8, you can see that for each object you can have attributes that are either optional or mandatory. All objects in the directory of a particular class must each have values for all the attributes required by the object class. The optional attributes can be used if you need them.

In the case of the OrganizationalPerson class, there are no required attributes. This is not the case with all classes, however. For example, in Figure 30.9, you can see that the PrintQueue class has five mandatory attributes that will be created for any object you create using this class. Additionally, there are various optional attributes you can also add to an object you create using this class. Keep in mind that classes and their attributes are merely templates. When you create an object in the Active Directory, you choose what class to use, and an object is created. The class that the object is derived from is not changed.

Figure 30.9. The PrintQueue object contains both mandatory and additional attributes.

In Figure 30.7, you saw a partial list of the attributes that are defined in the directory. You can use the scrollbar to scroll through the entire list to locate attributes. When you modify or create a new object in the schema, you can select from these attributes or create a new attribute. To create a new attribute, right-click on the Attributes folder in the left pane of the MMC and select New and then Attribute. A warning will pop up letting you know that adding an attribute is permanent, and you will not be able to delete it later. However, you will be able to “disable” the attribute if you no longer want to use it. Each attribute has a particular syntax associated with it, which defines the type of data that the attribute can hold. Figure 30.10 shows the dialog box associated with creating a new attribute with the syntax field expanded. As you can probably determine from this, modifying the schema requires that you fully understand what you are doing.

Figure 30.10. It’s easy to add new attributes using the Schema Manager.

You can add a new Schema object class almost as easily as you can modify an existing class. To add a new class, right-click the Classes folder in the left pane of the MMC Active Directory Schema Snap-In, right-click on Classes, and select New and then Class. After a similar warning message appears, click Continue. The Create New Schema Class dialog box appears (see Figure 30.11).

Figure 30.11. You can create a new object class in the Active Directory using this dialog box.

As you can see, you’ll have to supply a common name (CN), an LDAP display name, and a unique object ID for the class. If you want to create a class that is similar to an existing class, you can use the Parent Class field under the Inheritance and Type section of the dialog box to specify the class from which your new class will inherit a set of attributes that have already been defined. You can use the Class Type drop-down menu to specify the type of class you are creating.

The next dialog box allows you to enter the mandatory (required) and optional attributes for the class you are creating. When you’ve finished selecting these attributes, click the Finish button.

Finding Objects in the Active Directory

If you’ve gotten this far into this chapter without falling asleep, it’s time to put your knowledge to work. That is to say, it’s time to get practical and look at a few things you can accomplish using the Active Directory.

When viewing the property pages for a user account in the directory, you see that you can add much more information than was possible before. There are eight tabs on the properties page for a user object.

If you select each tab and look at the different fields, you can see that the user object now contains a wealth of information that can be quickly accessed by searching the directory, including the following:

Who Is This User?—The user’s full name, the user’s logon name, and a description of the user. The user’s title, department, company, manager, and reporting information.

Address—The office in which the user can be found, the user’s address.

Telephone—Phone numbers, fax numbers, pagers, mobile phone, IP phone, email addresses, and home page URLs.

Logon—Which servers the user can log on to, during which hours, password information, and expiration and account information. The user’s profile, logon path, and home directory.

Dial-In—Whether this user can log on using remote access, and from where. Callback options and addressing information.

Groups—User groups to which this user belongs.

The main benefit of having this information available in the directory might not become apparent at first. Most of this information could have been found in the old User Manager utility, in the Remote Access Administration utility, or in the human resources department. But now it all can be centrally located in a global, searchable directory. With the proper rights and permissions, the administrator or user can search the directory for any of the attributes associated with users. And because the Active Directory schema can be extended, you can add additional attributes that contain information specific to your business.

Finding a User Account

For example, instead of being limited to queries such as “Show me everything about user John Doe,” you now can execute queries such as “Show me all users that work in the accounting department in Florida” or “Show me all users who work in the accounting department in Florida that are in the Administrators group and have dial-in access.”

If you look at the total number of attributes associated with the user object, it’s quite large. For example, suppose you want to “find” a user in the Active Directory. It’s a simple thing to do by using the Active Directory Users and Computers MMC Snap-In in the Administrative Tools Folder. For example:

1. Click Start, Administrative Tools, and then click Active Directory Users and Computers.

2. In the left pane of the MMC console, highlight the domain you want to search and select Find. In Figure 30.12, you can see the Find Users, Contacts, and Groups dialog box that is used to search the directory for these sorts of objects.

Figure 30.12. You can easily search the entire directory for a user or user group using this dialog box.

3. To find a user, simply enter the name or a description. If you want to narrow the search, use the In field. Here, you can select to perform the search throughout the entire directory, or a specific container object, such as a domain. Then, simply click the Find Now button.

If that all seems too simple, it is. This simple search function on the User, Contacts, and Groups tab enables you to perform a search by specifying just a little information.

Even though we’ve invoked the “find” dialog box in the Active Directory Users and Computers tool, you still can search for other objects in the directory. After we finish going over how to search for a user object, we’ll use a similar dialog box, for example, to search for a printer. As you can see, other objects you can search for include the following:

Users, contacts, and groups

Computers

Printers

Shared folders

Organizational units

Custom search

The next field (named In) is also a drop-down menu, which enables you to further specify the container object, such as a domain, that you want to search. If you already know in what domain a user account exists, narrowing the search using this field will save time. Finally, when you’ve entered a user’s name, and/or a description, and narrowed the search to the container object in which you want to look, click the Find Now button.

However, to show you the power of the search capability in the Active Directory, let’s use the Advanced tab. In Figure 30.13, you can see the same dialog box, with the Advanced tab selected. Here, the Field drop-down menu enables you to refine your search criteria to a user, a group, or a contact.

Figure 30.13. The Field menu enables you to search for a user, group, or contact using the Advanced tab.

Notice in Figure 30.13, however, that when you click on User in the Field menu, a whole range of attributes is displayed that you can use to specify the search criteria. The number of attributes is so large that it won’t fit on my computer screen, so there’s a down arrow at the bottom that can be used to select even more attributes. There are actually more than 60 attributes you can use to specify search criteria, from the simple username, telephone number (and mobile telephone number), to the Web page address for a user or the manager of the user. Of course, the search will succeed only if you actually use these fields when you create user accounts. You don’t have to fill in every attribute when you create a new user. However, the more information you store in the directory about a user, the easier it’s going to be to locate that user when you have only a little information to go on.

After you specify an attribute, you can enter a value that will be used for the search in the Value field. Use the Condition field to specify how this value will be evaluated in the search. These are the conditions you can set for this attribute’s value in the search:

Starts with

Ends with

Is (exactly)

Is not

Present

Not present

As you add search criteria (an attribute, a selection condition, and a value to use for comparison in the search), they appear in the pane at the bottom of the dialog box.

After you have specified values for the attributes to be used for the advanced search, click the Find Now button. Next the dialog box expands to add another pane, which displays the results of the search.

One or more entries can show up in the results pane, depending on the search conditions you used. To view the detailed attributes for objects in the results pane, simply double-click an entry and a property sheet appears for the object.

Finding a Printer in the Active Directory

The directory doesn’t just contain information about users; it holds information about many resource types in the network. An object that represents a printer resource might contain the name of the printer, the type of hardware associated with it, and its location. With directory services you do not even have to know the name of a printer. You can execute a query such as “Show me all printers located on the third floor of the accounting department in the Florida office,” and then pick the printer you want to use, based on the information returned from the query.

For example, in a Windows Server 2003 network that has the Active Directory enabled, you’ll find that there’s a button (Find) on the Print dialog box that wasn’t there in previous versions of Windows NT. This button first appeared in Windows 2000.

When you click Find Printer, a dialog box similar to the one used to search for users pops up. This should be an indication to you that the Active Directory is tightly integrated into the Windows 2000 Server and Server 2003 operating systems.

At the top of this dialog box, use the In drop-down menu to narrow your search. For example, you can use the default to search the entire directory, or you can use this menu to specify a particular domain or other container object.

There are three tabs on the Find Printers dialog box that you can use for a search:

Printers—If you know the name, location, or model of the printer you want to find, you can specify it on this tab and click Find Now.

Features—This tab enables you to specify attributes the printer must have, such as whether it can print double-sided (duplex printing) or whether it is a color printer. You also can select the resolution, the printer speed, and whether the printer can staple the document after it’s printed, among other features, depending on the capabilities of the particular printer.

Advanced—This tab works in the same way that the Find Users dialog box worked. You can use the Field drop-down menu to specify any of the attributes associated with the Printer object, and then specify a condition and a value to be used for the search.

After you’ve specified the search criteria using any of these tabs, click the Find Now button and you’ll get a listing of the printers that match your search. You then can select which printer to use.

After you’ve found the printer you want to use, it’s a simple matter to make a connection to the printer. In the search Results pane, just right-click on the printer and select Connect. Or, if you’re in a real hurry, just double-click on the printer in the Results pane.

The Active Directory is accessible from within many other applications in Windows 2000. You can search for file shares and objects that you create yourself. The important thing to remember about the Active Directory is that, after you begin to use it in your network, it is not something to be taken lightly. Use caution when making modifications to the directory.

Using Start/Search

In the previous examples, we searched for users by using an Administrative Tool—the Active Directory Users and Computers Snap-In. To search for a printer, we used the Find Printer button on the print dialog box. However, there is a simpler way to find almost anything in the directory, provided that your logon account has the necessary access permissions to locate the object. Simply click Start and then Search.

The Search function in Windows 2000 Server and Professional is found from the Windows Start menu and allows you to

Search for files or folders

Search the Internet

Search for printers

Search using Microsoft Outlook

Search for people

If you use the For Printers or the For People options in the menu, you’ll get dialog boxes similar to the ones used in the examples earlier in this chapter.

Thus, the Active Directory is not just a tool that can be used by administrative personnel to administer the network, but it also is something that can be used by everyday users to locate objects or information they need to perform their jobs.

The Active Directory Service and Windows Server 2003

The previous sections of this chapter enabled you to understand how the Active Directory works with Windows Server 2003 (and in a similar manner, to the AD that comes with Windows 2000 Server). Now that you understand the principles behind the Active Directory, you can choose whether to install it. This section examines the features unique to the Windows Server 2003 version of Active Directory and depicts an example of how to install it.

New Active Directory Features in Windows Server 2003

The examples in this chapter were based on the Active Directory installed on a Windows 2003 computer. With the release of Windows Server 2003, there are some new features that will make administration of the directory a simpler task. Some of these include the following:

The Active Directory Migration Tool (ADMT) now copies passwords for user accounts when upgrading from Windows NT 4.0 (with Service Pack 2) and Windows 2000 Servers.

You can now rename domains (except for the root domain in a tree) in the Active Directory.

Although you can’t delete system classes or attributes, you can now deactivate classes or attributes.

The Microsoft Group Policy Management Console (GPMC) makes it easier to manage group policies by giving you a single MMC tool that includes capabilities that were previously contained in several other tools.

You can create queries to the database and save them for use later.

The MMC interface lets you select multiple objects at the same time to make editing objects an easier task.

A user account can exist in one forest, with the computer account created in another forest. The user needs only to log on once to gain access, preserving the single sign-on. This is called Cross-Forest Authentication.

Cross-Forest Authentication enables the administrator to select users and groups from a trusted forest and place them into a local group.

If you have a domain controller located at a branch office, and the data link to the main office becomes unavailable, cached data at the remote office can be used to authenticate users and access resources until the link is restored.

You can learn more about these new features at www.microsoft.com, by searching for Windows Server 2003. The preceding list contains only a few of the additions to the Active Directory, and a brief description of what they do. If you operate an enterprise-wide network, these new features can be of great importance when managing multiple domains, trees, sites, and forests.

For a smaller network, in which a single forest is used, these tools may prove useful, but the standard MMC tools should be sufficient.

Installing Active Directory on a Windows Server 2003 Computer

Okay, it’s time to illustrate how the AD installation process works under Windows Server 2003. The example here is based on the Enterprise edition, but the process is similar for all other Windows Server 2003 variants (except for the web edition). To install the Active Directory on Windows Server 2003, follow these steps:

1. In Figure 30.14 you can see the first window that the Configure Your Server Wizard pops up after the installation is finished and you have logged on using the Administrator account.

Figure 30.14. In Windows Server 2003 you can select one or more roles that the computer will be used for in the network.

2. When you click on the Add or Remove a Role button, the next window lists preliminary steps you should perform before continuing to select a role (see Figure 30.15). For example, if you will use a modem or another peripheral device, they should be installed. Because this computer will host the Active Directory, and provide AD services to clients on a network, you need to be sure that you have one or more network cards installed.

Figure 30.15. These steps should be performed before you select a role for your Windows Server 2003 computer.

At this point you will need to have a connection to the Internet and have the Windows 2003 CD available—or know the network path that holds the Windows 2003 setup files. This is necessary because some roles, such as the Domain Name System (DNS) or the Active Directory will require copying additional files to your computer.

3. When you click the Next button, the wizard makes sure that you are connected to a local network or the Internet. If this is the case, the next window the wizard displays is the one shown in Figure 30.16.

Figure 30.16. This wizard page enables you to install the Active Directory.

The Active Directory must be installed on a Domain Controller. In both Windows 2000 Server and Windows Server 2003, all domain controllers within a domain are equals, more or less. The distinction between Primary Domain Controllers (PDCs) and Backup Domain Controllers (BDCs) has been removed. There are still some details about which domain controller in a domain controls the global catalog, for example, but these are outside the scope of this chapter.

4. After you select Domain Controller (Active Directory) from the selections displayed in Figure 30.16, click the Next button and the next wizard window will show you a summary of what you have selected. Click Next to continue.

5. The Welcome to the Active Directory Installation Wizard appears. Click Next and the wizard displays information such as earlier versions of Windows (Windows 95 and Windows NT 4.0 with service pack 3 or earlier). Those earlier computers will not be able to log on to the Windows Server 2003 version of the Active Directory. Click Next to continue.

6. In Figure 30.17 the next dialog box presented by the wizard is shown. Here you need to make a selection based on your current AD setup. You can choose to create a domain controller for a new domain, or install the AD on a domain controller in a domain that already has the Active Directory installed on another computer. For purposes of this example, a new domain controller will be used.

Figure 30.17. Select to install a new domain controller for a new domain, or to install the Active Directory in a domain that already has the Active Directory installed on another server.

7. Likewise, the next wizard dialog box asks whether this will be a new domain in a new forest. A forest is simply a collection of domain trees that can interact with each other. In Figure 30.18 you can see that it is also possible to create a child domain within an existing domain. For example, you can create a domain called art.by.ono under the domain by.ono.

Figure 30.18. You can create a new domain in a new forest, a child domain, or a domain tree in an existing forest.

8. The third selection in Figure 30.18 enables you to create another domain in an existing forest of AD trees. If you are setting up your first domain and your first instance of the Active Directory, select the first radio button and click Next. Otherwise, you will have already done this and should be cognizant of what the other two choices mean!

9. The next wizard (see Figure 30.19) dialog box asks you to enter the fully qualified domain name for the domain (that is, include the .com, .net, or other qualifier). After entering the domain name, click the Next button.

Figure 30.19. Here you should enter the fully qualified domain name.

10. The next wizard screen enables you to enter a NetBIOS name that can be used by older Windows operating systems to access the directory. It is suggested that you use something similar to the domain name you entered in Figure 30.19. For example, the domain in Figure 30.19 was zira.com. The suggested NetBIOS name is ZIRA. You can change this NetBIOS name or take the default. Click Next to continue.

11. Next the wizard asks you where the database files for the Active Directory should be stored (see Figure 30.20). It is suggested that you put these files on a disk other than the one that holds the operating system. This increases performance, because both the operating system and the Active Directory, in a larger network, will probably be accessed frequently. By placing the files on a separate disk, you can improve performance.

Figure 30.20. Specify the location that will be used on your server to store the Active Directory data files.

If you don’t want to use the default disk drive or directories that the wizard suggests, use the Browse buttons for both the Database folder and the Log folder to change them to a location more suitable for your system.

12. The next wizard dialog box asks you to specify a location for the SYSVOL directory. This directory (or folder) contains public information that is replicated to all domain controllers in the domain. This is the situation when you create more than one domain controller, which is a good idea for the fault tolerance it provides. Again, you can take the default or use the Browse button to select a location that best fits your environment. Click Next after making your choice.

13. The Domain Name System server had not been installed on this computer, and Windows Server 2003 cannot find a domain controller that can resolve the name you have chosen for your domain. It is at this point that you can choose to create a DNS server on the same computer used by the Active Directory. If you want, you can fix the problem—is the DNS server for your network offline for some reason? Or you can choose to configure a DNS server after the Active Directory installation. For the purposes of this example, the default action (create the DNS server on the same server) is used.

14. You must now select what kind of permissions you will use on the server. If you are operating a mixed-mode network, which contains Windows operating systems that were marketed before Windows 2000, then select the first radio button (Permissions Compatible with pre-Windows 2000 Server Operating Systems).

Note also that this radio button should be used if your Windows Server 2003 system participates in a mixed-mode network that also has domain controllers prior to Windows 2000. For example, if you still have a mixed-mode Windows 2000 network that contains Windows NT 4.0 networks, select this option.

The second radio button on this Wizard dialog box lets you enable permissions to the Active Directory for just Windows Server clients. If you’ve upgraded your network to these servers (and in the case of Windows 2000, the Professional Edition), then make this selection. This will provide a more secure network than one using earlier clients or servers.

15. Finally, the wizard asks you to enter a password that can be used if you find a need to restart the server in Directory Services Restore Mode. This is not the same password used for the Administrator account on the computer. It is used only when you need to restore the Active Directory in case of a problem.

16. The Summary dialog box enables you to view the selections you have made before proceeding to create the Active Directory. Read these carefully to ensure that you are about to install the AD using selections compatible with your network. You can make changes using the Back button. When you are satisfied with your selections, click the Next button. An information dialog box will let you know that the Active Directory is being configured on your server. It will take a few minutes if you are installing on a high-end server, or longer if you are using a server based on the minimum requirements for Windows Server 2003.

17. The last Wizard dialog box lets you know that the Active Directory installation has finished. Click the Finish button. You will then have to restart the server to continue. When the system reboots, you can view the log file of what has been changed. See the location for this log file described earlier in this chapter.

If you chose to install the DNS server on the same server as the Active Directory, you will see a Manage the DNS Server selection on the Manage Your Server window that appears after the reboot. For instructions on how to manage a DNS server, see Chapter 28. Because DHCP is used to provide IP addressing configuration information to clients on your network, it is important that you understand the implications of setting the scope of IP addresses that the DHCP server can allocate. Inside a private intranet (or on a SOHO cable/DSL router), be sure to assign addresses for this scope that do not interfere with another DHCP range of addresses, such as those provided by your ISP. If you already have a range of IP addresses that are valid on the Internet, you should probably still use a private address range within your intranet to add a bit of security to your network.

The Manage Your Server window reappears after you have completed the installation of the Windows 2003 Active Directory.

You can continue to add roles to the server, such as the ability to Manage Users and Computers in Active Directory. However, the management functions listed here can also be found in the Administrative Tools folder. You can go ahead and choose to continue setting up your server using this window, or use the Administrative Tools later.

If you want, you can now create additional roles for this server, or you can use other servers to set up other roles. Your decision should depend on what role you choose, and the capacity of the servers you will use. In a small to moderate-sized network, you might be able to use a single server to perform the roles you select. However, in an Enterprise network, you should carefully plan to install many servers to use for separate roles in your network. Indeed, if you use multiple subnets, you will have to consider how network traffic affects your network, and probably use servers on each subnet that are set up to perform specific roles.