Determining Domain Migration Strategies
Determining Domain Migration Strategies |
|
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:
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:
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.
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™.
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.
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:
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
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
Nts determines that the domain name specified in the credentials passed to it,
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
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
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
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.
If w2kpro attempts to access a resource on a Windows NT computer such as nts.
