Windows Server 2003 on HP ProLiant Servers : Logical Structure Design (part 2) - Forest Structure, OU Structure

2. Forest Structure

Just as there are business and technical reasons for creating a single- or multiple-domain forest, there are also reasons to create a single- or multiple-forest AD infrastructure enterprise. Some say AD domains are security boundaries just like they were in Windows NT, and in a very limited sense they are; for example, for defining password policies. However, it is well known today that the true security boundary is at the forest level. In the beginning of Windows 2000 deployments, there were few multiforest deployments. However, a number of multiforest environments exist today and there are good reasons to employ such a structure. It was noted in the discussion on domain design that you should start with a single domain and prove you need more. This rule is even more important in regard to designing the forests.

Although there are many issues to consider in the single versus multiple domain debate, there are only a few when deciding whether you should use a multiple forest environment. It basically comes down to two issues: political and security. Microsoft defined the security issue with the following statement (from “Using the Organization Forest Domain Model” Web site article):

“Domain owners have authority over the entire domain, as well as access to all other domains in the forest. For this reason, domain owners must be trusted individuals selected by the forest owner...Keep in mind that if a forest owner delegates domain-level service management to a domain owner, then other groups might choose not to join that forest if they do not trust that domain owner. All domain owners must be aware that if any of these conditions change in the future, it might become necessary to migrate the organizational domains into a multiple forest deployment.”

This statement describes the importance of trust in those who are domain Administrators and the important security rights they have in the forest. It also points out that if others in the organization do not trust a domain Administrator, it may be cause for creating a separate forest. One government official I talked to several years ago was configuring a test environment to prove he could control security of data in a single domain. Because the implementation of Windows 2000 involved several government departments, if he lost his case, it could mean the creation of about 20 forests.

In addition to security reasons, there can be political, business, or even legal reasons to deploy a multiple-forest enterprise. In analyzing these reasons, perhaps it's easiest to outline the negative impact of multiple forests. The strongest arguments against a multiple forest deployment are administration and implementation of Exchange.

A good example of resolving the multiple forest issue is demonstrated in an AD design project I was involved in. This was a fairly small company that included an autonomous business unit. One business unit, we'll call it ABC, had a legal requirement to be separated from the rest of the company.

It seemed after the assessment, that the rest of the company could adopt a single domain in a forest. However, an engineering division had operated Windows NT domains independently of the IT department. The IT department managed the Windows NT environment for the rest of the company. The research division was lobbying for a multiple-forest environment to retain this autonomy, making an enterprise of three forests, all running on the same physical network. The IT Administrators, however, wanted only one additional forest in addition to the ABC forest. This discussion became very political, and my partner and I were asked to make a presentation to describe the pros and cons of a multiple-forest deployment. The reasons to have multiple forests include

• Maintain absolute security autonomy: The forest is a definite security boundary. However, a trust can be built to allow one or more groups or users access to resources in another forest. This really boils down to the use of the enterprise Admin account, which cannot be restricted from any domain in the forest, although there are certain rights it doesn't have. If no account can have access across certain domains, then multiple forests are required.

• Business autonomy: Business requirements might be such that data and security must be separated as though they were separate companies. One company had seven forests—one for each business unit. A holding company might employ a multiple forest structure for this reason.

• Administrative autonomy: As Microsoft noted in the article we quoted previously, Administrators that are not trusted by other domains can lead to multiple forests. Note that you should work this out rather than make multiple forests. This would have to be a very serious issue to justify the added cost of another forest.

• Business partner relationship: Perhaps you have a business partner that you want to share data with. Establishing a separate forest and controlling access via trusts would ensure security for each company.

• External Web farms in a Demilitarized Zone (DMZ): Many companies deploy Web farms that exist in a DMZ for security. In addition, it's difficult to replicate through a firewall, thus making a separate forest desirable.

When analyzing the reasons to deploy a multiple-forest structure, weigh the negative aspects associated with multiple forests, as noted in Table 2.

After presenting these issues to technical and managerial participants in the meeting, they kept pressing me to boil it down further. After reviewing their business and political environment, I decided it came down to two issues: the role of the Enterprise Admin and Exchange. Members of the enterprise Admins group cannot be locked out from any domain. This was a political concern because the research department Admins didn't trust the IT folks and vice-versa. They didn't want the other Admins in their data—a basic issue of trust as Microsoft's statement previously cited notes. Exchange was an issue because the company, including the ABC business unit, wanted to appear as a single organization. All employees should have a “User@company.com” e-mail address. Because Exchange uses the GC as the Global Address List (GAL), you can't have an organization spanning forests without synchronizing AD objects between the forests. It is possible to accomplish this by giving users in multiple forests a single e-mail address by the use of Simple Mail Transfer Protocol (SMTP) forwarding, but synching up contacts, calendar, and free/busy information is a huge challenge.

Gathering all the interested parties together, I presented these two issues as those that needed to be decided to resolve the question of whether the research department should have its own forest or simply an OU in the company's root domain. In regard to the enterprise Admin issue, it came to an issue of trust that should be controlled by company policy. Anyone who had enterprise Admin privilege should be required to abide by company policies that detail proper conduct and use of that authority. If they don't abide by that policy and if you can't control your employees, that's a management problem—not Windows. I then had an Exchange expert—Don Livengood,explain what was involved in getting Exchange to work across three forests—the administrative overhead and difficulty in keeping calendaring and free/busy data in sync. Recognizing e-mail functions as a mission-critical application, one Administrator said, “I think people wouldn't mind a power outage if they could get to their e-mail.” This discussion ended in a decision to adopt a single forest, single domain for these organizations. The point is that making the right decision took identifying the reasons not to adopt a multiple forest enterprise, getting all the parties together to discuss it, and urging them to do what is best for the company.

Although the company's reason for wanting multiple forests was to ensure division of administrative duties, this can be a reason for other enterprises not to go to multiple forests. This requires some fairly complex security group organization if you have Administrators who must have domain Admin or enterprise Admin rights in more than one forest.

3. OU Structure

The OU, of course, is an excellent alternative to multiple domains. Microsoft recommends using OUs to create directory partition structures for changeable entities. For instance, rather than making domains for Engineering, HR, Executive, Finance, and Program offices, OUs are a better solution because these names can change. Figure 9 compares a domain-based and an OU-based implementation. Although Windows Server 2003 has Domain Rename capability, it isn't trivial and there are still a lot of unresolved issues concerning application support. Building OUs allows not only flexibility of rename and restructure, but also requires no additional hardware for new DCs. Also, moving objects between OUs is much easier than between domains. Movement of users across domains requires tools such as Microsoft's Active Directory Migration Tool (ADMT), LDIFDE, or movetree.exe. Movement between OUs can be done in the AD Users and Computers GUI (Graphical User Interface).

In designing an OU structure, although there are no real design rules, some best practices have been developed from experienced AD designers. The structure really is determined by whether your focus is on Group Policy or administration. Most likely, you will need to consider both in your own design.

Group Policy-Based OUs

One common structure (and similar to that used by HP) that you might consider using is to divide up the first-level OU structure into users and computers. This is a Group Policy-based approach. Because policy is partitioned into user and computer settings, and you can actually limit a Group Policy Object (GPO) to apply only computer or user settings, OUs divided in this way make sense. Figure 10 shows an example of how a three-tier OU structure based on policy might be structured. Note that the first level has OUs titled Servers, Workstations, Printers, and Users. The second level further divides users into Sales, Manufacturing, Engineering, and IT staff. The second level under the Servers OU includes File/Print, Systems Management Services (SMS), and DHCP/WINS (Windows Internet Name Service). Similarly, you could subdivide the printers and workstations OUs, or leave them as single-level OUs. The Manufacturing OU contains a third-level OU structure that divides the Manufacturing users into geographies of North and South America and Canada. This demonstrates the flexibility of the OU structure. Some OUs need be only one level deep, some can be two, and others three or more.

Administration-Based OUs

An administration-based OU's model is primarily based on the requirements of a company for the delegation of administrative rights. The structure would look something like that shown in Figure 11. This is almost the reverse of the Group Policy-based structure. Here, you have the geography-based OUs at the top of the structure, the computer- and user-based OUs at the second level, and the subdivisions of those OUs (such as that shown for the Servers OU) on the third level. Obviously this would work if your Administrators were organized by geography. If organized by business unit, you could replace the geography OUs with business unit names.

In working with the Qtest Windows 2000 testing environment at HP (originally created at Compaq), I decided to create an OU structure for the QAmericas domain and struggled through several designs. During this exercise, I decided that the most important thing in this environment was administration. Administrators were scattered throughout North and South America. I needed an OU structure that was conducive to permitting Administrators to get to all resources in their geography. Imagine the nightmare if I used the Group Policy-based structure. My Administrators' accounts would reside in the geographies—the third tier in the structure. But there would potentially be more geography-based OUs at that level requiring some interesting delegation so that each South American Admin could manage South American resources. However, if I apply the administration-based structure shown in Figure 5.11, all the South American resources are under the South America OU. I can put the South American Admin accounts in that OU, or perhaps put them in a child OU, and delegate rights appropri ately. It's really amazing as you look at different structures and review your business needs, how the solution eventually presents itself to you.

OU Depth

The depth of the OU tree is really governed only by the Group Policy structure that affects logon performance and what you can live with. Microsoft published data for Windows 2000 that specified that each GPO applied to a user-generated 58K, and each GPO applied to a computer-generated 72K of traffic. On startup and logon, each policy is copied from the DC to the workstation. Thus, the more policies that apply to the user, the longer it takes to log on. Note that a user is penalized only for the GPOs that apply to the user—not the total GPOs defined in the domain. This is actually predictable.

A good example of an OU design exercise was a large, global enterprise based in Atlanta that had already determined that its OU structure was to be six levels deep when I was asked to review the design. The interesting thing was that all of the objects—users, computers, printers, and so on—were in the sixth-level OU. The other OU levels contained only groups and were designed to look like the business organization.

Concerned about this, I convinced my coworkers that we should review the structure. We locked ourselves in a conference room for about three hours one day and drew all possible OU structures—basically iterations of the Group Policy- and administration-based structures discussed in this section previously. As we drew the structures on the whiteboard, we tried to fit the company's administration model into them. Finally it was evident that the only way to meet the business needs of the administration model the company wanted was to implement the six-layer OU model. I was satisfied with that because we challenged the model and proved it was the best solution.

Note that if we had taken the rule of thumb of not going more than three levels deep, we would not have arrived at the best solution. In addition, this six-level structure didn't impact the logon performance more than if it had been a single-level structure because the number of GPOs would be the same. If you want to reduce the logon time, you reduce the GPOs or groups, not the OUs.

Default and Special-Purpose OUs

By default, one OU is created during AD installation: the DC's OU. This OU, by default, houses all DCs and contains a Default Domain Controller (DDC) GPO. Although you can move DCs to any OU you want to, I don't recommend it. DC security policy is really in its own world, even by Microsoft's standards. Moving DCs out of the DDC's OU and changing the DDC's policy is adding a degree of uncertainty to the environment. If you run into security issues in the future, you should first ask whether it's because the DCs are not in the DDC OU. There might be valid reasons to do this, but make sure it's critical enough to pay the potential price.