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 https://<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