How Domain Controllers Are Located in Windows

This article describes the mechanism used by Windows to locate a domain controller in a Windows-based domain.

This article applies to Windows 2000. Support for Windows 2000 ends on July 13, 2010. The Windows 2000 End-of-Support Solution Center is a starting point for planning your migration strategy from Windows 2000. For more information, see the Microsoft Support Lifecycle Policy.

Original product version: В Windows Server 2019, Windows Server 2016, Windows Server 2012 R2
Original KB number: В 247811

Summary

This article details the process of locating a domain by its DNS-style name and its flat-style (NetBIOS) name. The flat-style name is used for backward compatibility. In all other cases, DNS-style names should be used as a matter of policy. This article also addresses troubleshooting the domain controller location process.

More information

This sequence describes how the Locator finds a domain controller:

On the client (the computer that is locating the domain controller), the Locator is initiated as a remote procedure call (RPC) to the local Netlogon service. The Locator DsGetDcName application programming interface (API) call is implemented by the Netlogon service.

The client collects the information that is needed to select a domain controller and passes the information to the Netlogon service by using the DsGetDcName call.

The Netlogon service on the client uses the collected information to look up a domain controller for the specified domain in one of two ways:

For a DNS name, Netlogon queries DNS by using the IP/DNS-compatible Locator—that is, DsGetDcName calls the DnsQuery call to read the Service Resource (SRV) records and «A» records from DNS after it appends the domain name to the appropriate string that specifies the SRV records.

A workstation that is logging on to a Windows-based domain queries DNS for SRV records in the general form:

Active Directory servers offer the Lightweight Directory Access Protocol (LDAP) service over the TCP protocol. Therefore, clients find an LDAP server by querying DNS for a record of the form:

For a NetBIOS name, Netlogon performs domain controller discovery by using the Microsoft Windows NT version 4.0-compatible Locator (that is, by using the transport-specific mechanism (for example, WINS).

In Windows NT 4.0 and earlier, «discovery» is a process for locating a domain controller for authentication in either the primary domain or a trusted domain.

The Netlogon service sends a datagram to the computers that registered the name. For NetBIOS domain names, the datagram is implemented as a mailslot message. For DNS domain names, the datagram is implemented as an LDAP User Datagram Protocol (UDP) search. (UDP is the connectionless datagram transport protocol that is part of the TCP/IP protocol suite. TCP is a connection-oriented transport protocol.)

Each available domain controller responds to the datagram to indicate that it is currently operational and returns the information to DsGetDcName.

UDP allows a program on one computer to send a datagram to a program on another computer. UDP includes a protocol port number, which allows the sender to distinguish among multiple destinations (programs) on the remote computer.

• Each available domain controller responds to the datagram to indicate that it is currently operational and returns the information to DsGetDcName.
• The Netlogon service caches the domain controller information so that subsequent requests need not repeat the discovery process. Caching this information encourages consistent use of the same domain controller and a consistent view of Active Directory.

When a client logs on or joins the network, it must be able to locate a domain controller. The client sends a DNS Lookup query to DNS to find domain controllers, preferably in the client’s own subnet. Therefore, clients find a domain controller by querying DNS for a record of the form:

After the client locates a domain controller, it establishes communication by using LDAP to gain access to Active Directory. As part of that negotiation, the domain controller identifies which site the client is in based on the IP subnet of that client. If the client is communicating with a domain controller that is not in the closest (most optimal) site, the domain controller returns the name of the client’s site. If the client has already tried to find domain controllers in that site (for example, when the client sends a DNS Lookup query to DNS to find domain controllers in the client’s subnet), the client uses the domain controller that is not optimal. Otherwise, the client performs a site-specific DNS lookup again with the new optimal site name. The domain controller uses some of the directory service information for identifying sites and subnets.

After the client locates a domain controller, the domain controller entry is cached. If the domain controller is not in the optimal site, the client flushes the cache after fifteen minutes and discards the cache entry. It then attempts to find an optimal domain controller in the same site as the client.

After the client has established a communications path to the domain controller, it can establish the logon and authentication credentials and, if necessary for Windows-based computers, set up a secure channel. The client then is ready to perform normal queries and search for information against the directory.

The client establishes an LDAP connection to a domain controller to log on. The logon process uses Security Accounts Manager. Because the communications path uses the LDAP interface and the client is authenticated by a domain controller, the client account is verified and passed through Security Accounts Manager to the directory service agent, then to the database layer, and finally to the database in the Extensible Storage engine (ESE).

Troubleshooting the Domain Locator Process

To troubleshoot the domain locator process:

Check Event Viewer on both the client and the server. The event logs may contain error messages indicating that there is a problem. To view Event Viewer, click Start, point to Programs, point to Administrative Tools, and then click Event Viewer. Check the System log on both the client and the server. Also, check the Directory Service logs on the server and DNS logs on the DNS server.

Check the IP configuration by using the ipconfig /all command at a command prompt.

Use the Ping utility to verify network connectivity and name resolution. Ping both the IP address and the server name. You may also want to ping the domain name.

Use the Netdiag tool to determine whether networking components are working correctly. To send detailed output to a text file, use the following command:

netdiag /v >test.txt
Review the log file, looking for problems, and investigate any implicated components. This file also contains other network configuration details.

To fix minor problems, use the Netdiag tool with the following syntax: netdiag /fix .

Use the nltest /dsgetdc:domainname command to verify that a domain controller can be located for a specific domain.

Use the NSLookup tool to verify that DNS entries are correctly registered in DNS. Verify that the server host records and GUID SRV records can be resolved.

For example, to verify record registration, use the following commands:
nslookup servername. childofrootdomain. rootdomain.com
nslookup guid._msdcs. rootdomain.com

If either of these commands does not succeed, use one of the following methods to reregister records with DNS:

• To force host record registration, type ipconfig /registerdns.
• To force domain controller service registration, stop and start the Netlogon service.

To detect domain controller problems, run the DCdiag utility from a command prompt. The utility runs a number of tests to verify that a domain controller is running correctly. Use this command to send the results to a text file: dcdiag /v >dcdiag.txt

Use the Ldp.exe tool to connect and bind to the domain controller to verify appropriate LDAP connectivity.

If you suspect that a particular domain controller has problems, it may be helpful to turn on Netlogon debug logging. Use the NLTest utility by typing this command: nltest /dbflag:0x2000ffff . The information is then logged in the Debug folder in the Netlogon.log file.

If you still have not isolated the problem, use Network Monitor to monitor network traffic between the client and the domain controller.

References

For more information, see the Windows Resource Kit, Chapter 10, «Active Directory Diagnostic, Troubleshooting, and Recovery.»

Trust between a Windows NT domain and an Active Directory domain can’t be established or it doesn’t work as expected

This article describes the trust configuration issues between a Windows NT 4.0-based domain and an Active Directory-based domain.

Original product version:  Windows 10 – all editions, Windows Server 2012 R2
Original KB number: В 889030

Symptoms

If you try to set up a trust between a Microsoft Windows NT 4.0-based domain and an Active Directory-based domain, you may experience either of the following symptoms:

• The trust isn’t established.
• The trust is established, but the trust doesn’t work as expected.

Additionally, you may receive any of the following error messages:

The following error occurred attempting to join the domain «Domain_Name«: The account is not authorized to log in from this station.

No domain controller could be contacted.

Logon failure: unknown username or bad password.

When you use the object picker in Active Directory Users and Computers to add users from the NT 4.0 domain to the Active Directory domain, you may receive the following error message:

No items match the current search. Check your search parameters, and try again.

Cause

This issue occurs because of a configuration issue in any one of the following areas:

• Name resolution
• Security settings
• User rights
• Group membership for Microsoft Windows 2000 or Microsoft Windows Server 2003

To correctly identify the cause of the issue, you must troubleshoot the trust configuration.

Resolution

If you receive the «No items match the current search» error message when you use the object picker in Active Directory Users and Computers, make sure that the domain controllers in the NT 4.0 domain include Everyone in the Access this computer from the network user right. In this scenario, the object picker tries to connect anonymously across the trust. To verify these settings, follow the steps in the «Method three: Verify the user rights» section.

To troubleshoot trust configuration issues between a Windows NT 4.0-based domain and Active Directory, you must verify the correct configuration of the following areas:

• Name resolution
• Security settings
• User rights
• Group membership for Microsoft Windows 2000 or Microsoft Windows Server 2003

To do this, use the following methods.

Method one: Verify the correct configuration of name resolution

Step 1: Create an LMHOSTS file

Create an LMHOSTS file on the primary domain controllers to provide cross-domain name resolution capability. The LMHOSTS file is a text file that you can edit with any text editor, such as Notepad. The LMHOSTS file on each domain controller must contain the TCP/IP address, the domain name, and the \0x1b entry of the other domain controller.

After you create the LMHOSTS file, follow these steps:

Modify the file so that it contains text that is similar to the following text:

1.1.1.1 #DOM: #PRE
1.1.1.1 » \0x1b»#PRE
2.2.2.2 #DOM: #PRE
2.2.2.2 » \0x1b»#PRE

There must be a total of 20 characters and spaces between the quotation marks (» «) for the \0x1b entry. Add spaces after the domain name so that it uses 15 characters. The 16th character is the backslash that is followed by the «0x1b» value, and this makes a total of 20 characters.

When you finish the changes to the LMHOSTS file, save the file to the %SystemRoot% \System32\Drivers\Etc folder on the domain controllers. For more information about the LMHOSTS file, view the Lmhosts.sam sample file that is located in the %SystemRoot% \System32\Drivers\Etc folder.

Step 2: Load the LMHOSTS file into the cache

Click Start, click Run, type cmd, and then click OK.

At the command prompt, type NBTSTAT -R , and then press ENTER. This command loads the LMHOSTS file into the cache.

At the command prompt, type NBTSTAT -c , and then press ENTER. This command displays the cache. If the file is written correctly, the cache is similar to the following:

NT4PDCName UNIQUE 1.1.1.1 -1
NT4PDCName UNIQUE 1.1.1.1 -1
NT4PDCName UNIQUE 1.1.1.1 -1
NT4DomainName GROUP 1.1.1.1 -1
NT4DomainName UNIQUE 1.1.1.1 -1
W2KPDCName UNIQUE 2.2.2.2 -1
W2KPDCName UNIQUE 2.2.2.2 -1
W2KPDCName UNIQUE 2.2.2.2 -1
W2KDomainName GROUP 2.2.2.2 -1
W2KDomainName UNIQUE 2.2.2.2 -1

If the file doesn’t populate the cache correctly, continue with the next step.

Step 3: Make sure that the LMHOSTS lookup is enabled on the Windows NT 4.0-based computer

If the file doesn’t populate the cache correctly, make sure that LMHOSTS lookup is enabled on the Windows NT 4.0-based computer. To do this, follow these steps:

1. Click Start, point to Settings, and then click Control Panel.
2. Double-click Networks, click the Protocols tab, and then double-click TCP/IP Protocol.
3. Click the WINS Address tab, and then click to select the Enable LMHOSTS Lookup check box.
4. Restart the computer.
5. Repeat the steps in the «Load the LMHOSTS file into the cache» section.
6. If the file doesn’t populate the cache correctly, make sure that the LMHOSTS file is in the %SystemRoot%\System32\Drivers\Etc folder and that the file is formatted correctly.

For example, the file must be formatted similar to the following example formatting:

1.1.1.1 NT4PDCName #DOM:NT4DomainName#PRE
1.1.1.1 «NT4DomainName \0x1b»#PRE
2.2.2.2 W2KPDCName #DOM:W2KDomainName#PRE
2.2.2.2 «W2KDomainName \0x1b»#PRE

There must be a total of 20 characters and spaces inside the quotations marks (» «) for the Domain name and \0x1b entry.

Step 4: Use the Ping command to test connectivity

When the file populates the cache correctly on each server, use the Ping command on each server to test connectivity between the servers. To do this, follow these steps:

Click Start, click Run, type cmd, and then click OK.

At the command prompt, type Ping , and then press ENTER. If the Ping command doesn’t work, make sure that the correct IP addresses are listed in the LMHOSTS file.

At the command prompt, type net view , and then press ENTER. It’s expected that you receive the following error message:

System error 5 has occurred. Access is denied

If the net view command returns the following error message or any other related error message, make sure that the correct IP addresses are listed in the LMHOSTS file:

System error 53 has occurred. The network path was not found

Alternatively, Windows Internet Name Service (WINS) can be configured to enable name resolution functionality without using an LMHOSTS file.

Method two: View security settings

Typically, the Active Directory side of the trust configuration has security settings that cause connectivity problems. However, the security settings must be inspected on both sides of the trust.

Step 1: View security settings on Windows 2000 Server and Windows Server 2003

In Windows 2000 Server and Windows Server 2003, the security settings may be applied or configured by Group Policy, a local policy, or an applied security template.

You must use the correct tools to determine the current values of the security settings to avoid inaccurate readings.

To obtain an accurate reading of the current security settings, use the following methods:

In Windows 2000 Server, use the Security Configuration and Analysis snap-in.

In Windows Server 2003, use either the Security Configuration and Analysis snap-in, or the Resultant Set of Policy (RSoP) snap-in.

After you determine the current settings, you must identify the policy that is applying the settings. For example, you must determine the Group Policy in the Active Directory, or the local settings that set the security policy.

In Windows Server 2003, the policy that sets the security values is identified by the RSoP tool. However, in Windows 2000 you must view the Group Policy and the local policy to determine the policy that contains the security settings:

To view the Group Policy settings, you must enable logging output for the Microsoft Windows 2000 Security Configuration Client during Group Policy processing.

View the Application login Event Viewer and find Event ID 1000 and event ID 1202.

The following three sections identify the operating system and list the security settings that you must verify for the operating system in the information that you’ve collected:

Windows 2000

Make sure that the following settings are configured as shown.

Additional restrictions for anonymous connections	«None. Rely on default permissions»

LAN Manager authentication level	«Send NTLM response only»

SMB Signing, SMB Encrypting, or both:

Digitally sign client communications (always)	DISABLED
Digitally sign client communications (when it is possible)	ENABLED
Digitally sign server communications (always)	DISABLED
Digitally sign server communications (when it is possible)	ENABLED
Secure channel: Digitally encrypt or sign secure channel data (always)	DISABLED
Secure channel: Digitally encrypt secure channel data (when it is possible)	DISABLED
Secure channel: Digitally sign secure channel data (when it is possible)	DISABLED
Secure channel: Require strong (Windows 2000 or later) session key	DISABLED

Windows Server 2003

Make sure that the following settings are configured as shown.

RestrictAnonymous and RestrictAnonymousSam:

Network access: Allow anonymous SID/Name translation	ENABLED
Network access: Do not allow anonymous enumeration of SAM accounts	DISABLED
Network access: Do not allow anonymous enumeration of SAM accounts and shares	DISABLED
Network access: Let Everyone permissions apply to anonymous users	ENABLED
Network access: Named pipes can be accessed anonymously	ENABLED
Network access: Restrict anonymous access to Named Pipes and shares	DISABLED

By default, the value of the Network access: Allow anonymous SID/Name translation setting is DISABLED in Windows Server 2008.

Network security: LAN Manager authentication level	«Send NTLM response only»

SMB Signing, SMB Encrypting, or both:

Microsoft network client: Digitally sign communications (always)	DISABLED
Microsoft network client: Digitally sign communications (if server agrees)	ENABLED
Microsoft network server: Digitally sign communications (always)	DISABLED
Microsoft network server: Digitally sign communications (if client agrees)	ENABLED
Domain member: Digitally encrypt or sign secure channel data (always)	DISABLED
Domain member: Digitally encrypt secure channel data (when it is possible)	ENABLED
Domain member: Digitally sign secure channel data (when it is possible)	ENABLED
Domain member: Require strong (Windows 2000 or later) session key	DISABLED

After the settings are configured correctly, you must restart your computer. The security settings are not enforced until the computer is restarted.

After the computer restarts, wait 10 minutes to make sure that all security policies are applied and the effective settings are configured. We recommend that you wait 10 minutes because Active Directory policy updates occur every 5 minutes on a domain controller, and the update may change the security setting values. After 10 minutes, use Security Configuration and Analysis or another tool to examine the security settings in Windows 2000 and Windows Server 2003.

Windows NT 4.0

This section, method, or task contains steps that tell you how to modify the registry. However, serious problems might occur if you modify the registry incorrectly. Therefore, make sure that you follow these steps carefully. For added protection, back up the registry before you modify it. Then, you can restore the registry if a problem occurs. For more information about how to back up and restore the registry, click the following article number to view the article in the Microsoft Knowledge Base: 322756 How to back up and restore the registry in Windows

In Windows NT 4.0, the current security settings must be verified by using the Regedt32 tool to view the registry. To do this, follow these steps:

Click Start, click Run, type regedt32, and then click OK.

Expand the following registry subkeys, and then view the value that is assigned to the RestrictAnonymous entry:

Expand the following registry subkeys, and then view the value that is assigned to the LM Compatibility entry:

Expand the following registry subkeys, and then view the value that is assigned to the EnableSecuritySignature (server) entry:

Expand the following registry subkeys, and then view the value that is assigned to the RequireSecuritySignature (server) entry:

Expand the following registry subkeys, and then view the value that is assigned to the RequireSignOrSeal entry:

Expand the following registry subkeys, and then view the value that is assigned to the SealSecureChannel entry:

Expand the following registry subkeys, and then view the value that is assigned to the SignSecureChannel entry:

Expand the following registry subkeys, and then view the value that is assigned to the RequireStrongKey entry:

Method three: Verify the user rights

To verify the required user rights on a Windows 2000-based computer, follow these steps:

1. Click Start, point to Programs, point to Administrative Tools, and then click Local Security Policy.
2. Expand Local Policies, and then click User Rights Assignment.
3. In the right-pane, double-click Access this computer from the network.
4. Click to select the Local Policy Setting check box next to the Everyone group in the Assigned to list, and then click OK.
5. Double-click Deny access to this computer from the network.
6. Verify that there are no principle groups in the Assigned to list, and then click OK. For example, make sure that Everyone, Authenticated Users, and other groups aren’t listed.
7. Click OK, and then quit Local Security Policy.

To verify the required user rights on a Windows Server 2003-based computer, follow these steps:

Click Start, point to Administrative Tools, and then click Domain Controller Security Policy.

Expand Local Policies, and then click User Rights Assignment.

In the right-pane, double-click Access this computer from the network.

Make sure that the Everyone group is in the Access this computer from the network list.

If the Everyone group isn’t listed, follow these steps:

1. Click Add User or Group.
2. In the User and group names box, type Everyone, and then click OK.

Double-click Deny access to this computer from the network.

Verify that there are no principle groups in the Deny access to this computer from the network list, and then click OK. For example, make sure that Everyone, Authenticated Users, and other groups, aren’t listed.

Click OK, and then close the Domain Controller Security Policy.

To verify the required user rights on a Windows NT Server 4.0-based computer, follow these steps:

Click Start, point to Programs, point to Administrative Tools, and then click User Manager for Domains.

On the Policies menu, click User Rights.

In the Right list, click Access this computer from the network.

In the Grant to box, make sure that the Everyone group is added.

If the Everyone group isn’t added, follow these steps:

1. Click Add.
2. In the Names list, click Everyone, click Add, and then click OK.

Click OK, and then quit User Manager.

Method four: Verify group membership

If a trust is set up between the domains, but you can’t add principle user groups from one domain to the other because the dialog box doesn’t locate the other domain objects, the «Pre-Windows 2000 compatible access» group may not have the correct membership.

On the Windows 2000-based domain controllers and the Windows Server 2003-based domain controllers, make sure that the required group memberships are configured.

To do this on the Windows 2000-based domain controllers, follow these steps:

Click Start, point to Programs, point to Administrative Tools, and then click Active Directory Users and Computers.

Click Built in, and then double-click Pre-Windows 2000 compatible access group.

Click the Members tab, and then make sure that the Everyone group is in the Members list.

If the Everyone group isn’t in the Members list, follow these steps:

1. Click Start, click Run, type cmd, and then click OK.
2. At the command prompt, type net localgroup «Pre-Windows 2000 Compatible Access» everyone /add , and then press ENTER.

To make sure that the required group memberships are configured on the Windows Server 2003-based domain controllers, you must know if the «Network access: Let Everyone permissions apply to anonymous users» policy setting is disabled. If you don’t know, use the Group Policy Object Editor to determine the state of the «Network access: Let Everyone permissions apply to anonymous users» policy setting. To do this, follow these steps:

Click Start, click Run, type gpedit.msc, and then click OK.

Expand the following folders:

Local Computer Policy
Computer Configuration
Windows Settings
Security Settings
Local Policies

Click Security Options, and then click Network access: Let Everyone permissions apply to anonymous users in the right pane.

Note if the value in the Security Setting column is Disabled or Enabled.

To make sure that the required group memberships are configured on the Windows Server 2003-based domain controllers, follow these steps:

Click Start, point to Programs, point to Administrative Tools, and then click Active Directory Users and Computers.

Click Built in, and then double-click Pre-Windows 2000 compatible access group.

Click the Members tab.

If the Network access: Let Everyone permissions apply to anonymous users policy setting is disabled, make sure that the Everyone, Anonymous Logon group is in the Members list. If the «Network access: Let Everyone permissions apply to anonymous users» policy setting is enabled, make sure that the Everyone group is in the Members list.

If the Everyone group isn’t in the Members list, follow these steps:

1. Click Start, click Run, type cmd, and then click OK.
2. At the command prompt, type net localgroup «Pre-Windows 2000 Compatible Access» everyone /add , and then press ENTER.

Method five: Verify connectivity through network devices, such as firewalls, switches, or routers

If you’ve received error messages that are similar to the following error message and you’ve verified that the LMHOST files are correct, the issue may be caused by a firewall, router, or switch that has blocked ports between the domain controllers:

No domain controller could be contacted

To troubleshoot network devices, use PortQry Command Line Port Scanner version 2.0 to test the ports between your domain controllers.

For more information about PortQry version 2, click the following article number to view the article in the Microsoft Knowledge Base:

832919 New features and functionality in PortQry version 2.0

For more information about how the ports must be configured, click the following article number to view the article in the Microsoft Knowledge Base:

179442 How to configure a firewall for domains and trusts

Method six: Gather additional information to help troubleshoot the issue

If the previous methods did not help you resolve the issue, collect the following additional information to help you troubleshoot the cause of the issue:

Enable Netlogon logging on both domain controllers. For more information about how to complete Netlogon logging, click the following article number to view the article in the Microsoft Knowledge Base: 109626 Enabling debug logging for the Net Logon service

Capture a trace on both domain controllers at the same time that the issue occurs.

More information

The following list of Group Policy objects (GPOs) provides the location of the corresponding registry entry and the Group Policy in the applicable operating systems:

The RestrictAnonymous GPO:

• Windows NT registry location: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Rdr\Parameters
• Windows 2000 and Windows Server 2003 registry location: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA
• Windows 2000 Group Policy: Computer Configuration\Windows Settings\Security Settings\ Security Options Additional restrictions for anonymous connections
• Windows Server 2003 Group Policy: Computer Configuration\Windows Settings\Security Settings\Security Options Network access: Do not allow anonymous enumeration of SAM accounts and shares

The RestrictAnonymousSAM GPO:

• Windows Server 2003 registry location: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA
• Windows Server 2003 Group Policy: Computer Configuration\Windows Settings\Security Settings Security Options Network access: Do not allow anonymous enumeration of SAM accounts and shares

The EveryoneIncludesAnonymous GPO:

• Windows Server 2003 registry location: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA
• Windows Server 2003 Group Policy: Computer Configuration\Windows Settings\Security Settings\Security Options Network access: Let Everyone permissions apply to anonymous users

The LM Compatibility GPO:

Windows NT, Windows 2000, and Windows Server 2003 registry location: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\LMCompatibilityLevel

Windows 2000 Group Policy: Computer Configuration\Windows Settings\Security Settings\Security Options: LAN Manager authentication level

Windows Server 2003 Group Policy: Computer Configuration\Windows Settings\Security Settings\Security Options\Network security: LAN Manager authentication level

The EnableSecuritySignature (client) GPO:

• Windows 2000 and Windows Server 2003 registry location: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanManWorkstation\Parameters\EnableSecuritySignature
• Windows 2000 Group Policy: Computer Configuration\Windows Settings\Security Settings \Security Options: Digitally sign client communication (when possible)
• Windows Server 2003 Group Policy: Computer Configuration\Windows Settings\Security Settings\Security Options\Microsoft network client: Digitally sign communications (if server agrees)

The RequireSecuritySignature (client) GPO:

• Windows 2000 and Windows Server 2003 registry location: HKey_Local_Machine\System\CurrentControlSet\Services\LanManWorkstation\Parameters\RequireSecuritySignature
• Windows 2000 Group Policy: Computer Configuration\Windows Settings\Security Settings\Security Options: Digitally sign client communication (always)
• Windows Server 2003: Computer Configuration\Windows Settings\Security Settings\Security Options\Microsoft network client: Digitally sign communications (always)

The EnableSecuritySignature (server) GPO:

• Windows NT registry location: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Rdr\Parameters\EnableSecuritySignature
• Windows 2000 and Windows Server 2003 registry location: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanManServer\Parameters\EnableSecuritySignature
• Windows 2000 Group Policy: Digitally sign server communication (when possible)
• Windows Server 2003 Group Policy: Microsoft network server: Digitally sign communications (if client agrees)

The RequireSecuritySignature (server) GPO:

• Windows NT registry location: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Rdr\Parameters\RequireSecurityS ignature
• Windows 2000 and Windows Server 2003 registry location: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanManServer\Parameters\Require SecuritySignature
• Windows 2000 Group Policy: Digitally sign server communication (always)
• Windows Server 2003 Group Policy: Microsoft network server: Digitally sign communications (always)

The RequireSignOrSeal GPO:

• Windows NT, Windows 2000, and Windows Server2003 registry location: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters
• Windows 2000 Group Policy: Digitally encrypt or sign secure channel data (always)
• Windows Server2003 Group Policy: Domain member: Digitally encrypt or sign secure channel data (always)

The SealSecureChannel GPO:

• Windows NT, Windows 2000, and Windows Server2003 registry location: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters
• Windows 2000 Group Policy: Secure channel: Digitally encrypt secure channel data (when possible)
• Windows Server 2003 Group Policy: Domain member: Digitally encrypt secure channel data (when possible)

The SignSecureChannel GPO:

• Windows NT, Windows 2000, and Windows Server 2003 registry location: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters
• Windows 2000 Group Policy: Secure channel: Digitally sign secure channel data (when possible)
• Windows Server 2003 Group Policy: Domain member: Digitally sign secure channel data (when possible)

The RequireStrongKey GPO:

• Windows NT, Windows 2000, and Windows Server 2003 registry location: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters
• Windows 2000 Group Policy: Secure channel: Require strong (Windows 2000 or later) session key
• Windows Server 2003 Group Policy: Domain member: Require strong (Windows 2000 or later) session key

Windows Server 2008

On a domain controller that is running Windows Server 2008, the default behavior of the Allow cryptography algorithms compatible with Windows NT 4.0 policy setting may cause a problem. This setting prevents both Windows operating systems and third-party clients from using weak cryptography algorithms to establish NETLOGON security channels to Windows Server 2008-based domain controllers.

References

For more information, click the following article numbers to view the articles in the Microsoft Knowledge Base:

823659 Client, service, and program incompatibilities that may occur when you modify security settings and user rights assignments