Active DirectoryConcepts

Active DirectoryConcepts

---

Active Directory is the central repository of information on a WS2003-based network. Active Directory stores information about where different resources are located on the network. These resources include user and group accounts, computers, printers, and shared folders. Active Directory can be used to locate these resources quickly so that administrators can create, delete, configure, and maintain them as needed, and ordinary users can access them if they have suitable permissions to do so. Active Directory gives administrators a great deal of flexibility in how their network resources should be administered. By managing resources from any location in the enterprise, you can centralize IT administration in a few users or a single location. On the other hand, Active Directory allows you to create structure using domains and OUs and then to delegate authority over these portions. This allows for decentralized administration in which certain administrative tasks are devolved to various trusted users throughout the enterprise. Active Directory is managed primarily through the GUI but can also be programmatically accessed through an API called the Active Directory Service Interface (ADSI). By writing scripts that use ADSI, administrators can automate most Active Directory administrative procedures, but this requires a good understanding of VBScript or JScript and is beyond the scope of this book.

Logical Structure of Active Directory

In its most abstract sense, Active Directory represents a company's network resources using a hierarchical structure of logical objects such as the following:

Forest

The most encompassing logical construct in Active Directory. A forest is a collection of domain trees linked together at their roots by transitive trusts.

Tree

Also called a domain tree, a hierarchical grouping of domains beginning with a root domain and branching out to child domains. Trees must form a contiguous DNS namespace, and a forest can consist of one or more trees joined at their roots by transitive trusts.

Domain

The primary administrative boundary for WS2003 networks. Domains are named using DNS, and a tree consists of one or more domains hierarchically joined by transitive trusts.

Organizational unit (OU)

Logical containers you can use to group objects in a domain for security and administration purposes. You can create hierarchical treelike structures of OUs to reflect your company's geographical, organizational, or administrative structure.

Object

A user, group, computer, printer, shared folder, or anything else that can be "contained" within a domain or OU. For example, a user object represents an employee within your company, a computer object represents a physical computer, and so on.

Trust

A secure communications channel between domains, domain trees, or forests. Trusts enable users in one domain to be authenticated by a domain controller in other domains and may be transitive, one-way, or cross-linked in nature.

For more information on these topics, see Domain , Domain Controller , Forest , OU , and Trusts . For more information on specific types of Active Directory objects, see Group s, Printing , Shared Folders , and Users .

Planning Active Directory

A big part of planning for an Active Directory deployment involves planning the logical structure that best meets your company's administrative and security needs. Figure 4-1 illustrates the logical structure of an Active Directory with domains represented by black dots, trees by shaded areas, and trusts by lines joining domains. The entire diagram represents the forest. In addition, domains may also contain organizational units. An OU is a logical container that can be created to enclose other Active Directory objects, such as users, computers, groups, printers, or even other OUs.

The typical approach to creating the logical structure for Active Directory is to create your domains and trees in a way that mirrors the geographical or administrative structure of your company. For example, you might create separate domain trees for your American and European offices with the root domain of each tree representing headquarters and child domains representing branch offices. Then you would create OUs within your domains to establish a more granular level of logical structure. For example, you could create separate OUs for your management, sales, human resources, and customer support departments. Then within your sales OU you could create additional OUs for different product groups. The key idea in planning the logical structure of Active Directory is that the domains and upper-level OUs you create should be relatively stable and unchanging in order to simplify administration through delegation and use of Group Policy.

The most important thing to remember when planning your Active Directory structure is to keep it simpleif you can get by using only one domain, then do so. On the other hand, there are sometimes advantages to having multiple domains (or even multiple trees) in your forest, the main one being that by partitioning Active Directory into multiple domains you have better control over replication traffic, an issue of particular importance in a company spanning several locations connected by slow wide area network (WAN) links. Planning an Active Directory implementation is a complex subject, however, and is beyond the scope of this book; for a good book on this subject, see Active Directory (O'Reilly).

Figure 4-1. Typical logical structure of Active Directory

DNS and Active Directory

Since Active Directory domains are named using DNS, planning Active Directory also involves planning the DNS names of the domains within your forest. The most important choice is your root DNS name, the name of the first domain of your forest (called the forest root domain). You should generally select a root DNS name that reflects the largest scope of your entire organization, taking into account all of its branch offices, subsidiaries, partners , and even planned acquisitions and mergers. For more information on implementing a DNS WS2003 namespace for Active Directory, see Planning DNS under DNSConcepts later in this chapter.

In Windows 2000 (W2K) it was important to plan your DNS naming scheme and domain structure carefully since you couldn't rename domains after you created them in Active Directory. W2K did allow you to restructure your forest by creating new domains and using the MoveTree utility from Support Tools to move objects from old to new domains, but this was not a trivial procedure. WS2003 takes things a little further and now allows you to rename your domains, including your forest root domain, and to restructure your forest more easily by repositioning domains within a tree or forest. To accomplish these tasks, Microsoft provides a Domain Rename tool that is available on its web site (use search.microsoft.com and search for "domain rename tool" to find the current URL for downloading it ^[1] ). Note that this tool works only if all your domain controllers are running WS2003 and can't be used to change which domain is the root domain of your forest, to add or delete domains from your forest, or to change the name of a domain to the same name that another domain gave up in a previous restructuring. The main thing to remember is that the procedures involved are still complex and aren't intended for everyday administration; they should be used only for an exceptional event such as your company being acquired through a merger or changing its business identity.

^[1] At this writing it is http://www.microsoft.com/windowsserver2003/downloads/domainrename.mspx.

Delegation and Group Policy

While a simple deployment of one domain could be managed by a single administrator, enterprises that have many domains and OUs can take advantage of two powerful features of WS2003 that simplify administering and securing Active Directory: delegation and Group Policy. Delegation lets an administrator assign limited administrative rights over domains and OUs to trusted users in order to distribute the burden of managing Active Directory. Group Policy allows policy-based management of user and computer objects within Active Directory. See Delegation and Group Policy later in this chapter for more information.

New to WS2003 is the ability for administrators to set quotas limiting the number of objects that can be created in Active Directory by a user who has been delegated limited administrative authority. This new feature can be managed only from the command line; see dsadd , dsget , dsmod , dsmove , and dsquery in Chapter 5 for more information.

Schema

One final aspect of Active Directory's logical structure is the schema, which defines the classes of objects the directory may contain and the attributes these objects may have. Active Directory comes with a default schema that may be suitable for most companies, but the schema is also extensible for companies that need to create new object types and attributes. Modifying the schema is beyond the scope of this book.

Topological Structure of Active Directory

Besides logically representing your company's network resources, Active Directory can also topologically represent your company's IP internetwork. Large computer networks based on IP generally have a mesh-like structure in which smaller networks called subnets are joined together with routers into a single large internetwork. These subnets may be located at different geographical locations, in which case WAN links are used to connect locations. To ensure that Active Directory performs optimally over slower WAN connections, a topological structure can be created within Active Directory to reflect the WAN connections of your internetwork. The main elements of such a topology are sites. A site is a grouping of subnets that have high-speed (local area networkLAN) connections throughout. Sites are joined to other sites using site links (the logical counterpart in Active Directory to physical WAN links). Sites are important because domain controllers replicate portions of Active Directory with one another, and using sites allows replication traffic to be controlled so that it doesn't swamp the available bandwidth of slow WAN links. See Site later in this chapter for more information on these topics.

Physical Structure of Active Directory

From a physical perspective, Active Directory resides on special servers called domain controllers , which authenticate users and enable them to locate and access resources across the forest. To ensure scalability, Active Directory is partitioned into naming contexts (NCs), which are contiguous subtrees of directory objects and units of replication. Each domain controller has a replica of three directory partitions:

Schema NC

Contains the classSchema and attributeSchema objects, which define the kinds of objects that can exist in the forest. Every domain controller in the forest contains a full replica of the same schema NC.

Configuration NC

Contains objects that define the replication topology and other forestwide information. Every domain controller in the forest contains a full replica of the same configuration NC.

Domain NC

Contains objects like users and computers that belong to the local domain. Every domain controller in a domain contains a full replica of the domain NC for that domain, but domain controllers in one domain don't contain replicas of domain NCs for other domains.

Synchronization between domain controllers in a domain is maintained using multimaster replication, a process in which all domain controllers within a domain are peers and contain writable copies of the Active Directory partition for the domain (this is different from NT, in which only one domain controller, the PDC, contained a writable copy of the domain database). To speed queries across multiple domains in a forest, a subset of commonly used Active Directory objects called the global catalog is maintained by each domain.

Directories and Files

The Active Directory database and log files are located by default in the directory %SystemRoot%\NTDS and must be located on an NTFS partition. The main directory database file, or datastore, is NTDS.dit ; it uses the Extensible Storage Engine (ESE) database engine in Microsoft's Exchange Server. The database can grow to a maximum size of 16 terabytes and can contain more than 10 million objects, which means Active Directory can support even the largest enterprise networks. The database defragments and repairs itself automatically, but it can also be taken offline and manually defragmented using the ntdsutil utility to reclaim unused space in the directory database. For better performance, Active Directory log files can be placed on a separate physical disk (these log files record transactions written to the datastore and can be used to help restore a system if the datastore volume is lost). A typical configuration might be:

• WS2003 operating system installed on a mirrored volume

• Datastore located on a RAID-5 volume with at least 4 GB to accommodate future datastore growth

• Log files located on a mirrored volume

Make sure you back up Active Directory regularly. You can do this using the WS2003 Backup utility, which allows Active Directory and other system state information to be backed up while running. See Backup later in this chapter for more.

SYSVOL

Installing Active Directory creates and shares the directory %SystemRoot%\sysvol\sysvol with the share name SYSVOL. The SYSVOL share contains NETLOGON shares, Group Policies, logon scripts, and other important files that are replicated by the File Replication Service (FRS) to all domain controllers in the domain. Other than placing your logon scripts into the correct subdirectory of SYSVOL, you shouldn't fool around with any of the files stored there.