5

I've got an instance of sonarqube 5.5 running. I wanted to use the sonar-ldap-plugin 1.5.1 in order to delegate the authentication and authorization to the Active Directory service of my company.

The configuration for the LDAP plugin is the following (modulo some obfuscation):

sonar.authenticator.createUsers=false
sonar.security.savePassword=false
sonar.security.realm=LDAP
ldap.url=ldap://host.my.domain

ldap.user.baseDn=OU=Users,OU=Organic Units,DC=my,DC=domain
ldap.user.request=(&(objectClass=user) (sAMAccountName={login}))
ldap.authentication=DIGEST-MD5
ldap.bindDn=CN=harmlessServiceAccount,OU=users,OU=Organic Units,DC=my,DC=domain
ldap.bindPassword=<the user password in clear text>

sonar.log.level=DEBUG

And the sonarqube server reports the following error:

2016.07.13 10:19:38 INFO  web[o.s.p.l.LdapContextFactory] Test LDAP connection: FAIL
2016.07.13 10:19:38 ERROR web[o.a.c.c.C.[.[.[/]] Exception sending context initialized event to listener instance of class org.sonar.server.platform.PlatformServletContextListener 
java.lang.IllegalStateException: Unable to open LDAP connection
...
Caused by: javax.naming.AuthenticationException: [LDAP: error code 49 - 8009030C: LdapErr: DSID-0C0904DC, comment: AcceptSecurityContext error, data 52e, v1db1^@]
...

I did the exact same query with ldapsearch and did not meet any problem. So I think the Active Directory service is correct and accepts this user and the DIGEST-MD5 SASL mechanism.

I also used the same user through sonarqube with the SIMPLE (unsecure) mechanism and it was working "properly" as well. I also tried to put the md5 hash of the password instead of the password. And I tried a lot of other things I'm not proud of...

I read many similar issues online (stack overflow, other sources) and couldn't find a solution yet. Do you see anything wrong in my configuration? Am I doomed to use the SIMPLE mechanism and let everyone's password move around in clear text? I cannot use CRAM-MD5 neither GSSAPI as they are not supported by my company's active directory service.

TylerH
  • 20,799
  • 66
  • 75
  • 101
JCh
  • 81
  • 1
  • 2
  • Do you confirm that you're using the LDAP plugin and not the [Azure Active Directory plugin](https://github.com/SonarQubeCommunity/sonar-auth-aad)? – G. Ann - SonarSource Team Jul 13 '16 at 11:20
  • yes, I'm using the ldap plugin, version 1.5.1 – JCh Jul 14 '16 at 08:26
  • Do you mean you've got some hints, or you need more hints? :) – JCh Jul 15 '16 at 08:29
  • Maybe I make a mistake in the way I configure the ldap.bindDn and ldap.bindPassword. Shall they be clear text? or encrypted? and if so, how? – JCh Jul 15 '16 at 11:18
  • Does this answer your question? [LDAP: error code 49 - 80090308: LdapErr: DSID-0C0903A9, comment: AcceptSecurityContext error, data 52e, v1db1](https://stackoverflow.com/questions/31411665/ldap-error-code-49-80090308-ldaperr-dsid-0c0903a9-comment-acceptsecurityc) – TylerH Sep 14 '20 at 18:10

2 Answers2

2

The error code 49, has a subcode in it that tells you what the failure cause was. You reported:

[LDAP: error code 49 - 8009030C: LdapErr: DSID-0C0904DC, comment: AcceptSecurityContext error, data 52e, v1db1^@]

The data 52e part is the key.

Check out the list I maintain here, and you will see that 52e means bad password for your bind user. 525 would be bad DN for your user, so you have the correct LDAP DN, but the wrong password.

geoffc
  • 4,030
  • 7
  • 44
  • 51
  • 1
    Thanks for pointing this out, but the credentials are correct. The same request using another tool, e.g. ldapsearch, shows that there is nothing wrong in the ldap query itself (credentials, port, etc.). Now, what I'm not sure about is if the sonarqube configuration file takes the password in clear text or if it should be somehow encrypted (and if so, in which way), I couldn't figure it out from the sonarqube documentation. – JCh Jul 21 '16 at 06:51
  • 1
    @JCh See [this](http://docs.sonarqube.org/display/SONAR/Settings+Encryption) documentation page. All parts in the config file can be encrypted. – Jeroen Heier Aug 12 '16 at 08:48
  • Thank you, I tried it as well but it didn't help. It gives the same error. – JCh Aug 18 '16 at 14:56
2

I just encountered this and fixed it on sonarqube 6.x. and ldap plugin 2.2

The 52e will be a bit misleading I found as it can be invalid password, but that is also possible if the login is incorrect. http://ldapwiki.com/wiki/Common%20Active%20Directory%20Bind%20Errors

I had the following in my config

ldap.bindDn=domain\query_account

This has worked for other things but not SonarQube. Your line sonar.log.level=DEBUG actually helped me, I turned it on and it showed me the problem, I needed to escape the \ character. So this worked for me.

ldap.bindDn=domain\\query_account

this might not be your problem, but it definitely was mine. Hope it helps.

hoppy
  • 71
  • 1
  • 4
  • 1
    it certainly helped me, as it appears with digest-md5, the bindDN should just contain the username (harmlessServiceAccount), prefixed by the SALS realm (mydomain.my), and not something like: ldap.bindDn=CN=harmlessServiceAccount,OU=users,OU=Organic Units,DC=my,DC=domain. – Tallandtree Aug 15 '19 at 10:36
  • Yes, 52e is misleading. I deliberately used the wrong bindDn and still had that error code. Escaping the backslash worked for me (thank you!). Also make sure to remove "cn=" from bindDn if using this form to authenticate. – Patrick Mar 08 '23 at 19:16