Major Design Elements of Active Directory


The structure of Active Directory is hierarchical. It consists of five main design elements:

  • Forests

  • Trees

  • Domains

  • Organizational units

  • Sites

As you will see in subsequent chapters, you need to have an understanding of each design element to properly implement each one in an effective Active Directory infrastructure.

Forests

The first design element discussed 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. However, forests can contain multiple domains, and each new domain created with its own unique namespace establishes a new tree in the forest (trees are discussed later in the chapter, in the section titled "Trees"). Take a look at the structure of the XYZ Corporation in Figure 2.1.

Figure 2.1. The forest root domain is xyz.corp , and abc.corp requires its own namespace. Together, the two namespaces form an Active Directory forest.

graphics/02fig01.gif

The first domain created in the forest is xyz.corp . The Paris domain and NY domain are created in this tree and share a portion of their namespaces with xyz.corp . For administrative purposes, the ABC domain requires a separate namespace and is established as a new tree in the same forest.

The first domain created in the forest is the forest root . This domain cannot be renamed or deleted. For this reason, you must plan which domain will become the forest root domain for an organization. Careful planning during this phase can help avoid the possibility of having to completely reorganize the Active Directory structure in the future. After the forest root domain has been configured, new domains can be added to this tree or be established as new trees in the forest.

When you're designing the forest structure, remember that simpler is usually better. With Active Directory, you can create multiple forests, but a single-forest environment is much easier to administer and maintain. In some cases, however, an organization might need to create more than one forest to meet its administrative needs.

Domains in a single forest share some common elements, including the following:

  • Schema

  • Configuration container

  • Enterprise admins

  • Schema admins

Having common elements shared among domains in a single-forest environment makes the administration of multiple domains much simpler. Conversely, this can also be the reason an organization opts to create a multiforest structure. The next two sections should clarify this statement.

Schema

The schema maintains a list of all the objects that can be stored in 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 in an Active Directory is the Users class. An attribute associated with this class could 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. For the most part, the default schema should meet the needs of an organization, but components can also be added or modified in the schema if necessary. For example, an organization might stipulate that employee IDs 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 must consider the schema policy. If the default schema policy does not meet the needs of the entire organization, multiple forests might need to be created. For example, if two organizations work together but require different schema policies for their domains, creating multiple forests would be necessary.

graphics/note_icon.gif

You can modify the schema in the Microsoft Management Console using the Schema snap-in. To modify the schema for a forest, 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 connecting 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. Having a forest-wide configuration container means that configuration information does not need to be created for each domain, which makes the administration of multiple domains much easier.

Global Catalog

All domains in a forest also share a single Global Catalog (GC). The GC stores certain attributes pertaining to each object in the forest. You can query the GC using the attributes of an object to determine its location. This is beneficial for clients because they do not need to search for objects in different domains. Think of a GC in terms of 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 objects in the forest, you can query the GC to determine their locations instead of having to perform an extensive search. This is a welcome change from Windows NT 4.0, where users who wanted to locate an object in the network had to do a search of the entire domain and any trusted domains.

Default attributes are automatically included in the GC. Organizations have the option of adding attributes and customizing the information stored in the GC to meet their needs. For example, adding the employee ID attribute to the GC enables you to search for users based on this attribute. An administrator can add attributes to the GC using the Active Directory Schema snap-in (see Figure 2.2).

Figure 2.2. To add an attribute to be replicated to the GC, use the Active Directory Schema snap-in in the MMC. For any additional attributes you want stored in the GC, select the Replicate This Attribute to the Global Catalog check box.

graphics/02fig02.gif

graphics/caution_icon.gif

During the logon process, the GC is also used to determine universal group membership. If a Global Catalog server is unavailable, users will be logged on using cached credentials. If the user Group Policy restricts logons using cached credentials, users will only be able to log on locally.


By default, the first domain controller in the forest is designated as the Global Catalog Server. An organization can thereafter designate any additional domain controllers as Global Catalog Servers. For a Windows 2000 network running in native mode, a Global Catalog Server is required for the logon process. Therefore, a domain controller might be need to be designated in each site as a Global Catalog Server so that users do not have to log on via a wide area network (WAN) link. The XYZ Corporation might need to designate another server as a Global Catalog Server in its New York site if its current Global Catalog Server is in Paris. Designating another server as a Global Catalog Server can be done through Active Directory Sites and Services, under the administration tools (see Figure 2.3).

Figure 2.3. Accessing the NTDS Settings property box through Active Directory Sites and Services enables you to delegate an additional domain controller as a Global Catalog Server.

graphics/02fig03.gif

Trusts

Windows 2000 has also made the process of providing access to resources across multiple domains much simpler. In previous versions of NT, for users in one domain to access resources in another domain, at least a one-way trust had to be manually set up between the two domains. Assuming the domain controllers in Figure 2.1 are running NT 4.0, if users in the Paris domain needed access to resources in the NY domain, the administrators would have to manually set up a one-way trust in which NY would trust Paris. With Active Directory, two-way, transitive Kerberos trusts are automatically established between all domains in the same forest. For example, if the Paris and NY domains are in the same forest, complete trusts would automatically be established between them, which would give users in each domain access to others' resources. This eliminates the need for trusts to be manually created between domains. You should keep in mind that in a multiforest environment, for users in one forest to access resources in another, an explicit trust must first be established.

graphics/note_icon.gif

In an organization that has a combination of Windows 2000 and Windows NT 4.0 domains, trusts can still be established, but they must be set up manually.


graphics/caution_icon.gif

Be prepared to encounter exam questions pertaining to trusts because two-way transitive trusts are a new feature in Windows 2000. They are created automatically between parent and child domains and between root domains in a forest. Old-style, one-way trusts can still be manually created between domains in different forests, as well as between Windows NT and Windows 2000 domains. These one-way trusts are identical to NT trusts and are not transitive.


Now let's take a look at how domains are organized in an Active Directory forest.

Trees

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

In the example shown in Figure 2.4, the Paris domain is added to an existing tree in the forest and inherits a portion of its namespace from its parent domain ”in this case, xyz.corp . Any new domains added to the forest that require a unique namespace can be established as new trees. A tree structure similar to the one shown in Figure 2.4 might be appropriate for organizations that have more than one registered DNS domain name and that want to maintain each of them. If the organization itself consists of multiple divisions with distinct and separate roles that require their own unique namespaces, a new tree might need to be created in the forest for each division.

Figure 2.4. A single forest consisting of two trees: xyz.corp and abc.corp .

graphics/02fig04.gif

graphics/note_icon.gif

To create a new domain with its own unique namespace, select the option to create a new tree in an existing forest during the installation of Active Directory.


With NT 4.0, each time a new domain is created, an administrator must manually configure a trust along with any other domains with which it needs to share resources. If the environment consists of multiple domains configured in a multiple-master domain model, the administrator must establish several trusts. In addition, the trusts that are set up by the administrator are 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. Therefore, if A trusts B and B trusts C, then 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. Trusts in Active Directory are covered in greater detail later in this chapter.

Domains

The main components of the Active Directory hierarchy are domains and organizational units (OUs). The domain is the main object in Active Directory; organizational units are created in the domain to organize objects based on the organization's administrative model.

Domains determine both the security and administrative boundaries in the Active Directory hierarchy. Think of a domain as a container, and all the objects in the container share the same administration, replication process, and security requirements. In most cases, the same security requirements can be applied to an entire business. If a business requires separate security policies to meet its administrative structure, such as different password lengths or expiration policies, more than one domain might need to be created. Objects would then inherit the security policy from the domain in which they are located.

A new feature in Windows 2000 and Active Directory is the multiple-master replication model. In a domain, all domain controllers are considered to be equal, meaning they all contain a working copy of the directory. Previous versions of NT had only one working copy of the directory database for the domain that was stored on the primary domain controller (PDC). The backup domain controllers (BDCs) only maintained copies, which they received from the PDC. If a PDC was taken offline, a BDC had to be promoted to take its place so that a working copy of the directory database was available. In Active Directory, each domain controller can receive changes to the directory and then replicate the changes to other domain controllers in the domain.

Domains in Active Directory exist together in a hierarchical relationship known as a parent-child relationship . An example of this type of relationship is shown in Figure 2.5. Using this relationship, an organization can create a central root domain for administrative purposes and allow the various departments or geographical locations to remain as their own domains by making them child domains to the root. An analysis of the organization's administrative needs must be done to determine whether child domains are necessary.

Figure 2.5. xyz.corp is the parent domain of paris.xyz.corp and ny.xyz.corp , and paris.xyz.corp is the parent domain of sales.paris.xyz.corp .

graphics/02fig05.gif

Organizational Units

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

graphics/note_icon.gif

Creating an OU within another OU is known as nesting .


For example, within the ny.xyz.corp domain, the administrators might decide to create OU for each department. If the domain consists of three separate departments, three OUs could be created (see Figure 2.6).

Figure 2.6. The ny.xyz.corp domain has created OUs based on departments.

graphics/02fig06.gif

By creating these OUs, administrators can delegate control of the objects to other users in the organization. This way, domain administrators do not need to remain responsible for every administrative aspect pertaining to their organization. For example, within the structure shown in Figure 2.6, an OU could be created in each department for network printers and delegation of control over this OU could be assigned to another individual or group of individuals.

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

Not only can OUs be created to assign a user or group control over the objects contained within them, but they can also be used to group objects that require a similar Group Policy (for an in-depth discussion of Group Policies, see Chapter 6, "Designing Active Directory for Group Policy"). By applying a Group Policy to an OU, an administrator can limit the capabilities or restrict the environment of the objects contained in it. A group of users who require similar desktop environments can be grouped into an OU, and the Group Policy can then be applied to that specific container.

graphics/note_icon.gif

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

The last major design elements in the Active Directory structure are sites. 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 in the Active Directory infrastructure to optimize replication between domain controllers. A site topology is designed around the physical location of IP subnets in a domain and the type of link connecting them. As with the other design elements previously 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 need to determine is where the domain controllers will be located. Clients typically prefer a quick response time, so in most situations, at least one domain controller is placed in each of the sites (in instances when it is determined that a site does not require a domain controller, such as if 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 needs to be done. Then, after connectivity and available bandwidth have been assessed, you can determine where site links will be established.

If the ny.xyz.corp domain shown in Figure 2.7 consists of five IP subnets, the design team would have to look at the speed of the connection between them and the current amount of network traffic. Through analysis, the team could determine that IP subnets 1 and 3 are connected by a fast, reliable link and are associated with one site ”site A. Replication between these subnets does not need to be controlled because the connection between them has sufficient bandwidth to support replication traffic as well as any other network traffic. The remaining three subnets in the NY domain have been grouped to form another site (site B) because the physical connection between these three is also high-speed, reliable, and capable of supporting a large amount of traffic. Replication in each site (intrasite) will occur within 5 minutes of a change.

Figure 2.7. ny.xyz.corp has been segmented into two separate sites to optimize replication. An analysis determines that the 256Kbps connection will not be capable of supporting the regular traffic generated by replication.

graphics/02fig07.gif

If subnets in a domain are linked via a connection that cannot support a lot of replication traffic because it is an unreliable, slow link or is already heavily used, multiple sites can be created. The analysis determines that the connection between site A and site B cannot support regular traffic generated through replication because it is already heavily used (see Figure 2.8).

Figure 2.8. The 56Kbps connection will not be capable of supporting the regular replication traffic. Two separate sites with a site link connecting them are created so that replication across the connection can be controlled.

graphics/02fig08.gif

By creating two separate sites, administrators can then create a site link between them to connect the two sites. The site link enables replication between subnets to be controlled. Also, the site link can be assigned a cost and a schedule, limiting when replication occurs and which site link is used if multiple site links exist. By specifying a polling interval, administrators can also control how often a domain controller will check for updates. After a site link is established, any information sent across the link is compressed.

graphics/note_icon.gif

Compression of data across a site link does not actually occur until the amount of traffic is greater than 50K.


The site links that are created are transitive as well. Therefore, if a link is created between site A and B and also between site B and C, it is assumed that the domain controllers in site A and C can communicate.



MCSE Active Directory Services Design. Exam Cram 2 (Exam Cram 70-219)
MCSE Windows 2000 Active Directory Services Design Exam Cram 2 (Exam Cram 70-219)
ISBN: 0789728648
EAN: 2147483647
Year: 2003
Pages: 148

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net