Designing the Active Directory Structure
Designing the Active Directory Structure |
|
To determine the number of domains that you will have in each forest, start by considering a single domain only, even if you currently have more than one Windows NT 4.0 domain. Next, provide a detailed justification for each additional domain. Every domain that you create will introduce some incremental cost in terms of additional management overhead. For that reason, be certain that the domains you add to a forest serve a beneficial purpose.
Some of the factors that lead to the creation of multiple domain environments in previous versions of Windows NT Server no longer apply to Active Directory and Windows 2000. These factors are as follows:
Security Accounts Manager (SAM) Size Limitations In previous versions of Microsoft® Windows NT® Server, the SAM database had a practical limitation of about 40,000 objects per domain. Active Directory can scale easily to millions of objects per domain. It should never be necessary to create additional domains in order to handle more objects.
Primary Domain Controller (PDC) Availability Requirements In previous versions of Windows NT Server, only a single domain controller, the PDC, could accept updates to the domain database. In an organization with a large network, this limitation made it difficult to ensure high availability of the PDC, because a network outage could prevent administrators on one part of the network from being able to update the domain. To satisfy the availability requirement, you created additional domains so that PDC servers could be distributed throughout the network. This is no longer necessary in Windows 2000, because all Active Directory domain controllers can accept updates.
Limited Delegation of Administration Within a Domain In previous versions of Windows NT Server, you delegated administration using built-in local groups such as the Account Operators group, or by creating multiple domains and having distinct sets of domain administrators. For example, to delegate the management of a set of users, you created a new user domain. To delegate management of resource servers like file or print servers, you created resource domains. In Windows 2000, it is possible to delegate administration within a domain using organizational units (OUs). An OU is a container that you use to organize objects within a domain into logical administrative subgroups. OUs are easier to create, delete, move, and modify than domains, and they are better suited to the delegation role.
For more information about using OUs to delegate administration, see "Creating an Organizational Unit Plan" later in this chapter.
Three possible reasons for creating additional domains are:
If you already have Windows NT domains in place today, you might prefer to keep them as they are instead of consolidating them into a smaller number of Active Directory domains. If you decide to keep or consolidate a domain, be sure to weigh those costs against the long-term benefits of having fewer domains. The costs associated with domain consolidation are discussed in the chapter "Determining Domain Migration Strategies" in this book. If this is your first time through domain design, it is recommended that you aim for the fewest domains possible, and reevaluate this plan after reading that chapter.
More domains might be necessary depending on the administrative and policy requirements of your organization, described as follows.
Unique domain user security policy requirements You might want to have a set of users on your network abide by a domain user security policy that is different from the security policy applied to the rest of the user community. For example, you might want your administrators to have a stronger password policy, such as a shorter password change interval, than the regular users on your network. To do this, you must place those users in a separate domain.
Division requires autonomous domain administration supervision The members of the domain administrators group in a particular domain have complete control over all objects in that domain. If you have a subdivision in your organization that will not allow outside administrators control over their objects, place those objects in a separate domain. For example, for legal reasons, it might not be prudent for a subdivision of an organization that works on highly sensitive projects to accept domain supervision from a higher level IT group. Remember that all domains in the forest must share the Configuration and Schema containers.
Physical partitioning involves taking the domains you have in a forest and dividing them up into a greater number of smaller domains. Having a greater number of smaller domains allows you to optimize replication traffic by only replicating objects to places where they are most relevant. For example, in a forest containing a single domain, every object in the forest is replicated to every domain controller in the forest. This might lead to objects being replicated to places where they are rarely used, which is an inefficient use of bandwidth. For example, a user that always logs on at a headquarters location does not need their user account replicated to a branch office location. Replication traffic can be avoided by creating a separate domain for the headquarters location and not replicating that domain to the branch office.
Note
If you have already deployed Windows NT 4.0 domains, you might be satisfied with your existing physical partitioning. Looking at partitioning again from a clean sheet can help you identify areas for possible domain consolidation. If you have already decided to upgrade your Windows NT 4.0 domains in place and not perform any consolidation, you can skip the partitioning discussion.
To determine if, and how, to partition a forest, you should:
Begin by drawing a basic network topology diagram. Later in the planning process you will add more detail to this diagram when you plan your site topology. To create the topology diagram:
A site is a network of fast, reliable connectivity. A local area network (LAN) or set of LANs connected by a high-speed backbone can be considered a site. Draw each site on your network diagram and indicate the approximate number of users at the site.
A site link is a slow or unreliable link that connects two sites. A wide area network (WAN) that connects two fast networks is an example of a site link. It is recommended you treat any link that is slower than LAN speed as a slow link. On the topology diagram, show how each site connects to other sites with site links.
For each site link, record the following:
If you have a site that has no physical connection to the rest of your network but can be reached via Simple Mail Transfer Protocol (SMTP) mail, mark that site as having mail-based connectivity only.
Figure 9.3 shows the network topology for the fictitious Reskit company.
Figure 9.3 Reskit Company Network Topology
The availability of Active Directory is determined by the availability of domain controllers. Domain controllers must be available so that users can be authenticated. In this step, you will determine where you need to place domain controllers to maintain availability in case of possible network outages.
To place domain controllers, use the following process:
You can select the home site arbitrarily. For example, use your headquarters location, the site with the largest number of users, or the site with the best overall connectivity to the rest of your network. All the users in the home site will authenticate with this domain controller. Ignore for now the question of what domain is being serviced by that domain controller, and how many replicas of that domain will be necessary in the site.
Or, instead of placing a domain controller in that site, determine if users in that site can authenticate over the site link back to the domain controller in the home site. If it is acceptable to you that authentication fails when the site link fails, then you do not need to place a domain controller into the site.
For small branch offices that have client computers but no servers, a domain controller is not necessary. If the link back to the central site fails, users in the office will still be able to log on to their computers using cached credentials. Further authentication is unnecessary because there are no other server-based resources to access in the office — all of the resources are back at the central site.
You should put a domain controller into the site if:
Apply the same process to the next adjacent site, until you have visited every site and determined whether or not a local domain controller is necessary.
Note
Domain controllers contain security-sensitive information, such as copies of users' secret keys used for domain authentication. Having fewer copies of this information reduces the opportunities for unauthorized access. Domain controllers must be physically secure from unauthorized access. For example, it is recommended that domain controllers be located in a locked room with limited access. Physical access can allow an intruder to obtain copies of encrypted password data to use for an off-line password attack. Stronger security options are available using the Syskey tool. For more information about Syskey, see "Encrypting File System"in the Distributed Systems Guide.
When a user logs on, the domain controller servicing the authentication request must be able to communicate with a global catalog server. When you decide to place a domain controller in a site, you need to also consider that domain controller as a global catalog server. As you proceed, keep in mind that global catalog servers generate more replication traffic than regular domain controllers. They contain both a complete copy of one domain and a read-only partial copy of every other domain in the forest.
Figure 9.4 shows the domain controller placement for the Reskit company.
Figure 9.4 Reskit Company Domain Controller Placement
Now you will assign a domain to each domain controller, determine if your network can handle the replication traffic, and partition your forest into smaller domains if necessary. While doing this, remember that the objective of partitioning is to put physical copies of directory objects near the users that need those objects. For example, a user's user account object needs to be located on a domain controller that is in the same site as the user.
To partition the forest, perform the following steps for each domain currently in the domain plan:
Consider these factors when deciding whether or not to replicate a domain between sites, or to split it into two or more smaller domains:
The actual capacity of a site link is a function of link speed, daily usage characteristics, reliability, and availability. Consider the following information about a link when deciding whether to create a domain:
For more information about network capacity planning and Active Directory replication traffic, see the Microsoft Windows 2000 Server link on the Web Resources page at http://windows.microsoft.com/windows2000/reskit/webresources.
Interrupting or delaying business-critical traffic might be much more costly than adding an additional domain.
When a link is pay-by-usage, minimizing usage will minimize your costs.
Active Directory mail-based replication can only occur between domains. Mail-based replication cannot be used between domain controllers of the same domain.
If you do decide to split a large domain into several smaller domains, a good strategy for creating the smaller domains is to base them on geography or geo-political boundaries. For example, create domains that map to countries, regions or continents. Geographical mapping for domains is recommended because network topologies tend to map to geographical locations, and geography tends to change less than any other basis for divisions.
You might want to create a greater number of smaller domains simply to optimize replication traffic on your network. Remember, optimization is a tradeoff against other factors, such as:
As discussed earlier, each additional domain introduces a fixed on-going management overhead.
The fewer the number of objects in a domain, the more likely a user in that domain will want to access objects that are in some other domain. If there is no local domain controller for the other domain, the query will cause traffic to leave the site.
Note
A model with a single large domain works best with a large roaming user population because every user account will be available in every site that has a domain controller. In this case, a roaming user will never lose the ability to log on if a network outage occurs between the user's current location and home location.
Figure 9.5 shows the physical partitioning for the Reskit company. The domain assignments are as follows:
Figure 9.5 Reskit Company Domain Assignment
Each domain in the forest will introduce some amount of management overhead. When debating whether or not to add a domain to your domain plan, weigh the following costs against the benefits you determined earlier in the chapter.
More Domain Administrators Because domain administrators have full control over a domain, the membership of the domain administrators group for a domain must be closely monitored. Each added domain in a forest incurs this management overhead.
More Domain Controller Hardware In Windows 2000, a domain controller can host only a single domain. Each new domain that you create will require at least one computer, and in most cases will require two computers to meet reliability and availability requirements. Because all Windows 2000 domain controllers can accept and originate changes, you must physically guard them more carefully than you did Windows NT 4.0 backup domain controllers (BDCs), which were read-only computers. Note that the administration delegation within Active Directory domains reduces the requirement for resource domains. Some remote locations that currently must host two domain controllers (a master user domain and a local resource domain) will now only require one domain controller if you choose to consolidate to fewer Active Directory domains.
More Trust Links For a domain controller in one domain to authenticate a user from another domain, it must be able to contact a domain controller within the second domain. This communication represents an added possible point of failure if, for example, the network between the two domain controllers is malfunctioning at the time. The more users and resources located in a single domain, the less an individual domain controller must rely on being able to communicate with other domain controllers to maintain service.
Greater Chance of Having to Move a Security Principal Between Domains The more domains you have, the greater the chance you have to move security principals, such as users and groups, between two domains. For example, a business reorganization or a job change for a user can create the need to move a user between domains. To end users and administrators, moving a security principal between OUs inside a domain is a trivial and transparent operation. However, moving a security principal between domains is more involved and can impact the end user.
For more information about moving security principals between domains, see "Determining Domain Migration Strategies" in this book.
Group Policy and Access Control Do Not Flow Between Domains Group Policy and access control applied within a domain do not flow automatically into other domains. If you have policies or delegated administration through access control that is uniform across many domains, they must be applied separately to each domain.
