Windows Server 2008 R2 Outbound trusts with Windows NT 4.0 domains do not validate or function correctly

Article translations Article translations
Article ID: 2021766 - View products that this article applies to.
Expand all | Collapse all

Symptoms

Consider the following test scenario:

  1. Promote a Windows Server 2008 R2 domain controller and a Windows NT 4.0 domain controller to two different domains.

    Configure security settings in the Windows Server 2008 R2 domain as follows:

    Computer Configuration\Policies\Windows Settings\Security Settings\Local Policies\Security Options

    DC: LDAP Server Signing Requirements: none
    DC: Digitally encrypt or sign secure channel data (always): disabled
    Domain Member: Require strong (w2k or later) session key: disabled
    MS Network Client: digitally sign communications (always): Disabled
    MS Network Server: digitally sign communications (always): Disabled
    Network Access: allow anonymous SID/Name translation: Enabled
    Network Access: do not allow anonymous enumeration of SAM accounts: disabled
    Network Access: Let everyone permissions apply to anonymous users: enabled
    Network Security: Lan Manager Authentication level: send LM & NTLM responses
    Network Security: Minimum session security for NTLM SSP based clients: no minimum
    Network Security: Minimum session security for NTLM SSP based servers: no minimum
    Network Security: LDAP client signing requirements: none

    Computer Configuration\Policies\Administrative Templates\system\net logon\

    Allow cryptography algorithms compatible with windows NT4: enabled

  2. From the console of the Windows Server 2008 R2 DC, use the Domains and Trust (domain.msc) snap-in to establish an outbound trust relationship with the NT 4.0 domain (such that Windows Server 2008 R2 serves as the trusting / resource domain and Windows NT 4.0 domain serves as the trusted / account domain).

  3. Note that the Domain.msc snap-in fails to validate Windows Server 2008 R2 domains outbound trust with the NT 4.0 domain with the following on-screen error:

    Dialog Title Text: Active Directory Domain Services

    Dialog Error Text: Verification of the trust between the domain <DNS domain name for Windows Server 2008 R2 Active Directory domain> and the domain <Windows NT 4.0 NetBIOS domain name> 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.

    OK




  4. NETLOGON Event 3210 with status c00000022 is logged in the System event log of the Windows Server 2008 R2 computer following the trust validation in domain.msc.


    Log Name:      System
    Source:        NETLOGON
    Date:          <date> <time>
    Event ID:      3210
    Task Category: None
    Level:         Error
    Keywords:      Classic
    User:          N/A
    Computer:      WIN-KJNCA5BPH95.contoso.com
    Description:
    This computer could not authenticate with \\NT4PDC, a Windows domain controller for domain NT4DOM, and therefore this computer might deny logon requests. This inability to authenticate might be caused by another computer on the same network using the same name or the password for this computer account is not recognized. If this message appears again, contact your system administrator.
    Event Xml:
    <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
      <System>
        <Provider Name="NETLOGON" />
        <EventID Qualifiers="0">3210</EventID>
        <Level>2</Level>
        <Task>0</Task>
        <Keywords>0x80000000000000</Keywords>
        <TimeCreated SystemTime="2010-07-20T21:40:05.000000000Z" />
        <EventRecordID>9221</EventRecordID>
        <Channel>System</Channel>
        <Computer>WIN-KJNCA5BPH95.contoso.com</Computer>
        <Security />
      </System>
      <EventData>
        <Data>NT4DOM</Data>
        <Data>\\NT4PDC</Data>
        <Binary>220000C0</Binary>
      </EventData>
    </Event>

  5. Authenticated operations over the oubound trust fail. For example, a net use command to a shared folder in the trusting domain by a user in the trusted domain fails with the following error: 

    Dialog Title Text: \\<server name>\<share name>
    Dialog Error Text: The trust relationship between the primary domain and the trusted domain failed.


     

  6. Attempts by the Windows Server 2008 R2 DC in the trusting domain fails to establish a secure channel session with the trusted Windows NT 4.0 domain with error status 0xc002002e.

    The NETLOGN.LOG of the Windows Server 2008 R2 DC with Netlogon logging enabled (nltest /debug:2080ffff) shows the following:

<date> <time> [CRITICAL] NlPrintRpcDebug: Dumping extended error for I_NetLogonGetCapabilities with 0xc002002e
<date> <time> [CRITICAL]  [0] ProcessID is 488
<date> <time> [CRITICAL]  [0] System Time is: 7/20/2010 21:40:5:754
<date> <time> [CRITICAL]  [0] Generating component is 2
<date> <time> [CRITICAL]  [0] Status is 1745
<date> <time> [CRITICAL]  [0] Detection location is 1750
<date> <time> [CRITICAL]  [0] Flags is 0
<date> <time> [CRITICAL]  [0] NumberOfParameters is 1
<date> <time> [CRITICAL]      Long val: 469827586
<date> <time> [CRITICAL] CONTOSO-DOMAIN: NT4DOM: NlConfirmCapabilities: denying access after status: 0xc002002e
<date> <time> [SESSION] CONTOSO-DOMAIN: NT4DOM: NlSessionSetup: denying access because of unmatching capabilities
<date> <time> [MISC] Eventlog: 3210 (1) "NT4DOM" "\\NT4PDC" 2f8270f1 5bc8d5e7 34c3e164 6665df64   .p./...[d..4d.ef

The error code 0xc002002e maps to "The procedure number is out of range" (RPC_NT_PROCNUM_OUT_OF_RANGE).

For information about enabling Netlogon logging, see the following article in the Microsoft Knowledge Base:

109626 Enabling debug logging for the Net Logon service

Cause

In general, Netlogon secure channels used to create trust relationships and join member computers to Windows or Active Directory domains are not supported between Windows NT 4.0 computers and Windows Server 2008 / Windows Server 2008 R2 computers in any direction because they were not tested.

In addition, the AllowNT4Crypto secure default prevents Windows Server 2008 and Windows Server 2008 R2 family of operating systems from being the receiver (but not the initiator) of a trust relationship with an NT 4.0 domain until that secure default is manually relaxed using one of the methods described in MSKB article 942564.  

As part of a continuing effort to improve security, Windows 7 and Windows Server 2008 R2 computers use the NetrLogonGetCapabilities API  to ensure that partner operating system support more secure crypto capabilities after establishing a secure channel session.

The NetrLogonGetCapabilities API is supported by Windows 2000 and later versions of Windows but not by Windows NT4. As a result, attempts by a Windows Server 2008 R2 DC to establish an outbound trust relationship with an NT 4.0 computer (where Windows Server 2008 R2 serves as the trusting / account domain and Windows NT 4.0 serves as the trusted or account domain) fails with a status of c002002e (RPC_NT_PROCNUM_OUT_OF_RANGE), causing the trust setup to fail.

The NlConfirmCapabilities API is called by Windows 7 and Windows Server 2008 R2 computers when setting up a secure channel, and specifically by Windows Server 2008 R2 computers when validating an outbound trust relationship.

The calling of the NetrLogonGetCapabilities API that prevents Windows 7 and Windows Server 2008 R2 computers from establishing secure channels and hence outbound trusts with Windows NT 4.0 computers cannot be turned off or disabled by any method, including settings in Windows policy or the Windows registry.

Resolution

While Windows Server 2008 R2 computers cannot establish outgoing trusts with Windows NT 4.0 domains, such outbound trusts can be established with Windows 2000, Windows Server 2003, Windows Server 2008 and Windows Server 2008 R2 domains.

Windows 2000, Windows Server2003 and Windows Server 2008 computers can create outbound trusts with Windows NT 4.0 domains although this feature was not tested in Windows Server 2008 and would require a change to the AllowNT4Crypto setting on Windows Server 2008 domain controllers participating in the trust.

Valid solutions for resolving this condition include:

  1. Upgrade Windows NT 4.0 domain controllers to Windows 2003 or a later operating system revision.

    Although Windows 2000 is the minimum operating system level needed to resolve this issue, Windows 2000 is no longer supported after July 13, 2010, so you should deploy Windows Server 2003 or later versions of Windows. For more information on the Windows 2000 life cycle policy, see the Windows 2000 End-of-Support Solution Center.

    OR

  2. Downgrade your deployment of Windows Server 2008 R2 computers with Windows Server 2008 computers

    Assuming that your deployment does not have a dependency on a Windows Server 2008 R2-only feature (i.e. Direct Access, DNSSEC or an OS version dependency by a server-based application) replace your deployment of Windows Server 2008 R2 domain controllers with Windows Server 2008 DCs.

    While Netlogon secure channels were not tested between Windows NT 4.0 and Windows Server 2008 computers, Windows Server 2008 does not use the more secure method to establish secure channels. For more information on downgrade rights, see Windows Server Downgrade.


For more information on trust direction, see Appendix: New Trust Wizard Pages

Note This is a "FAST PUBLISH" article created directly from within the Microsoft support organization. The information contained herein is provided as-is in response to emerging issues. As a result of the speed in making it available, the materials may include typographical errors and may be revised at any time without notice. See Terms of Use for other considerations.

Properties

Article ID: 2021766 - Last Review: December 29, 2010 - Revision: 21.0
APPLIES TO
  • Windows 7 Professional
  • Windows 7 Ultimate
  • Windows Server 2008 R2 Standard
Keywords: 
KB2021766

Give Feedback

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com