Why are LDAP queries using PrincipalContext very slow since upgrading to Windows Server 2019

hbuelow 21 Reputation points
2020-12-24T20:38:26.067+00:00

We recently upgraded from Windows 2008 R2 to Windows Server 2019 and since the upgrade the piece of code below now takes over a minute to run when it previously took 1 to 2 seconds. Using netmon I can see that the server is making multiple DNS calls to locate the dc even though we specified the fully qualified name of the dc in the request. The network adapter on the server is configured to append 3 different DNS suffixes and calls are made using each suffix to determine the dc even though it is not necessary. If I remove ContextOptions.Negotiate and use ContextOptions.SimpleBind then these additional calls are not made. Unfortunately this is not a viable option. I also ran the same test on a Windows 2008 R2 server with the additional DNS suffixes as well and no calls are made to locate the dc so the call completes fast. I also used tracelog on both the windows 2008 R2 server and on the Windows 2019 server and compared them and the main difference is that the log from the Windows 2019 server contains the text “LDAP connection 0x7e86118 attempting to resolve 'FULLQUALIFIEDDCNAME.COM' using DC locator.” Why is it trying to locate the dc when I specified the fully qualified name of the dc??

Dim oPrincipalContext As New PrincipalContext(ContextType.Domain, Me.activeDirectoryHost & ":636", sDefaultSearchUserOU, ContextOptions.ServerBind Or ContextOptions.Negotiate Or ContextOptions.SecureSocketLayer, sDomain & "\" & sServiceUser, sServicePassword)
Dim oUserContext As OurCustomUserPrincipalExtended = OurCustomUserPrincipalExtended.FindByIdentity(oPrincipalContext, sUserName)

Windows Server 2019
Windows Server 2019
A Microsoft server operating system that supports enterprise-level management updated to data storage.
3,708 questions
Active Directory
Active Directory
A set of directory-based technologies included in Windows Server.
6,456 questions
Accepted answer
  1. Gary Nebbett 6,066 Reputation points
    2020-12-30T19:13:21.117+00:00

    Hello Helen (@hbuelow ),

    If one cannot investigate further the firewall problems between the Windows 2019 server and the DC then it is perhaps worth investigating how the Windows 2008 R2 server manages to work.

    Here are three ideas, although none of them may be suitable in your environment:

    1. Don't use ContextOptions.SecureSocketLayer and TCP port 636 (just normal LDAP and port 389); now make a new Network Monitor capture and run your code/script. Most of the connection will still be encrypted (by SASL), but the authentication mechanism should be visible in the trace.
    2. Follow the instructions in Event Tracing in LDAP Applications to capture ETW (Event Tracing for Windows) data for the connection (this way of capturing data can see the raw LDAP protocol without encryption, so you can continue to use the ContextOptions.SecureSocketLayer option).
    3. Just use ETW to trace the Microsoft-Windows-LDAP-Client provider. Without the registry modification of option 2, this will collect less information but it might still be enough to understand how the Windows 2008 R2 system is authenticating.

    The "klist purge" might have not had the desired effect because explicit credentials are used in the LDAP bind. There are two "messages" to the local Kerberos client that "purge" its cache: KerbPurgeTicketCacheMessage and KerbPurgeTicketCacheExMessage. "klist purge" probably uses the first message, but the second message might be necessary in this case.

    Gary

7 additional answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. Daisy Zhou 22,716 Reputation points Microsoft Vendor
    2020-12-25T06:53:45.507+00:00

    Hello @hbuelow ,

    Thank you for posting here.

    To better understand our question, please confirm the following informaton:
    1.Did you upgrade Windows server 2008 R2 to Windows server 2012 R2,then to Windows Server 2019?
    2.Do you have the same issue when running the same code on one newly installed Windows server 2019?
    3.Is the Windows server 2008 R2 or Windows Server 2019 you mentioned Domain Controller or member server?
    4.Did you have the same issue when running the same code on other DCs or other member servers?
    5.How can I test the code on one Windows server 2019 in my lab?
    6.Check if the server or domain controller is correctly configured with site and subnet?
    7.Would you please check if you have the same issue via UI on this server and other server?

    Steps to check:
    1.Open CMD and type ldp.exe and click Enter.
    2.Click "connect" under Connect tab and provide the information based on your environment information.
    51160-ldp1.png

    3.Click "bind" under Connect tab and provide the information based on your environment information.
    51231-ldp2.png

    If anything is unclear, please feel free to let us know.

    Best Regards,
    Daisy Zhou

    0 comments
  2. hbuelow 21 Reputation points
    2020-12-25T15:56:26.037+00:00

    Hi Daisy

    1. Yes we upgraded to Windows Server 2012 R2 and then to Windows Server 2019.
    2. Unfortunately I don't have access to a server that is a fresh install of Windows Server 2019 so I cannot verify.
    3. The domain controller is running on Windows Server 2019
    4. Yes if I point to other dcs I can still reproduce the issue
    5. You can reproduce using any ldap query from Windows Server 2019. The code below also reproduces this issue:
      Dim oPrincipalContext As New PrincipalContext(ContextType.Domain, Me.activeDirectoryHost & ":636", sDefaultGroupCompaniesOU, ContextOptions.ServerBind Or ContextOptions.Negotiate Or ContextOptions.SecureSocketLayer, sDomain & "\" & sServiceUser, sServicePassword)
      Dim oGroupPrincipal As GroupPrincipal = GroupPrincipal.FindByIdentity(oPrincipalContext, sGroupName)
    6. Yes server and domain controller are properly configured.
    7. This issue is reproducible on the Windows Server 2019 server using ldp.exe. The UI hangs for over a minute until the bind completes. Using ldp.exe on the Windows 2008 R2 server the bind is instantaneous.
      Thanks for the help!
  3. hbuelow 21 Reputation points
    2020-12-28T14:18:33.093+00:00

    Did you try adding additional DNS suffixes? I don't think this is an issue with the DC because I can bind to the same DC from a Windows 2008 R2 server and it's fast but if I bind to the same DC from a Windows 2019 server it's slow (both servers have the additional DNS suffixes). On the Windows 2019 Server I can see a lot of DNS requests to determine the ip of the DC even though I supplied the fqdn. I should also mention that the 2019 Server and 2008 R2 Servers that query the DC are not on the same domain as the DC. We also see this issue if we bind on port 389 w/o SSL when we use ContextOptions.Negotiate. If I use the ip instead of the fqdn then the call completes quickly and we don't see the additional DNS requests in the netmon log. Unfortunately you cannot use the ip when using SSL. From 2008 server using ldp.exe:51712-netmon-2008-1.png From the 2019 server using ldp.exe:51722-netmon-2019-1.png

    0 comments
  4. hbuelow 21 Reputation points
    2020-12-29T15:04:46.923+00:00

    Hi Daisy
    I was able to reproduce this on a new (non-upgraded) Windows 2019 server. I added the 3 DNS suffixes to the network adapter, then I logged out, logged back on and then did bind using ldp.exe with negotiate and the UI hangs for over a minute.

Your answer

Answers can be marked as Accepted Answers by the question author, which helps users to know the answer solved the author's problem.