Determining the Order for Upgrading Domains

After you have a strategy in place for upgrading domain controllers, your next step is to determine which domain to upgrade first. Your choice depends on your overall upgrade goals. For example, if you plan to restructure certain domains, there might be little point in upgrading those domains first. Also, if an existing domain is to become the forest root you must upgrade that domain first.

It is recommended that you upgrade your domains in the following order:

1. Account domains

2. Resource domains

Guidelines for Upgrading Account Domains

Generally, you will get the most benefit from upgrading your account domains first because, in many cases, there are more users to administer than computers. Upgrading your account domains to Windows 2000 offers you the following benefits:

• Improved scalability of Active Directory — Many organizations are pushing the upper bounds of the recommended SAM size with their existing numbers of users and groups. Active Directory provides improved scalability to support larger user populations running a wide range of applications.

• Delegated administration — The Windows 2000 infrastructure allows delegation of administrative capability at very fine granularity, without requiring that absolute power be granted to local administrators.

If you have more than one account domain, the following guidelines will help you choose which order to upgrade them:

Mitigate risk and maintain control.    Even when you have tested your upgrade strategy in a lab or through a pilot project migration, the first production migration is the riskiest. To mitigate risk, upgrade the account domains in which you have the easiest access to domain controllers.

Minimize disruption.    First, upgrade the account domains with fewer users and with local control of domain controllers. This will minimize disruption to the greatest number of users, particularly while you are gaining experience in the deployment process.

Get the job done.    After you have gained experience, have confidence in the process, and have reduced the risk factor, move on to upgrading the larger account domains, which most likely will become consolidation points for other domains. As your user base grows, it will experience greater value of Windows 2000 features.

Identify account domains that are targets for restructure.    If you are planning to restructure your account domains, initially upgrade the ones that are the likely restructure targets. You cannot consolidate domains into a target domain that does not exist. Identify the account domains to be restructured.

Guidelines for Upgrading Resource Domains

If you have more than one resource domain, use the following guidelines to determine which order to upgrade them:

Choose domains in which new applications will require Windows 2000 platform or features.    Your first step is to upgrade domains where you plan to deploy applications that demand Windows 2000 infrastructure or features, such as Active Directory, which is required by Exchange Platinum (the next major release of Microsoft Exchange).

Choose domains with many clients.    Your next step is to upgrade domains that have many Windows NT clients, so that you can take advantage of Windows 2000 infrastructure components such as Microsoft® IntelliMirror#8482;.

Choose domains that are targets for restructure.    As with account domains, if you are planning to restructure your resource domains, first upgrade the domains that are the likely restructure targets. Identify the smaller resource domains to be restructured.

Child Domains and Trusts

The domain controller of the parent domain eventually copies all schema and configuration information to the new child domain. After this information is replicated, the upgraded domain is a fully functional member of the Windows 2000 tree. Note that until you decide to switch the domain to native mode, it remains in mixed mode and has limited access to Active Directory features.

Active Directory–aware clients such as computers running Windows 2000 Professional or Windows 95 or Windows 98 (running Active Directory client software) can now make use of Active Directory and perform tasks such as querying global catalogs (GCs) to locate resources and people. Transitive trusts allow clients existing within the forest to access resources throughout that forest. How this occurs depends on whether the client is running Windows 2000 or a pre–Windows 2000 operating system such as Windows NT, Windows 95, or Windows 98, and also on the upgrade state of the target domain. Resources are available across the forest through transitive trust when the clients reside in any of the following:

• Native mode domains.

• Mixed mode domains in which all the domain controllers have been upgraded to Windows 2000.

• Mixed mode domains in which the domain controller servicing the Kerberos or NTLM authentication request has been upgraded to Windows 2000.

In all other cases, clients have access only to those resources available through existing one-way explicit trusts, which remain unchanged as a result of the upgrade. Figure 10.4 illustrates how transitive trusts work between parent and child domains. The two-way arrows indicate transitive trusts between domains.

Figure 10.4 Example of Transitive Trusts Between Parent and Child Domains

Using NTLM Authentication

NTLM is an authentication protocol that is the default protocol for network authentication in Windows NT. It is retained in Windows 2000 for compatibility with clients and servers that are running versions of Windows NT.

For example, a user logs onto the domain reskit-acct.reskit.com, a mixed mode domain, from the Windows NT workstation ntws , which is in the same domain, as shown in Figure 10.5. The user then tries to make a network connection to a Windows NT server, nts , in the domain reskit-other.reskit.com , a native mode Windows 2000 domain. Because ntws is a pre–Windows 2000 client, it uses NTLM.

Nts determines that the domain name specified in the credentials passed to it, reskit-acct.reskit.com , does not refer to its own account database. So Nts sends the logon request to a domain controller in its own domain for authentication. The domain controller checks the domain name and, because it does not match the domain name of the domain controller, the domain controller checks to see whether the domain is a trusted domain. Domains reskit-acct.reskit.com and reskit-other.reskit.com are both children of the same root, reskit.com , so ** transitive trust exists between the two domains. Therefore, the domain controller passes the logon request through to a domain controller in the trusted domain. That domain controller authenticates the user name and password against its domain account database and, assuming the credentials match, passes the account identification information and group membership list back to the domain controller that contacted it, which in turn sends it back to the server.

The server then creates an impersonation access token for the user, containing the user SID and the SIDs of any domain groups of which the user is a member. The server handling the client request uses a thread to impersonate the security context of the user, which bears the impersonation token and attempts to access the resource on behalf of the user.

This example demonstrates that a pre–Windows 2000 client in a mixed mode domain can access a pre–Windows 2000 server in a native mode domain through transitive trusts using NTLM. Because all trees in the same forest are linked by transitive trusts, the same would be true even if the two domains were in different trees.

By extension, it follows that if a user attempts to access a resource on the Windows NT server nts in the mixed mode domain reskit-res1.reskit-other.reskit.com , that resource is accessible across the forest through a transitive trust, as long as the domain controller that receives the logon request from the server is running Windows 2000.

Using Kerberos Authentication

The Kerberos service is the default network authentication protocol for computers running Windows 2000. Secure Sockets Layer (SSL) and NTLM authentication are also available for network authentication within and between Windows 2000 domains. Kerberos authentication is a ticket-based protocol, in which users are issued Ticket Granting Tickets (TGTs) by the Key Distribution Center (KDC) on a Windows 2000 domain controller at initial logon to the domain. TGTs contain authentication information about the user and are encrypted with a key known by the KDC. After the client obtains the TGT, it can be presented back to the domain controller as part of the requests for additional service tickets to connect to other servers in the domain. After the user is granted a TGT, subsequent checks are quick and efficient, since the domain controller only needs to decrypt the TGT to check user credentials. Service tickets are similar to TGTs, but are encrypted using a key shared between the server and the domain controller.

In the example shown in Figure 10.4, the user now logs onto the domain reskit-acct.reskit.com as before , but this time from the computer w2kpro in the same domain, which is running ** Windows 2000. The user wants to make a network connection to a Windows 2000 Server, w2ksrv , in the reskit-other.reskit.com domain. Because w2kpro is a Windows 2000 client, the client attempts to use the Kerberos protocol.

The Kerberos protocol, like NTLM, can operate across domain boundaries. A client in one domain can authenticate to a server in another domain if the two domains have established a trust relationship. When domains establish trust, they exchange inter-domain keys. The authentication service for each domain uses its inter-domain key to encrypt tickets to the KDC of the other domain.

When a client wants access to a server in a remote domain, the client contacts the domain controller in its home domain for a TGT. The client then presents the TGT to the KDC on the domain controller of the remote domain if the client has a direct trust relationship with the remote domain, or its parent domain. This process is repeated with all intermediate domains until a trust path has been built between the home domain of the client and the remote domain.

The client presents the referral TGT to the KDC of the remote domain controller, asking for a ticket to a server in the client domain. The remote domain controller uses its inter-domain key to decrypt the TGT of the client. If decryption is successful, the remote domain controller can be sure that the TGT was issued by a trusted authority. The remote domain controller then grants the client a ticket to the requested server.

Figure 10.4 shows that a trust path can be built between the two domains reskit-acct.reskit.com and reskit-other.reskit.com because they ** are children of the same root and a ** transitive trust exists between them. On receiving the referral TGT, the domain controller in the target domain checks to see if it has a shared key for the server in question. If so, the domain controller issues a service ticket to the client. Because w2ksrv is a Windows 2000 computer, a shared key exists, so a ticket can be issued to w2kpro .

The important factors in this example are the existence of a domain controller in the target domain running the Kerberos KDC, and the existence of a shared key between the domain controller and the server. Windows 2000 domain controllers have the Kerberos service enabled as part of the Active Directory installation process, and adding a member server to a Windows 2000 domain involves the creation of a shared key. From this it follows that w2kpro is able to access w2ksrv.reski-res1.reskit-other.reskit.com using Kerberos as long as there is a Windows 2000 domain controller available to issue the session ticket.

If w2kpro attempts to access a resource on a Windows NT computer such as nts.reskit-res1.reskit-other.reskit.com , Kerberos authentication fails, and the client then attempts NTLM authentication, as described earlier in this section under "Using NTLM Authentication."