- Designing the Active Directory Infrastructure to Meet Business and Technical Requirements
- Designing the Network Services Infrastructure to Meet Business and Technical Requirements
- Analyzing the Effect of the Infrastructure Design on the Existing Technical Environment
- Exam Prep Questions
- Need to Know More?
Chapter 3: Creating the Active Directory and Network Services Conceptual Designs
Terms you'll need to understand:
Techniques you'll need to master:
Designing the Active Directory infrastructure to meet business and technical requirements
Designing the network services to meet business and technical requirements
Analyzing the impact of the infrastructure design on the existing technical environment
Designing an infrastructure that will properly support Windows Active Directory requires a large amount of pre-planning. Many organizations will be upgrading their current infrastructure. With that in mind, the organization will likely have in mind certain requirements for the new infrastructure. An important part of the design phase is to identify the business and technical requirements, and then use the information to design an Active Directory hierarchy that meets these requirements.
Designing the Active Directory Infrastructure to Meet Business and Technical Requirements
You need to begin your analysis of the business and technical requirements by addressing the organization's administrative model.
Designing the Envisioned Administrative Model
During this phase of the Active Directory design, you assess the current administrative model that is being used by an organization. This information has a major effect on the Active Directory structure that will be put into placefor example, the number of domains that are created.
Determining the Administrative Model
Determining the administrative model that a business has implemented is important to the Active Directory design process. The administrative model basically determines who holds the decision-making authority within a business and who is responsible for implementing these decisions. There are basically three administrative models that can be implemented: centralized, decentralized, and mixed mode. Table 3.1 summarizes these three administrative models.
Table 3.1 The Three Administrative Models
A central group holds all the decision-making authority within an organization.
Different units within a business are responsible for their own administration.
A central group maintains some level of decision-making or mixed mode authority, but certain administrative tasks are assigned to each business unit.
Identifying Responsibilities for Administering Resources
After the administrative model within the organization has been identified, the next step is to identify who is currently responsible for administering network resources. When determining administrative responsibilities, consider the following questions:
Who is responsible for what?
Where do these privileges apply?
What type of privilege is assigned?
Determine which individuals or groups within the business should have administrative privileges and what their responsibilities are. For example, a group of individuals might have been given the responsibility of administering user accounts, whereas another group might have administrative privileges over network printers.
Do the permissions apply throughout the organization or only to certain areas? For example, in an enterprise network, if a user has been given administrative authority over user accounts, should this privilege apply to all domains and organizational units (OUs) or just specific ones? In other words, what is the scope of the administrative privilege?
Does the individual or group have full administrative privileges or control over only certain aspects? For example, what level of control does the individual or group have over user accounts? Does the individual or group have full control or control over only certain aspects of user accounts?
Determining the answers to these questions will help you develop a delegation plan that can easily integrate into the business's current administrative model and its current way of distributing administrative tasks among its employees.
Determining the Type of IT Organization
To effectively design an Active Directory hierarchy, the current structure of the IT organization within the business must be assessed. After the current structure has been documented, the design team can work with the company to determine whether there are any areas that need improvement or areas that can be restructured for easier administration. This information will assist in creating a design that meets the requirements of the business.
When assessing how the IT organization within a business is structured, determine the model that is currently in place. Is the network administration centralized or does the business allow for distributed administration (decentralized)? Determining this will ensure that the needs of the IT organization are identified and reflected in the administrative model that is developed.
An organization can also have decentralized management but a centralized IT function, and vice versa. Do not assume that decentralized management means decentralized IT.
The centralized model is hierarchical in structure. It is characterized by one individual or group overseeing all network development and administration to whom the IT organization would report. Some of the day-to-day administrative tasks might be assigned to select individuals or groups outside the IT organization, but most network administration remains centralized. The IT organization maintains decision-making authority as well as the responsibility for ensuring that all decisions are implemented throughout all levels within the business.
There is also a slight variation to this model in which the IT group is still centralized, but some of the day-to-day management tasks are decentralized. The central IT organization is responsible for overseeing network development and possibly implementing organization-wide policies, and the IT groups within the different business units are responsible for the day-to-day administrative tasks, such as creating user accounts.
With decentralized management, one person or group no longer holds all the decision-making and network administrative authority; in other words, no hierarchy or central IT organization oversees all network development. Each business unit maintains its own IT organization and implements its own IT model based on its needs. When it comes to technical issues affecting the entire organization, the different IT groups from each of the business units would have to work together. For example, if a business is planning a rollout of Windows Server 2003, each of the IT groups from the different business units would have to be involved.
The type of IT management structure that a business implements will not have a direct effect on the Active Directory structure. It is still crucial to characterize the current IT organization that a business has implemented because this information helps the design team determine the administrative model to use. However, the administrative model directly affects the organization of the different elements within the Active Directory structure.
Developing a Model for Administration
After you've characterized the type of IT organization that a business has in place, the next step is to develop a model for its administration. The administration model that is chosen determines the organization of the Active Directory structure. The type of model that is developed should be based on the structure of the IT organization (centralized versus decentralized). There are basically four models for administration:
Organizational (business unit or department)
Hybrids (combinations of the preceding types)
The administrational model chosen directly affects the Active Directory designparticularly the creation of top-level domains or organizational units.
If you choose to implement an administration model that's based on geographical location, the Active Directory structure will be organized around the different locations within the business. This type of model is well suited for a business that maintains a central IT organization but decentralizes management by assigning the responsibility of performing day-to-day administrative tasks to the different IT groups within the business units.
Before implementing this type of model, make sure that an individual or a group of individuals at the different locations is capable of performing these day-to-day tasks.
One of the positive features of an administrative model based on location is that it is fairly immune to reorganization and expansion. When a company changes its structure, it most often reorganizes departments but not the geographical locations of the business. Accommodating expansion can be as simple as creating a new domain or OU for the new location.
Organizational (Business Unit or Department)
If a business has implemented a decentralized IT organizational model and allowed the different departments to maintain localized control, a model for administration that is organizational (based on business units or departments) might be best. The organization of the Active Directory structure would be based on the different business units or departments within the company.
One of the nice features of this model is that it allows a business to maintain its departmental divisions. Each business unit maintains control over itself. However, in a model based on departments, if the departments are reorganized, it could mean a reorganization of the Active Directory structure.
This type of model is based on the different job roles within a business, without consideration of the different geographical locations and departments. For businesses that implement a decentralized IT organization and have job roles that span multiple divisions, the functional model might be more suited to their administrative needs than an organizational model.
This model is more manageable within a smaller business because users are more easily grouped into general functions. The larger the business, the more variance in job roles and the harder it is to group users. However, large organizations with many mobile users might find this model very attractive.
Because this model is based on the different roles within the business, it is essentially immune to reorganization. Reorganizations within a business most often affect departments, whereas job roles are not usually affected.
So far, we've covered three different administration models that a business could implement. The fourth model is a combination of those three models.
To design an Active Directory structure that meets the administrative needs of the IT organization, it might sometimes be necessary to combine several models. This type of models is known as a hybrid. Two of the common hybrid designs are "geographical, then organizational" and "organizational, then geographical."
In a "geographical, then organizational" model, the upper layers within the Active Directory structure are based on location, and the lower layers are organized around business units. This type of model is well suited for a business that spans geographical locations. Because the lower levels of the structure are based on business units, it also allows a business to maintain departmental independence.
Because the upper layers of the Active Directory structure are organized around the geographic locations of the business, it is immune to company reorganizations. However, a reorganization of the company might result in some restructuring of the lower layers because they are based on departments. Nonetheless, restructuring of OUs is simpler than the restructuring of domains.
The second type of hybrid model is the opposite of the one we just discussed: The upper levels of the hierarchy are based on the different business units or departments within the company, and the lower levels are based on the geographical locations. This model is ideal for businesses that need to maintain independence between the different departments for security purposes. Basing the lower levels on the physical structure (geography) also allows a business to distribute administration among the IT groups in different locations.
You might recall the discussion about models for administration based on departments and how they are affected by reorganization. This model will be affected by any reorganization that occurs within the business and might result in an entire restructuring of the Active Directory.
Creating the Conceptual Design of the Active Directory Forest Structure
In most cases, a single-forest structure should be sufficient. You also want to keep your Active Directory design as simple as possible. With that in mind, a single-forest structure is usually recommended for administrative purposes. However, in some instances, it will be necessary to consider a multiple-forest environment to meet the requirements of a business. This type of model is one of the most difficult to design and administer, so when you're considering the forest structure, keep the following topics in mind:
Before designing an elaborate structure that includes multiple forests, be sure to assess the business to determine whether there is an actual need for more than one forest. Consider a multiple-forest structure if a business has any of the requirements discussed in the next few paragraphs.
Does the business maintain partnerships or have subsidiaries with which it needs to maintain a very limited partnership? One of the most common reasons why you would create a multiple-forest environment is to meet an organization's need to maintain a limited trust with another organization or its subsidiaries. A situation such as this might arise when a business establishes a limited partnership with another organization or when an organization includes subsidiaries gained through corporate acquisitions. Separate forests might need to be created for security purposes, and when multiple forests are established, the scope of the trust relationship can be limited and closely monitored.
Does the business need multiple global directories? The global directory maintains a listing of all objects within the forest as well as certain attributes pertaining to each object, and all domains within a forest have access to a common global directory. If a business does not want one global directory for its entire organization, a multiple-forest structure must be implemented.
You'll recall from Chapter 2, "Gathering and Analyzing Business and Technical Requirements," that the schema maintains a list for the entire forest of all objects that can be stored within Active Directory as well as the attributes associated with each object (see Figure 3.1). A default schema policy comes with Windows Server 2003, but it can be modified if it does not meet your business's requirements. If an organization requires different schema policies for its various business units or if the administrators from the different business units cannot agree on a schema policy, multiple forests must be created.Figure 3.1 The Active Directory schema.
Partitions are applied at the forest level, so all domains within a forest will be affected by the same partition. If a business plans to make changes to the default schema but does not want its entire organization to be affected by changes, a multiple-forest structure should be considered. An appropriate partition could then be implemented for each forest. Because partitions are not replicated between forests, schema changes in one forest do not affect other forests.
Make sure you understand the circumstances under which it is appropriate to create multiple forests. Be prepared to encounter exam questions in which you must determine whether multiple forests are necessary based on a given scenario.
Creating the Conceptual Design of the Active Directory Domain Structure
As you've probably already noticed, assessing the needs of the business is crucial in all aspects of designing an Active Directory infrastructure. The needs of the business should also be the first thing considered when designing a domain. The infrastructure created by the design team should reflect the current structure of the business. When assessing the business, you need to detail the administrative requirements as well as the security requirements. Both of these requirements have a major effect on the domain and OU structure that will be planned for the business.
Administrative and Security Requirements
When designing a domain, the first thing that should be documented (or reviewed, if it has already been determined) is the administrative strategy that the business has implemented. The type of administrative structure that a business has in place determines the creation and organization of domains within the Active Directory. Does the business implement a centralized or decentralized strategy for administration? Knowing how the administrative tasks are distributed throughout the business helps determine the model for administration that will best meet the needs of the business. The administration model implemented should allow the business to distribute administrative tasks in a way that meets its administrative requirements. The administration model will also determine the organization of domains and OUs in the Active Directory hierarchy.
Recall that there are essentially four models that can be implemented for administration: geographical (location), organizational (business unit), functional (role), and hybrid models. The domain design should be based on the administrative model.
After you've determined the administrative requirements of the business, the security requirements have to be assessed. (Security within a business is usually crucial, so be sure that the assessment is thorough.) When assessing the security requirements, you need to determine who is responsible for administration within the business (delegation of authority). Documenting this information ensures that the proper permissions are assigned to the proper individuals. Use the following questions as a guide when performing the assessment:
Who in the business requires administrative privileges?
What are they responsible for?
What type of administrative privileges do they require to do their jobs?
What is the scope of their responsibilities?
Will their privileges apply at the site, domain, or OU level?
After the administrative and security requirements of the business have been determined, you should have a good understanding of the domain structure that best meets the business's needs. Your next step is to plan the creation of the first domain within the Active Directory structure.
Creating the First Domain in Active Directory
The first domain created within Active Directory becomes the forest root domain. This is the domain that represents the entire business. It is important to plan which domain will become the forest root domain because it can be difficult to restructure the Active Directory hierarchy if this domain must be renamed.
Careful planning is required when choosing a name for the forest root domain because other domains added to the structure might inherit a portion of their namespace from the root domain.
When deciding what to name the first domain in Active Directory, keep the following points in mind:
Choose a name that will not change in the near future; that is, choose a name that is static. Changing the name of the forest root domain is not easy, so try to choose a name that will not be change in the next 3 to 5 years.
Choose a name that is meaningful to the business, its employees, and its clients. When naming the forest root, consider using the name of the business.
Make sure that the name is available for use on the Internet. Even if the business has no intention of using its name on the Internet, make sure that the name is registered in case the business changes its mind in the future.
The internal namespace can be, and often is, different from the company's external namespace, but it can still cause problems if it is the same as a name already being used on the Internet.
When creating the forest root domain, the design team might determine that the business's name is an appropriate choice (as long as the business has no intention of changing the company name in the near future). The company name provides a general representation of the business and an appropriate namespace for child domains within the forest. The company name is meaningful to employees and clients and makes the domain easily identifiable.
Several elements make up an Active Directory infrastructure. When you're planning for each element, different aspects of the business must be assessed to ensure that each element is implemented in a way that meets these business requirements. When you're designing a domain tree, one of the first things that must be done is an assessment of the business. When you're designing a domain structure, keep in mind that a single-domain model is simpler to implement and easier to administer than a multiple-domain model. There will definitely be times when a single-domain model is not suitable for a business, but only a thorough assessment of the business can determine whether a multiple-domain model is necessary.
Requirements for Multiple Domains
There are some instances in which a single domain will not meet the requirements of an organization. In other words, certain situations might result in the creation of multiple domains. If one of the requirements discussed in this section is met, consider implementing multiple domains.
Does the business want to maintain decentralized administration among its business units or geographical locations? If the business requires each division or geographical location to be responsible for its own administration, multiple domains might need to be created.
Is there a need to maintain a distinct administrative boundary between different areas within the business? If so, multiple domains should be considered. Domains determine both the security and administrative boundaries within an Active Directory hierarchy. When multiple domains are created in a forest, the Domain Admins group within each domain has privileges only within its own domain unless permissions to another domain are explicitly granted.
Does the business require multiple security policies? Remember that in an Active Directory hierarchy, the domain is the security boundary. In some cases, a single security policy can meet the security needs of an entire business. For cases in which a company has to create multiple security policies for different areas within the business, a multiple-domain structure is needed.
Does the business have subsidiaries that need to maintain separate and distinct namespaces? For those businesses that have established partnerships and need to be included in the Active Directory structure, a multiple-domain structure is necessary, especially if a separate namespace is required.
Does the physical structure of the current network present a need for multiple domains? Replication within a domain occurs between all domain controllers. If there are locations within a business that are connected by physical links that are slow or unreliable, multiple domains can be created to optimize replication.
Be sure that you understand when to create multiple domains. You're likely to encounter exams questions in which you must decide whether to implement a single domain or multiple domains based on a specific scenario.
Planning Domain Trees
So far, we've been talking about creating a single forest with a single tree. However, there could also be instances in which you need to create multiple trees within a single forest. To create a domain structure that meets the business requirements, it's crucial that you first have a thorough understanding of how certain operations occur between domains (certain operations that occur within a domain might occur differently between domains). When you're planning domain trees, an understanding of the following topics is necessary:
Accessing resources between domains
Authentication across domains
Types of trust relationships
Creating an empty root domain
Accessing Resources Between Domains
Windows Server 2003 provides support for the Kerberos version 5 protocol (an industry-supported authentication protocol), which is responsible for the authentication of users across domains. One of the features of the Kerberos version 5 protocol is transitive trusts. In a multiple-domain structure, two-way transitive trusts are automatically configured between parent and child domains within a forest. This enables users to be granted permissions to resources throughout the forest. When a user attempts to access a resource located within another domain in the forest, the transitive trust path is followed.
Authentication Across Domains
Authentication is the process of confirming the identity of the user attempting to gain access to network resources. Before a user in one domain can access resources in another domain within the forest, that user must be authenticated. As already mentioned, the Kerberos version 5 protocol is responsible for authentication across domains. Because support is included for this industry-standard security protocol, users need only provide a single username and password at logon to gain access to resources throughout the forest.
Before a user is granted access to resources in another domain, the key distribution center (KDC) from each domain in the trust path must first authenticate the user. The KDC has two roles: It is responsible for authenticating users and for issuing session tickets to users so that they can identify themselves to other domains.
Types of Trust Relationships
Three types of trust relationships can be implemented in Windows Server 2003 to enable users to gain access to resources located in other domains: transitive, shortcut, and external trusts. Transitive trusts are automatically established, whereas shortcut and external trusts must be explicitly defined. Within a single forest, no trust relationships have to be explicitly defined. This is due to the fact that two-way transitive trusts are automatically established between parent domains and child domains, thereby creating a trust path throughout the forest. Shortcut trusts can be established between two domains to shorten the trust path. However, the trust exists between only the specified domains.
Creating an Empty Root Domain
In an Active Directory hierarchy where there are multiple domains, the design team might choose to create an empty forest root domain. That domain would not contain any OUs, and the only users in the domain would be the members of the Enterprise Admins group. The empty forest root domain establishes the namespace that will be inherited by child domains (see Figure 3.2). Creating an empty forest root domain would be appropriate for a business that wants to maintain a contiguous namespace throughout the organization and allow for decentralized administration.
Now that you've familiarized yourself with how some of the operations occur within a multiple-domain structure, let's take a look at some of the guidelines that you must consider when designing multiple domains.Figure 3.2 A forest root domain with its child domains.
Domain Design Issues
When planning a multiple-domain structure, keep the following design issues in mind:
WAN or LAN bandwidth constraints
One of the reasons why a multiple-domain structure might be created is to meet the security requirements of a business. If the business implements decentralized administration and needs to maintain a distinct security boundary between its different business units, a multiple-domain structure should be established. Creating a separate domain within the forest for each business unit allows each business unit to maintain its own administration.
If the different locations or departments within a business have different security needs (such as password requirements) or if a single security policy for the entire organization cannot be agreed upon, multiple domains might have to be created. That way, the administrators from each domain can establish security policies that meet their specific requirements.
Also keep in mind that the more domains you create, the more Domain Admins groups there are to monitor. This adds administrative overhead and might become difficult to track (especially for security purposes).
WAN or LAN Constraints
Replication is based on the multi-master replication model. All domain controllers within a domain are equal and all maintain an up-to-date working copy of the directory database. That means there will be more replication traffic within a domain (as opposed to between domains) because any changes made to the directory will be replicated throughout the domain to all domain controllers.
Also keep in mind that every attribute associated with an object is replicated throughout the domain, which adds to network traffic. On the other hand, only certain attributes are replicated to Global Catalog servers in other domains.
The point of this discussion is that if there are LAN or WAN links within the organization that are slow, unreliable, or already heavily used, they might not be able to support the amount of replication traffic that will be generated within a domain. In cases such as this, multiple domains must be created to optimize replication.
The use of site links within a single domain can also provide the same control over replication as creating multiple domains.
In today's world of enterprise networks that span different countries, there might be legal issues to consider when planning domains that could result in the implementation of a multiple-domain structure. For example, a business that has an international presence might be required to maintain separate domains for its overseas locations. An organization might need to keep employee information for its European subsidiaries separate from U.S. employees because the European Union has much more stringent confidentiality requirements than the United States. To meet the security requirements of different countries, separate domains would have to be created.
If there is a need to create different security configurations for different groups of users and computers throughout the business, it might be necessary to create more than one domain. Only a thorough assessment of a business's security requirements can determine whether more than one domain will be needed. The following are some security options set on a domain basis:
Password policyPassword policies determine the requirements for user passwords, such as a minimum password length.
Account lockout policyAn account lockout policy determines the guideline for locking a user account out of the system.
Kerberos policyA Kerberos policy determines the settings pertaining to Kerberos security, such as session ticket expiration time.
A forest is established when the first Active Directory domain is created; this domain is known as the forest root. Within a forest, any domains that share a contiguous namespace form a tree (see Figure 3.3). After a tree has been established within a forest, any new domain added to an existing tree inherits a portion of its namespace from its parent domain. Any domain that is added to the forest and maintains a unique namespace forms a new tree. Therefore, it's possible to have more than one tree within a single forest, and there might be instances in which multiple trees are required to meet the needs of a business.Figure 3.3 A multiple tree forest.
Remember that when you're planning a domain structure, simplicity is always best. If a business does not require multiple trees, don't make things more difficult by creating an elaborate multiple-tree structure. However, there will be instances when multiple trees are required. Again, only a thorough assessment of the business can determine whether this is necessary. When considering a multiple-tree structure, keep the requirements discussed in the following subsections in mind. If a business requires any one of the following, you might need to design a multiple-tree structure.
If a business is comprised of different subsidiaries or has partnered with other businesses that need to maintain their distinct public identities as well as separate (noncontiguous) DNS names, multiple trees might have to be created within a single forest.
If an organization has subsidiaries with unique DNS domain names, the organization can create a domain tree for each namespace to maintain the subsidiaries' individual DNS identification.
Central Directory Information
All trees within a single forest share the same schema, configuration container, and Global Catalog. If an organization wants to have centralized administration of these and maintain a single schema, configuration container, and Global Catalog for the entire organization and all its business units, a single forest with multiple trees can be implemented.
One of the nice features of being able to create a distinction between business units while keeping them within the same forest is that users within different trees can still easily search for objects forest-wide because all objects share a common Global Catalog.
Trusts Between Trees
When a new tree is established within a forest, a two-way transitive trust is automatically established between the two root domains. This two-way trust creates a trust path that enables users from one tree to access resources located within another tree in the same forest. The really nice thing about this is that a path is created throughout the Active Directory hierarchy without any administrative effort.
Creating the Conceptual Design of the Organizational Unit Structure
The OU structure that is designed should reflect the administrative needs of the business. The OU structure is irrelevant to the regular users within the businessit is created for the purpose of administration. The design should enable administrators to easily delegate control over groups of objects to the appropriate user or group. The OU hierarchy should also allow for the linking of group policies. The following topics are covered in this section:
Starting with administrative requirements
Tailoring for group policy application
Starting with Administrative Requirements
When you're creating an OU structure, remember that it must meet the needs of administration (this cannot be emphasized enough). The structure you design should be based on the administrative model that the business implements. The OU structure should allow the business to continue to delegate authority and distribute administrative tasks in a way that meets its needs.
As the OU structure is being designed, keep in mind that the upper layers of the hierarchy are based on the model for administration. If the design team determines that a model based on geographical location is needed for administration, the upper layers of the OU hierarchy will reflect this model.
Be sure to base the structure of the upper layers of the OU hierarchy on something that will remain static (for example, geographic location as opposed to department or business unit). Doing so will help to avoid a reorganization of the Active Directory hierarchy in the future.
The lower levels within the OU hierarchy should be created with specific administrative tasks in mind; in other words, what types of objects will users and groups be responsible for administering? How can these objects be grouped to allow for this administration? For example, if a group is to be responsible for printer administration within its location, an OU could be created for printer objects and delegation of authority can be assigned to that group. By nesting OUs within one another, you can create an OU structure that meets the specific administrative requirements of the business.
Although nesting OUs is a good thing, the hierarchy can become difficult to administer and troubleshoot if it is too deep.
After you've determined that the administrative requirements have been met by the OU structure, you also need to determine how it will be affected by the application of group policies.
Tailoring for Group Policy
Group Policy is used to administer the computing environment of users and computers within a business (which is further discussed in Chapter 4, "Creating the Logical Design for an Active Directory Infrastructure"). A Group Policy object can be linked to different levels within the Active Directory hierarchy, and the level at which it is linked determines the scope of the policy. Group policies are most commonly linked to the OU level because doing so provides administrators with the most control over the computing environment and allows for the delegation of authority to users and groups, thus eliminating the need to give them administrative privileges at the domain level.
The lower levels of the OU hierarchy should enable administrators to apply specific group policies to the necessary objects. For example, if a group policy needs to be applied to a group of specific users, a lower-level OU could be created for this group and linked to the appropriate group policy.
Remember that GPOs are applied from the top level down, and if the OU structure is too deep with GPOs at different levels, it might result in poor network performance. However, it is the number of GPOs, not the OU depth, that affects logon times.