Lesson 1: Planning Active Directory Implementation
Active Directory provides methods for designing a directory structure that meet the needs of your organization. Before implementing Active Directory you must examine your organization's business structure and operations and plan the domain structure, domain namespace, OU structure, and site structure needed by your organization. With the flexibility of Active Directory, you can create the network structure that best fits your company's needs. This lesson walks you through the steps of planning an Active Directory implementation.
After this lesson, you will be able to
Plan a domain structure
Plan a domain namespace
Plan an OU structure
Plan a site structure
Estimated lesson time: 35 minutes
Because the core unit of logical structure in Active Directory is the domain, which can store millions of objects, it is essential to plan the domain structure for your company carefully. When planning a domain structure, you must assess your company's
Logical and physical environment structure
Administrative requirements
Domain requirements
Domain organization needs
Assessing the Logical Environment
You must understand how your company conducts daily operations to determine the logical structure of your organization. Consider how the company operates functionally and geographically. For example, Figure 4.1 shows fictitious functional and geographical divisions for Microsoft. Functionally, Microsoft operates through its Administration, Purchasing, Sales, and Distribution departments. Geographically, Microsoft has offices in Kansas City, St. Paul, Chicago, and Columbus.
Figure 4.1 Functional and geographical divisions for Microsoft
Assessing the Physical Environment
By assessing your company's physical environment, you can determine the technical requirements for implementing Active Directory. Although you've already examined geographical locations, you must now consider your company's user and network requirements so you can determine the logical requirements for implementing Active Directory.
To assess user requirements, for each functional and geographical division determine
The number of employees
The growth rate
Plans for expansion
To assess network requirements, for each geographical division determine
How network connections are organized
Network connection speed
How network connections are utilized
TCP/IP subnets
For example, Figure 4.2 shows the physical environment for Microsoft. Employees are distributed fairly evenly among the four locations. However, among the functional divisions, more employees are employed in the Administration department. In the next five years, growth for all locations and all departments is estimated at 3 percent. The Chicago office is the hub of the Microsoft wide area network (WAN). Network connections are utilized moderately; however, the Kansas City-to-Chicago connection has a high degree of utilization.
Figure 4.2 Physical environment for Microsoft
Assessing Administrative Requirements
Assessing how your company's network resources are managed also helps you to plan your domain structure. Identify the method of network administration used by your company:
Centralized administration. A single administrative team provides network services. Smaller companies with fewer locations or business functions often use this method.
Decentralized administration. A number of administrators or administrative teams provide network services. Teams may be divided by location or business function.
Customized administration. The administration of some resources is centralized and it is decentralized for others, depending on business needs.
In the example, Microsoft requires decentralized administration methods. Each location requires its own team of administrators to provide network services for all four functional divisions.
After you've determined the logical and physical environment structure and the administrative requirements for your company, you can begin to determine the need for a domain in your organization.
The easiest domain structure to administer is a single domain. When planning, you should start with a single domain and only add domains when the single domain model no longer meets your needs.
One domain can span multiple sites and contain millions of objects. Keep in mind that site and domain structures are separate and flexible. A single domain can span multiple geographical sites, and a single site can include users and computers belonging to multiple domains. Planning your site structure is covered later in this lesson.
You do not need to create separate domains merely to reflect your company's organization of divisions and departments. Within each domain, you can model your organization's management hierarchy for delegation or administration using OUs for this purpose, which will act as logical containers for other objects. You can then assign group policy and place users, groups, and computers into the OUs. Planning OU structure is covered later in this lesson.
The following are some reasons to create more than one domain:
Decentralized network administration
Replication control
Different password requirements between organizations
Massive numbers of objects
Different Internet domain names
International requirements
Internal political requirements
In the example, Microsoft requires multiple domains for the following reasons:
Stricter password requirements exist at the Chicago office.
There is a need to control replication on the highly utilized Chicago-to-Kansas City network connection.
There are plans for adding a new office in Fargo, North Dakota within two years.
Assessing Domain Organization Needs
If you've determined that your company requires more than one domain, you must organize the domains into a hierarchy that fits the needs of your organization. You can arrange domains into a tree or a forest depending on the company's business needs. Recall that domains in trees and forests share the same configuration, schema, and global catalog. As domains are placed in a tree or forest hierarchy, the two-way transitive trust relationship allows the domains to share resources.
The primary difference between domain trees and forests is in their Domain Name Service (DNS) name structure. All domains in a domain tree have a contiguous DNS namespace. Unless your organization operates as a group of several entities, such as a partnership or conglomerate, your network probably lends itself to a contiguous DNS namespace, and you should set up multiple domains in a single domain tree. If you need to combine organizations with unique domain names, create a forest. You can also use a forest to separate DNS zones. Each tree in the forest has its own unique namespace.
In the example, the Microsoft organizational structure maps to a group of domains in a domain tree. Microsoft is not a part of any other entity, nor are there any known plans for creating multiple entities in the future.
In Windows 2000 Active Directory, domains are named with DNS names. But before you begin using DNS on your network, you must plan your DNS namespace. You must make some decisions about how you intend to use DNS naming and what goals you are trying to accomplish using DNS. For instance:
Have you previously chosen and registered a DNS domain name for use on the Internet?
Will your company's internal Active Directory namespace be the same or different from its external Internet namespace?
What naming requirements and guidelines must you follow when choosing DNS domain names?
When setting up DNS servers, it is recommended that you first choose and register a unique parent DNS name that can be used for hosting your organization on the Internet. For example, Microsoft uses microsoft.com. This name is a second-level domain within one of the top-level domains used on the Internet.
Before you decide on a parent DNS name for your organization to use on the Internet, perform a search to see if the name is already registered to another entity. The Internet DNS namespace is currently managed by Network Solutions, Inc., though other domain name registrars are also available.
Once you have chosen your parent DNS name, you can combine this name with a location or organizational name used within your organization to form other subdomain names. For example, a subdomain added to the Microsoft second-level domain might be chicago, forming the namespace chicago.microsoft.com.
Internal and External Namespaces
To implement Active Directory, there are two choices for namespace design. The Active Directory namespace can either be the same or separate from the established, registered DNS namespace.
Same Internal and External Namespaces
In this scenario, the company uses the same name for the internal and external namespaces as shown in Figure 4.3. Microsoft.com is used both inside and outside of the company. To implement this scenario, the following requirements must be met:
Users on the company's internal, private network must be able to access both internal and external servers (both sides of the firewall).
Clients accessing resources from the outside must not be able to access internal company resources or resolve names to protect company data.
Figure 4.3 Same internal and external namespaces
For this scenario to work, two separate DNS zones must exist. One zone will exist outside the firewall, providing name resolution for public resources. This zone is not configured to resolve internal resources, thereby making internal company resources nonaccessible to external clients.
The challenge in this configuration is making publicly available resources accessible to internal clients, as the external DNS zone is not configured to resolve internal resources. One suggestion is to duplicate the external zone on an internal DNS for internal clients to resolve resources. If a proxy server is being used, the proxy client should be configured to treat microsoft.com as an internal resource.
The advantages to using the same internal and external namespaces are as follows:
The tree name, microsoft.com, is consistent both on the internal private network and on the external public Internet.
This scenario extends the idea of a single logon name to the public Internet, allowing users to use the same logon name both internally and externally. For example, jsmith@microsoft.com would serve as both the logon and e-mail ID.
The disadvantages to using the same internal and external namespaces are as follows:
It results in a more complex proxy configuration. Proxy clients must be configured to know the difference between internal and external resources.
Care must be taken not to publish internal resources on the external public Internet.
There will be duplication of efforts in managing resources; for example, maintaining duplicate zone records for internal and external name resolution.
Even though the namespace is the same, users will get a different view of internal and external resources.
Separate Internal and External Namespaces
In this scenario, the company uses separate internal and external namespaces as shown in Figure 4.4. Basically, the names will be different on either side of the firewall. Microsoft.com is the name that is used outside the firewall and msn.com is the name used inside the firewall.
Figure 4.4 Separate internal and external namespaces
Separate names are used inside and outside the corporation. Microsoft.com is the name that the Internet community sees and uses. Msn.com is the name that the private network sees and uses. To do this, two namespaces must be registered with the Internet DNS. The purpose of registering both names is to prevent duplication of the internal name by another public network. If the name were not reserved, internal clients would not be able to distinguish between the internal name and the publicly registered DNS namespace.
Two zones will be established. One zone will resolve microsoft.com and the other DNS zone will resolve msn.com on the inside of the firewall. Users can clearly distinguish between internal and external resources.
The advantages to using the separate internal and external namespaces are as follows:
Based on different domain names, the difference between internal and external resources is clear.
There is no overlap or duplication of effort, resulting in a more easily managed environment.
Configuration of proxy clients is simpler because exclusion lists only need to contain microsoft.com when identifying external resources.
The disadvantages to using the separate internal and external namespaces are as follows:
Logon names are different from e-mail names. For example, John Smith would log on as jsmith@msn.com and his e-mail address would be jsmith@microsoft.com.
Multiple names must be registered with an Internet DNS.
NOTE In this scenario, logon names are different by default. An administrator can use the MMC to change the user principal name (UPN) suffix properties of users so that the user logon will match the user e-mail address. However, this requires additional intervention.
Domain Naming Requirements and Guidelines
When you plan your company's domain namespace, consider the following domain naming requirements and guidelines for root domains and subdomains:
Select a root domain name that will remain static. Changing a root domain name may be impossible or costly in the future.
Use simple names. Simple and precise domain names are easier for users to remember and they enable users to search intuitively for resources.
Use standard DNS characters and Unicode characters. Windows 2000 supports the following standard DNS characters: A-Z, a-z, 0-9, and the hyphen (-), as defined in Request for Comment (RFC) 1035. The Unicode character set includes additional characters not found in the American Standard Code for Information Exchange (ASCII) character set, which are required for some languages other than English.
NOTE Use Unicode characters only if all servers running DNS service in your environment support Unicode. For more information on the Unicode character set, read RFC 2044, by searching for RFC 2044 with your Web browser.
Limit the number of domain levels. Typically, DNS host entries should be three or four levels down the DNS hierarchy and no more than five levels down the hierarchy. Multiple levels increase administrative tasks.
Use unique names. Each subdomain must have a unique name within its parent domain to ensure that the name is unique throughout the DNS namespace.
Avoid lengthy domain names. Domain names can be up to 63 characters, including the periods. The total length of the name cannot exceed 255 characters. Case-sensitive naming is not supported.
Taking into account the logical, physical, and administrative requirements, as well as the need for domains and domain organization, Figure 4.5 shows the domain structure for Microsoft. The company's root domain, microsoft.com, contains subdomains for its four offices.
Figure 4.5 Microsoft domain structure and domain names
After you determine your company's domain structure and plan its domain namespace, you must plan its OU structure. You can create a hierarchy of OUs in a domain. In a single domain, organize users and resources by using a hierarchy of OUs to reflect the structure of the company. OUs allow you to model your organization in a meaningful and manageable way and to assign an appropriate local authority as administrator at any hierarchical level.
Each domain can implement its own OU hierarchy. If your enterprise contains several domains, you can create OU structures within each domain, independent of the structures in the other domains.
Consider creating an OU if you want to do the following:
Reflect your company's structure and organization within a domain. Without OUs, all users are maintained and displayed in a single list, regardless of a user's department, location, or role.
Delegate administrative control over network resources, but maintain the ability to manage them. You can grant administrative permissions to users or groups of users at the OU level.
Accommodate potential changes in your company's organizational structure. You can reorganize users between OUs easily, whereas reorganizing users between domains generally requires more time and effort.
Group objects to allow administrators to locate similar network resources easily, to simplify security, and to perform any administrative tasks. For example, you could group all user accounts for temporary employees into an OU called TempEmployees.
Restrict visibility of network resources in Active Directory. Users can view only the objects for which they have access.
When planning an OU hierarchy, it's important to consider two main guidelines:
Although there are no restrictions on the depth of the OU hierarchy, a shallow hierarchy performs better than a deep one.
OUs should represent business structures that are not subject to change.
There are many ways to structure OUs for your company. It is important to determine what model will be used as a base for the OU hierarchy. Consider the following models for classifying OUs in the OU hierarchy:
Business function-based OUs can be created based on various business functions within the organization. A business function-based OU hierarchy for domain.com is shown in Figure 4.6. The top level of OUs—ADMIN, DEVELOPMENT (DEVEL), and SALES—corresponds to the company's business divisions. The second level of OUs represents the functional divisions within the business divisions.
Figure 4.6 A business function-based OU structure
Geographical-based OUs can be created based on the location of company offices. A geographical-based OU hierarchy for domain.com is shown in Figure 4.7. The top level of OUs—WEST, CENTRAL, and EAST—corresponds to the regions set up for the organization. The second level of OUs represents the physical locations of the company's eight offices.
Figure 4.7 A geographical-based OU structure
Business function and geographical-based OUs can be created based on both business function and the location of company offices. A business function and geographical-based OU hierarchy for domain.com is shown in Figure 4.8. The top level of OUs—NORTH AMERICA and EUROPE—corresponds to the continents on which the company has offices. The second level of OUs represents the functional divisions within the company.
Figure 4.8 A business and geographical-based OU structure
Recall that a site is part of the Active Directory physical structure and is a combination of one or more Internet Protocol (IP) subnets connected by a highly reliable and fast network connection. In Active Directory, site structure is concerned with the physical environment and is maintained separately from the logical environment, the domain structure. A single domain can include multiple sites, and a single site can include multiple domains or parts of multiple domains. The main role of a site is to provide good network connectivity.
The way in which you set up your sites affects Windows 2000 in two ways:
Workstation logon and authentication. When a user logs on, Windows 2000 will try to find a domain controller in the same site as the user's computer to service the user's logon request and subsequent requests for network information.
Directory replication. You can configure the schedule and path for replication of a domain's directory differently for inter-site replication, as opposed to replication within a site. Generally, you should set replication between sites to be less frequent than replication within a site.
Optimizing Workstation Logon Traffic
When planning sites, consider which domain controller(s) the workstations on a given subnet should use. To have a particular workstation only log on to a specific set of domain controllers, define the sites so that only those domain controllers are in the same subnet as that workstation.
Optimizing Directory Replication
When planning sites, consider where the domain controllers and the network connections between the domain controllers will be located. Because each domain controller must participate in directory replication with the other domain controllers in its domain, configure sites so that replication occurs at times and intervals that will not interfere with network performance. Consider establishing a bridgehead server to provide criteria for choosing which domain controller should be preferred as the recipient for inter-site replication.
Designing a site structure for a network that consists of a single local area network (LAN) is simple. Because local area connections are typically fast, the entire network can be a single site. Establish a separate site with its own domain controllers when you feel domain controllers are not responding fast enough to meet the needs of your users. Determining what is fast enough depends on your criteria for network performance. Inadequate performance is more common when deployments span a wide geographic range. Other inadequacies may be attributed to poor network design and implementation.
Follow these steps to design a site structure for an organization with multiple physical locations:
Assess the physical environment. Review the information you gathered when determining domain structure, including site locations, network speed, how network connections are organized, network connection speed, how network connections are utilized, and TCP/IP subnets.
Determine the physical locations that form domains. Determine which physical locations are involved in each domain.
Determine which areas of the network should be sites. If the network area requires workstation logon controls or directory replication, the area should be set up as a site.
Identify the physical links connecting sites. Identify the link types, speeds, and utilization that exist so the links can be determined as site link objects. A site link object contains the schedule that determines when replication can occur between the sites that it connects.
For each site link object, determine the cost and schedule. The lowest cost site link performs replication; determine the priority of each link by setting the cost (default cost is 100; lower cost provides a higher priority). Replication occurs every 3 hours by default; set the schedule according to your needs.
Provide redundancy by configuring a site link bridge. A site link bridge provides fault tolerance for replication.
NOTE For detailed information on configuring sites and inter-site replication, see Chapter 6, "Configuring Sites."
In this lesson you learned that before implementing Active Directory you must examine your organization's business structure and operations and plan the domain structure, domain namespace, OU structure, and site structure needed by your organization.
When planning a domain structure, you must assess your company's logical and physical environment structure, administrative requirements, need for multiple domains, and domain organization needs.
You also learned that you must make some decisions about how you intend to use DNS naming, including the use of previously chosen DNS domain names, and whether your company's internal Active Directory namespace will be the same or different from its external Internet namespace. You learned the naming requirements and guidelines you must follow when choosing DNS domain names.
You learned how OUs allow you to model your organization in a meaningful and manageable way and assign an appropriate local authority as administrator at any hierarchical level. You explored various ways to structure OUs for your company.
Finally, you learned how setting up sites affects Windows 2000 workstation logon traffic and directory replication. You learned about the steps necessary to design a site structure for an organization with multiple physical locations.