DomainConcepts | Windows Server 2003 in a Nutshell

DomainConcepts

A domain is a container in Active Directory that defines a logical boundary for objects that share common requirements for security, replication, and administration.

Security: A domain is a security boundary within which objects (users, groups, computers, printers, and so on) can be managed. For example, all users in a domain can log on to the domain using their usernames and passwords. Domains also have their own security policy, called a domain security policy, that defines account policies such as password and account lockout settings. See Group Policy later in this chapter for more information on domain security policies.
Replication: A new domain is created when you install the first domain controller for the domain. Domains are also units of replication, for all domain controllers in a domain automatically replicate their Active Directory updates to one another. See Domain Controller later in this chapter for more information.
Administration: Domains share common administration, and members of the Domain Admins group have broad rights and permissions for performing administrative tasks on objects in the domain. These administrators can also delegate aspects of domain administration to other trusted users using the Delegation of Control Wizard. Administrators can add further structure to a domain by creating a hierarchy of OUs within the domain. Administrators can delegate authority over OUs to trusted users to allow them to perform specific administrative tasks on the objects within the OUs. See Delegation and OU in this chapter for more information.

Domains can exist by themselves , or they can be grouped into multidomain hierarchical structures called trees. A tree consists of a root domain and one or more child domains joined by trusts to the root or to each other in hierarchical fashion. Elements of a tree share a common namespace. A forest consists of one or more trees joined at the roots by trusts. All domains in a tree or forest implicitly trust each other using two-way transitive trusts, allowing users to log on to a client computer anywhere in the enterprise and access shared resources on any server. For more information, see Forest and Trusts later in this chapter.

Domains aren't the same as sites. Domains are logical groupings of users, computers, and other Active Directory objects, while sites are physical divisions between networks connected by slow WAN links. One domain can span several sites, and one site can contain several domains. For more information, see Site later in this chapter.

Domains are named using DNSfor example, mtit.com or sales.mtit.com . The forest root domain is the first domain you create when you install Active Directory. When you promote your first domain controller, the forest root domain is created and is the root of both your first tree and the entire forest. Domains in a tree must form a contiguous namespace in Active Directory. For example, if the root domain of a tree is mtit.com , then vancouver.mtit.com and seattle.mtit.com would be two examples of child domains of mtit.com , while support.vancouver.mtit.com and sales.vancouver.mtit.com would be two more child domains whose parent domain is vancouver.mtit.com .

In W2K, domains could not be renamed actually, there was a hack in which you could create a new domain with the desired DNS name and then use the MoveTree utility from Support Tools to move all the objects from your old domain to the new one, but this was tedious and somewhat risky. In WS2003, however, you can rename domains, reposition domains within a tree, and create new trees using the Rendom utility. This operation is still tedious, but it's no longer risky and can be used to restructure your forest after mergers and other major changes to your company.

Domain Functional Level

In W2K, domains could run in one of two domain modes:

Mixed mode: Allowed downlevel domain controllers running NT to coexist with domain controllers running W2K by using NTLM authentication instead of Kerberos
Native mode: Supported only domain controllers running W2K by requiring Kerberos authentication

You could switch W2K domains from mixed mode to native mode but not the reverse.

In WS2003 things are a little more complicated, for domains can now run in one of four different domain functional levels:

Windows 2000 mixed (default for new domains): Supports domain controllers running WS2003, W2K, and NT.
Windows 2000 native: Supports domain controllers running WS2003 and W2K.
Windows Server 2003 interim: Supports domain controllers running WS2003 and NT. This is a special domain functional level that exists only when you upgrade an NT-based network directly to WS2003.
Windows Server 2003: Supports only domain controllers running WS2003.

By default, when you create a new domain, its domain functional level is Windows 2000 mixed, which gives it the greatest degree of interoperability with NT/2000 domain controllers. You can raise the domain functional level for your domain to Windows 2000 native if you have no more NT domain controllers or to WS2003 if you have no more W2K domain controllers, but you can't undo this operation afterward. Each time you raise the domain functional level, additional features that simplify the administration of your Windows-based network are supported; these are shown in Table 4-12.

Table 4-12. Features of different domain functional levels

Feature	Windows 2000 mixed	Windows 2000 native	Windows Server 2003
Universal groups	No	Yes	Yes
Group nesting	Partial nesting (global groups can belong to domain local groups)	Full nesting	Full nesting
NT domain controllers	Allowed	Prohibited	Prohibited
W2K domain controllers	Allowed	Allowed	Prohibited
Rename domain controllers	No	No	Yes
Rename domains	No	No	Yes

Different domains within a forest can be assigned different domain functional levels, depending on how far your network migration has gone. Another type of functional level, called forest functional level, affects all domains in your forest. For more information, see Forest later in this chapter.

Planning Domains

When you are planning an Active Directory implementation, start by assuming that a single domain will suffice, create OUs within your domain to add additional structure mirroring the organization of your company, and then delegate authority over OUs to suitable users. Plan for additional domains only if necessary to separate administrative functions more sharply between business subsidiaries, locations, or departments. For example, the following security features are domainwide in scope:

Password policy

Account lockout policy

Kerberos policy

EFS recovery policy

IPSec policy

Public key encryption policy

Certificate authorities

What this means is that if two departments in your company absolutely must have different password policies, then these departments must be different domains. Before you start creating additional domains, it might be time to consider harmonizing security policies across your company.

Here are some reasons to create multiple domains or trees in your forest:

Your company is large enough to consider using the complexity of a multidomain implementation of WS2003 Active Directory. There is no hard and fast rule for how big a company should be, though; this is based essentially on your available IT resources and expertise, as well as on the other factors described later.
Your company requires that IT administration be decentralized across multiple locations or divisions. Multiple domains are appropriate here because domains represent strong security boundaries for administration of users, groups, computers, and other resources. Domain Admins in one domain can't administer resources in other domains unless they are explicitly given permission to do so.
Your company requires distinct Group Policy security settings (such as password and account lockout settings) for different locations or divisions. This might even be for legal reasonsfor example, if some of your subsidiaries are in foreign countries with different legal security requirements.
Your WAN links are slow, and you want to keep replication traffic between different locations to a minimum and to control it more tightly. You could make each location both a separate domain in the tree and a separate site. This is because the only Active Directory information replicated between domains in a tree are the schema, the configuration information, and the global catalog. If you use a single domain with multiple sites instead, the site links between the sites require enough bandwidth to support the greater traffic that occurs during intradomain replication of Active Directory.

If you are migrating an existing NT-based enterprise to WS2003, the migration strategy you use depends on which of the four NT domain models your company currently employs:

Single-domain model: If you are currently using the single-domain model in your NT network, you simply upgrade the existing NT domain to create a root domain of a new WS2003 forest.
Single-master-domain model: This model consists of an account domain (the master domain) that is trusted by one or more resource domains (slave domains). You first upgrade the account domain to create the root domain of your new forest, then you upgrade the resource domains to become child domains of the root domain. This results in a single tree with one or more first-level child domains. An alternative is to upgrade your account domain to a root domain, create one top-level OU in the root domain for each existing resource domain, and then join the member servers and workstations to the OUs within the root domain, discarding the domain controllers in the resource domains. This leaves you with a single domain to manage.
Multiple-master-domain Model: This model consists of two or more account domains (master domains), which trust each other, and one or more resource domains (slave domains), each of which trusts every account domain. A recommended procedure is first to create a new WS2003 domain as the root domain of your forest. This domain is left empty except for administrators belonging to the Enterprise Admins group. Next, you migrate the account domains to become child domains of the empty root domain. Finally, you migrate the resource domains to each become a child domain of the most appropriate, former account domain. The result is a tree with three levels of domains. Alternatively, you can create OUs in the former account domains and join servers and workstations in the resource domains to these former account domains, placing them in the appropriate OUs. The result is a tree with only two levels instead of three (a process called flattening the domains), which is easier to manage.
Complete-trust model: This model consists of two or more NT domains that trust each other. The recommended procedure here is first to create an empty root domain in a new forest and then migrate every NT domain to become a child domain of the root domain. For example, if MTIT Enterprises has the DNS domain name mtit.com and consists of two relatively independent offices in Vancouver and Seattle, you could create the forest root domain mtit.com in one of the two locations and add a few high-level Administrator accounts to the Enterprise Admins group in this root domain. Do not create any OUs or any other Active Directory objects such as users, groups, computers, or printers in this domain. In other words, this root domain is empty except for a few enterprise-level Administrator accounts. Then create the domains vancouver.mtit.com and seattle.mtit.com as child domains of the root domain mtit.com . Let the members of the Domain Admins group in each of these two child domains create the users, groups, computers, printers, OUs, and other directory objects for their own domains.