Determining Domain Migration Strategies
Determining Domain Migration Strategies |
|
The first step in the domain upgrade process is to upgrade the PDC to Windows 2000 Server. After you have upgraded the PDC, your next goal is to upgrade all the BDCs in the domain as soon as possible. This step is necessary to minimize the impact of having Windows 2000 features that are not supported on Windows NT BDCs.
A domain is considered a Windows NT domain if the PDC has not been upgraded to Windows 2000. During the process of upgrading the PDC and BDCs, the domain is in the intermediate operational state known as mixed mode. You can leave the domain operating in mixed mode indefinitely or move it to the final operational state known as native mode.
A domain is considered to be in mixed mode when one of the following conditions exist:
Table 10.5 summarizes the Windows 2000 features available in mixed mode, and those available only by switching to native mode. If you are hesitant about switching the domain to native mode, review your migration goals to determine whether remaining in mixed mode compromises your goals, or if the tradeoffs are acceptable.
Table 10.5 Availability of Windows 2000 Features in Mixed Mode
| Feature | Available in Mixed Mode? |
|---|---|
| Transitive trusts for Kerberos authentication | Yes. Windows 2000 Server and Windows 2000 Professional use Kerberos services available on the Windows 2000 domain controller. |
| Active Directory organizational units (OUs) | Yes, but only visible using Windows 2000 administration tools. Cannot be administered from Windows NT BDCs or member servers. |
| Active Directory security groups | No, only Global and Local groups available. |
| IntelliMirror | Yes, but only for client computers running Windows 2000 Professional in an Active Directory environment. |
| Windows Installer | Yes. |
| 64-bit memory architecture | Yes, with hardware support. |
| Active Directory scalability | Yes, but only when all BDCs have been upgraded and are running Active Directory. You need to be cautious of taking advantage of this feature, because new Windows NT BDCs can still be added while the domain is in mixed mode. This feature might be an important part of your fallback planning, so it must not be compromised. |
| Kerberos authentication | Yes, for Windows 2000 computers running Active Directory. |
| Microsoft Management Console (MMC) | Yes. |
| Group Policy | Yes, but only for client computers running Windows 2000 Professional in an Active Directory environment. |
| Security configuration and analysis | Yes. |
| Active Directory multiple-master replication | Yes, between the PDC and BDCs that have been upgraded. |
Until you decide to switch the domain to native mode, the domain remains in mixed mode even if all the BDCs have been upgraded.
Note that when you set the native mode switch, the domain could still contain member servers running Windows NT Server 4.0 or clients running Windows NT Workstation 4.0 or Windows 95 or Windows 98.
Figure 10.3 shows the transition from a Windows NT domain to a native mode Windows 2000 domain.
Figure 10.3 Domain Upgrade Modes
Native mode is the final operational state of a Windows 2000 domain, and is enabled by setting a switch on the user interface. It means that the upgraded domain is now considered a Windows 2000 domain and can take advantage of the full range of Windows 2000 features as described in "Reasons for Moving to Native Mode" later in this chapter. After you have upgraded all domain controllers to Windows 2000, you can then choose to move the domain to native mode. During the switch, the following occurs:
All pre–Windows 2000 clients use the PDC emulator to locate the PDC and perform password changes. In addition, Windows NT resource domains use the PDC location information to establish trusts. The PDC emulator is defined later in this chapter.
Group nesting and Windows 2000 group types, such as universal and domain local groups, are available.
 |
Critical Decision Until you decide to switch the domain to Windows 2000 native mode, it remains in mixed mode. You can leave the domain operating in mixed mode indefinitely, even if you have upgraded all the BDCs in the domain. However, once you switch the domain to native mode, it cannot be returned to mixed mode or become a Windows NT domain. |
After synchronizing all BDCs in the domain so that they are completely updated with any recent changes made at the PDC, you can begin the account domain upgrade by upgrading the PDC. After the core operating system is installed on the PDC, Windows 2000 Setup detects that a domain controller is being upgraded. Setup then prompts you to install Active Directory on the server by automatically running the Active Directory Installation Wizard.
For more information about how to install Windows 2000 Server, see "Automating Server Installation and Upgrade" in this book.
The Active Directory Installation Wizard gives you the following options:
The option you choose depends on the outcome of your namespace planning. For more information about planning your namespace, see "Designing the Active Directory Structure"in this book, which is a prerequisite to this chapter.
During the upgrade process, the contents of the Windows NT account database (SAM) are copied into Active Directory. These objects are the security principals (user accounts, local and global groups, and computer accounts). Note that for large account domains, this process can take some time.
Active Directory also incorporates support for Kerberos authentication. After the Active Directory Installation Wizard completes, the Kerberos authentication service is available for Windows 2000 systems. At this time, if you decide to join a domain containing an upgraded PDC to an existing tree, a transitive (two-way) trust relationship is established with the parent domain. Any trust relationships created before the PDC was upgraded still exist, but they remain explicit one-way trusts.
Because Active Directory supports multiple-master updates, a Windows 2000 domain controller is not a PDC in the same manner as a Windows NT 4.0 PDC. When you upgrade a Windows NT PDC to a Windows 2000 domain controller, it then acts as a PDC by holding the role of PDC emulator. In Windows 2000, there is one PDC emulator for each domain in the forest.
The PDC emulator supports Windows NT clients, member servers, and domain controllers; and Windows 95 and Windows 98 clients through the following:
These functions of the PDC emulator become unnecessary after Windows NT clients, member servers, and domain controllers; and Windows 95 and Windows 98 clients are all upgraded.
Note
Windows 2000 clients — and all Windows 95 and Windows 98 clients that have the ADClient package installed — can use any domain controller in the domain to perform directory writes, such as password changes. These activities are no longer limited to the domain controller that advertised itself as the PDC.
The PDC emulator retains some functions in fully upgraded Windows 2000 domains. Password changes performed by other domain controllers in the domain are replicated preferentially to the PDC emulator. When an authentication request fails due to a bad password at the other domain controllers in the domain, the domain controllers forward the authentication request to the PDC emulator before failing the request. This is done in case the password had been recently changed. Account lockouts are processed on the PDC emulator. Group Policy also defaults to the PDC emulator when you edit Group Policy objects on a server.
For more information about security policies, see the Microsoft® Windows 2000 Server Resource Kit Distributed Systems Guide.
The PDC emulator provides backward compatibility by exposing the data in Active Directory as a flat store to Windows 95, Windows 98, and Windows NT computers, including BDCs, during replication. This compatibility manifests itself in the following ways:
Multiple-master replication means that you can perform an update at any Windows 2000 domain controller, even if that domain controller is disconnected from the rest of the network. For instance, if you make an update at a disconnected domain controller, and at the same time, someone else makes an update at another domain controller that conflicts with your update, both updates will replicate when network connectivity is restored. In spite of the conflicting updates, all domain controllers eventually converge to the same value. This convergence process is called conflict resolution.
However, some conflicts are too difficult to resolve. Suppose that different domain controllers have conflicting versions of the directory schema. Schema conflicts can be resolved using the same rules that Active Directory uses to resolve normal conflicts (the "last writer wins").
Having moved security principals into Active Directory during the PDC upgrade, one key concern is the effect this move has on access to resources. The following sections describe the components that control resource access.
The Windows NT security model (the basis for Windows NT and Windows 2000 security) identifies security principals such as users, groups, computers, and domains by security identifiers (SIDs). SIDs are domain-unique values, built when the user or group is created, or when the computer or trust is registered with the domain.
The components of a SID follow a hierarchical convention. A SID contains parts that identify the revision number, the authority that assigned the SID, the domain, and a variable number of sub-authority or Relative Identifier (RID) values that uniquely identify the security principal relative to the issuing authority.
Important
Though there are well-known SIDs that identify generic groups and users across all systems, the security principals discussed are identified in the context of a domain. These security principals cannot be moved between domains without their SIDs changing. If SIDs are altered in any way, resource access is affected. During an upgrade, however, security principals remain in the same domain in which they were created, so the SIDs identifying the security principals remain unchanged. As a result, resource access is unaffected by upgrade.
Authentication is an essential component of the Windows NT security model. Authentication is the means by which a user is identified to the domain through the presentation of credentials, usually in the form of a user name and password. Assuming these credentials are acceptable, the security subsystem creates an access token for the user that includes the primary SID (the SID of the user) as well as the SIDs of all the domain and local computer groups of which the user is a member. Every process the user creates, such as running an application, carries the user access token.
The user access token can be thought of as the form of user ID presented to the system. It is used by the system to determine whether the user needs to be granted access to system resources.
The counterpart of the user access token is the security descriptor attached to resources such as files or printers. A security descriptor contains an access control list (ACL), which consists of access control entries (ACEs). An ACE consists of a SID, together with an indicator that the security principal identified by the SID is granted or denied some sort of access to the resource, such as read, write, and execute permissions. The system performs access check verification by comparing the SIDs in the access token against the SIDs in the ACL to determine whether to grant requested permissions.
