Update/Info: I continue my work at Nextcloud. /Update

With ownCloud it is possible to connect to one or more LDAP instances so existing users are able to login with their passwords and have email and pictures imported. However, if a somewhat bigger directory is in use, an improvable performance might be faced in some scenarios. Typically the first look at the Users page after configuring an LDAP connection can make the admin wait quite a while. Obscure rumours claim that this delay is sponsored by the coffee industry.

Even if the LDAP integration already works fast enough, speed and a responsive service have a big positive impact on the user experience. No one likes to wait when performing a search or opening up a web page. There are some ways to minimize the time LDAP queries take, making ownCloud behave snappier.

1. Enable Memory Cache

The default principle is that ownCloud operates mostly online against the LDAP directory. It is not attempted to mirror parts of the directory. This requires that LDAP lookups are done on certain actions. However, this can be expensive at times and thus ownCloud does cache results to avoid querying the server for the same information repeatedly (e.g. user existence, login however is always requires a live bind).

ownCloud does support memory based caches, like PHP's APCu or Memcached, but is not limited to them. Using one of those is the best choice. Until and including ownCloud 8.0, a such a cache was used whenever it was available. In case none was found, a file cache was used as fallback. The file cache however had two issues: while it was still faster than no cache it was not terribly fast either, and it does not work well with concurrent operations.

With the upcoming ownCloud 8.1 the file cache will be removed, but also the memory cache must be configured explicitly in the config.php file. When a migration to OC 8.1 is being plannned, make sure to not forget to set it up! An example can be found in the config.sample.php, nevertheless enabling a memory cache is also documented.

The LDAP Backend documentation has more detailed information on how caching is done.

2. Narrow Bases

On the very first tab of the LDAP Backend configuration assistant a Base DN is supposed to be given. At that time it is used to determine Users and Groups and related information in the subsequent configuration steps. We even have a detection therefore, but while it provides ease of use, it pulls in a too wide search scope on bigger directories when in full operation.

Once the first tab is done or the necessary configuration steps completed, different Base DNs for both users and groups can be specified on the Advanced tab in the "Directory Settings" section. Try to be as narrow as possible. The smaller the searchable trees are in LDAP the faster the queries run and the snappier the ownCloud experience will be.

3. Narrow Filters

Small branches to search are good, but maybe not enough. It is possible to still narrow down the result set by having strict filters. Users only from this and that group shall be allowed? Make use of memberOf in the filter as well. The assistant helps by compiling it, all that is to be done is just selecting the desired groups. Or, is a custom LDAP schema available or possible to add so that a specific attribute for ownCloud users is provided? Splendid, use it in the User and Login filter! The filter has to be entered manually then, however if inserting a new schema was mastered this is a breeze.

Wait, groups cannot be selected on the User Filter tab? Chances are good that OpenLDAP is in use. Here it is necessary to get active on the LDAP server side and enable the MemberOf-Overlay first. While AD does provide it out of the box, I am not familiar with how it looks like on other LDAP servers as it is not standardized. Even if the server has an implementation which differs from the approach on OpenLDAP and AD, it is pretty likely that a working filter can be written manually. The virtual memberOf attribute helps with determining group associations and speeds up loading of the Users page, with upcoming ownCloud 8.1

And the same applies for the group filter. Within the set up Group Base DN are still plenty-thousand of groups, but only one or two handful would suffice? Select them directly, or introduce a custom schema as well and utilize an attribute in the filter. Many groups can delay loading of the Users page significantly at the moment and, depending on Sharing configuration, in the share dialog.

Following example show how a custom schema with ownCloudUser and ownCloudGroup object classes and ownCloudEnabled attributes can be used for a short but precise filter. Adding, removing, enabling and disabling both users and groups can be done on LDAP side.

4. Clever Search Attributes

A handy thing ownCloud provides are configurable search attributes. When a user wants to look up someone else or also a group (for instance in the share dialog) ownCloud by default matches it against the corresponding display name attribute and attaches a wildcard to the entered term. When "Alic" is typed in ownCloud will find "Alice Alison", but not if "alison" is entered.

A helpful idea is to specify "sn" and "givenname" as search attributes, and it won't matter whether "alic" or "aliso" or "alice alison" or "alison alice" was used as search text, the desired user will be found. Many attributes can be enlisted and it may be useful to keep "displayname" as well and also add attributes for email, license plate number or favorite pet. However, the more attributes are chosen the more complex the resulting search filter will be and could take longer to process. So, pick them wisely. A wide selection of attributes enhances the user experience, but do not overdo it unnecessarily as it will slow things down. This impacts only user and group searches, for instance in the share dialog or the users admin page.

5. LDAP Indexes

Consider setting up LDAP indexes. On which attributes mostly depends on the existing configuration. Have a look at the configured User and Group filters and the search attributes. On OpenLDAP, the attributes used in the filters qualify for an eq index, while the search attributes for a sub index. On Active Directory, only the index flag needs to be set per attribute.

There is more and specific documentation about OpenLDAP Indexes (official doc) and also by Zytrax. Further, there is also an informative blog on Indexing on Active Directory as well as a short How-To.