Symptoms

• The log-in process is very slow
• Jenkins takes too long to recognize the LDAP groups
• I am able to log-in on Jenkins
• LDAP groups are recognized by Jenkins
• In /whoAmI LDAP groups are cognized

Diagnosis/Treatment

Configure the cache

This is one of the options which might increase the performance of your Jenkins instance when there are consecutive lookups. Enable this option is totally recommended.

Advance Configuration

IMPORTANT: Configure LDAP Performance Tuning with the help of a LDAP Admin.

Tune the Group membership filter

Reference: Group membership filter.

In order to improve the performance of the LDAP query, you should include one of the following values on the text section that appears when you select the option Search for groups containing user:
* (member={0})
* (uniqueMember={0})
* (memberUid={1})
* (memberOf={0}) [Only for Active Directory servers]
The reason for that is related to the way we are building our LDAP query. Firstly, we are using the default group membership filter. The default filter is (| (member={0}) (uniqueMember={0}) (memberUid={1})). Such a filter is a default that catches most LDAP schemas. However, it is at least three times slower that whatever is the correct filter for your LDAP schema. The correct filter for your schema will be one of (member={0}) or (uniqueMember={0}) or (memberUid={1}). Changing to the correct filter will have a threefold increase in performance.

• Advanced: More specific configuration can be performed if you can restrict the groups to lookup. Let’s say on my tree I would like to restrict the groups to look for users inside the builds group. Then, my filter could look something like (& (cn=builds) (uniqueMember={0})).

Group search base / Group search filter

Reference: Group search base / Group search filter.

IMPORTANT: Group search filter is relative to the Group search base, if Group search base is left blank then root DN would be taken as default.

These options allow us to tell the ldap-plugin where the groups are located inside the ldap tree and what is the type of group we are using. On the case below, I would like to restrict the lookup to OU=groups,DC=brodate,DC=net. Since objectClass is groupOfUniqueNames in all my group objects, then I can restrict the object type to this one. The configuration will look something like:

• Group search base -> ou=groups
• Group search filter -> (& (cn={0} (objectclass=groupOfUniqueNames))

Examples of Group Search Filters.

User search base / User search filter

Reference: User search base / User search filter

These options allow us to tell the ldap-plugin where the users are located inside the ldap tree and what is the type of user we are using. On the case below, I would like to restrict the lookup to OU=people,DC=brodate,DC=net. Since objectClass is organizationalPerson in all my user objects, then I can restrict the object type to this one. The configuration will look something like the configuration below:

• User search base -> ou=people
• User search filter -> (& (uid={0}) (objectclass=organizationalPerson))

Validate your configuration

After applying any of the above changes, validate you configuration by clicking on Test LDAP Settings.

Once your configuration is validated, log-in with an “UserX” and browse to http://<JENKINS_URL>/whoAmI/ then validate groups for “UserX” are correctly retrieved.

Finally, the following Groovy script can be useful when trying to determine whether you have group search configured correctly.

Logging

To troubleshoot specific issues you could create a LDAP dedicated logger including the following packages:

Version 1.26 or newer

• org.springframework.ldap = ALL
• org.springframework.security.ldap = ALL

Before 1.26

• org.acegisecurity.ldap = ALL
• org.acegisecurity.providers.ldap = ALL

Tested products/plugins version

The latest update of this article has been tested with:

• Jenkins LTS 2.73.2-cb-1
• LDAP Plugin 1.18
• OpenLDAP