Active Directory Overview

For experts to properly implement an Active Directory infrastructure, they must have an understanding of the Active Directory design elements and, equally important, an understanding of the business for which the Active Directory infrastructure is being designed. The process of developing an Active Directory infrastructure involves an analysis of the business's current administrative and geographic model, goals it wants to achieve, as well as any future plans. With proper business analysis, an Active Directory infrastructure can meet the current requirements while easily allowing for future growth and expansion.

Active Directory is implemented as a service that allows network administrators to centrally organize and manage objects such as users, computers, printers, applications, and profiles. That means locating and managing network resources is now much simpler.

Objects that are stored in Active Directory are accessible to users throughout an organization. Users do not need to know the physical location of the objects because they are logically grouped into a central location. The specific structure of Active Directory can be customized to meet the needs of almost any business environment. The structure of Active Directory is hierarchical and consists of five main design elements:

• Forests

• Trees

• Domains

• Organizational units

• Sites

The Five Main Elements

Before diving into the analysis process of Active Directory design, you need to understand the various Active Directory elements outlined in the preceding list. The following sections provide an overview of the five main Active Directory elements.

Forests

The first design element that we'll discuss is the forest. A forest is the boundary of the scope of an Active Directory implementation. In its simplest form, a forest is a single domain. A forest can contain multiple domains, and each new domain created with its own unique namespace establishes a new tree within the forest (trees will be discussed later in the chapter).

The first domain created within the forest is the forest root. It's important to plan which domain will become the forest root domain for an organization. Careful planning can help avoid the possibility of having to completely reorganize the Active Directory structure in the future. However, Windows Server 2003 makes restructuring simpler because any domain, including the forest root domain, can now be renamed (this was not the case in Windows Server 2000).

Because the ability to rename the forest root domain is a new feature in Windows Server 2003, be prepared to encounter an exam question pertaining to this topic. You can use the Rendom.exe utility to rename a domain.

After the forest root domain has been configured, new domains can be added as child domains of the forest root or they can be established as new trees within the forest. When you are designing the forest structure, remember that simpler is usually better. It's possible to create multiple forests with Active Directory, but a single-forest environment is much easier to administer and maintain. However, it might be necessary for organizations to create more than one forest in order to meet their administrative needs.

Domains within a single forest share some common elements:

• Schema

• Configuration container

• Global catalog

• Enterprise Admins group

• Schema Admins group

Having common elements shared among domains within a single-forest environment makes the administration of multiple domains much simpler. Conversely, this could also be a reason why an organization would opt to create a multi-forest structure. The next two sections should clarify this statement.

Schema

The schema maintains a list of all objects that can be stored within Active Directory as well as the attributes associated with each object. The schema is made up of two main components:

• The class-schema object

• The attribute-schema object

An example of a class-schema object within an Active Directory would be the Users class. An attribute associated with this class may be the user's first name. Each attribute, such as the user's first name, has an attribute-schema object associated with it that defines items such as the syntax of the attribute. The default schema should meet the needs of most organizations, but components can also be added or modified within the schema if needed. For example, an organization might require that employee ID be a required field for all users. In a case such as this, the schema can be modified to include this attribute.

When planning a forest structure, the design team has to consider the schema policy. If the default schema policy does not meet the needs of the entire organization, it might be necessary to create multiple forests.

To make changes to the schema, you must be a member of the Schema Admins group.

Configuration Container

A forest also contains a single configuration container that is copied to all domain controllers in each domain. This container stores configuration information about the entire forest, such as which subnets have been combined into sites and the site links that connect them. This information can be used for tasks such as replication. The configuration container can be examined when determining links between sites and the best route for replication if multiple links exist. The existence of a forestwide configuration container means that configuration information does not have to be created for each domain, which makes the administration of multiple domains much easier.

Global Catalog Server

All domains within a forest also share a single global catalog server. The global catalog server stores certain attributes that pertain to each object within the forest. You can query the global catalog by using an attribute of an object to determine its location. This is beneficial for clients because they do not have to search for an object in different domains.

Think of a global catalog server as analogous to the Yellow Pages, which stores certain attributes for businesses in a city. You use the Yellow Pages when you want to quickly determine the location of a business or find its phone number. When searching for an object within the forest, you can query the global catalog server to determine the object's locations instead of performing an extensive search. This is a welcome change from Windows NT 4.0, where users who wanted to locate an object within the network had to perform a search of the entire domain and any trusted domains.

Default attributes are automatically included within the global catalog. An organization has the option to add attributes and customize the information stored in the global catalog server to meet its needs (see Figure 2.1). For example, adding the employee ID attribute to the global catalog enables you to search for users based on this attribute.

Figure 2.1. Adding an attribute to the global catalog.

During the logon process, the global catalog server is also used to determine universal group membership. If a global catalog is unavailable and the user has never logged on before, he will only be able to log on locally. However, Windows Server 2003 allows users to log on with cached credentials. If the functional level is Windows 2000 native or Windows Server 2003 and the user has previously logged on, he will be able to log on with cached credentials if the global catalog is unavailable. Administrators, on the other hand, can log on regardless of whether or not they've logged on in the past.

By default, the first domain controller within the forest is designated as the global catalog server. An organization can thereafter designate its domain controller of choice as the global catalog server (see Figure 2.2).

Figure 2.2. Designating a global catalog server.

Trusts

Windows Server 2003 makes the process of providing access to resources across multiple domains and forests much simpler. In previous versions of Windows NT, for users in one domain to access resources in another domain, at a minimum, a one-way trust had to be manually set up between the two domains.

With Active Directory, two-way transitive Kerberos trusts are automatically established between all domains in the same forest. This eliminates the need for trusts to be manually created between domains.

Trusts can be established in an organization that has a combination of Windows Server 2003 and Windows NT 4.0 domains, but they must be set up manually.

Trees

Within a forest, domains that share a contiguous namespace form a tree. After a tree has been established within a forest, any new domain added to an existing tree inherits a portion of its namespace from its parent domain.

A forest can also consist of multiple trees. For example, an organization that has more than one registered domain name can create multiple trees within a single forest so that the namespaces can be maintained.

Each time a new domain is created with Windows NT 4.0, an administrator must manually configure a trust with any other domains with which the new domain needs to share resources. If the environment consists of multiple domains configured in a multiple-master domain model, the administrator would have to establish several trusts. The trusts that are set up by the administrator are also not transitive, meaning that if A trusts B and B trusts C, A and C do not trust each other.

Conversely, in Active Directory, two-way transitive trusts are immediately set up between the new domain and its parent domain without the intervention of an administrator. This means that if A trusts B and B trusts C, A and C also trust each other. When a new tree is created, a two-way transitive trust is also established between the root domain of the new tree and the forest root.

Domains

The main components of the Active Directory hierarchy are domains and organizational units. Domains determine the administrative boundaries within the Active Directory hierarchy. Think of a domain as a container. All the objects within the container share the same administration, replication process, and security requirements. In some cases, the same security requirements can be applied to an entire business. If a business requires separate security policies, such as unique password policies, to meet its administrative structure, it might be necessary to create more than one domain. Objects would then inherit the security policy from the domain in which they are located.

Windows Server 2003 (and 2000) uses a multi-master replication model within a domain. Within a domain, all domain controllers are considered equal, meaning that they all contain a working copy of the directory and every domain controller can read and write changes to the directory. In previous versions of Windows NT, there was only one working copy of the directory database for the domain, and it was stored on the primary domain controller (PDC). The backup domain controllers (BDCs) maintained only copies, which they received from the PDC. If a PDC was taken offline, it was necessary to promote a BDC to take its place so that a working copy of the directory database was available. Within Active Directory, each domain controller can receive changes to the directory and then replicate the changes to other domain controllers in the domain.

Organizational Units

Another design element within Active Directory is the organizational unit. Organizational units are container objects that are used to organize objects within a domain. They are not based on the physical structure of the network. When you're planning organizational units within Active Directory, it's important to base them on the business's current administrative model. For example, a business might decide to create an organizational unit for each department (Accounting, Human Resources, and so on). Additional organizational units could then be created to organize the objects in each department.

By creating organizational units, administrators can delegate control of the objects to other users in the organization (referred to as delegation of authority). In this way, domain administrators don't have to remain responsible for every administrative aspect of their organization.

All domains within a forest maintain their own hierarchy of organizational units, which enables administrators in different domains to establish a hierarchy that best meets their needs. Likewise, if all domains within a forest require the same hierarchy of organizational units, they can be modeled on one another. For example, if a central IT team manages an entire corporation, this team can develop a structure of organizational units within Active Directory that could then be implemented by each domain in the forest.

Not only can organizational units be created to assign a user, group, and computer control over the objects contained within them, but they can also be used to group objects that require a similar group policy. By applying a group policy to an organizational unit, an administrator can limit the capabilities and restrict the environment of the objects contained within it. A group of users that requires a similar desktop environment can be grouped into an organizational unit, and a group policy can then be applied to that specific organizational unit.

Group policies are similar in concept to system policies in Windows NT 4.0. Group Policy is a directory-based management tool that can be used by administrators to define configurations for users and computers.

Sites

Sites are the last major design element within the Active Directory structure. A site is basically a collection of IP subnets that are connected by high-speed, reliable links with a lot of available bandwidth. Sites are created within the Active Directory infrastructure to optimize replication between domain controllers. A site topology is designed around the physical location of IP subnets within a domain and the type of link connecting them. As with the other design elements we've discussed, a careful analysis of the physical structure must be done to determine the number of sites needed.

When planning for sites, the first thing you must determine is where the domain controllers will be located. Clients usually prefer a quick response time; so, in most situations, at least one domain controller will be placed in each of the sites (there might be instances when it is determined that a site does not require a domain controller, such as when a site has a very small number of users). After the domain controllers have been placed, a careful examination of the type of links connecting them and how much network use each one will experience must be done. After connectivity and available bandwidth have been assessed, you can determine where site links will be established.

DNS and DNS Namespace Planning

Windows Server 2003 has adopted the DNS naming convention for naming an object within Active Directory. Each DNS name within the DNS database is derived from a root name, forming a hierarchical structure. A host's DNS name identifies its position within the hierarchy. This is the same naming structure that has now been implemented within Active Directory. The naming scheme is simple and logical for administrative purposes, but it's also descriptive of the object's location within the hierarchy. A domain within an Active Directory structure is identified by the name it has been assigned, and its domain name identifies its position within the Active Directory hierarchy. When you're choosing a DNS name for an organization, it is once again important to assess the organization's structure, needs, and future plans.

The DNS naming standards are now applicable to the objects stored within Active Directory to ensure that all names remain unique. By implementing this type of naming scheme, the names that users use on their intranet are also compatible and ready for use on the Internet. Users no longer need to remember two different names their logon name and their email name. For example, with Active Directory, a user can log on to the network with a name such as [e-mail], which could also be his email address.

The naming scheme implemented by Active Directory adheres to the same naming requirements as DNS names so that all names within a hierarchy remain unique. When assigning DNS names, keep the following points in mind:

• A child domain can have only one parent domain.

• If two children share the same parent domain, each must be assigned a unique name. In other words, to keep names among domains unique, each domain within a single tree requires a unique name.

Contiguous and Disjointed Namespaces

Within the Active Directory structure, there are basically two types of namespaces:

• Contiguous namespace

• Disjointed namespace

A contiguous namespace is one in which a child object inherits a portion of its namespace from its parent object. For example, assume that the Bayside Corporation uses the name Bayside.net. When a new domain is added to the forest for the San Francisco location as a child domain, the new domain inherits a portion of its namespace from its parent and becomes SF.Bayside.net (see Figure 2.3).

Figure 2.3. A contiguous DNS namespace.

A disjointed namespace is one in which a new parent domain has a namespace that is independent from the forest root domain. If the Bayside Corporation assumes ownership of the Riverside Corporation, Riverside can maintain its existing DNS name of Riverside.net if it's added as a new tree to the existing Bayside forest (see Figure 2.4). This is an example of a disjointed namespace because it is independent of the forest root domain, bayside.net.

Figure 2.4. A disjointed DNS namespace.

Here's an easy way to differentiate between the two types of namespaces within a forest: A contiguous namespace forms a tree structure, whereas a disjointed namespace establishes a new tree within the forest.

Now that you're familiar with some of the fundamental concepts of Active Directory, let's move on and take a look at the role of analysis on the design of an Active Directory infrastructure.