Artifactory uses a 10-second connection timeout to the LDAP server by default. 10 seconds for timeout is sufficient in most cases, and we would strongly suggest to see why the timeout between the Artifactory and the LDAP server is occurring from time to time. If the LDAP search does not return a result in 10 seconds, Artifactory will through an error similar to below:
[ERROR] (o.a.a.l.p.LdapGroupProviderImpl:190) – An error occurred while retrieving LDAP groups with strategy STATIC, org.springframework.ldap.UncategorizedLdapException: Uncategorized exception occured during LDAP processing; nested exception is javax.naming.NamingException: LDAPresponse read timed out, timeout used:10000ms.; remaining name ‘ou=exchange_objects,dc=joshuanet,dc=global,dc=joshua,dc=com’
When the timeout issue happens, your Artifactory server could be failing to get a response from your LDAP server for more than 10 seconds. Please verify this by checking your network between the Artifactory server and the LDAP server when this issue happens. You may run a network trace between them to expedite the investigation.
Also, please consider narrowing down your Artifactory LDAP search base by using “Search Base” in Artifactory’s LDAP setting. The Search Base in Artifactory is the context name in which to search relative to the base DN in the LDAP URL. Please see our Wiki for details, and consult your LDAP administrator for assistance.
Or, you may increase the LDAP socket timeout value set at artifactory.system.properties, for example to 20 seconds (20000 ms)
Please note that you will need to restart Artifactory after making the change.
If the solution above doesn’t apply, then please take look at other components in between Artifactory and LDAP, such as reverse proxy, LDAP server, or router, to see who is making the limit. For example, OpenLdap has a default idle timeout of 30 seconds, but it can be customizable.
To troubleshoot the issue, we would like to recommend running the same REST-API (based on the request.log) using the same user to try replicating the issue using a CURL command with -v and -L so we may see what could be the limiting factor.