Microsoft KB Archive Search

Notice: This website is an unofficial Microsoft Knowledge Base (hereinafter KB) archive and is intended to provide a reliable access to deleted content from Microsoft KB. All KB articles are owned by Microsoft Corporation. Read full disclaimer for more details.

  1. Home
  2. The Net Logon service on Windows Server 2008 and newer domain controllers do not allow the use of older cryptography algorithms that are compatible with Windows NT 4.0 by default

The Net Logon service on Windows Server 2008 and newer domain controllers do not allow the use of older cryptography algorithms that are compatible with Windows NT 4.0 by default

View products that this article applies to.

Important This article contains information about how to modify the registry. Make sure that you back up the registry before you modify it. Make sure that you know how to restore the registry if a problem occurs. For more information about how to back up, restore, and modify 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

↑ Back to the top

Symptoms

Note Windows NT 4.0 is past the Microsoft support life cycle period. Scenarios that are relevant to Windows NT 4.0 have not been tested and are not supported. The following information is informational only and is provided to facilitate an easier transition from Windows NT 4.0 systems. For more information about the Microsoft support life cycle policy, visit the following Microsoft Web site:
http://support.microsoft.com/lifecycle
  When a Windows NT 4.0-based computer tries to use the NETLOGON service to establish a security channel to a Windows Server 2008 or newer domain controller, the operation may fail. Hardware or software may be unable to establish a security channel to a current version Windows Server domain controller if the hardware or the software uses the cryptography algorithms that are used in Windows NT 4.0.

In this scenario, you may experience the following symptoms.

Symptom 1

You cannot log on to a domain from a Windows NT 4.0-based computer that is serviced by a Windows Server 2008 or newer domain controller. Depending on whether the credentials of the domain logon account are cached on the Windows NT 4.0-based computer, you may receive one of the following error messages:

Error message 1
The system cannot log you on now because the domain DomainName is not available.
Error message 2
A domain controller for your domain could not be contacted. You have been logged on using cached account information. Changes to your profile since you last logged on may not be available.

Symptom 2

Trusts that exist between Windows NT 4.0 domains and current Windows Server domains may not work. You may successfully create the initial trust. However, when you try to validate the trust by using the Domain.msc Microsoft Management Console (MMC) snap-in, the validation may fail. Additionally, you receive the following error message:
The operation failed with error code 317 (0x0000013d)

Symptom 3

A SAMBA SMB client cannot perform a domain join operation to a Windows Server 2008 or newer domain controller. Or, a SAMBA Server Message Block (SMB) client cannot establish a security channel to a current Windows Server domain controller.

Additionally, the Windows Server domain controller that processes the security channel request returns the following error code:
Hex: 0x4F1h
Decimal: 1265
Symbolic Error: ERROR_DOWNGRADE_DETECTED
Short Error: "STATUS_DOWNGRADE_DETECTED"
Friendly Error: The system detected a possible attempt to compromise security. Please ensure that you can contact the server that authenticated you.
Note The "STATUS_DOWNGRADE_DETECTED" error has multiple root causes. Therefore, this error does not necessarily indicate that you are experiencing symptom 3.

Symptom 4

A SMB storage device may be unable to use weak cryptography algorithms to establish a security channel to a Windows Server 2008-based domain controller.

Note SMB storage devices are also known as IP storage devices.

On the authenticating domain controller, the following errors are logged in the System log:

Error 1
Log Name: System
Source: NETLOGON
Date: Date: Time
Event ID: 5805
Task Category: None
Level: Error
User: N/A
Computer: AuDomainName
Description: The session setup from the computer <client computer> failed to authenticate. The following error occurred: Access is denied.
Note AuDomainName represents the name of the authenticating domain controller.

Error 2
Log Name: System
Source: NETLOGON
Date: Date: Time
Event ID: 5722
Task Category: None
Level: Error
Keywords: Classic
User: N/A
Computer: AuDomainName
Description: The session setup from the computer ClientComputerName failed to authenticate. The name(s) of the account(s) referenced in the security database is ClientComputerName$. The following error occurred: The system detected a possible attempt to compromise security. Please ensure that you can contact the server that authenticated you.

Currently, you experience symptom 4 on the following SMB storage device:
  • EMC Celerra
Contact the device vendor to see whether an update for this problem is available.

Additionally, you may be unable to establish a security channel from Hewlett-Packard (HP) Advanced Server for OpenVMS to a Windows Server 2008 or newer domain controller. Specifically, the current Windows Server 2008 domain controller returns the following error code to the OpenVMS NetrServerAuthenticate request:
Hex: 0x4F1h
Decimal: 1265
Symbolic Error: ERROR_DOWNGRADE_DETECTED
Short Error: "STATUS_DOWNGRADE_DETECTED"
Friendly Error: The system detected a possible attempt to compromise security. Please ensure that you can contact the server that authenticated you.
Note The "STATUS_DOWNGRADE_DETECTED" error has multiple root causes. Therefore, this error does not necessarily indicate that you are experiencing symptom 4.

Symptom 5

A Windows NT 4.0 primary domain controller (PDC) cannot create an external trust between itself and a PDC emulator that is running Windows Server 2008 R2 or newer. Servers that are running at least Windows Server 2008 R2 cannot be accessed by using a Windows NT 4.0-based domain trust. Windows NT 4.0 members that are in a Windows NT 4.0-based domain also cannot access domain controllers that are running Windows Server 2008 R2 or better by using a trust. This behavior occurs even if the trust was created between a PDC that is running Windows NT 4.0 and a PDC that is running Windows Server 2008 or Windows Server 2003.

The following errors are logged in the System log on a PDC that is running Windows NT 4.0 after the trust is created:

The following errors are logged in the System log on the PDC that is running Windows Server 2008 R2 after the trust is created:When you try to validate the trust by using Domain.msc, you receive the following error message:

"Verification of the trust between the domain southridgevideo and the domain cpandl was unsuccessful because: Access is denied. To repair a trust to a pre-Windows 2000 domain you must remove and re-add the trust on both sides."
You use a Windows NT 4.0-based member computer in the Windows NT 4.0-based domain over a validated trust. When you try to access a resource that is located on a domain controller that is running Windows Server 2008 R2, you receive the following error message:

"The trust relationship between the primary domain and the trusted domain failed."

↑ Back to the top

Cause

This problem occurs because of the default behavior of the Allow cryptography algorithms compatible with Windows NT 4.0 policy on Windows Server 2008-based domain controllers. This policy is configured to prevent Windows operating systems and third-party clients from using weak cryptography algorithms to establish NETLOGON security channels to Windows Server 2008-based domain controllers.

Important Windows NT 4.0 trusts cannot be created between Windows Server 2008 R2 or newer domains and Windows NT 4.0-based domains. The workaround steps that are documented later in this article apply to only Windows Server 2008. Security changes that are in Windows Server 2008 R2 prevent a trust between Windows Server 2008 R2-based domains and Windows NT 4.0-based domains. This behavior is by design.

↑ Back to the top

Workaround

To work around this problem, make sure that client computers use the cryptography algorithms that are compatible with Windows Server 2008. You may have to request software updates from the product vendors.

If you cannot install software updates because a service outage will occur, follow these steps:
  1. Log on to a Windows Server 2008-based domain controller.
  2. Click Start, click Run, type gpmc.msc, and then click OK.
  3. In the Group Policy Management console, expand Forest: DomainName, expand DomainName, expand Domain Controllers, right-click Default Domain Controllers Policy, and then click Edit.
  4. In the Group Policy Management Editor console, expand Computer Configuration, expand Policies, expand Administrative Templates, expand System, click Net Logon, and then double-click Allow cryptography algorithms compatible with Windows NT 4.0.
  5. In the Properties dialog box, click the Enabled option, and then click OK.

    Notes
    • By default, the Not Configured option is set for the Allow cryptography algorithms compatible with Windows NT 4.0 policy in the following Group Policy objects (GPO):
      • Default Domain Policy
      • Default Domain Controllers Policy
      • Local Computer Policy
      By default, the behavior for the Allow cryptography algorithms compatible with Windows NT 4.0 policy on Windows Server 2008-based domain controllers is to programmatically prevent connections from using cryptography algorithms that are used in Windows NT 4.0. Therefore, tools that enumerate effective policy settings on a member computer or on a domain controller will not detect the Allow cryptography algorithms compatible with Windows NT 4.0 policy unless you explicitly enable or disable the policy.
    • Windows 2000 Server-based domain controllers and Windows Server 2003-based domain controllers do not have the Allow cryptography algorithms compatible with Windows NT 4.0 policy. Therefore, pre-Windows Server 2008-based domain controllers accept security channel requests from client computers even if the client computers use the old cryptography algorithms that are used in Windows NT 4.0. If security channel requests are intermittently processed by Windows Server 2008-based domain controllers, you will experience inconsistent results.
  6. Install third-party software updates that fix the problem, or remove client computers that use incompatible cryptography algorithms.
  7. Repeat steps 1 through 4.
  8. In the Properties dialog box, click the Disabled option, and then click OK.

    Important For security reasons, you should set the option for this policy back to Disabled.

↑ Back to the top

Status

This behavior is by design.

↑ Back to the top

More Information

A related problem on computers that are running Windows 2000 or later versions of Windows

The ability of client computers that are running Windows 2000 or later versions of Windows to establish security channels to Windows Server 2008-based domain controllers will not be affected by the Allow cryptography algorithms compatible with Windows NT 4.0 policy. However, when these client computers use the NetJoinDomain function together with the NETSETUP_JOIN_UNSECURE join option against a Windows Server 2008-based domain controller, the domain controller returns the following error code:
Hex: 0x4F1h
Decimal: 1265
Symbolic Error: ERROR_DOWNGRADE_DETECTED
Short Error: "STATUS_DOWNGRADE_DETECTED"
Friendly Error: The system detected a possible attempt to compromise security. Please ensure that you can contact the server that authenticated you.
This problem occurs when the policy setting is Disabled or Not Configured.

Note The "STATUS_DOWNGRADE_DETECTED" error has multiple root causes. Therefore, this error does not necessarily indicate that you are experiencing this problem.

You may experience this problem on computers that are running the following operating systems:
  • Windows 2000
  • Windows XP
  • Windows Server 2003
  • The release version of Windows Vista
Note Computers that are running Windows Vista with Service Pack 1 (SP1) or later versions of Windows Vista are not affected.

The NetJoinDomain function is used together with the NETSETUP_JOIN_UNSECURE option in the following scenarios. (This function is also used in other scenarios.)
  • You use Windows Deployment Services (WDS) or Remote Installation Services (RIS) to install a Windows operating system.
  • You use the Active Directory Migration Tool (ADMT) to perform computer account migration of a Windows operating system.
The following hotfix package may be applied to computers that are running Windows XP or Windows Server 2003 to resolve this issue:
944043 Description of the Windows Server 2008 read-only domain controller compatibility pack for Windows Server 2003 clients and for Windows XP clients and for Windows Vista

↑ Back to the top

How to troubleshoot these problems

When you cannot establish a security channel from a client computer to a Windows Server 2008-based domain controller, follow these steps to troubleshoot the problem:
  1. If the client computer is running Windows NT 4.0, upgrade Windows NT 4.0 to Windows 2000 or to later versions. If you cannot perform the upgrade, follow the steps in the "Workaround" section.
  2. If the client computer is running Windows 2000 or a later version of Windows, and the client computer runs an unsecured domain join operation, follow the steps in the "Workaround" section as a temporary solution.
  3. If the client computer is running Windows 2000 or a later version of Windows, and you are not sure whether the client computer is performs an unsecured join operation, examine the %systemroot%\Debug\Netsetup.log file. If the client computer is performing an unsecured join operation, information that resembles the following is logged:
    11/09 02:21:04 Failed to validate machine account for ComputerName against
    SPN_Name: 0xc0000388
    11/09 02:21:04 NetpJoinDomain: w9x: status of validating account: 0x4f1
    Note The NETLOGON service runs only on a computer that joins a domain.
  4. If the client computer is not running Windows, follow these steps:
    1. Determine which domain controller is processing security channel requests.

      Note You can use event logs and trace logs to determine the domain controller.
    2. Make sure that the NETLOGON service is started. To do this, follow these steps:
      • Click Start, click Run, type Services.msc, and then click OK.
      • In the Services console, make sure that the status for the NETLOGON service is Started.
      • If the status is not Started, right-click the NETLOGON service, and then click Start.
    3. Enable debug logging for the NETLOGON service on the Windows Server 2008-based domain controller that processes security channel requests. To do this, use one of the following methods.

      Method 1
      1. Click Start, click Run, type cmd, and then click OK.
      2. At the command prompt, type the following command:
        Nltest.exe /DBFLAG:2000FFFF
      Note If the NETLOGON service is not started, you receive a "RPC_S_UNKNOWN_IF" error message.

      Method 2

      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 the operating system. Microsoft cannot guarantee that these problems can be solved. Modify the registry at your own risk.
      1. Click Start, click Run, type regedit, and then click OK.
      2. Locate and then right-click the following registry subkey:
        HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters
      3. Point to New, and then click String Value.
      4. Type DBFLAG, and then double-click the DBFLAG registry entry.
      5. In the Edit String box, type 2000FFFF in the Value data box.
      6. Exit Registry Editor.
    4. Open the %systemroot%\Debug\Netlogon.log file in Notepad, and then search for the following error message:
      the client ClientComputerName$ is asking for NT4 crypto and this server disallows it.
    5. If you find this error message, the client computer is using old cryptography algorithms that are used in Windows NT 4.0 to establish a security channel to the Windows Server 2008-based domain controller.
    6. Disable debug logging for the NETLOGON service on the Windows Server 2008-based domain controller. To do this, type the following command at a command prompt:
      Nltest.exe /DBFLAG:0

↑ Back to the top

References

For more information about how to enable debug logging for the NETLOGON service, click the following article number to view the article in the Microsoft Knowledge Base:

109626 Enabling debug logging for the Net Logon service


For more information about the NetJoinDomain function, visit the following Microsoft Web site:
http://msdn2.microsoft.com/En-US/library/aa370433.aspx
The third-party products that this article discusses are manufactured by companies that are independent of Microsoft. Microsoft makes no warranty, implied or otherwise, about the performance or reliability of these products.

↑ Back to the top

Keywords: kb, kbprb, kbtshoot, kbexpertiseadvanced

↑ Back to the top

Article Info
Article ID : 942564
Revision : 4
Created on : 4/17/2018
Published on : 4/17/2018
Exists online : False
Views : 3768