Understanding Forests and Domains

A domain is a collection of computers and resources that share a common security database, in this case, the Active Directory database. Computers in the domain also have a common namespace. A namespace is the hierarchical grouping of service and object names that are stored in Active Directory and DNS. Active Directory and DNS namespaces have to be the same. This is a Microsoft requirement. A domain can also be considered a security boundary because you can create and manage related resources within a domain and then exercise administrative control and implement security. You define security policies such as account lockout policy and password policy on a domain basis. Administrative rights granted in one domain are therefore only valid within that particular domain. Active Directory domains contain a logical partition of users, groups, computers and other objects within the environment. All network objects exist in a domain. Each domain only stores information on the particular objects that it contains. A domain is actually the core logical structure in Active Directory. In addition to domains, there are other logical components in Active Directory. These are domain trees, organizational units (OUs), and forests. Components that are considered physical structures are domain controllers, and sites.

A domain tree or tree is formed by grouping one or multiple domains whereby each domain in the tree shares a contiguous namespace and a hierarchical naming structure. You typically form domain trees by creating and adding one or multiple child domains to a parent domain.

A forest on the other hand is the grouping of one or more domain trees. Trees in a forest have the naming structures of their associated domains. Domains in a forest are linked by two-way transitive trusts. Domains in a forest share a common global catalog and schema. When you install the first domain, it becomes the forest root domain. The root domain contains specific objects and services including the Schema Master role, Domain Naming Master role, and the Enterprise Admins and Schema Admins groups. Because of the importance of the root domain, you should implement fault tolerance and perform regular backups.

Forest and Domain Functional Levels

The functions performed in a domain are controlled by the domain functional level operating. The domain functional levels are summarized below. A few advanced Active Directory features are only available when the domain functional level is raised to the Windows Server 2003 functional level.

• Windows 2000 Mixed supports domain controllers running Windows NT 4.0, Windows 2000 and Windows Server 2003.

• Windows 2000 Native supports domain controllers running Windows 2000 and Windows Server 2003.

• Windows Server 2003 Interim supports domain controllers running Windows NT 4.0 and Windows Server 2003.

• Windows Server 2003 supports domain controllers running Windows Server 2003.

As is the case with domain functional levels, the Windows Server 2003 forest functional level makes a few additional Active Directory features available as well. Forest functions are also restricted by the forest functional level configured. The forest functional levels that can be set are summarized below:

• Windows 2000 supports domain controllers running Windows NT 4.0, Windows 2000 and Windows Server 2003.

• Windows Server 2003 Interim supports domain controllers running Windows NT 4.0 and Windows Server 2003.

• Windows Server 2003 supports domain controllers running Windows Server 2003.

New Forest-wide Features in Windows Server 2003 Active Directory

A few important forest-wide features introduced with Windows Server 2003 are listed below.

• If the forest functional level is raised to Windows Server 2003, you are able to rename a domain. You can change the DNS name and NetBIOS name of any parent, chil, domain tree root, or forest root domain.

• You can also restructure a forest by moving existing domains to different locations within the namespace. Restructuring basically involves the breaking up of existing trust relationships, and the re-establishment of the suitable trust relationships. Forest restructuring typically occurs when you want to change the internal namespace, perform a network infrastructure upgrade, or decommission a domain.

• You can also install a domain controller using a backup from an existing domain controller within the domain. The feature can also be used for Global Catalog servers.

• You can disable, rename, redefine, and reactivate an Active Directory schema class or attribute. Defunct is the terminology used to describe a class or attribute that remains disabled.

• The application directory partition or naming context is a new directory partition introduced with Active Directory in Windows Server 2003. Applications and services can now store application specific information in this partition. All Active Directory objects, other than security principals can store information in the application directory partition.

• Through linked value replication you can add or remove individual users from a large group during replication, to reduce the amount of network traffic generated by the replication process. Simply put, a large group no longer needs to be handled as one replication entity.

• The Active Directory data store has also been enhanced due to a new feature known as Single Instance Store (SIS). SIS prevents redundant information from being duplicated in the data store.

• With Windows Server 2003 Active Directory came the concept of multiple forest trust or federated forests. Federated forests allow cross-forest trusts to exist in your Active Directory environment. Forest trust is important for Kerberos authentication between forests to function.

• Universal Group caching is a new feature that results in minimizing bandwidth, better logon response times, and also eliminates the need for domain controllers to obtain Universal Group membership information from a Global Catalog for authentication operations. All this is possible because the Universal Group membership of a user is initially cached at log on, and all other log on functions use the information stored in the cache. The information in the cache is also refreshed.

• In Windows Server 2003 Active Directory, the Knowledge Consistency Checker (KCC) calculator has been improved to successfully handle replication between 5,000 sites. The figure in Windows 2000 was a mere 200 sites.

• Active Directory quotas allow you to control the number of objects that a particular user in a directory partition can own. The Active Directory quota feature is managed from the command-line using the dsadd, dsmod, dsquery and dsget command-line utilities.

New Domain-wide Features in Windows Server 2003 Active Directory

The more important domain-wide features introduced with Windows Server 2003 are listed below. While some of these features are regarded as basic Active Directory features, and are implemented immediately; others are only implemented when the domain functional level of your domain controllers are raised to the Windows Server 2003 functional level.

• Domain Controller rename: A new feature in Windows Server 2003 is the facility to rename domain controllers with no longer needing to first demote them. Before renaming multiple domain controllers, you first need to perform the following tasks:

  • If the domain controller that you want to rename is a Global Catalog server, you first have to move that particular role to another domain controller.

  • If the domain controller that you want to rename has an Operational Master role, you have to move that role as well.

  • If the domain controller you want to rename is the root domain controller, you have to first transfer all Global Catalog operations and Flexibl Single Master Operations (FSMO) roles to a different domain controller.

• You can use the new security group nesting feature to add a group to a different group for the purpose of consolidating group member accounts. Security group nesting assists in decreasing Active Directory replication traffic. Another feature is the distribution group nesting feature that allows you to also add a group to another group.

• You are also able to convert a Distribution Group to a Security Group. A distribution group is typically used with e-mail applications while a security group is used for access control.

• Another new feature is that Universal Groups can now include members from any domain in a forest. Through Universal Groups, you can consolidate groups. Universal Groups are also replicated to each Global Catalog in a forest, which basically means that you should perform management activities in a manner that minimizes the frequency of changes to the Global Catalog.

• Group scope conversions are also allowed but for only those domains running in Windows 2000 Native or Windows Server 2003 domain functional level:

  • You can change a Universal Group to a Domain Local Group

  • You can change a Universal Group to a Global Group only where the particular group includes no other Universal Group.

  • You can change a Global Group to a Universal Group only where the particular group is not a member of a different Global Group.

  • You can change a Domain Local Group to a Universal Group only where the particular group includes no another Domain Local Group as a group member.

Forest Design Factors

A few factors that you should include or consider when planning the design of the forest are discussed in the following section:

• The structure of the organization: Most large organizations usually consist of many smaller businesses or companies that have been acquired my business mergers. With these organizations, there is usually a need for some form of business independence within the organization. To cater for this need, there may be a requirement that certain business be separated from others. This separation is usually achieved by the implementation of forests.

• Identify operation requirements: Smaller companies within a larger organization might each need to store different data in the Active Directory data store. In cases where the objects that need to be stored in the Active Directory schema differ, you might need to create different forests to service this requirement.

• Legal factors: Legal factors also sometimes lead to the formation of forests. This typically occurs with organizations such as financial institutions where certain data has to be completely separated from other data.

• Cost factors: With the deployment of multiple forests comes the need for additional hardware, and increased administrative costs. Shared infrastructures are usually the most costs effective solution. However, this solution could possibly not meet the requirements of the organization.

• Namespace factors: It is extremely important to plan and manage namespaces if you plan to create multiple forests with more than one domain tree. Remember that for each forest, you have to define a one DNS namespace. For each domain tree that you create, you have to define another namespace.

• Identify the forest owner(s): Each forest that you plan to create has to have a designated owner, or a group of owners. The forest owner is responsible for the operation of the forest. This includes the following:

  • Forest root domain

  • Sites and subnets, including site group policies

  • The schema

  • The replication process

  • Security policies for the domain.

  • Domain controller group policies

  • Specifying the appropriate owners or administrators for each Organizational Unit (OU).

  • Specifying forest service admins and domain service admins.

• Testing the forest design: You should implement a testing strategy and testing environment in which to test your forest design. The testing environment should ideally be a separate Active Directory environment to the production environment, but should mirror the production environment.

Differences between a Multiple Forest Model and a Single Forest Model

Before examining the major advantages and disadvantages of a multiple forest model and a single forest model, consider the following statement: The most ideal implementation is that of a single forest model.

Advantages of a single forest model:

• A single forest implementation has less design, implementation, hardware, and administrative costs when compared to a multiple forest implementation.

• A single forest model enables objects to be shared over domains in a non-complicated manner

• There is a single set of schema objects and configuration objects, and a single Global Catalog.

• You can also implement a single Exchange Organization.

Disadvantages of a single forest model:

• A single forest implementation does not include test environments.

• Because there is only one forest, you need to thoroughly plan and control changes which are made to the forest. Any changes that are made to the forest affect all the domains within the environment.

• You also have to strictly control enterprise components that are shared over all domains

Advantages of a multiple forest model:

• Each business within the larger organization can function in isolation. Businesses can therefore operate independently from one another.

• Isolated schemas and configuration directory partitions enable you to define forest autonomy at the schema level and configuration level.

• For each business, you can define a separate DNS hierarchy.

• Test environments can be implemented.

Disadvantages of a multiple forest model:

• A multiple forest implementation has a far greater design, implementation, hardware, and administrative cost than that of a single forest implementation.

• You need to establish external trusts to domains to share network resources.

• Global Catalog queries only extend to the objects in the local forest.

• You need to implement and manage synchronization between forests.

Domain Design Factors

The factors that typically affect the domain design are summarized below:

• Geographical factors: Where organizations span may geographical regions, you might consider implementing a geographic domain design to control replication over different regions within the enterprise. Domain controllers would then only replicate data in its local domain.

• WAN link costs: The cost of implementing and maintaining unreliable WAN links could be high, as is the case in some countries.

• Business Requirement Factors: There may be cases where different businesses within the same organization can indeed share a forest, but the nature of their business might lead to each business needing to have its own domains. This is normally necessary when each business needs to implement its own domain security policies.

• Domain Name Strategy: Each domain has to have a NetBIOS name and a DNS name. Each domain name has to be unique. When assigning NetBIOS names, try using names that you would not need to change, and use Internet standard characters. NetBIOS names should typically be 15 characters, or less than 15 characters in length. When you assign DNS names, try to keep the prefix of the DNS name and NetBIOS name the same.

The Single Domain Forest Model

When a single domain is deployed within one forest, the domain contains the following:

• Domain controllers, Users, Computers, Groups, all other objects, forest service admins and domain service admins.

A single doman forest offers a few advantages such as low design, hardware and administrative costs. However, a main disadvantage of a single domain forest is that you basically have to rebuild the domain if you want to rename it – changing a single domain forest is an intricate process! Another key disadvantage is that all objects are replicated to all domain controllers. This typically leads to replication generating significant volumes of traffic.

Creating Multiple Domains

You usually create multiple domains in your Active Directory environment because of the following reasons:

• Groups of users have different security policy requirements: With Active Directory, you can only specify account policy settings of a Group Policy Object (GPO) at the domain level. The account policies found in the Account Policies sub-directory in the Security Settings node is Password Policy, Account Lockout Policy, and Kerberos Policy. In cases where the security requirements differ in your organization, you would need to create multiple domains.

• Groups of users have different administrative requirements dues to security reasons that cannot be catered for by implementing Organizational Units (OUs) in the domain.

• When a forest only has one domain, the objects in the forest are replicated to all domain controllers in that forest. In an extremely large domain, you might need to create multiple domains to control Active Directory replication traffic. Multiple domains enable you to configure replication to occur for those objects associated with a particular domain. This in turn decreases the bandwidth requirement for replication, and decreases network traffic generated by replication.

• You also possibly decide to keep an existing Windows NT domain in if you have a fairly large Windows NT domain structure.

Before creating multiple domains, you should consider the following points:

• Creating multiple domains leads to increased administrative costs. Whenever new domain is created, another Domain Admins global group is created that needs to be administered. In addition to this, by creating multiple domains, you also increase the likelihood of having to move security principals between domains. While moving a security principal within the same domain is fairly simple, moving a security principal between domains can be a fairly complicated process.

• Multiple domains also increase hardware costs. A requirement of a Windows Server 2003 domain is that it has a minimum of two domain controllers for fault tolerance and multimaster purposes.

• In cases where users in one domain need to access resources hosted in another domain, you would need to define trust relationships which in turn need to be configured, managed and maintained.

• Because group policy and access control are implemented at the domain level, you would need to implement them for each domain.

The Root Domain

When you create the first domain in a forest, that domain becomes the root domain. The root domain has many unique components and features that the remainder of the domains added to the same forest do not have. The root domain is the only domain that contains the following groups and roles:

• Enterprise Admins group

• Schema Admins group

• Schema Master role

• Domain Naming Master role

You can choose to define the root domain as a dedicated root domain. What this basically means is that the root domain will not contain users or groups other than the default user and group objects. If you choose to not have a dedicated root domain, some thought has to go into deciding on which domain would be created first. Remember that this domain would contain the previously mentioned roles and groups. Administrators of the first created domain would therefore have control over the forest and domain.