LDAP Best Practices

Use secure connections

Always use secure connections when sending credentials for authentication, and when reading or writing any data that is not public.

For LDAP applications, either connect to the directory server's LDAPS port (636), or if possible, begin each session with the StartTLS extended operation on the (cleartext) LDAP port (389).

See https://github.com/ucidentity/ldap-client-examples

Reuse connections

The LDAP protocol is stateful. Typically you bind (connect), search or make an update, and then unbind (disconnect). The server maintains a context and enforces authorization decisions concerning your requests. Your application should reuse connections.

You can make multiple requests without having to set up a new connection and authenticate for every request. Many client libraries for LDAP allow your application to share connections in a pool, avoiding the overhead of setting up and tearing down connections if you use them often. This can significantly improve your application’s performance and reduce load on the directory server.

See https://github.com/ucidentity/ldap-client-examples

Use paged searches

If you suspect that the result set from a given query may be very large, you should be able to retrieve a result set in small pieces. The Simple Paged Result extended control allows this type of retrieval by allowing a one-way traversal of the result set. Options on this control allow the client to set the initial page size and reset the page size with each subsequent request to the server.

The Simple Paged Result control is also used to access all of a large result set when there is a server-side administrative limit to the number of items returned from a query. For example, CalNet LDAP Directory servers have a default server-side limit of 1000 entries as the maximum number of results that are returned in a single request. If the results of a query exceed this limit, the Paged Results control is used with a page size equal to or less than the server-side limit in order to retrieve all of the results of the query.

See https://github.com/ucidentity/ldap-client-examples

Apply resource limits

LDAP client applications can set time limits and size limits on search requests to avoid overuse of server resources. Setting limits is appropriate when the searches your application performs are not fixed, but instead partially or fully determined by user input.

The ldapsearch command has --sizeLimit and --timeLimit options

Request only what you need

Request the attributes you need explicitly and request all the attributes in the same search. This reduces the number of trips to the server and improves the speed of your application

Good Search:

Bad Search:

Use specific LDAP filters

The difference between a general filter (berkeleyEduOfficialEmail=*@berkeley.edu) and a good, specific filter like (berkeleyEduOfficialEmail=agent.cooper@berkeley.edu) significant processing time and a very large number of entries, both for the directory server and for your application. In general, try to use short, specific filters. As a rule, prefer equality filters over substring filters.

Furthermore, always use & with ! to restrict the potential result set before returning all entries that do not match part of the filter. For example:
(&(berkeleyEduDept=FBI)(!(berkeleyEduOfficialEmail=agent.cooper@berkeley.edu)))

Use indexed searches

Some directory servers reject unindexed searches by default because unindexed searches are generally far more resource-intensive. The CalNet directory currently allows unindexed searches but that may change in the future. If your application needs to use a filter that results in an unindexed search, then work with us to find a solution, such as having the directory maintain the indexes required by your application.

See Currently Indexed Properties

Ask the directory server what it supports

Directory servers expose their capabilities, suffixes they support, and other information as attribute values on the root DSE.

This allows your application to discover a variety of information at run time, rather than storing configuration separately. Querying the directory about its configuration and the features it supports can make your application easier to deploy and maintain.

For example, rather than hard-coding dc=berkeley,dc=edu as a suffix DN in your configuration, you can search the root DSE on DS servers for namingContexts, and then search under the naming context DNs to locate the desired entries to initialize your configuration.

The directory servers also advertise supported security mechanisms such as the root DSE attributes supportedTLSCiphers and supportedTLSProtocols.

Directory servers expose their schema over LDAP. The root DSE attribute subschemaSubentry shows the DN of the entry holding LDAP schema definitions.

Trust result codes

The LDAP result codes that your application gets from the directory server is reliable and consistent. For example, if you request a modified operation and you get ResultCode.SUCCESS, then consider the operation a success rather than immediately issuing a search to get the modified entry.

The LDAP replication model is loosely convergent. The directory server will send you ResultCode.SUCCESS before replicating your change to every directory server instance. If you issue a read immediately after a write, and your request is sent to a different directory server instance, you could get an inconsistent result.

Avoid server-side sorting

Directory servers also support a resource-intensive operation called server-side sorting. When your application requests a server-side sort, the directory server retrieves all the entries matching your search, and then returns the whole set of entries in sorted order. For result sets of any size server-side sorting therefore ties up server resources that could be used elsewhere. Alternatives include both sorting the results after your application receives them, and working with our team to enable appropriate browsing (virtual list view) indexes on the directory server for applications that must regularly page through long lists of search results.

Check Result Codes

LDAP result codes are standard and clearly defined, and listed in "LDAP Result Codes". When your application receives a result, it must the result code value to determine what action to take. When the result is not what you expect, read or at least log the additional message information.

DS 7 > LDAP Result Codes

Indexed Properties

The following attributes are indexed and should be preferred for search filters. If your application requires another index please let us know.