SonarQube sonarqube-10.8.1.101195 LDAP - GSSAPI LDAP Bind Failure

Version: sonarqube-10.8.1.101195
Deployed: From Zip
Goal: LDAP integration with Kerberos / GSSAPI
Tried:

              initialDirContext = Subject.doAs(lc.getSubject(), new PrivilegedExceptionAction<InitialDirContext>() {
                @Override
                public InitialDirContext run() throws NamingException {
                  Properties env = new Properties();
                  env.put(Context.INITIAL_CONTEXT_FACTORY, factory);
                  env.put(Context.PROVIDER_URL, providerUrl);
                  env.put(Context.REFERRAL, referral);
                  return new InitialLdapContext(env, null);
                }
              });
  • Tested code by adding, Context.SECURITY_AUTHENTICATION
               initialDirContext = Subject.doAs(lc.getSubject(), new PrivilegedExceptionAction<InitialDirContext>() {
                @Override
                public InitialDirContext run() throws NamingException {
                  Properties env = new Properties();
                  env.put(Context.INITIAL_CONTEXT_FACTORY, factory);
                  env.put(Context.PROVIDER_URL, providerUrl);
                  env.put(Context.SECURITY_AUTHENTICATION, "GSSAPI");
                  env.put(Context.REFERRAL, referral);
                  return new InitialLdapContext(env, null);
                }
              });

Issue arises with the following authentication:

ldap.authentication=GSSAPI

Error displayed in the logs:

2025.03.22 17:16:48 INFO  web[][o.s.a.l.LdapContextFactory] Test LDAP connection on *******************: OK
Caused by: javax.naming.NamingException: [LDAP: error code 1 - 000004DC: LdapErr: DSID-0C090CAF, comment: In order to perform this operation a successful bind must be completed on the connection., data 0, v4f7c^@]
        at java.naming/com.sun.jndi.ldap.LdapCtx.mapErrorCode(Unknown Source)
        at java.naming/com.sun.jndi.ldap.LdapCtx.processReturnCode(Unknown Source)
        at java.naming/com.sun.jndi.ldap.LdapCtx.processReturnCode(Unknown Source)
        at java.naming/com.sun.jndi.ldap.LdapCtx.searchAux(Unknown Source)
        at java.naming/com.sun.jndi.ldap.LdapCtx.c_search(Unknown Source)
        at java.naming/com.sun.jndi.ldap.LdapCtx.c_search(Unknown Source)
        at java.naming/com.sun.jndi.toolkit.ctx.ComponentDirContext.p_search(Unknown Source)
        at java.naming/com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(Unknown Source)
        at java.naming/com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(Unknown Source)
        at java.naming/javax.naming.directory.InitialDirContext.search(Unknown Source)
        at org.sonar.auth.ldap.LdapSearch.find(LdapSearch.java:130)
        at org.sonar.auth.ldap.LdapSearch.findUnique(LdapSearch.java:143)
        at org.sonar.auth.ldap.DefaultLdapUsersProvider.getUserDetails(DefaultLdapUsersProvider.java:78)
        ... 174 common frames omitted

With GSSAPI on,

Java Test Code without Context.SECURITY_AUTHENTICATION, the error above is reproduced.

Java Test Code with Context.SECURITY_AUTHENTICATION, the error is resolved. LDAP bind observed in network traffic.

Based on the test above, switch the following setting to “simple”:
ldap.authentication=simple

LDAP authentication is resolved and works. LDAP Server is configured to support LDAP GSSAPI as it is configured with other products to use it.

With all of the above, and LDAP plug-in code being incorporated into Sonar as written in GitHub,

The suspicion is there is a defect of a missing statement for GSSAPI to set the Context.SECURITY_AUTHENTICATION to “GSSAPI”.

Issue persists with:
ldap.authentication=GSSAPI

Thread similar to this one found at: Trouble getting integrated with Active Directory

Please advise

Hi @compi2025,

Thank you very much for the detailed analysis and for taking the time to dig into the code —this kind of deep investigation is incredibly valuable and appreciated by the team.

To be fully transparent, SonarSource no longer actively maintain the LDAP feature for SonarQube Server. However, we’ve taken note of this potential bug and will keep an eye out for similar reports. If this emerges as a recurring issue, we’ll certainly look into your solution.

Thanks again for your contribution!

Best regards,