locked
DsEnumerateDomainTrusts() fails with error 1722 [RPC Server Unavailable] when NTLM is disabled/restricted RRS feed

  • Question

  • I have some C++ code that makes use of the DsEnumerateDomainTrusts() API function as part of gathering information about the AD forest environment that the code is executing in.  This code has been functioning correctly for nearly 10 years when executed in a variety of environments.  Recently, a run-time environment was encountered where the call to DsEnumerateDomainTrusts() failed with error 1722, which is RPC Server Unavailable.  Further review of the run-time environment showed that the DCs in the forest root domain had the "Network security: Restrict NTLM: Incoming NTLM traffice" security option set to "Deny all accounts" via a GPO setting.  Testing in a lab environment duplicated these conditions and caused the error to occur.  Removing the restriction on incoming NTLM authentication causes the error to cease to occur, and DsEnumerateDomainTrusts() to work properly.  The setting of restricting incoming NTLM authentication can be toggled on & off dynamically, and the [non-]occurrence of error 1722 tracks with it 100%.

    This, of course, leads to a question... Why is this happening?

    Is DsEnumerateDomainTrusts() locked in to using NTLM as it makes an RPC call to a DC?

    Is DSEnumerateDomainTrusts() and its usage of RPC affected in any way by how COM Security is initialized via CoInitializeSecurty()?

    [Edit] - Windows Firewall is disabled.  There are no firewalls or other types of network security tools present that can block access to TCP ports.  The one and only change that is being made is to disable or re-enable incoming NTLM authentication on the DCs in the forest root domain.  In the case of my lab environment, it's a single domain forest with a single DC and a single member server, with my code executing on the member server.  A bi-directional forest trust exists between this forest and another similarly configured forest.  No attempt is being made communicate with any computers across the forest trust.


    • Edited by Chuck Chopp Wednesday, September 7, 2016 1:44 PM
    Wednesday, September 7, 2016 1:39 PM

Answers

  • Issue resolved...

    As it turns out, the problem was being caused by the following combination of conditions:

    1)  NTLM Authentication was disabled, either outbound on the server where the code was executing, or inbound on the DCs in the forest root domain.

    2)  The code in question was calling DsEnumerateDomainTrusts().  The flags value, although not a specific factor in the occurrence of the problem, was 4, meaning that trusts for all of the tree roots in the forest were to be enumerated and returned.

    3)  The value of the "ServerName" parameter was the DNS FQDN of the forest root domain, rather than that of an individual server.

    Under these conditions, error 1722 would occur due to the fact that Kerberos was attempting to resolve a SPN value of "cifs/<forest-root-domain-dns-fqdn>", which does not and cannot exist.  Given that all SPN values must be unique, and that it wouldn't be possible for this SPN to exist in the "servicePrincipalName" attribute's value list on multiple domain controller computer objects, the Kerberos authentication fails.  When the authentication attempt fails, instead of reporting back an error indicating specifically that Kerberos authentication failed, the less descriptive RPC Server Unavailable [1722] error is returned.

    The code has been refactored to make use of DsGetDcOpenW() and DsGetDcNext() are called to enumerate all of the DCs in the specified domain, and then attempts are made to call DsEnumerateDomainTrusts() in a loop, once for each DC's DNS FQDN, until success is achieved or the entire list has been exhausted with all attempts failing.

    • Proposed as answer by Burak Uğur Thursday, September 22, 2016 4:06 PM
    • Marked as answer by Alvwan Friday, September 23, 2016 8:55 AM
    Thursday, September 22, 2016 3:19 PM

All replies

  • Hi,

    Thanks for your post.

    It looks like the query is more related to DS functions API. For the programming-related question, I suggest that you post to the MSDN forum. The support professionals there are better qualified to assist you.

    MSDN forum

    https://social.msdn.microsoft.com/Forums/en-US/home

    Thank you for your understanding.

    Best Regards,

    Alvin Wang


    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.



    • Proposed as answer by Burak Uğur Thursday, September 8, 2016 6:13 PM
    • Unproposed as answer by Chuck Chopp Thursday, September 8, 2016 6:58 PM
    • Edited by Alvwan Friday, September 9, 2016 1:49 AM
    Thursday, September 8, 2016 7:26 AM
  • That link you provided doesn't actually go anywhere...

    Thursday, September 8, 2016 12:25 PM
  • Hi

     Please check these forum links also;

    https://social.msdn.microsoft.com/Forums/en-US/home

    https://social.msdn.microsoft.com/Forums/azure/en-US/home?forum=azureapimgmt


    This posting is provided AS IS with no warranties or guarantees,and confers no rights. Best regards Burak Uğur

    Thursday, September 8, 2016 6:13 PM
  • Issue resolved...

    As it turns out, the problem was being caused by the following combination of conditions:

    1)  NTLM Authentication was disabled, either outbound on the server where the code was executing, or inbound on the DCs in the forest root domain.

    2)  The code in question was calling DsEnumerateDomainTrusts().  The flags value, although not a specific factor in the occurrence of the problem, was 4, meaning that trusts for all of the tree roots in the forest were to be enumerated and returned.

    3)  The value of the "ServerName" parameter was the DNS FQDN of the forest root domain, rather than that of an individual server.

    Under these conditions, error 1722 would occur due to the fact that Kerberos was attempting to resolve a SPN value of "cifs/<forest-root-domain-dns-fqdn>", which does not and cannot exist.  Given that all SPN values must be unique, and that it wouldn't be possible for this SPN to exist in the "servicePrincipalName" attribute's value list on multiple domain controller computer objects, the Kerberos authentication fails.  When the authentication attempt fails, instead of reporting back an error indicating specifically that Kerberos authentication failed, the less descriptive RPC Server Unavailable [1722] error is returned.

    The code has been refactored to make use of DsGetDcOpenW() and DsGetDcNext() are called to enumerate all of the DCs in the specified domain, and then attempts are made to call DsEnumerateDomainTrusts() in a loop, once for each DC's DNS FQDN, until success is achieved or the entire list has been exhausted with all attempts failing.

    • Proposed as answer by Burak Uğur Thursday, September 22, 2016 4:06 PM
    • Marked as answer by Alvwan Friday, September 23, 2016 8:55 AM
    Thursday, September 22, 2016 3:19 PM
  • Hi

     glad to hear that the issue solved and thanks for sharing the solution with us.


    This posting is provided AS IS with no warranties or guarantees,and confers no rights. Best regards Burak Uğur

    Thursday, September 22, 2016 4:06 PM