Before You Begin

You must consider several things when you are deciding how to arrange your domains for the migration. These include the following:

• Existing namespaces ” Do you already have registered Internet domain names in use at your company? Do you have more than one namespace; that is, acme.com and acme-mfg.com ? The Active Directory names domains use DNS (Domain Name System)-style names such as these, rather than NetBIOS-style names.

• Number of users in the network ” Although the Active Directory is scalable to many millions of objects, hardware capacity and network bandwidth will still limit the numbers of objects that any particular domain can handle efficiently . You might find that for branch offices, for example, it's easier to create a separate domain to reduce the amount of data in a single domain. This can also cut down on the multimaster replication used by the Active Directory across slow links.

• Structure of the organization ” Many existing Windows NT networks use domains to model the business's organization structure. In the Active Directory, the OU can perform this function.

• Geographical separation ” If you have a large enterprise with many users separated into distinct geographical sites, you can use either multiple domains to accommodate them or choose to use Active Directory sites and a single domain. As noted earlier, keep in mind the bandwidth used to connect to remote sites when deciding to use a single domain or multiple domains. Replication traffic can consume valuable bandwidth over slow links.

Windows NT Domain Controllers and Member Servers

One of the annoyances with Windows NT 4.0 was that to create a PDC or BDC, you had to do so when you first installed the operating system . That is no longer the case with Windows 2000. In fact, as discussed earlier in this chapter, there are no primary or backup domain controllers. There are only domain controllers, each of which holds a full copy of the domain's Active Directory database. Updates, such as adding new users or changing passwords, can be done using any domain controller in the domain. For Windows NT 4.0, you had to make these changes on a PDC and either wait for the data to be replicated to BDCs or force a push of the data to synchronize the domain controllers. Updates made to domain controllers in Windows 2000 can be made at any domain controller, and updates are propagated using multimaster replication to all other domain controllers in the domain.

Also, remember that in the Active Directory domain names are expressed as DNS-style names. That is, instead of naming a domain acme , for example, you should use a name such as acme.com , which is a DNS-style name. When you create a tree of domains in the Active Directory, you must use a hierarchical DNS naming scheme so that you maintain a contiguous namespace.

Even though your domains now use a DNS-style name, you're still asked to provide a NetBIOS-style name when you upgrade a server to an Active Directory domain controller. This NetBIOS-style name will be used for down-level clients ”for example, any NT 4.0 Workstation systems that are left on the network.

Note

Although you could use a DNS server in a Windows NT 4.0 network, it was not a requirement. Microsoft developed the Windows Internet Naming Service (WINS) that could be used in a similar fashion, although it mapped NetBIOS names to IP addresses, whereas DNS performs mappings of DNS-style names to IP addresses. In Windows 2000/2003 networks, a DNS server (which must be capable of accepting dynamic updates) is required because clients use it to locate domain controllers, as well as register their own information when they boot. For more information about DNS and WINS, see Chapter 30, "Network Name Resolution." You still can use WINS in a Windows 2000/2003 network, but it isn't needed unless you have pre-Windows 2000 clients that depend on NetBIOS name resolution to function on the network. Additionally, some applications, such as System Management Server (SMS), might require WINS. Check your documentation for all applications before deciding on a no-WINS solution.

Each domain in the tree is a subdomain of the topmost domain. The domain tree provides a two-way transitive trust relationship between all domains that exist in a single Windows 2000 tree. In Windows NT, trust relationships had to be established between domains, with one trust relationship created for each direction that you wanted to trust. In other words, you could trust one domain, or it could trust your domain, or two trust relationships could make the trust relationship mutual.

In the Active Directory, inheritance of security rights flows downward from the top of the tree. So, you can assign users administrative access rights and permissions at a single point in the tree and therefore grant them the same rights for child objects farther down the tree. Access control lists (ACLs) can help you further refine the delegation of authority in the Active Directory.

When you have a network that's composed of disparate namespaces, you can create separate trees and group them into a forest . Recall that a forest is a collection of domain trees. In this type of organization, each domain tree represents a contiguous namespace, but other disjointed namespaces exist in the network. A domain forest is used in a similar manner to a domain tree, in that users still can be granted access rights in domains that are contained in other domain trees. The main difference between a domain tree and a forest is the disjointed namespaces (that is, different DNS-style names that can exist when you merge two or more businesses together). Additionally, although domains that exist within the same domain tree have implicit transitive trust relationships, you must create trust relationships between domains that exist in different trees in a forest before you can begin to grant users access to resources in other domain trees. Later in this chapter, you'll learn how this has changed in Windows 2003. This simple feature could be a deciding factor in which version of Windows Server operating systems you choose for your upgrade.

Replication of Directory Information

Active Directory domain controllers replicate, through multimaster replication techniques, all changes to the Active Directory database for their domain to all other domain controllers in the domain. Domain controllers for other domains in the domain tree do not receive these replication updates because they're responsible only for the portion of the directory database that concerns objects in their respective domains.

For more information about multimaster replication, see Chapter 31.

However, all domain controllers in a particular domain tree do receive replication updates that concern the metadata , which defines the domain tree. For example, when a new domain joins a domain tree or when a domain is detached from one part of the tree and reattached at another part, this information is replicated to other domain controllers in the domain tree.

Modeling the Directory Structure After Your Business Organization

The main points to consider when grouping users and resources are how you want to administer them and what this will do to affect the network traffic associated with logon authentication and directory information replication.

Do you want to create a network that allows centralized or decentralized control? In Windows NT, domains were used to enable you to group users and resources into convenient , manageable units that share a common security policy. With the X.500 naming hierarchy adopted by the Active Directory, you might find that you now can get by with fewer domains, while using other methods , such as organizational units, to make administration more flexible.

Having a single domain and using OUs to divide users and resources for administrative control purposes is a good idea if the network is connected by high-speed links. If your network is widely dispersed over a large geographical distance (or via slow links), you should take into consideration the replication traffic that will occur when changes are made to the database if a single domain is used. If frequent changes to the database occur, you might want to consider using separate domains for users and resources in different locations so that only the domain tree metadata becomes the object of replication.

For example, suppose that a manufacturer has just decided to upgrade all its business sites to Windows 2000 and use the Active Directory to manage resources. The sales office is located in New York and two manufacturing sites are located in Dallas. The user base at the Dallas site has a much higher turnover rate than that of the New York site. Because users at each site mainly access only resources local to their site, it makes sense to use two domains, one for each geographical site. Using two domains also keeps replication traffic between the sites to a minimum because the frequent changeover of users at the Dallas site does not need to be replicated to the New York site.

Later, the company decides to open another manufacturing plant in San Antonio. A high-speed leased line is installed between the Dallas and San Antonio sites because the plants will be sharing a lot of information between them. The Dallas domain is expanded to include the San Antonio users. However, a separate OU is used for each of these sites so that users can be dealt with easily by the local managers for each site. Because both of these OUs reside in the same domain, controlling user access to domain resources is a simple task no matter where the user is located.

Domains Are Partitions of the Active Directory

A domain in the Active Directory is basically a partition of the entire domain tree namespace. The namespace consists of all domains in the domain tree of which the domain is a member. In the Active Directory, each domain controller in the domain holds a complete replica of that domain's partition of the directory database. Each domain is responsible for holding directory information about users, resources, and other objects defined in the domain. The global catalog enables users in other domains in the domain tree the ability to quickly locate resources that are entered in other partitions, or domains, of the tree.

Note

You aren't stuck with your initial decision when you set up a domain tree or forest. The Active Directory uses a unique number, the globally unique identifier (GUID), to identify each domain in the network. Because this identifier is used throughout the network to uniquely identify the domain, the directory enables you to add, delete, and change domain names easily as your organization or network changes. Because each domain can be easily identified by its GUID, you can make changes to the shape of the domain tree or forest by moving domains around and reattaching them at different points to match your current needs. In the Windows 2003 Active Directory, you can use drag-and-drop utilities to rearrange domains in a tree.

Another important characteristic of a domain is the domain security policy. You define certain characteristics of the security policy, such as the password history and account lockout values, on a domain-by-domain basis. However, you cannot assign different account policies, such as lockout values, on an OU basis.

Organizational Units Allow for Delegation of Control

Organizational units are container objects in the Active Directory. A container object is an object that can hold other objects in the directory. An OU can hold other organizational units and container objects, as well as leaf objects in the directory. Leaf objects are the endpoints in the tree structure of the directory and hold information about such things as users, printers, applications, and other resources.

Tip

In the Active Directory, you can use the OU to subdivide portions of the directory. By doing so, you can reduce the number of domains that you need. You can delegate authority to manage OUs to only those administrators who need such access. Thus, OUs can be used not only to partially replace domains, but also can be a very useful method for controlling rights and access for day-to-day management chores.

In Windows NT, you use a domain to group users and resources so that they can be managed as a unit. Within a domain, you can grant certain users the rights to perform system management and administrative tasks , such as creating user accounts or adding computers to the domain. However, this administrative control is domainwide . For example, if you grant a user account the right to modify user accounts, that user can modify any user account in the domain.

OUs enable you to further subdivide a domain and grant those same user rights based on the OU instead of the entire domain. This finer granularity of control can make it possible for you to get by with fewer domains in situations in which you want to use a large number of user groupings for administrative control purposes. Instead of creating a domain for each of the accounting, human resources, and manufacturing departments, you can create one domain and assign administrative privileges by OUs created within the domain to allow each department to control its own users and resources.

Migration Considerations: Centralized Versus Decentralized Management

When planning the domain layout for your organization, you should consider the type of management control (centralized versus decentralized), security policies, and the network infrastructure. When deciding whether to use many or fewer domains as the basis for dividing resources and users, consider what happens on the domain level. Each domain controller in a domain holds a complete copy of the domain's portion of the directory database. Replication between domain controllers happens only within a domain. That is, when you add a new user, file, or print resource, the information is replicated via multimaster replication to all other domain controllers in the domain. The information is not replicated outside of the domain to the domain controllers in other domains (although some attributes are stored in the global catalog). Thus, by using a larger number of domains for geographically dispersed networks, you can reduce replication traffic.

Security policy also is implemented on a domain basis. If different departments in your business have widely varying security requirements, you might need to use the domain as a tool for organizing users and resources. You cannot define different password history values or set a security policy of how strong a password must be based on the OU.

Delegation of Administrative Rights Reduces the Need for Multiple Domains

In Windows NT, several built-in domain groups were used to grant administrative rights to users. Those included the all-powerful Domain Admins group, whose members can perform all administrative functions in the domain (unless the local administrator chose to take the Domain Admins group out of the Administrators group), down to the Account Operators and Backup Operators groups, which have access to only specific management functions. Although having these built-in user groups made it easy to grant specific users only a portion of the administrative rights that are possible in a domain, the drawback is that these rights exist throughout the domain. For example, if a user is a member of the Account Operators group, that user can potentially modify any user account in the domain (other than the Administrator accounts).

The Active Directory provides for the capability to delegate the assignment of administrative rights, down to the level of the OU. Because user accounts are not stored in the Registry-based SAM (Security Accounts Manager) database anymore, but are instead objects in the directory database, you can grant or deny administrative privileges on specific portions of the directory tree.

Two important concepts to understand about administrative privileges in the Active Directory are

• Per-property access rights

• Inheritance of access rights

Each object in the Active Directory can have an ACL attached to it, which defines who is allowed to perform what functions on the object. This access can be defined down to the property (or attribute ) level. That means you can grant a specific user the ability to manage all aspects of user account management for a particular container object (OU), or the ability to modify selected properties of user objects within the container, such as the users' passwords or default directories.

Each object in the directory is made up of specific attributes, called properties . Each property is a single type of information about the object. You can grant or deny administrative privileges on each and every property of a particular object type. To make things even easier, you also can grant or deny administrative privileges on groups of properties. The property set attribute of the schema defines groups of properties that can be administered together. If the default definitions of this attribute do not meet your needs, you can modify the schema.

Caution

As explained in Chapter 31, you should think carefully before modifying the schema. Changes to the schema cannot be undone. Although you can disable objects or attributes that you add, this applies only to new instances of these objects or attributes and not those created before you made schema changes. In other words, don't change the schema unless you have an absolute need to do so. The objects that are provided with the Active Directory should satisfy most business needs.

Inheritance of access rights is another concept that makes delegating administrative authority more convenient. If you think of the Active Directory as a hierarchical structure organized in a tree fashion, you can pick a particular point in the tree and grant access rights to a user from that point to objects farther down the tree. The administrative rights flow down the tree to include other container objects and finally down to the end leaf objects of the tree. When a new child object is created in the directory tree, the access rights that apply to the container object that holds the child object are included with the default access rights created on the child object. This is true unless you place ACLs on specific objects or OUs to prevent this inheritance.

This method of inheritance allows for faster authentication time when the operating system must determine access rights. It isn't necessary to trace back up the hierarchy through all parent objects to determine the access rights of a particular child object. The child object contains all the information that's required to perform an access right check.