No decision is more important for Windows 2000 migration than the choice of a domain structure. The options range from one large domain to multiple independent forests, each including one or more separate domain trees. This document provides a brief description of the current ITSS proposal for organizing Windows 2000 domains at Stanford, followed by a description of why this approach was chosen.
ITSS proposes creating a single Windows 2000 domain tree for the Stanford campus containing two levels of domains. The root domain in this tree, win.stanford.edu, will be operated by ITSS. Below this domain will be other domains, one for each school, run by administrators assigned by that school. There will also be a miscellaneous domain, run by ITSS, containing Windows 2000 systems that don’t belong to any school domain. The basic idea of how this would look is shown in the figure below.
Each school domain will be divided into some number of Organizational Units (OUs). How many OUs each school domain has and what those OUs should be will be decided by each school. Each of those OUs may also have an administrator with partial or complete power over that OU. This decision will also be made by the domain administrator of each school domain. Creating subdomains below the school domains—sometimes called grandchild domains—will not be allowed.
The root domain will contain account objects for all single-sign-on (SSO) accounts that correspond with SUnet accounts. In other words, any Windows 2000 user in the tree who wishes to have an SSO account allowing Kerberos-based authentication to Windows 2000 resources anywhere in the tree and to resources in Stanford’s existing Kerberos realm will have an account in the root domain. Users who don’t need SSO accounts can have accounts in the domain for their school. Non-SSO accounts (or Accounts local to a child domain) will be controlled by domain and OU administrators for the domain in which they exist. Users can have both kinds of accounts.
Because the SSO accounts are in a single location in the top domain, management of them is a point of great interest. Critical account changes such as creation, deletion, password changes (and other pertinent fields already contained in Stanford.you) will be tied to an automated process linked to the existing sunet id process. ITSS administrators will be available to troubleshoot any problems with this process. Windows-centric account changes such as home directory location, profile location, and windows group membership will all be controlled by the administrator for the department defined in the sunet id's department field (as seen in Stanford.you). These windows administrators will associated with department groups during the initial process of joining the infrastructure.
ITSS has bought the domain controllers for the root domain and general domain for the tree, but applicable organizations will need to buy their own domain controllers for their own domain. All domain controllers in the tree will be kept in a secure physical location, and managed by ITSS. Domain and OU administrators for school domains will have administrative access to these machines, although they won’t have immediate physical access to them. Because the machines will be physically housed by ITSS, ITSS administrators will also need administrative access to all domain controllers.
There are many different ways to organize Windows 2000 domains. This section examines the pros and cons of the most important of these options, explaining why ITSS settled on the design proposed above.
One large domain
In general, a Windows 2000 domain structure should be as simple as possible. The simplest possible approach is to create just one domain. The benefits of doing this include the following:
· it’s the most straightforward design, requiring the least replication traffic and a minimum of administrative complexity;
· it requires the fewest domain administrators;
· it requires the fewest domain controllers;
· by creating OUs and OU-level administrators, it still allows administrative control at low levels in the domain—a domain administrator isn’t required to perform most tasks.
One large domain also has some important drawbacks, however, including these:
· domain administrators can always override OU administrators if they choose to, which means that ITSS administrators would ultimately have control of the domain;
· some Group Policy settings can only be controlled domain-wide, which means that those settings would need to be identical for the entire Stanford environment;
· trust relationships with domains not in the campus domain tree can only be created on a per-domain basis. If the entire campus were in a single domain, any group that wished to establish a trust relationship with another domain would be exposing all resources in the campus domain tree to that trust;
· some users will have only SSO accounts, some will have only local accounts in their domain, and some will have both. With only one domain, all of these accounts would need to have usernames that were unique throughout the domain. Yet suppose a user with a SUnet account wishes to also create an SSO account in this single domain. If a local account already exists with the same username, this won’t be possible. This kind of name collision would be bound to happen if the entire campus were contained in a single domain.
A small number of domains in a single domain tree
The next simplest structure is a root domain with some number of domains beneath it. The benefits of this approach include the following:
· it’s relatively simple, compared to any of the more complex choices described below;
· no all-powerful ITSS domain administrator exists with power over all domains. The domain administrator of the root domain does have complete power over the Active Directory tree, however, and as mentioned earlier, ITSS administrators would need some access to all domain controllers in the tree;
· trust can be established with a domain outside the Stanford tree without exposing the entire Stanford Windows 2000 community to the effects of that trust;
· all SSO accounts will be defined in the root domain, while local accounts will be defined in child domains. This minimizes the possibility for name collisions between the two.
The drawbacks of this approach include:
· it’s more complex than a single domain and creates more replication traffic;
· it requires more domain controllers than a single domain;
· it requires more domain administrators than a single domain;
· setting tree-wide Group Policies requires using site Group Policy Objects (GPOs) or replicated domain/OU GPOs;
· it’s not obvious how to define domains—who should get their own?
· if too many child domains are created, or if multiple levels of child domains are allowed, the tree could become very complex.
Multiple domain trees in a single forest
All domains in a forest can belong to a single domain tree if their DNS names are contiguous. If their DNS names are not contiguous—for example, if some end in win.stanford.edu and some end in mycompany.com—either separate domain trees or separate forests must be created. ITSS believes that the names of all Windows 2000 domains at Stanford can end in win.stanford.edu. Accordingly, one domain tree is sufficient—there’s no inherent need to create either multiple trees or multiple forests.
Multiple forests
The final possibility is to create multiple independent forests of Windows 2000 domains. The primary advantage of this is that it offers maximum flexibility. There is, for example, no central administrator for Active Directory over the entire environment. There are many drawbacks, however, including:
· no possibility for SSO accounts for trees not in the campus domain tree (i.e. ITSS forest);
· trusts between different forests must be established on a per-tree basis, not per forest, which can create substantial overhead;
· multiple Active Directories implies multiple schemas and more administrative effort;
· a forest with a root domain name other than win.stanford.edu would require getting another name assigned below stanford.edu, something that’s not currently allowed.
In the end, a separate forest is only useful if a Windows 2000 domain or group of domains wishes to be completely separate from all other Windows 2000 domains on campus.
Summary
Given the pros and cons for each choice, ITSS believes that the best choice is option two, a small number of domains grouped into a single domain tree. It offers the best balance between flexibility and simplicity. And because all domain controllers will be physically housed by ITSS, it also offers good security and a single point of maintenance for Active Directory.
Adopting this plan requires two key things. First, the affected organizations must agree that this approach makes sense. Second, ITSS must identify contact people for creating the per-school domains in the tree. ITSS is currently working toward both of these goals.