How To: Choose Between LDAP Bind and Search Query Modes

Version Affected: All

 

Overview

SecureAuth's LDAP provider can query Active Directory (AD) and other LDAP sources using either of two methods: Search or Bind. Each has tradeoffs, so it's up to the administrator to determine which is the better fit for their environment.

There is more than one way to do this:

• Use Search if you want built-in connection pooling and don't need an SSL connection method.
• Use Bind if the realm uses an SSL connection method, or if an integrated application requires low latency (for example, TACACS with a 3-second timeout) and the added overhead of a new TCP connection per request is acceptable.

In this article

• Method 1: Search
• Method 2: Bind

Method 1: Search

In Search mode, the LDAP provider uses the search filter to find the user, then binds using the user's userPrincipalName. This method uses the built-in LDAP APIs, which support connection pooling -- re-using existing TCP connections instead of opening a new one for every request.

Method 2: Bind

In Bind mode, the LDAP provider uses the search filter to find the user, then uses the user's Distinguished Name (DN) to bind directly to the LDAP server. Bind uses raw LDAP connections, so there is no connection pooling -- a new TCP connection is created for each request. If the realm uses an SSL connection method, Bind must be used, or the Identity Provider (IdP) will return false negatives when testing the connection.

Special Considerations

In Active Directory domains that enforce an account lockout policy, using Search mode instead of Bind mode can cause premature account lockouts. See badPwdCount is incremented by 2 each time a bad password is entered via an IdP realm for more information.


 

SecureAuth Knowledge Base Articles provide information based on specific use cases and may not apply to all appliances or configurations. Be advised that these instructions could cause harm to the environment if not followed correctly or if they do not apply to the current use case.

Customers are responsible for their own due diligence prior to utilizing this information and agree that SecureAuth is not liable for any issues caused by misconfiguration directly or indirectly related to SecureAuth products.