Module 7: Designing a Multiple-Domain Structure. Overview Identifying Business Needs Accessing...

Module 7: Designing a Multiple-Domain

Structure

Overview

Identifying Business Needs

Accessing Resources Between Domains

Planning for Multiple-Domain Trees

Planning for Multiple-Tree Forests

Planning for Multiple Forests

Domains, trees, and forests are bordered units within Microsoft® Windows® 2000 Active Directory™ directory service. These units can share resources but can also be administered separately. There is also a difference in how these units intercommunicate, and how replication traffic flows between them. If your organization requires more than one domain, tree, or forest, then you must understand how information flows across these borders. The information flow between units will help you decide whether you need a structure more complex than a single domain, and if so, how to plan for the most effective administration model.

At the end of this module, you will be able to:

Identify business needs that require a multiple-domain structure, and business needs that can be met by a single domain.

Describe the trust relationships that allow users and resources to gain access to multiple domains, and the security protocol used to authenticate access.

Plan an infrastructure in Active Directory that has multiple domains in a single tree.

Plan an infrastructure in Active Directory that has multiple trees in a single forest.

Plan an infrastructure in Active Directory that has multiple forests.


Reasons to Maintain a Single Domain

Reasons to Create Multiple Domains

The smallest tree in Active Directory consists of a single domain. While this is the simplest design for an Active Directory structure, there are business circumstances in an organization that require the addition of child domains to the tree. Some business needs that may seem to require multiple domains might be adequately met by a single domain structure. Before designing a multiple-domain structure, you should first ensure that the design cannot be met by using a single domain.

This section will discuss the reasons to maintain a single domain, and help you identify the reasons that would require you to create multiple domains.

In this lesson you will learn about the following topics:

Reasons to maintain a single domain

Reasons to create multiple domain

Reasons to Maintain a Single Domain

Ease of Management

Easier Delegation

Fewer Members in Domain Admins Group

Object Capacity Same as Multiple Domain Structure

OUOUOUOU

OUOUOUOU OUOUOUOU

The default structure in Active Directory begins with a single domain, and, if at all possible, your structure should keep a single domain. Single domains offer the following advantages over multiple-domain structures:

Ease of management. Single domains require less hardware to purchase and maintain, less trusts to create, and less administrative groups to create and maintain.

Easier delegation of administrative authority. In a single-domain structure, you can create organizational units (OUs) as needed to delegate authority over resources and Active Directory objects. Delegating administrative authority is more complicated in a multiple-domain structure.

Fewer members in the Domain Admins group. With a single domain you can keep membership of the powerful Domain Admins group to a minimum, and use delegation to allow detailed control of directory objects in Active Directory.

Object capacity same as multiple domain structure. You can theoretically have over four billion objects in the global catalog. The global catalog includes all objects in all domains in a forest, regardless of the number of domains present. So, if the objects will not fit within a single domain, they will not fit within a multiple-domain forest either.

Reasons to Create Multiple Domains

Reasons for Using a Multiple-Domain Tree:

Distinct domain-level policies

Tighter administrative control

Decentralized administration

Separation and control of affiliate relationships

Reduced replication traffic

OUOUOUOU

OUOUOUOU OUOUOUOU

OUOUOUOU

OUOUOUOU OUOUOUOU

OUOUOUOU

OUOUOUOU OUOUOUOU

OUOUOUOU

OUOUOUOU OUOUOUOU

The single domain in Active Directory is the most flexible, least expensive, and easiest to administer directory structure. However, when planning the design for the Active Directory structure, you may want to consider additional domains if your organization requires any of the following:

Distinct domain-level policies. Because account and password policies are applied at the domain level, you can create separate domains with distinct policies that will apply to the users in each domain.

Tighter administrative control. A domain is a security boundary. Domain administrators cannot cross domain boundaries to manage other domains without explicit permission.

Decentralized administration. In some organizations, divisions that make a monetary investment in their own computer hardware, such as domain controllers, want to retain complete administrative control of their hardware.

Separation and control of affiliate relationships. Large corporations often form business affiliations by being involved in joint ventures or partnerships. Multiple domains allow you to isolate administrative and security control of shared resources and external users.

Reduced replication traffic. Within a domain, all objects and attributes are replicated between all domain controllers in the domain. If a slow or congested wide area network (WAN) link within a domain prevents Active Directory replication from occurring within a necessary timeframe, consider creating multiple domains to reduce replication traffic. The only data replicated between separate domains are changes to the global catalog server, configuration information, and schema.

Accessing Resources Between Domains

Authentication Across a Forest

Types of Trusts

You locate, access, and manage resources and information within a single domain differently than you do across multiple domains. Security protocols govern authentication between domains in a forest. Trusts are means to manage authentication between domains in a forest. Understanding how these processes differ can help you decide whether a multiple-domain tree model fits the administrative needs of your organization.


Authentication across a forest

Types of trust

Authentication Across a Forest

na.contoso.msftna.contoso.msft

nwtraders.msftnwtraders.msft

south.nwtraders.msftsouth.nwtraders.msft

contoso.msftcontoso.msft

Authenticatio

n Path

Authenticatio

n Path

11

22 33

44

55

KerberosKerberos

The Kerberos version 5 protocol, a security feature of Windows 2000, governs access between domains within an Active Directory infrastructure. The Kerberos V5 protocol employs three components: a client, a server, and a trusted third party to mediate between them. The trusted intermediary in the protocol is known as the Key Distribution Center, or KDC. In Windows 2000, the domain controller functions as the KDC.

When accessing resources across a forest, the Kerberos V5 protocol trust path must be followed. In the example, one tree of the forest consists of contoso.msft and its child domain, na.contoso.msft. The other tree in the forest consists of nwtraders.msft and its child domain, south.nwtraders.msft.

If a user in na.contoso.msft needs to gain access to resources in south.nwtraders.msft, the following process occurs (without user interaction):

The user will first receive an authorization called a session ticket from the KDC in the na.contoso.msft domain. The user presents the session ticket to the KDC in contoso.msft.

The KDC in contoso.msft supplies the user with a session ticket for nwtraders.msft.

The user presents the nwtraders.msft session ticket to the KDC in nwtraders.msft.

The KDC in nwtraders.msft supplies a session ticket for the KDC in south.nwtraders.msft, which will in turn supply a session ticket for the desired server.

Types of Trusts

Transitive

External

Shortcut

Windows 2000 uses trusts to allow users to access resources in different domains. There are three types of trusts used in Windows 2000: transitive, shortcut, and explicit trusts. Each type of trust follows a trust path between the domain controllers for the source and target domains. A trust path is the series of domain trust relationships that must be traversed by security in Windows 2000 to pass authentication or query requests between any two domains.

Transitive Trusts

A transitive trust is a two-way secure relationship that exists between each child domain and its parents or to the root domain of the forest. Transitive trusts are created automatically between parent and child domains, and between trees in a forest. Because all child domains within a tree are derived from a common parent domain, each domain in a tree will trust all other domains in the tree.

When you create a new tree as a result of promoting a server to a domain controller, you must specify the root domain of the initial tree in the forest. Thus, a trust relationship is established between the root domains of the new tree and the initial tree. If you create a child domain, a trust relationship is established between the child and the parent. Because this trust is transitive and bi-directional, resources can be shared between all three trees with no further trust configuration.

Transitive trusts make information accessible to all domains in the forest. Once a user is authenticated, discretionary access control list (DACL) entries control resource access privileges to users or groups.

Shortcut Trusts

You can shorten the trust path within a forest by creating a shortcut trust specifically, or explicitly, between two domains within a forest. A shortcut trust is a transitive trust intentionally created between two distant domains within the same forest. By creating a shortcut trust, you optimize the authentication process by creating a shorter trust path.

External Trusts

Domains in different forests do not automatically have a trust relationship. To allow access between different forests, you must create an external trust explicitly between two domains. Unlike transitive and shortcut trusts, external trusts are one-way trusts that give a desired domain access only to the domain originating the external trust. For a two-way trust to exist between two domains, both domains must create external trusts to each other. Also, external trusts only extend to the domains specified; any other transitive trusts associated with the domains remain separate from the external trust.

While external trusts must be explicitly created and managed, they allow you to customize access privileges for individuals in other forests, monitor activity both within and between domains, and limit the scope of authenticated access to the domain that is explicitly trusted. While the characteristics of an external trust are important for inter-forest communication, you must plan external trusts carefully to ensure proper resource management, trust placement, and maintenance.


Characteristics of Multiple-Domain Trees

Creating an Empty Root Domain

Design Guidelines

By default, a single-domain tree is created when the first server in a network is promoted to a domain controller. However, you can construct a larger tree by adding more domains to an existing tree. Before creating a multiple-domain tree, you should understand the structure and characteristics of a multiple-domain tree, and the organization's business situations that may require multiple domains.


Characteristics of multiple domain trees

Creating an empty root domain

Designing guidelines

Characteristics of Multiple-Domain Trees

Child

Domain


us.nwtraders.msftus.nwtraders.msft

sales.us.nwtraders.msftsales.us.nwtraders.msft

Child Domain

Child Domain

europe.nwtraders.msfteurope.nwtraders.msft

RootRootRootRoot

Transitive Trusts Exist Between All Domains

When additional domains, or child domains, are attached to the initial domain they form a hierarchical structure. Any child domain can be the parent of additional child domains.

Domains Within a Tree Share a Single Tree Root

A tree has a single root and is built as a strict hierarchy. Each domain below the root has exactly one immediate parent domain. Each level of the hierarchy is directly related to the level above it and to the level below it.

An Active Directory tree hierarchy is a Domain Name System (DNS) hierarchy. Child domains derive their names from the parent domain. For example, you have an international company with a root domain named contoso.msft. To have decentralized administration between the Europe and the United States divisions, you can create a new domain for each and join them to the existing tree. These new domains become europe.contoso.msft and us.contoso.msft.

Domains Within a Tree Share Information Through Automatic Trusts

All domains within an Active Directory tree share a common directory schema, configuration information, and global catalog. They also have automatic transitive trust relationships that allow users in each domain to gain access to available resources in all other domains in the tree.

Creating an Empty Root Domain

Child Domain


usa.nwtraders.msftusa.nwtraders.msft

Child Domain

europe.nwtraders.msfteurope.nwtraders.msft

RootRootRootRoot

Enterprise Admin is Sole User in Root Domain

Enterprise Admin is Sole User in Root Domain

An organization with decentralized administration may choose a single tree with an empty root domain. An empty root domain contains no OUs and only the enterprise administrator (or a small number of administrators) as the only users in the domain. The advantage of this model is a contiguous namespace with a distinct separation between divisions. In the scenario pictured in the slide, the root domain holds the default administrator account as the enterprise administrator. The two (or more) Information Technology (IT) groups in the child domains could limit the number of users with access to this powerful account. For example, the IT groups could establish a policy that requires the enterprise administrator to log on with an authentication device such as a smart card. The smart card could be secured in such a way that it requires a user from each IT group to access it.

Design Guidelines

Design Needs that May Require a Multiple-Domain Tree:

Distinct Security Boundaries

Bandwidth Constraints on WAN Links

Legal Reasons for Separate Domains

Distinct Domain-Level Group Policy Settings

The following are design criteria that may require a multiple-domain tree.

You need a distinct security boundary. If your organization uses decentralized administration, or if some groups must be separated for security reasons, creating multiple domains allows each domain to administer itself. Another reason to create separate domains is to reduce the influence that the Enterprise Admins group has over all objects within a domain.

You determine that replication traffic could overwhelm wide area network (WAN) links. Within a domain, every attribute of every object is replicated between domain controllers. If a WAN link within the domain is very slow or congested, this could overwhelm the link, even if different sites are created. In a multiple-domain structure, only the schema, configuration, and global catalog are replicated, thereby reducing network traffic.

You have legal reasons for separating the domains; for example, some organizations with a foreign presence may be required to maintain separate domains for foreign user accounts.

You have distinct domain-level Group Policy settings, for example, password restrictions for different groups, which can be set only at the domain level.


Characteristics of Multiple-Tree Forests

Design Guidelines

A forest is a collection of one or more Active Directory trees connected by two-way, transitive trust relationships between the root domains of each tree. Before creating a multiple-tree forest, you should understand the structure and characteristics of a multiple-tree forest, and the organization's business situations that may require multiple-tree forests.


Characteristics of multiple-tree forests

Design guidelines for multiple trees forests

Characteristics of a Multiple-Tree Forest

Tree 2

RootRootRootRoot

ChildChild

ChildChild


domainB.domainA.nwtraders.msftdomainB.domainA.nwtraders.msft

Transitive Trust Relationship Created Between Roots

Tree 1

RootRootRootRoot

ChildChild


ChildChild

domain3.contoso.msftdomain3.contoso.msftdomain2.contoso.msftdomain2.contoso.msft

domainA.nwtraders.msftdomainA.nwtraders.msft

Trees in a forest share a common directory schema, configuration information, and global catalog. Both the sharing of common data and the trust relationships between the roots of trees distinguishes a forest from a set of unrelated trees.

Trees are identified by the DNS name of the first domain created in the tree. This name is unique in the forest and is what separates trees within a forest. Each tree forms a separate naming hierarchy that is based on different DNS root domain names. The forest itself is identified by the DNS name of the initial tree that was created in the forest, which is the root domain.

Although the roots of the separate trees have non-contiguous names, the trees are a part of a single overall hierarchy, and Active Directory can still resolve names of objects within the forest.

Before designing a new tree, you must first determine its structure by determining the following:

The DNS domain name of the new tree. Remember that each tree has a unique DNS domain name. Once you choose the name, you can then create the new domain.

The structure of domains in the tree. This includes determining if additional domains in the tree are necessary and identifying which domains are child domains.

Design Guidelines

Consider Using a Multiple-Tree Forest When You Need:

Distinct DNS names for Public Identities

Centralized Control Among All Active Directory Trees and Domains

Large organizations may require multiple trees in a single forest to address the following circumstances:

The organization has different public identities and needs to maintain distinct names within Active Directory, yet have full access between the trees. For example, the organization may have a subsidiary with its own registered domain name, and want to maintain the separate name.

The organization requires centralized control of administration, and a global organizational directory for full access of resources and information. The trees in a forest still share a common directory schema, configuration information, and global catalog.


Characteristics of Multiple Forests

Design Guidelines

Multiple forests are comprised of separate and distinct forests that do not share any information in Active Directory unless special trust relationships are explicitly created. An organization's need for a multiple forest will most likely arise through corporate acquisitions, or through conducting business with limited business partners such as joint ventures or subsidiaries. Before creating multiple forests, you should understand the structure and characteristics of a multiple forest, and any business situations that may require multiple forests.


Characteristics of multiple forests

Design guidelines for multiple forests

Characteristics of Multiple Forests

Tree 1

Tree 2

RootRootRootRoot

ChildChild

RootRootRootRoot

ChildChild

ChildChild


ChildChild

domain3.contoso.msftdomain3.contoso.msft


domainB.domainA.nwtraders.msftdomainB.domainA.nwtraders.msft

domain2.contoso.msftdomain2.contoso.msft

One-Way External Trusts Established Among Specified

Domains Only

domainA.nwtraders.msftdomainA.nwtraders.msft

Multiple forest environments can be very difficult and complex to manage. This type of environment is not recommended for a single organization with no branches or subsidiaries, because any interaction between forests must be explicitly created.

Forests do not share a common schema and configuration, nor do the global catalog servers share information between each other. A directory synchronization product will be needed to have a global organizational directory listing between forests.

To allow users to gain access to information in multiple forests, you must explicitly create one-way external trusts between domains of different directories in Active Directory. To permit a two-way trust between domains, both of the domains must create one-way external trusts with each other.

Design Guidelines

Design Multiple Forests When:

You Do Not Want a Common Schema

You Do Not Want a Global Directory

You Need Limited Partner or Affiliate Relationships

The following are design criteria that may require multiple forests.

You do not want to have a common schema. Different components of your organization may require schema modifications that are not desired by the rest of the organization. Schema changes are not replicated across forests.

You do not want a global directory. Unless you establish directory synchronization between the forests, there will be no default global directory for an organization comprised of multiple forests.

You have partner or affiliate relationships. You may wish to have limited access to resources between an organization's partners or affiliated companies, but want to keep the administration separate. Creating multiple forests ensures separation of resources, and permits sharing only when specifically authorized.

Lab A: Designing a Multiple Domain Structure

Exercise 1: Designing a Domain Strategy for a Medium-sized Organization

In this exercise, the scenario and design criteria at a medium-sized company will be examined to determine the best domain strategy.

Scenario

Woodgrove Bank is a regional bank with 200 branches located in Ohio, Illinois, and Indiana. Woodgrove will be using corp.woodgrove.msft as the Active Directory root domain. Woodgrove has recently acquired, as a wholly owned subsidiary, Hanson Brothers Financial Services, a financial brokerage firm.

Criteria

Hanson Brothers should be included in the new Active Directory design.

Hanson Brothers plans to maintain their DNS domain identity of hansonbros.msft.

The two organizations will allow access to each other's resources.

While a distinction between the two organizations will remain, in the future Woodgrove has plans to merge their two distinct IT groups.

Design Decision

Use Visio 2000 (or another tool) to document a design for Woodgrove Bank and Hanson Brothers Financial Services.

Exercise 2: Designing a Domain Strategy for a Large Organization

In this exercise, the scenario and design criteria at a large organization will be evaluated to determine the domain strategy for the organization.

Review the company profile and the design criteria and perform the tasks.

Scenario

You have been hired to assist in the design of an Active Directory naming strategy for Tasmanian Traders.

Tasmanian Traders is a multi-national corporation comprised of several distinct business units. Each unit has a distinct IT group, although in some cases, a technical collaboration may occur across units. The business units are: Enchantment Lakes Corporation extracts and processes

industrial diamonds into grinding and polishing products for industries worldwide.

Ferguson and Bardell buys, sells, and develops land in Australia for residential and commercial use.

Lucerne Real Estate, a subsidiary to Ferguson and Bardell, maintains a land brokerage and a construction division in Sydney. Lucerne has its own IT staff, which works under the direction of the Ferguson and Bardell staff.

Lakes & Sons manages a fleet of commercial vessels that transport shipments worldwide.

Shear Savvy processes and exports sheep pelts to the United States and Europe.

Criteria

A company-wide initiative exists to create an Enterprise Directory Service.

To make any modifications that will affect all business units, one corporate and at least two subsidiary representatives are required.

None of the business units wants to be subordinate to another.

The design should support different business units with offices in a single location.

The organization is vulnerable to restructuring, either through acquisitions or internal growth.

The users in Enchantment Lakes frequently access resources in Lakes & Sons.

Design Decisions

Use Visio 2000 (or another tool if Visio is not available) to document the Active Directory domain design. Make sure it is possible to give all users access to enterprise-wide resources. Identify any means to optimize the access of resources.

Review


Accessing Resources Across Domains




Module 7: Designing a Multiple-Domain Structure. Overview Identifying Business Needs Accessing...

Documents

Transcript of Module 7: Designing a Multiple-Domain Structure. Overview Identifying Business Needs Accessing...