Can't connect SonarQube to LDAP directory for user mapping - ldap

Question

I'm trying to set up the user mapping on SonarQube (Latest) so it can fetch the organizational structure from LDAP.
I already installed the LDAP plugin on Sonar (1.5.1), and created a minimal configuration to connect the two:
# General Configuration
sonar.security.realm=LDAP
ldap.url=ldap://ldap:389
# User Mapping
ldap.user.baseDn=ou=users,ou=udd,dc=example,dc=com
ldap.user.request=(&(objectClass=inetOrgPerson)(uid={uid}))
ldap.user.realNameAttribute=cn
ldap.user.emailAttribute=mail
All my users are under the example.com domain:
But then, as I try to login to Sonar using the LDAP entries I get the following error on the logs:
Error from external users provider: exception Java::OrgSonarApiUtils::SonarException: Unable to retrieve details for user dev1 in <default>
Which is pretty frustrating, since all those properties are configured on the configuration file above.
Any ideas about the source of this issue?
EDIT:
I found this when I increased the log depth to DEBUG:
2016.01.25 05:54:27 DEBUG web[o.s.p.l.LdapContextFactory] Initializing LDAP context {java.naming.provider.url=ldap://ldap:389, java.naming.factory.initial=com.sun.jndi.ldap.LdapCtxFactory, com.sun.jndi.ld
ap.connect.pool=true, java.naming.security.authentication=simple, java.naming.referral=follow}
2016.01.25 05:54:27 DEBUG web[o.s.p.l.LdapUsersProvider] integer expected inside {}: (&(objectClass=inetOrgPerson)(uid={uid}))
javax.naming.directory.InvalidSearchFilterException: integer expected inside {}: (&(objectClass=inetOrgPerson)(uid={uid}))
at com.sun.jndi.toolkit.dir.SearchFilter.format(SearchFilter.java:602) ~[na:1.7.0_95]
at com.sun.jndi.ldap.LdapCtx.c_search(LdapCtx.java:1785) ~[na:1.7.0_95]
...
I don't see why is an integer supposed to be expected between the {}'s, and that doesn't make much sense compared to my LDAP structure.

Answer 1

Try to set ldap.user.request to (&(objectClass=inetOrgPerson)(uid={login}) (instead of using (uid={uid})).
Details:
The LDAP Plugin does not recognise {uid} and therefore doesn't know what to do with it. It then passes it to the LDAP javax.naming API, which chokes on this. This behaviour is made explicit at SonarQube startup (logs in my case):
INFO web[o.s.p.l.LdapSettingsManager] User mapping: LdapUserMapping{baseDn=cn=employees,dc=example,dc=org, request=(&(objectClass=inetOrgPerson)(uid={uid})), realNameAttribute=cn, emailAttribute=mail}
Using {login} instead (keyword shown in the documented default values) will let the LDAP Plugin build a well-formed request with a {0}:
INFO web[o.s.p.l.LdapSettingsManager] User mapping: LdapUserMapping{baseDn=cn=employees,dc=example,dc=org, request=(&(objectClass=inetOrgPerson)(uid={0})), realNameAttribute=cn, emailAttribute=mail}
The javax.naming API will then replace this {0} by a parameter which SonarQube will set to the actual username value you fill in the login form.