Chapter 11: Core Active Directory Services Administration

---

One of the more important areas of Windows networking has to do with Active Directory. Active Directory is an extensible and scalable directory service that provides a networkwide database for storing account and resource information. Using Active Directory, you have a consistent way to name, describe, locate, manage, and secure information for resources. This means that you can use Active Directory to work with user, group, and computer accounts as easily as you can use it to work with applications, files, printers, and other types of resources. You can use Active Directory to help you manage the network infrastructure, perform system administration, and control the user environment.

Active Directory is only available in Windows domains running Windows 2000 or later domain controllers. A domain controller is a server running a server version of the Windows operating system. One way to think of Active Directory is as an improvement to the domain-based architecture of Windows NT, in which the Security Accounts Manager (SAM) database is replaced by a more flexible, extensible, and scalable database. As with the SAM, Active Directory acts as the central authority for security; unlike the SAM, however, Active Directory also acts as the integration point for bringing together diverse systems. Active Directory consolidates management tasks into a single set of Windows-based management tools, and their counterparts are the directory service command-line tools discussed in this chapter.

Controlling Active Directory from the Command Line

A basic understanding of Active Directory and its structures is all that it is needed to take advantage of the many command-line tools that are available to manage Active Directory. Microsoft designed Active Directory to use Domain Name System (DNS) as a naming system. With DNS, you organize network resources using a hierarchical structure that matches how you manage the resources. This hierarchy of domains, or domain tree, is the backbone of the Active Directory environment and looks much like a directory structure used with files. Another name for such a hierarchy or tree is a namespace. Every organization that uses Active Directory domains has an Active Directory hierarchy or namespace.

Understanding Domains, Containers, and Objects

The first Active Directory domain that you create is the root of the tree and the parent of all domains below it. Domains below the root are called child domains. Suppose, for example, that the root domain is cpandl.com. You can then decide to break down your organization geographically or functionally into child domains. Grouping geographically, you might have seattle.cpandl.com, ny.cpandl.com, and la.cpandl.com child domains. Grouping functionally, you might have sales.cpandl.com, support.cpandl.com, and tech.cpandl.com child domains. The key here is that child domains must have a name that extends from the parent domain. If the name doesn’t extend from the parent domain, the domain is in a separate namespace. For example, microsoft.com, msn.com, and hotmail.com are all in different namespaces from cpandl.com.

You can create additional levels within the namespace if you choose. Under the la.cpandl.com child domain, you might have sales.la.cpandl.com, tech.la.cpandl.com, and support.la.cpandl.com. If this isn’t enough, you can add another level, and then another and another to the namespace. Keep in mind that Active Directory manages the relationships within the tree and creates the appropriate trust relationships between domains.

In Active Directory, trusts are automatically two-way and transitive. Simply creating a child domain, such as tech.la.cpandl.com, creates a two-way trust relationship between tech.la.cpandl.com and la.cpandl.com. The trust continues up and down the tree as well, meaning that because la.cpandl.com trusts cpandl.com, tech.la.cpandl.com has an automatic trust relationship with cpandl.com, as well as with all the other domains in the same namespace.

Active Directory uses objects to represent network resources, such as users, groups, and computers. It also uses specialized objects called containers to organize network resources according to geographic, business, or functional needs. Typically, containers are used to group objects that have similar attributes. For example, you might want to apply a specific set of permissions to all engineers, and putting these users together in the same container will make this easier.

Each container represents a grouping of objects and each individual resource is represented by a unique Active Directory object. The most common type of Active Directory container is an organizational unit, or OU. Objects placed in an OU can only come from the related domain. For example, OUs associated with tech.la.cpandl.com contain objects for this domain only. This means you can’t add objects from support.la.cpandl.com, la.cpandl.com, or tech.ny.cpandl.com to these containers.

Each Active Directory object class, such as container, user, group, or printer, is assigned a set of attributes that describes the individual resource. For example, user objects have attributes that describe user accounts including contact information along with their permissions and privileges. This means that user object attributes are related to first names, last names, display names, telephone numbers, e-mail addresses, passwords, and so on.

Because each object within Active Directory is really a record in a database, it is possible to expand the attribute set to meet the needs of individual organizations. This allows you to add custom attributes to help describe objects. For example, you can add an attribute to include an employee’s identification code.

Understanding Logical and Physical Structures in Active Directory

So far we’ve talked about Active Directory structures that are used to organize directory data logically, including domains, subdomains, and OUs. You use these structures to organize Active Directory according to business or functional needs. You can also use them to specify geographic breakdowns, such as occurs if you had ny.cpandl.com, la.cpandl.com, and seattle.cpandl.com domains.

Insofar as Active Directory is concerned however, domains, subdomains, and OUs have no mapping to the real world—even if you create geographic breakdowns for domains or OUs. They are simply locations within the directory where related data is stored and, as far as Active Directory is concerned, they could all have one physical location, which is how Active Directory sees things until you tell the directory about the physical structures associated with your logical breakdowns of domains, subdomains, and OUs.

In the real world, any of these logical structures could span more than one physical location. It doesn’t matter whether we are talking about different floors in a single building, different buildings entirely, or different cities; these are all different physical locations. To tell Active Directory about these multiple locations, you must define subnets and sites. A subnet is a network group with a specific IP address range and network mask. A site is a group of one or more subnets that maps your network’s physical structure. Because site mappings are independent from logical domain structures, there’s no necessary relationship between a network’s physical structure and its logical domain structure.

You can create multiple sites within a single domain and you can create a single site that serves multiple domains. For example, if you group subdomains geographically, you might have seattle.cpandl.com, ny.cpandl.com, and la.cpandl.com child domains and corresponding sites named Seattle-Site, NY- Site, and LA-Site. But if your organization has only one office and you group subdomains functionally, you might have sales.cpandl.com, support.cpandl.com, and tech.cpandl.com child domains and a single site called Main-Site.

Understanding Distinguished Names

Every object in Active Directory has an associated distinguished name, or DN. The DN uniquely identifies the object by its common name and its location within the namespace. An object’s common name is the plain-English name given to the object when you created it. You identify an object’s common name using CN=Name, where Name is the common name of the object, such as:

CN=William Stanek

The common name is also referred to as an object’s relative DN (RDN). What this refers to is the fact that this portion of the object’s full name relates to its location in Active Directory. An object’s location is determined by the names of the container objects and domains that contain the object. You identify OU containers using OU= and domain components using DC=. Each level within the domain tree is broken out as a separate domain component. Consider the following example:

OU=Engineering, DC=ny, DC=tech, DC=cpandl, DC=com

Here, you specify the DN for the Engineering OU in the ny.tech.cpandl.com domain. You use commas to separate each name component and the name components go from the lowest level of the tree to the highest level (that is, from the OU that contains the actual object you want to work with) to the child domain to the parent domain and finally to the root domain.

What makes the DN so important is that it specifies the exact location of an object; and the DN is what Active Directory uses to search for, retrieve, and manage objects within the database. Knowing the DN for an object allows you to perform these same tasks.

All objects have associated containers and domain components. Although the container for users, computers, groups, and other types of objects typically is an OU, this isn’t always the case, because Active Directory includes several default containers where objects can be stored. These default containers are identified by their common name using CN= and include

• Builtin A container for built-in security groups

• Computers The default container for member servers and workstations in a domain

• ForeignSecurityPrincipals A container for objects from a trusted external domain

• UsersThe default container for users

Note

The Domain Controllers container is created as an OU. This means you would use OU=Domain Controllers as the name identifier.

Knowing this, you can identify an object in any of these containers. For example, if you wanted to identify an object in the Users container for the tech.cpandl.com domain, you would use

CN=Users,DC=tech,DC=cpandl,DC=com

If the object is the user account for William Stanek, the complete DN would be

CN=William Stanek,CN=Users,DC=tech,DC=cpandl,DC=com

If the user account is later moved to the Engineering OU, its DN would become

CN=William Stanek,OU=Engineering,DC=tech,DC=cpandl,DC=com

Getting Started with the Active Directory Command-Line Tools

Once you know the basic structures of Active Directory and can identify the DN for the objects you want to use, you are ready to control Active Directory from the command line. You’ll find that the key advantage of doing so is in the additional flexibility you gain. You can in fact perform many tasks easily from the command line that are either much more difficult to perform in the graphical tools or simply cannot be performed. For example, you might search for all computer accounts that have been inactive for more than a week and then disable them. Or you might modify the properties of multiple user accounts at the same time using a single command.

When you are working with Windows domains, both Windows Server 2003 and Windows XP Professional include a set of command-line tools that you can use to manage Active Directory. These tools include

• DSADD Adds objects to Active Directory

• DSGET Displays properties of objects registered in Active Directory

• DSMOD Modifies properties of objects that already exist in Active Directory

• DSMOVE Moves a single object to a new location within a single domain or renames the object without moving it

• DSQUERY Finds objects in Active Directory using search criteria

• DSRM Removes objects from Active Directory

Each of the various command-line utilities is designed to work with a specific set of objects in Active Directory. Table 11-1 provides an overview of the utilities and the objects they are designed to work with.

Table 11-1: AD Command Line Utilities and the Objects They Work With

Object	Dsquery	Dsget	Dsadd	Dsmod
Computer	Yes	Yes	Yes	Yes
Contact	Yes	Yes	Yes	Yes
Group	Yes	Yes	Yes	Yes
Partition	Yes	Yes	No	Yes
Quota	Yes	Yes	Yes	Yes
Server	Yes	Yes	No	Yes
Site	Yes	Yes	No	No
Subnet	Yes	Yes	No	No
User	Yes	Yes	Yes	Yes
OU	Yes	Yes	Yes	Yes

In most cases, AD objects are manipulated with a set of parameters specific to the type of object you are working with and the subcommand name used to access these parameters is the same as the object name. For example, if you wanted to add a computer to the domain, you would use DSADD COMPUTER and its related parameters. If you wanted to add a user account to the domain, you would use DSADD USER and its related parameters.

Note

DSMOVE and DSRM aren’t listed in the table because they are designed to work with any object in the directory. You move or remove objects based on their DNs. In addition, using an asterisk (*) as the object name for DSQUERY, you can find any objects in the directory with criteria that match your query.

---