Background Information for Upgrading to Windows Server 2003 Active Directory

  • Article

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

Before you begin the Windows NT 4.0 in-place domain upgrade, become familiar with some important issues that affect the upgrade process.

PDC Offline Operations

During the process of upgrading the operating system on the primary domain controller (PDC) from Windows NT 4.0 to Windows Server 2003 and installing Active Directory, client operations such as logon and resource access will continue to function because these services are provided by backup domain controllers. However, because the PDC will be offline during most phases of the upgrade process, typically between one and three hours, operations that require data to be written to the domain will not succeed. For example, users will not be able to change their passwords and administrators will not be able to create, delete, or unlock user accounts. Administrative tools, such as User Manager for Domains or Server Manager, can be used only in read-only mode on backup domain controllers in the domain. In addition, you will not be able to create new objects, such as users and groups, while the PDC is offline.

Full Synchronization of the Local Security Authority Database

After upgrading a Windows NT 4.0 PDC, or after transferring the PDC role to another domain controller, the LSA will perform a single full synchronization of all objects in the database. This synchronization causes events to be logged in Event Viewer; specifically, Event Viewer in Windows Server 2003 will log Event ID 5713 and Event Viewer in Windows NT 4.0 will log Event ID 5717. However, the LSA database contains relatively few objects and the full synchronization does not affect network performance.

Do not confuse the full synchronization of the LSA database with a backup domain controller (BDC) full synchronization. A BDC full synchronization typically happens when too many changes occur on a PDC before the PDC can replicate the changes to a BDC. The number of objects that are replicated during a BDC full synchronization and the amount of network traffic that is generated depends on the number of users, groups, and workstations in the domain.

Domain Users and Client Workstation Operating Systems

When Microsoft® Windows® 2000, Microsoft® Windows® XP, and Windows Server 2003 clients attempt to authenticate with a domain controller, they first retrieve a list of domain controllers from either DNS or WINS, and will then authenticate with the first domain controller that responds to their authentication request. The first domain controller to respond is usually a domain controller located closest to the client. The client and the domain controller will then negotiate which authentication protocol to use.

When Windows 2000, Windows XP, and Windows Server 2003 clients are members of a Windows NT 4.0 domain, they will only use the NTLM protocol to authenticate because that is the only authentication protocol supported by Windows NT 4.0. Windows 2000 and Windows Server 2003 domain controllers are capable of using either the NTLM or the more secure Kerberos authentication protocol.

When performing an in-place upgrade of a Windows NT 4.0 domain to Windows Server 2003, the first domain controller upgraded is the Windows NT 4.0 PDC. If clients in the domain running Windows 2000, Windows XP, and Windows Server 2003 select the new Active Directory domain controller for authentication, the negotiation of the authentication protocol will reveal that there are now domain controllers in the domain that support the Kerberos protocol. These clients will then upgrade their secure channel to exclusively use the Kerberos protocol for authentication requests and will no longer attempt to authenticate using the NTLM protocol, potentially causing the new Active Directory domain controller to become overloaded with authentication requests.

To prevent Windows Server 2003–based domain controllers from being overloaded with authentication requests, configure each Windows Server 2003–based domain controller to emulate a Windows NT 4.0–based domain controller during the upgrade process. Configuring a newly upgraded Windows Server 2003–based domain controller to emulate a Windows NT 4.0–based domain controller by using the NT4Emulator registry entry shields the new domain controller from getting too many authentication requests from Active Directory clients. Shielding the Active Directory domain controller takes place before the operating system is upgraded to Windows Server 2003 to prevent clients running Windows 2000, Windows XP, and Windows Server 2003 from ever establishing exclusive communications with a Windows Server 2003–based domain controller.

When upgrading additional Windows NT 4.0–based domain controllers after the PDC has been configured to emulate a Windows NT 4.0–based domain controller, you must remember to configure the computer you are upgrading with the NeutralizeNT4Emulator registry entry. This is so that the additional domain controller will recognize the upgraded PDC that is emulating a Windows NT 4.0–based domain controller as an Active Directory domain controller. If the computer is not configured to neutralize emulation, you will not be able to install Active Directory because the additional domain controller will not be able to authenticate to an Active Directory domain controller.

For each site in which clients are running Windows 2000, Windows XP, and Windows Server 2003, ensure that you have enough Windows Server 2003–based domain controllers deployed in that site before removing Windows NT 4.0 emulation.

For more information about emulating Windows NT 4.0–based domain controllers, see "Configure Protection Against Domain Controller Overload on Additional Domain Controllers" later in this chapter.

For more information about domain controller placement, see "Designing the Site Topology" in this book. For more information about domain controller capacity planning and determining the number of domain controllers needed in each site to service Active Directory clients, see "Planning Domain Controller Capacity" in this book.

Service Compatibility

In Windows NT 4.0 and earlier server operating systems, services running in the context of the Local System account communicate with other services over the network by using null sessions (a session in which a user name or password is not provided). In Windows 2000 and later operating systems, services running in the context of the Local System account on the local computer use the local computer account to authenticate to other servers. By default, Active Directory does not accept null session queries.

Of all the services that run in the context of the Local System account, Remote Access Services (RAS) is the most prominent. You cannot use null sessions to access network resources by using NTLM authentication unless the remote computer allows access with null credentials.

In an Active Directory environment containing both Windows NT 4.0–based and Windows Server 2003–based domain controllers, a member server that is running Windows NT 4.0 and is configured as a RAS server cannot retrieve information from a Windows Server 2003–based domain controller. For example, if a caller tries to dial into your network and accesses a Windows NT 4.0 member server that is configured as a RAS server, the RAS server must query a domain controller first to verify whether the caller has permission to dial into the network. Therefore, RAS operates correctly only if the domain controller responding to the RAS authentication request is a Windows NT 4.0–based BDC or the Active Directory domain has been configured to allow resources to be accessed by using null credentials. By upgrading the operating system on Windows NT 4.0 member servers that are configured as RAS servers to Windows Server 2003, you ensure that RAS callers are successfully authenticated by a Windows Server 2003 Active Directory–based domain controller.

The recommended solution is to upgrade the RAS servers to Windows Server 2003. However, if this cannot be done, the alternatives are:

  • While installing Active Directory on the upgraded Windows NT 4.0 PDC, on the Permissions page of the Active Directory Installation wizard, select Permissions compatible with pre-Windows 2000 Server operating systems.

    – Or –

    Add the Everyone group and the Anonymous Logon group to the Pre-Windows 2000 Compatible Access built-in group by using Active Directory Users and Computers or the command line.

To add the Everyone group to the Pre-Windows 2000 Compatible Access Group by using the command line

  • At the command line, type:

    net localgroup "Pre-Windows 2000 Compatible Access" Everyone /add

To add the Anonymous Logon group to the Pre-Windows 2000 Compatible Access Group by using the command line

  • At the command line, type:

    net localgroup "Pre-Windows 2000 Compatible Access" “Anonymous Logon” /add

    Note

    • After this update to the Pre-Windows 2000 Compatible Access group replicates, you must restart the Server service on all domain controllers.

Both of these methods combined allow null sessions to read information out of the directory. After you upgrade all RAS servers, and when you no longer need backward compatibility with operating systems earlier than Windows 2000, remove the Everyone group and the Anonymous Logon group from the Pre-Windows 2000 Compatible Access built-in group. For more information about removing the Everyone group and the Anonymous Logon group from the Pre-Windows 2000 Compatible Access group, see "Eliminate Anonymous Connections to Domain Controllers" later in this chapter.

LAN Manager Replication Service and the File Replication Service

In Windows NT 4.0, the LAN Manager Replication (LMRepl) service provides single master replication of logon scripts and other database information located in the NETLOGON share on a Windows NT 4.0–based domain controller that is designated as an export server to all other Windows NT 4.0–based domain controllers in the domain. LMRepl can be configured only on Windows NT 4.0–based domain controllers. In Windows 2000 and Windows Server 2003, logon scripts and profile information are stored in the NETLOGON shared folder (which contains policies and scripts for non-Active Directory clients) and the SYSVOL shared folder (which contains Group Policy files and scripts for Active Directory clients). The File Replication Service (FRS), a multimaster replication engine that runs automatically on all Windows Server 2003–based domain controllers, replaces the LMRepl service and replicates the NETLOGON and SYSVOL shared folders between domain controllers in a Windows Server 2003 domain.

During the in-place domain upgrade process, your environment includes Windows NT 4.0–based BDCs operating with Windows Server 2003–based domain controllers. FRS and LMRepl are not backward compatible. Therefore, to provide support for the LMRepl service in the Active Directory environment, you need to create a bridge between LMRepl and FRS to replicated new files created in the NETLOGON folder on Windows Server 2003 domain controllers to the Windows NT 4.0 export server. The bridge is created by using the Lbridge.cmd script and the Robocopy.exe tool so that both services can operate autonomously. Do this by selecting one Windows Server 2003–based domain controller to copy the SYSVOL shared folder to the Windows NT 4.0 export directory of the Windows NT 4.0 export server. You can use a regularly scheduled script to copy the shared folder. For more information about creating this script, see "Synchronize File Replication Services" later in this chapter.

Security Policy Considerations when Upgrading from Windows NT 4.0 to Windows Server 2003

Server message block (SMB) packet signing and secure channel signing are security policies that are enabled by default on Windows Server 2003–based domain controllers. To allow clients running earlier versions of Windows to communicate with domain controllers running Windows Server 2003, you might need to temporarily disable these security policies during the upgrade process.

SMB packet signing

SMB packet signing is a security mechanism that protects the data integrity of SMB traffic between client computers and servers, and prevents man-in-the-middle attacks by providing a form of mutual authentication. This is done by placing a digital security signature into each SMB packet, which is then verified by the receiving party. Server-side SMB signing is required by default on Windows Server 2003–based domain controllers, which means that all clients are required to have SMB packet signing enabled.

Clients running Windows NT 4.0 with Service Pack 2 or earlier, and clients running Microsoft® Windows® 95 without the Directory Service Client Pack, do not support SMB packet signing. These clients will not be able to authenticate to a Windows Server 2003–based domain controller. To ensure successful authentication, upgrade these clients to a later version of the operating system or Service Pack. However, if you cannot upgrade your clients, you can allow them to be authenticated by configuring SMB packet signing on all Windows Server 2003–based domain controllers so that SMB packet signing is preferred but not required.

For more information about SMB packet signing, see "Microsoft network server: Digitally sign communications (always)" on the Microsoft Web site.

For more information about configuring SMB packet signing on Windows Server 2003–based domain controllers, see "Modify Security Policies" later in this chapter.

For more information about the Directory Services Client Pack, see article 323466, "Availability of the Directory Services Client Update for Windows 95 and Windows 98" in the Microsoft Knowledge Base. To find this article, see the Microsoft Knowledge Base link on the Web Resources page at https://www.microsoft.com/windows/reskits/webresources.

Secure channel signing and encryption

When a computer becomes a member of a domain, a computer account is created. Each time the computer starts, it uses the computer account password to create a secure channel with a domain controller for its domain. This secure channel is used to ensure secure communications between a domain member and a domain controller for its domain. Secure channel signing is required by default on Windows Server 2003–based domain controllers, which means that all clients must enable secure channel signing and encryption.

Clients running Windows NT 4.0 with Service Pack 3 or earlier installed do not support secure channel signing. These clients will not be able to establish communications with a Windows Server 2003–based domain controller. To ensure successful communication, upgrade these clients to a later version of the operating system or Service Pack. However, if you cannot upgrade your clients, you must disable secure channel signing on all Windows Server 2003–based domain controllers so that the traffic passing through the secure channel is not required to be signed or encrypted.

Note

  • Unlike SMB packet signing, secure channel signing does not affect Windows 95 clients.

For more information about secure channel signing, see "Domain member: Digitally encrypt or sign secure channel data (always)" in Help and Support Center for Windows Server 2003.

For more information about configuring secure channel signing on Windows Server 2003–based domain controllers, see "Modify Security Policies" later in this chapter.