Integration of sonarqube with on-prem active directory

SonarQube Server / Community Build Plugin Development
1

is anyone here who has been able to integrate sonarqube server with active idirectory for authentication purposes?

on the sonar.properties,I added required parameters however I failed to login with the ad account,kindly advise

2

Hi @kagabaj,

Welcome to the community. To help diagnose why your AD login is failing, we’ll need a bit more information:

  1. SonarQube version (found in Administration → System)
  2. Your sonar.properties LDAP configuration (redact any passwords/sensitive values)
  3. The error message you see when attempting to log in — either in the browser or in the SonarQube web.log file
  4. The relevant log output — enable debug logging at Administration → System → Log Level, attempt a login, then share any LDAP-related errors from web.log

In the meantime, the LDAP authentication documentation covers the required properties for Active Directory integration and common pitfalls. Make sure you’re following the Active Directory-specific examples, as the configuration differs slightly from generic LDAP.

Best regards,

Stevan

3

1.We are on sonarqube 2026.1.3

2.sonar.properties is below:

sonar.security.realm=LDAP

ldap.url=dc1.com

3.No error message,only I can’t see the option to switch to ad login from the portal

4.from web.log,advise which specific lines to check for this purpose

sonar.security.ldap.bindDn=CN=(binding account),OU=Service Accounts,DC=,DC=,DC=
ldap.bindPassword=
ldap.user.request=(&(objectClass=user)(sAMAccountName={login}))
ldap.user.baseDn=
ldap.user.realNameAttribute=cn
sonar.log.level=DEBUG
ldap.group.baseDn=
ldap.group.request=(&(objectClass=group)(member={dn}))
ldap.group.idAttribute=cn
sonar.authenticator.provisioning=true

4

Hi @kagabaj,

Thanks for sharing your configuration. I can see a few issues that explain why the AD login option isn’t appearing.

1. Invalid ldap.url format is the main issue

Your current value ldap.url=dc1.com is missing the protocol prefix. SonarQube requires a full URL:

ldap.url=ldap://dc1.com:389

When this is incorrect, the LDAP plugin silently fails to initialize at startup, and SonarQube falls back to local authentication only, which is why you’re not seeing the AD login option.

2. ldap.user.baseDn is empty

This is a required field. Set it to the base DN of your Active Directory domain, for example:

ldap.user.baseDn=DC=yourcompany,DC=com

3. Incorrect property prefix for bindDn

You have sonar.security.ldap.bindDn — the correct property name is simply ldap.bindDn (no sonar.security. prefix). All LDAP properties use the ldap. prefix.

4. sonar.authenticator.provisioning is not a valid property and will be silently ignored. User provisioning on first login is the default behavior and doesn’t need to be explicitly configured.

Here’s a corrected configuration to start from:

sonar.security.realm=LDAP
ldap.url=ldap://dc1.com:389
ldap.bindDn=CN=bindingaccount,OU=Service Accounts,DC=yourcompany,DC=com
ldap.bindPassword=yourpassword
ldap.user.baseDn=DC=yourcompany,DC=com
ldap.user.request=(&(objectClass=user)(sAMAccountName={login}))
ldap.user.realNameAttribute=cn
ldap.group.baseDn=DC=yourcompany,DC=com
ldap.group.request=(&(objectClass=group)(member={dn}))
ldap.group.idAttribute=cn

After updating, restart SonarQube and check web.log for lines containing LDAP — a successful initialization will log something like LDAP realm activated. Any connection or configuration errors will appear there as well.

Best regards,

Stevan

5

knowing that the bin account and password are 100% correct,the app is failing to start with the error 52e and 49 as error code.

I used your configurations 100%.

Regards

6

Hi @kagabaj,

Thanks for the update. Good progress, errors 49/52e mean the LDAP plugin is now initializing and connecting (the URL fix worked), but the bind step is failing. This is a narrower problem to solve.

LDAP error 49 / sub-code 52e means Invalid Credentials in Active Directory, the domain controller is rejecting the bind DN or password.

Here are the most likely causes:

1. Placeholder DC values not replaced
My example used DC=yourcompany,DC=com as a placeholder. You need to substitute your actual domain. If your AD domain is corp.example.com, that becomes:

ldap.bindDn=CN=bindingaccount,OU=Service Accounts,DC=corp,DC=example,DC=com
ldap.user.baseDn=DC=corp,DC=example,DC=com
ldap.group.baseDn=DC=corp,DC=example,DC=com

2. Try UPN format as an alternative
Instead of the full DN for ldap.bindDn, try:

ldap.bindDn=bindingaccount@yourdomain.com

3. Bind account may lack read permissions
The service account needs at minimum read access to the directory. Confirm with your AD administrator.

To help diagnose further, please share:

  1. The startup section of web.log - the lines containing LDAP that appear in the first ~30 seconds after SonarQube starts. These will show the exact bind error and what DN is being attempted.
  2. Your current sonar.properties with passwords redacted - specifically the ldap.bindDn, ldap.user.baseDn, and ldap.group.baseDn values so we can verify the DN format.

The web.log is found in $SONARQUBE_HOME/logs/web.log.

Best regards,
Stevan