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. When the realm's Validate User Type field (on the Data tab) is set to Search, each incorrect password causes two logon attempts against AD, so the user's badPwdCount attribute increases by 2 instead of 1 and the user reaches the lockout threshold in half the expected number of attempts. Setting Validate User Type to Bind makes only one logon attempt per incorrect password.

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.