Windows Server Members Still Authenticate with BDCs After PDC Is Upgraded (309273)

SYMPTOMS

In a Microsoft Windows NT 4.0 domain that includes Windows Server or Windows XP-based member computers, when you upgrade the Primary Domain Controller (PDC) to Windows Server, you may experience the following symptoms:

The Windows Server or Windows XP-based member computers may continue to use a Windows NT 4.0 Backup Domain Controller (BDC) for authentication.
In Windows Server, specific attributes on the computer account (dNSHostName and servicePrincipalName) may be missing.
When you log on to the workstations, "Directory" may be missing under "Entire Network" in "My Network Places".
In network traces from affected domain members, you may see Kerberos errors on logon. This is because many computer accounts do not have the servicePrincipalName attribute that is required to issue Kerberos tickets.
Windows Server members only apply downlevel machine policies and not machine policies that are defined on sites, domains and organizational units in Active Directory.
The domain that the computer is joined to lists the NetBIOS name of the domain instead of the fully qualified domain name (FQDN) when Windows Server members have established encrypted channels to Windows Server domain controllers in a mixed-mode, mixed-version domain.

CAUSE

This behavior may occur because Windows Server or Windows XP-based member computers that are joined to a Windows NT 4.0 domain that is later upgraded to Windows Server Active Directory do not actively discover or establish encrypted channels with Windows Server domain controllers. Because of this, Active Directory features such as Kerberos authentication, Active Directory policies, and site-based domain controller discovery are not enabled.

The only certain way for a Windows Server or Windows XP-based member computer to learn that its domain contains Windows Server domain controllers is for the member computer to query the primary domain controller for the version of its operating system. In a large domain, this operation could overload the PDC with session and authentication requests. To avoid this overload scenario, Windows Server-based or Windows XP-based member computers continue to establish encrypted channels with existing downlevel domain controllers until Windows Server domain controllers are "discovered".

In a network trace you can see that the client sends logon requests to all domain controllers that are returned in the WINS 1C response and also tries other means (such as broadcasts) to locate domain controllers. Both Windows NT 4.0 and Windows Server domain controllers may respond to the logon request, but in the end the client will establish an encrypted channel and authenticate with the domain controller that first responds. The user logon authentication may later occur by using Kerberos with a Windows Server domain controller.

MORE INFORMATION

In Windows 2000 Service Pack 2, support was added for Nt4emulator. Nt4emulator makes uplevel domain controllers in a Windows NT 4.0 domain behave as Windows NT 4.0 domain controllers. This prevents uplevel clients from detecting and possibly overloading the uplevel domain controllers. There are settings that can accelerate or delay the discovery of Windows Server domain controllers by domain members with downlevel encrypted channels.

For WINS, read the following Microsoft Knowledge Base article:
269424 WINS Prepend1BTo1CQueries Feature Aids Load-Balancing
Stack the WINS 1C list on WINS servers with static registrations for Windows Server or Windows NT 4.0 domain controllers to be used for logon authentication.
The NETBIOS node type, this is configurable through DHCP options on DHCP servers or the Windows registry that defines the order and type of name resolution clients that are used to discover domain controllers.

You can also use an LMHOSTS file to have better control of which domain controllers the member will find. For additional information about this, click the article number below to view the article in the Microsoft Knowledge Base:

180094 How to Write an LMHOSTS File for Domain Validation

Windows Server and Windows XP members will create a encrypted channel with Windows Server domain controllers when the following conditions are true:

A Windows Server domain controller responds first to the logon requests when the member boots up.
The encrypted channel is manually reset to a Windows Server domain controller by using the netdom reset or nltest /sc_reset command.
Create a new computer account and rejoin the domain member to the domain.

At this point the member will learn the DNS name of the domain and store it in an LSA secret. The next time the member computer is rebooted, all components in the system will learn about the DNS domain name.

At this time, the dnsHostName and servicePrincipalName properties will be updated on the computer object in Active Directory, and the FQDN will appear in My Computer, under Properties.