New sessions setup for LDAP services take longer than expected if targeting host names

Applies to: Windows Server 2019Windows Server 2016Windows Server 2012 R2

Symptoms


Lightweight Directory Access Protocol (LDAP) queries that target host names randomly take longer than expected to respond.

Additionally, DNS client events such as the following may be logged In the event log:


Note In this log entry, the <name> parameter can be any of the following:

  • Domain NETBIOS name
  • Domain Controller host name
  • Domain Controller DNS FQDN host name

This problem causes multiple issues that affect administrators, users, and applications. These issues include but are not limited to the following:

  • An LDAP connection against Windows Server 2008 R2 domain controllers (DCs) or later version DCs takes about six seconds. The same connections against Windows Server 2003 or Windows Server 2008 DCs usually takes less than one second. When this occurs, the subsequent LDAP operations, such as bind and LDAP searches, appear to have no additional delay after the initial LDAP connect.
  • The LDIFDE.EXE command is slow regardless of whether the /S parameter is used.
  • The Microsoft System Center Active Directory Management Pack (SCOM ADMP) health check script (AD_General_Response.vbs) experiences slow run times.
  • Microsoft Active Directory Users and Computers (ADUC) is slow to start or slow to open OU containers. Extensions in the Active Directory Users and Computers snap-in, DSA.MSC, uses the DC FQDN computer name as a domain name.
  • Microsoft Active Directory Administrative Center (ADAC) Extensions in the Active Directory Administrative Center use the DC FQDN computer name as a domain name.
  • Microsoft Group Policy Management Console (GPMC) does not consistently use name resolution flags.
  • Visual Basic Script (VBS) scripts that make LDAP calls that reference the DC fully qualified DNS name are slow to run.
  • .NET Framework applications that use System.DirectoryServices and System.DirectoryServices.Protocols may experience delays when they create server sessions.

Cause


Starting in Windows 7 and Windows Server 2008 R2, Windows introduced a change in name lookup behavior to fix two earlier problem scenarios:

  • LDAP clients fall back to NTLM whenever the NetBIOS domain name is supplied as the host name in the LDAP connection.
  • LDAP clients do not connect to a DC in the domain if a client has the same name as the targeted NetBIOS domain name.

The delay occurs because one of the following two conditions is true:

  • You encounter a long wait time for a broadcast response. You do not see this delay if NetBIOS over TCP/IP (NetBT) name resolution through broadcasts is turned off.
  • Delays in the DNS name resolution occur as the application queries for several DNS names that do not exist.

The delays can be observed in a network trace that shows LDAP clients running NetBIOS name lookups for a "[HOSTNAME]<0x1C>" record before they run a DNS lookup to locate the application host computer (see Figure A).

Figure A
Network trace of Windows 7 client performing ldap_connect using ldp.exe

The network trace of a Windows Server 2003 or 2008 LDAP client showed that it directly ran the DNS lookup for the host computer without performing the NetBIOS lookup for the "<0x1C>" record.

Figure B
Network trace of Windows Server 2003 client performing an ldap_connect using ldp.exe

In the case of DNS, you see name queries for names that end in a DC computer name, such as the following:

_ldap._tcp.Default-First-Site-Name._sites.ADDC01.contoso.com_ldap._tcp.ADDC01.contoso.com_ldap._tcp.Default-First-Site-Name._sites.ADDC01_ldap._tcp.ADDC01

Resolution


When you target an LDAP server by host name instead of domain name, you should use the LDAP_OPT_AREC_EXCLUSIVE session option to indicate that the target is a host name instead of a domain name.

This option is set differently depending on the programming interface that is used. Use the following information as reference.

Wldap32

If an Active Directory DNS server name is passed for the HostName parameter, ldap_set_option should be called to set the LDAP_OPT_AREC_EXCLUSIVE flag before calling any LDAP function that creates the actual connection.

Doing this forces an A-record lookup and bypasses any SRV record lookup when the computer resolves the host name. In some scenarios, it improves network performance. For example, in a branch office that uses a dial-up connection, using A-Record lookup can avoid forcing the dialup to query a remote DNS server for SRV records when it resolves names.

ADSI

If you must specify a server, use the ADS_SERVER_BIND flag to avoid unnecessary or incorrect queries to the DNS server. For more information, see this documentation of ADsOpenObject() and related functions.

System.DirectoryServices

If your ADsPath includes a server name, specify the AuthenticationTypes.ServerBind flag when you use the LDAP provider. Do not use this flag for paths that include a domain name or for serverless paths. Specifying a server name without also specifying this flag causes unnecessary network traffic.

For example:

DirectoryEntry ent = new DirectoryEntry("LDAP://server01",null,null,AuthenticationTypes.ServerBind);

System.DirectoryServices.Protocols

When you prepare a new LDAP connection, include an LdapDirectoryIdentifier object that is constructed by using a host name and optional port that you want to contact, and also includes a <fullyQualifiedDnsHostName> parameter that is set to True.

The new default behavior in Windows 7, Windows Server 2008 R2, and later versions can be reverted to pre-Windows 7 behavior. This may re-introduce problems that affect NetBIOS names as described in the "Cause" section. However, there are also scenarios in which the Pre-Windows 7 behavior provides better results. Therefore, which setting produces the better results depends on the main LDAP client use scenario.

The long-term solution should always be to get the application to use server and domain names that have the appropriate flags when calling into LDAP, ADSI, or .NET interfaces. You should use the correct flags to make the application independent from scenario dependencies when the directory services client code has to decide the resolution method in ambiguous situations.

You can revert to pre-Windows 7 behavior by setting the following registry value:

Subkey: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LDAP
Entry: UseOldHostResolutionOrder
Type: REG_DWORD
Value data: 1

As an additional approach, you can turn off name resolution by using broadcasting for NetBt. See 819108 Settings for minimizing periodic WAN traffic to configure NodeType as "p-mode."

Configuration for nodes

  • Use 0x00000008 for hybrid node or h-node
  • Use 0x00000004 for mixed node or m-node
  • Use 0x00000002 for point-to-point WINS or p-node
  • Use 0x00000001 for broadcast node or b-node
     

Name resolution node types

  • B-Node (broadcasting): Uses broadcasts to resolve names. (Not recommended for larger networks.)
  • P-Node (peer to peer): Uses WINS only, no broadcasts. No WINS server, no resolution.
  • M-Node (mixed): Broadcast first, then WINS. (Not recommended abecause you want to minimize broadcasts.)
  • H-Node (hybrid) - uses WINS first, then broadcasts. (Recommended because it reduces the number of broadcasts by trying WINS first and resorting to broadcasting only as last resort.)

References


For more information, see the following articles:

Ldap_init function
LDAP 
session options (see LDAP_OPT_AREC_EXCLUSIVE, 0x98)

ADSI function AdsopenObject
ADSI
AuthenticationEnum with the ADS_SERVER_BIND value

S.DS AuthenticationTypes Enum with the ServerBind value
S.DS.P
LdapDirectoryIdentifier constructor with the fullyQualifiedDnsHostName flag