Presentation on theme: "Module 7: Designing a Multiple-Domain Structure. Overview Identifying Business Needs Accessing Resources Between Domains Planning for Multiple-Domain."— Presentation transcript:
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.
Identifying Business Needs 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 OUOU 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 OUOU OUOUOUOU OUOU OUOUOUOU OUOU OUOUOUOU OUOU 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.
In this lesson you will learn about the following topics: Authentication across a forest Types of trust
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.
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.
Planning for Multiple-Domain Trees 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.
In this lesson you will learn about the following topics: Characteristics of multiple domain trees Creating an empty root domain Designing guidelines
Characteristics of Multiple-Domain Trees Child Domain nwtraders.msft us.nwtraders.msft sales.us.nwtraders.msft Child Domain europe.nwtraders.msft RootRoot 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 nwtraders.msft usa.nwtraders.msft Child Domain europe.nwtraders.msft RootRoot 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.
Planning for Multiple-Tree Forests 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.
In this lesson you will learn about the following topics: Characteristics of multiple-tree forests Design guidelines for multiple trees forests
Characteristics of a Multiple-Tree Forest Tree 2 RootRoot Child nwtraders.msft domainB.domainA.nwtraders.msft Transitive Trust Relationship Created Between Roots Tree 1 RootRoot Child contoso.msft Child domain3.contoso.msft domain2.contoso.msft domainA.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.
Planning for Multiple Forests 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.
In this lesson you will learn about the following topics: Characteristics of multiple forests Design guidelines for multiple forests
Characteristics of Multiple Forests Tree 1 Tree 2 RootRoot Child RootRoot contoso.msft Child domain3.contoso.msft nwtraders.msft domainB.domainA.nwtraders.msft domain2.contoso.msft One-Way External Trusts Established Among Specified Domains Only domainA.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.
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 Identifying Business Needs Accessing Resources Across Domains Planning for Multiple-Domain Trees Planning for Multiple-Tree Forests Planning for Multiple Forests