Trust between a Windows NT domain and an Active Directory domain cannot be established or it does not work as expected (889030)

RESOLUTION

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 one: 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. For more information about how to create the LMHOSTS file, click the following article number to view the article in the Microsoft Knowledge Base: After you create the LMHOSTS file, follow these steps:

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

   1.1.1.1	 <NT_4_PDC_Name>		 #DOM:<NT_4_Domain_Name>	#PRE
   1.1.1.1	 "<NT_4_Domain>  \0x1b"			#PRE
   2.2.2.2	 <Windows_2000_PDC_Name>		 #DOM:<Windows_2000_Domain_Name>	#PRE
   2.2.2.2	 "<2000_Domain>  \0x1b"			#PRE
   

   Note 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.
2. 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 two: Load the LMHOSTS file into the cache

1. Click Start, click Run, type cmd, and then click OK.
2. At the command prompt, type NBTSTAT -R, and then press ENTER. This command loads the LMHOSTS file into the cache.
3. 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 <03> UNIQUE 1.1.1.1 -1 
   NT4PDCName <00> UNIQUE 1.1.1.1 -1 
   NT4PDCName <20> UNIQUE 1.1.1.1 -1 
   NT4DomainName <1C> GROUP 1.1.1.1 -1 
   NT4DomainName <1B> UNIQUE 1.1.1.1 -1
   W2KPDCName <03> UNIQUE 2.2.2.2 -1 
   W2KPDCName <00> UNIQUE 2.2.2.2 -1 
   W2KPDCName <20> UNIQUE 2.2.2.2 -1 
   W2KDomainName <1C> GROUP 2.2.2.2 -1 
   W2KDomainName <1B> UNIQUE 2.2.2.2 -1

   If the file does not populate the cache correctly, continue with the next step.

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

If the file does not 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 does not 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
   

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

Step four: 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:

1. Click Start, click Run, type cmd, and then click OK.
2. At the command prompt, type Ping Name_Of_Domain_Controller_You_Want_To_Connect_To, and then press ENTER. If the Ping command does not work, make sure that the correct IP addresses are listed in the LMHOSTS file.
3. At the command prompt, type net view Name_Of_Domain_Controller_You_Want_To_Connect_To, and then press ENTER. It is 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 a LMHOSTS file. For more information about how to use WINS for name resolution, click the following article number to view the article in the Microsoft Knowledge Base:

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 one: 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. For more information about how to determine the current security policy on a Windows 2000-based computer, click the following article number to view the article in the Microsoft Knowledge Base:

  258595 Gpresult does not enumerate the resultant computer security policy

• In Windows Server 2003, use either the Security Configuration and Analysis snap-in, or the Resultant Set of Policy (RSoP) snap-in. For more information about how to use the Resultant Set of Policy snap-in, click the following article number to view the article in the Microsoft Knowledge Base:

  323276 How to install and use RSoP in Windows Server 2003

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. For more information about how to enable logging output for the Microsoft Windows 2000 Security Configuration Client during Group Policy processing, click the following article number to view the article in the Microsoft Knowledge Base:

  245422 How to enable logging for security configuration client processing in Windows 2000

• View the Application log in Event Viewer and find Event ID 1000 and event ID 1202. For more information about event ID 1000 and event ID 1202, click the following article number to view the article in the Microsoft Knowledge Base:

  319352 Event ID 1000 and event ID 1202 are logged to the event log every five minutes in Windows 2000 Server

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 have collected:Windows 2000Make sure that the following settings are configured as shown.

RestrictAnonymous:

Additional restrictions for anonymous connections

"None. Rely on default permissions"

LM Compatibility:

LAN Manager authentication level

"LM & NTLM responses" or "Send LM & NTLM - use NTLMV2 session security if negotiated"

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 2003Make 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

LM Compatibility:

Network security: LAN Manager authentication level

"LM & NTLM responses" or "Send LM & NTLM - use NTLMV2 session security if negotiated"

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

Warning Serious problems might occur if you modify the registry incorrectly by using Registry Editor or by using another method. These problems might require that you reinstall your operating system. Microsoft cannot guarantee that these problems can be solved. Modify the registry at your own risk.

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:

1. Click Start, click Run, type regedt32, and then click OK.
2. Expand the following registry subkeys, and then view the value that is assigned to the RestrictAnonymous entry:

   HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Rdr\Parameters

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

   HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\LMCompatibilityLevel

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

   HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Rdr\Parameters\EnableSecuritySignature

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

   HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Rdr\Parameters\RequireSecuritySignature

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

   HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters

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

   HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters

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

   HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters

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

   HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters

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, are not 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:

1. Click Start, point to Administrative Tools, and then click Domain Controller 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. Make sure that the Everyone group is in the Access this computer from the network list. If the Everyone group is not listed, follow these steps:
   1. Click Add User or Group.
   2. In the User and group names box, type Everyone, 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 Deny access to this computer from the network list, and then click OK. For example, make sure that Everyone, Authenticated Users, and other groups, are not listed.
7. 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:

1. Click Start, point to Programs, point to Administrative Tools, and then click User Manager for Domains.
2. On the Policies menu, click User Rights.
3. In the Right list, click Access this computer from the network.
4. In the Grant to box, make sure that the Everyone group is added. If the Everyone group is not added, follow these steps:
   1. Click Add.
   2. In the Names list, click Everyone, click Add, and then click OK.
5. Click OK, and then quit User Manager.

Method four: Verify group membership

If a trust is set up between the domains, but you cannot add principle user groups from one domain to the other because the dialog box does not 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:

1. Click Start, point to Programs, point to Administrative Tools, and then click Active Directory Users and Computers.
2. Click Built in, and then double-click Pre-Windows 2000 compatible access group.
3. Click the Members tab, and then make sure that the Everyone group is in the Members list.
4. If the Everyone group is not 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 do not 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:

1. Click Start, click Run, type gpedit.msc, and then click OK.
2. Expand the following folders:

   Local Computer Policy
   Computer Configuration
   Windows Settings
   Security Settings
   Local Policies

3. Click Security Options, and then click Network access: Let Everyone permissions apply to anonymous users in the right pane.
4. 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:

1. Click Start, point to Programs, point to Administrative Tools, and then click Active Directory Users and Computers.
2. Click Built in, and then double-click Pre-Windows 2000 compatible access group.
3. Click the Members tab.
4. 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.
5. If the Everyone group is not 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 have received error messages that are similar to the following error message and you have 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: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: For more information about how the ports must be configured, click the following article number to view the article in the Microsoft Knowledge Base:

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. For more information about how to capture network traffic, click the following article number to view the article in the Microsoft Knowledge Base:

  812953 How to use Network Monitor to capture network traffic