Planning a Domain Structure
Once you've settled on the overall design of your namespace, you need to design your domain structure to support it. Each branch of the namespace breaks down to either a domain or an organizational unit (OU). Whether a branch is a domain or an OU will depend on a variety of considerations, including the need for replication, security policy, resource availability, quality of the connection, and so forth.
Domains vs. Organizational Units
The Windows 2000 network trees are made up of domains and organizational units. Each provides for administrative boundaries between branches on the tree, but they have different implications and resource requirements.
Domains
The core unit of the Windows 2000 Active Directory is the domain, just as it is in Windows NT 3.x and Windows NT 4. All network objects exist as part of a domain, and the security policy is uniform throughout a domain. Unlike Windows NT, Windows 2000 security is based on Kerberos version 5, and the trust relationships are transitive. In transitive relationships, if domain A trusts domain B and domain B trusts domain C, then domain A also trusts domain C.
PLANNING
One-way Windows NT 4-style trust relationships can still be set up. More important, the relationships between Windows 2000 domains and legacy Windows NT domains are based on the one-way, nontransitive trust relationships inherent in Windows NT. It is essential that you consider these relationships when planning your domain structure.
With Windows 2000, the concepts of primary domain controller and backup domain controller are finally history. Domain controllers in Windows 2000 are multiple master and peer based. Each controller of a domain has identical authority over the domain, and if any controller goes down, the others continue to administer and authenticate the domain. Any domain controller can originate a change to the domain and then propagate the change to the other domain controllers in the domain.
The domain is also the unit of replication. Changes in the domain are replicated throughout the domain, even when the domain spans multiple sites or locations. This capability allows domain controllers at distant sites to originate changes to the domain and have the changes replicated across the domain.
While access rights are transitive across domain boundaries, administrative rights are, by default, limited to the domain. This allows you to grant administrative rights to a key user in a particular domain without worrying about compromising the overall security of the organization, since the administrative rights stop at the domain boundary unless explicitly granted to other domains.
Organizational Units
The OU concept is new to Windows 2000. It has some of the characteristics of a domain, but without the resource overhead of one. An OU is contained within a domain and acts as a container for directory service objects. It forms a branch of the contiguous namespace, and it can in turn contain other OUs. Thus, the domain corp.microsoft.com may contain other domains, such as finance.corp.microsoft.com, and it may also contain OUs such as hr.corp.microsoft.com. The OU provides a convenient administrative boundary, and rights and privileges for administration can be granted to users in an OU without compromising the rest of the domain. However, an OU does not require a separate domain controller, nor is it involved in replication.
The closest analogy to an OU from the Windows NT domain model is the resource domain, but without the domain controller overhead that was required under Windows NT. In cases where there is no particular need for a separate security policy for a given administrative container, the OU provides an appropriate and less resource-intensive boundary. Moreover, in case of need, an OU can be easily promoted to a domain.
Designing a Domain Structure
Once you have designed your namespace and everyone involved has signed off on it, you're ready to start designing and implementing your domain structure. The design of your domain structure will closely match the design of your namespace, though you may make a decision that certain namespace boundaries require only OUs, not full domains. Your choice between an organizational unit and a domain should be based on whether you need a separate security policy for the entities within the namespace boundary. If a particular namespace boundary will not require a security policy that is different from that of its parent, you will probably find an OU to be an appropriate division, since it requires fewer resources to implement. As mentioned earlier, you can easily promote an OU to a domain later if that becomes necessary.
Designing a Tree Domain Structure
If you'll be creating a single, contiguous namespace and therefore a pure tree domain structure, you'll want to create the domains in hierarchical order, starting at the top of the tree. The first domain will be your root domain and will, most likely, have either all of the users in it (for smaller, single-domain models) or no users at all (if you use a structural domain as the root domain). For those familiar with the Windows NT 4 domain models, this pattern very roughly corresponds to the "single master" domain model, with one important difference. Users need not (and most often should not) reside in a single master domain, but should reside in their actual appropriate place in the domain structure.
As you branch down the tree of your namespace, you will create domains or organizational units for each branch of the tree. The decision about whether to create an OU or a domain controller will depend on your overall security model, the quality of the connection to the location, and a variety of other factors, including political considerations from the original namespace planning. If you're in doubt at any point, simply create an OU—it's easy to upgrade the OU to a domain later.
Designing a Forest Domain Structure
The forest of trees structure is most often used to accommodate an existing namespace that is noncontiguous and can't easily be made contiguous. You'll end up with multiple root domains, all on the same level. Below each of these root domains, you'll have a contiguous namespace for that tree. Each branch of the namespace will be either a domain (with its attendant requirement of one or more domain controllers) or an organizational unit. You'll generally create each tree from the top down, and each branch of the tree will automatically have a transitive trust relationship with the other branches of the tree.
The trees in the forest will share the same schema, configuration, and Global Catalog, with transitive Kerberos trust relationships among all members of the forest. The trust hierarchy within each tree will follow the naming hierarchy. The trust hierarchy in the forest as a whole, however, will follow the order in which trees are joined to the forest. This fact is transparent to the users but can be manipulated by the administrator to improve management and referrals.
Domain Security Guidelines
Within each domain, the security requirements, policy, and configuration are consistent. If you need to change the security requirements and policy for a subunit within a domain, you'll need to create that subunit as a domain, not an OU. Keep this limitation in mind as you plan your overall namespace—you'll need to have a separate branch of the namespace in order to have a separate security policy.
What is meant by "security policy"? What sorts of things does it entail? Chapters 17 through 19 deal exclusively with security matters, so for the moment, we'll take a summary view. The security policy includes
- Logon requirements
- Certificates
- Password aging and minimum length requirements
- Smart card or other authentication add-ons
- Machine and time-of-day restrictions
Many of these things will comfortably be the same throughout your organization, but there may well be certain areas that require significantly greater security than that needed in the rest of the organization. If so, plan for areas that require extra care to be in a separate domain so that their more restrictive security won't be imposed on the entire organization.
Creating Organizational Units
In situations where you don't need to create separate domains for security reasons but do want to maintain a separate level in the namespace, you'll create a separate OU. Thus, you might have a domain called noram.microsoft.com that you want to divide into business units within the region. You could create separate sales, support, education, human resources, manufacturing, and finance domains under noram.microsoft.com. However, the overhead of separate domains (and their required controllers) for each of these units isn't necessary—especially since they all share a single security policy. So simply create OUs for each of them. If you later decide to upgrade one or more of them to a domain, you can do it easily.
Organizational units make useful boundaries for administrative purposes. Various administrative tasks and privileges can be delegated to the administrator for a specific OU, freeing up the domain administrator and giving the OU local control of its own resources.
EAN: 2147483647
Pages: 366