Determining a Strategy for Upgrading Domain Controllers

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.

Windows 2000 Domain Modes

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 .

Mixed Mode

A domain is considered to be in mixed mode when one of the following conditions exist:

• The PDC has been upgraded but not all BDCs have been upgraded.

• The PDC and all BDCs have all been upgraded but the native mode switch has not been enabled.

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

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

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:

• Netlogon synchronization is switched off, and the domain uses only Active Directory multiple-master replication between domain controllers.

• Because Netlogon synchronization is now switched off, you can no longer add Windows NT BDCs to the domain.

• Because multiple-master replication is enabled, the former PDC is no longer the master of the domain, and all domain controllers can now perform directory updates. Despite this, Windows 2000 still designates the role of PDC emulator to the former PDC. Usually the former PDC continues as PDC emulator, which in a native mode environment means that password changes are replicated to the former PDC preferentially by other domain controllers.
  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.

Upgrading the Windows NT PDC

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:

• Creating the first tree in a new forest

• Creating a new tree in an existing forest

• Creating a new replica of an existing domain

• Installing a child domain

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.

PDC Emulation in Windows 2000

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:

• A Windows NT, Windows 95 or Windows 98 client performs directory writes (for example, password changes) at the PDC emulator.

• Password checks.

• Windows NT BDCs replicate from the PDC emulator.

• In a network running the Windows NT browser service, the PDC emulator plays the role of Domain Master browser. It registers the NetBIOS name Domain name<0x1B>.

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 KitDistributed Systems Guide.

PDC Emulator Properties

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:

• The PDC emulator appears as a Windows 2000 domain controller to other Windows 2000 computers, and as a Windows NT PDC to computers that have not been upgraded.

• The PDC emulator can still be used to create new security principals and to replicate these changes to the Windows NT BDCs.

• Windows 95, Windows 98, and Windows NT clients can use the PDC emulator as a possible logon server.

• If the PDC emulator goes offline or becomes unavailable, and another Windows 2000 domain controller exists in the domain, then that domain controller needs to be made the PDC emulator. If no other Windows 2000 domain controllers exist in the domain, then a Windows NT BDC can be promoted to a PDC, then upgraded to Windows 2000 Server.

Conflict Resolution

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").

Access Control Components

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.

Security Identifiers

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 and Access Tokens

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.

Authorization and Security Descriptors

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.