SonarQube LDAP Authentication seems to load but won't allow login via domain user

Question

I\'ve been trying to setup SonarQube (v4.1) with the LDAP authentication plugin (v1.4) and I just can\'t get it to authenticate against my domain user. My config is setup as

Answer 1

I just worked through getting the SonarQube LDAP plugin to work with Active Directory myself. Since everyone's network is set up differently, you often can't just copy and paste a configuration. Here is the process I used to figure out the correct configuration at my company:

As stated in the documentation, this configuration goes in the file:

SONARQUBE_HOME/conf/sonar.properties

The following line is required as-is:sonar.security.realm=LDAP. Other lines will be different per company.

It was helpful for me to test the configuration with a GUI tool. I used the Softerra LDAP Browser (free read-only version of LDAP Administrator). In that LDAP Browser,

1. Create a new profile.
2. Lookup Servers button will help determine ldap.url. You will need to end up with something along the lines of ldap.url=ldap://dc01.mycompany.local:3268. NOTE: As stated in another answer, this may need to be a different port than the one listed in this screen.
3. The Base DN box can be left blank for now.
4. For authentication, I just chose the currently logged on user.
5. The filter can also be left blank for now.
6. Click Finish and it should display items at the top level of your AD.
7. F3 toggles the Quick Search bar.
8. Since you can't connect SonarQube to AD with Anonymous Authentication, you will need to select a user for the SonarQube service to connect as. Search for that user in the Quick Search.
9. You should find a CN (Common Name) entry. Double-click that to open it up.
10. Find the distinguishedName field and copy its value to use as your ldap.bindDn
11. ldap.bindPassword should be that user's password.
12. That should be enough to let SonarQube start successfully, but it is NOT enough to let it search for the user that is trying to log into your SonarQube web portal. For that, first pick a sample person (such as yourself).
13. Do another Quick Search for the sample person and open up their CN entry
14. Take the value of their distinguishedName, remove the "CN={Their Name}," piece, and put that into ldap.user.baseDn
15. The last piece that you need to determine with the ldap.user.request. The suggestion from the SonarQube docs to use with AD worked for me: (&(objectClass=user)(sAMAccountName={login})). Let me explain why, in case it does not work for you. The "{login}" will be replaced by whatever the SonarQube enters for their username, so that request string (which is called "Filter" in LDAP Browser) is essentially saying to search for all entries with any objectClass equal to "user" and their sAMAccountName equal to whatever is typed into the username textbox in your SonarQube web portal. Inside the sample person's info, there should be at least one field called "objectClass". One of those should have the value "user". There should also be an field for sAMAccountName. Use that value for the username textbox in your SonarQube web portal.
16. To test if that request string should work for you, do a Directory Search in LDAP Browser (Ctrl+F3). Put your ldap.user.baseDn value in the "Search DN" texbox and put your ldap.user.request value in the Filter texbox (be sure to manually replace "{login}" with your sample username). It should return the CN entry for the sample person.

Answer 2

Using port 3268 did the trick for me. Here is my configuration that works with SonarQube 5.0.1 and Active Directory:

sonar.security.realm=LDAP
sonar.security.savePassword=true
sonar.security.updateUserAttributes=true
sonar.authenticator.createUsers=true

ldap.url=ldap://dc101.office.company.com:3268
ldap.bindDn=CN=Service Account,OU=Windows Service,OU=Accounts,OU=Resources,DC=office,DC=company,DC=com
ldap.bindPassword=PASSWORD

ldap.user.baseDn=DC=office,DC=company,DC=com
ldap.user.request=(&(objectClass=user)(sAMAccountName={login}))
ldap.user.realNameAttribute=cn
ldap.user.emailAttribute=mail

Answer 3

http://blogs.msdn.com/b/visualstudioalm/archive/2015/11/13/support-for-active-directory-and-single-sign-on-sso-in-the-sonarqube-ldap-plugin.aspx

With the new v1.5, only one line is required:

LDAP configuration

sonar.security.realm=LDAP

Answer 4

I am using SonarQube 3.7.3 and I attached my configuration which works. I hope that would be useful.

# General Configuration
sonar.security.realm=LDAP
sonar.authenticator.createUsers=true
sonar.security.savePassword=true
sonar.security.updateUserAttributes=true
ldap.url=ldap://...
ldap.bindDn=user
ldap.bindPassword=password

# User Configuration
ldap.user.baseDn=ou=People,dc=company,dc=local
ldap.user.request=(&(objectClass=user)(sAMAccountName={login}))
ldap.user.realNameAttribute=cn
ldap.user.emailAttribute=mail

Answer 5

None of solutions before worked for me, but this:

# Configuration
sonar.realm=myreal.domain.com
sonar.security.realm=LDAP
sonar.authenticator.createUsers=true
sonar.security.savePassword=true
sonar.security.updateUserAttributes=true
ldap.url=ldap://myreal.domain.com:389

ldap.bindDn=cn=CNUser,dc=domain,dc=com
ldap.bindPassword=password

# User Configuration
ldap.user.baseDn=ou=people,dc=domain,dc=com
ldap.user.request=(&(objectClass=user)(sAMAccountName={login}))
ldap.user.realNameAttribute=cn
ldap.user.emailAttribute=mail

#logeo lo que pasa
wrapper.console.loglevel=DEBUG

My Ldap server do needs authentication, so i cant avoid that. If it doesnt works for you, try not to especify the ldap.user.request: all depends of the configuration of your network´s LDAP server.

Answer 6

My Fix

I had painstakingly verified my settings, even to the point of using the log file's "User mapping" output line to configure a manual ldapsearch command and verify that my user was being retrieved properly.

For some reason, specifying this setting fixed it for me:

ldap.user.realNameAttribute=cn

Why?

This attribute is supposed to be optional and default to cn anyway, but it only works for me if I specify it manually. This might be a bug.

Debugging with ldapsearch

ldapsearch can allow you to bypass the application query LDAP directly.

I looked in the log file for this line:

INFO  web[o.s.p.l.LdapSettingsManager] User mapping: LdapUserMapping{baseDn=DC=my-ad,DC=example,DC=com, request=(&(objectClass=user)(sAMAccountName={0})), realNameAttribute=cn, emailAttribute=mail}

And then built an ldapsearch command like:

ldapsearch -D CN=myldapuser,CN=Users,DC=my-ad,DC=example,DC=com -W -h my-ad.example.com -b "DC=my-ad,DC=example,DC=com" "(&(objectClass=user)(sAMAccountName=myuser))"

• -D specifies the bind DN, basically the login username for LDAP
• -W means that ldapsearch will prompt you for the password
• -h specifies the LDAP URL
• -b should be baseDN from the log file line
• The last positional parameter is the request value from the log file line, after replacing {0} with a real username.

If you get real user info back, it means your basic settings are right. This is a hint that something else is going wrong.