LDAP

You can configure SonarQube authentication and authorization to an LDAP server (including the LDAP service of Active Directory)

You can configure SonarQube authentication and authorization to an LDAP server (including the LDAP service of Active Directory) by configuring the correct values in <SONARQUBE_HOME>/conf/sonar.properties.

The main features are:

• Password checking against the external authentication engine.

• Automatic synchronization of usernames and emails.

• Automatic synchronization of relationships between users and groups (authorization).

• During the first successful authentication, the user account is created in the SonarQube database. Each time a user logs into SonarQube, the username and the email are synchronized.

• Overview is an option that will sync SonarQube group memberships with the LDAP service.

	Apache DS	OpenLDAP	Open DS	Active Directory
Anonymous
Simple
LDAPS
DIGEST-MD5
CRAM-MD5
GSSAPI

= successfully tested

Setup

1. Configure LDAP by editing <SONARQUBE_HOME>/conf/sonar.properties (see table below).

2. Restart the SonarQube server and check the log file for: INFO org.sonar.INFO Security realm: LDAP ... INFO o.s.p.l.LdapContextFactory Test LDAP connection: OK

3. Log in to SonarQube.

4. On log out users will be presented with a login page (/sessions/login), where they can choose to log in as a technical user or a domain user by passing the appropriate credentials.

For SonarScanners, we recommend using Security for authentication against SonarQube Server.

General Configuration

Property	Description	Default value	Required	Example
sonar.security.realm	Set this to LDAP authenticate first against the external sytem. If the external system is not reachable or if the user is not defined in the external system, authentication will be performed against SonarQube’s internal database.	none	Yes	LDAP (only possible value)
sonar.authenticator.downcase	Set to true when connecting to a LDAP server using a case-insensitive setup.	false	No
ldap.url	URL of the LDAP server. If you are using ldaps, you should install the server certificate into the Java truststore.	none	Yes	ldap://localhost:10389
ldap.bindDn	The username of an LDAP user to connect (or bind) with. Leave this blank for anonymous access to the LDAP directory.	none	No	cn=sonar,ou=users,o=mycompany
ldap.bindPassword	The password of the user to connect with. Leave this blank for anonymous access to the LDAP directory. If you use a Kubernetes secret to pass the password, see below.	none	No	secret
ldap.authentication	Possible values: simple, CRAM-MD5, DIGEST-MD5, GSSAPI. See the tutorial on authentication mechanisms	simple	No
ldap.realm	See Digest-MD5 Authentication, CRAM-MD5 Authentication	none	No	example.org
ldap.contextFactoryClass	Context factory class.	com.sun.jndi.ldap.LdapCtxFactory	No
ldap.StartTLS	Enable use of StartTLS	false	No
ldap.followReferrals	Follow referrals or not. See Referrals in the JNDI	true

If passing LDAP bind password via a Kubernetes secret

If you use a secret in an environment variable in a Kubernetes pod to pass the LDAP bind password, you must add the ldap.bindPassword property to sonar.properties as described below with an example.

Environment variable definition in the yaml file:

env:
  - name: ldap_bindPassword
    valueFrom:
      secretKeyRef:
        name: ldap
        key: password

Corresponding bind password definition in sonar.properties:

ldap.bindPassword: ${env:ldap_bindPassword}

User Mapping

Property	Description	Default value	Required	Example for Active Directory
ldap.user.baseDn	Distinguished Name (DN) of the root node in LDAP from which to search for users.	None	Yes	cn=users,dc=example,dc=org
ldap.user.request	LDAP user request.	(&(objectClass=inetOrgPerson)(uid={login}))	No	(&(objectClass=user)(sAMAccountName={login}))
ldap.user.realNameAttribute	Attribute in LDAP defining the user’s real name.	cn	No
ldap.user.emailAttribute	Attribute in LDAP defining the user’s email.	mail	No

Group synchronization

Only groups and static groups are supported. Roles and dynamic groups are not supported; this page about Static Vs Dynamic LDAP Group management offers more detail about the differences.

To delege authorization, groups must first be defined in SonarQube. See the Group synchronization section on the Overview for more details. After your groups are created, the following properties must be defined to allow SonarQube to automatically synchronize the relationships between users and groups.

Property	Description	Default value	Required	Example for Active Directory
ldap.group.baseDn	Distinguished Name (DN) of the root node in LDAP from which to search for groups.	none	No	cn=groups,dc=example,dc=org
ldap.group.request	LDAP group request.	(&(objectClass=groupOfUniqueNames)(uniqueMember={dn}))	No	(&(objectClass=group)(member={dn}))
ldap.group.idAttribute	Property used to specifiy the attribute to be used for returning the list of user groups in the compatibility mode.	cn	No	sAMAccountName

Configuration sample

# LDAP configuration
# General Configuration
sonar.security.realm=LDAP
ldap.url=ldap://myserver.mycompany.com
ldap.bindDn=my_bind_dn
ldap.bindPassword=my_bind_password
  
# User Configuration
ldap.user.baseDn=ou=Users,dc=mycompany,dc=com
ldap.user.request=(&(objectClass=inetOrgPerson)(uid={login}))
ldap.user.realNameAttribute=cn
ldap.user.emailAttribute=mail
 
# Group Configuration
ldap.group.baseDn=ou=Groups,dc=sonarsource,dc=com
ldap.group.request=(&(objectClass=posixGroup)(memberUid={uid}))

Advanced LDAP Topics

Authentication Methods

• Anonymous - Used when only read-only access to non-protected entries and attributes is needed when binding to the LDAP server.

• Simple Simple authentication is not recommended for production deployments not using the LDAP secure protocol since it sends a cleartext password over the network.

• CRAM-MD5 - The Challenge-Response Authentication Method (CRAM), based on the HMAC-MD5 MAC algorithm (RFC 2195).

• DIGEST-MD5 - This is an improvement on the CRAM-MD5 authentication method (RFC 2831).

• GSSAPI - GSS-API is Generic Security Service API (RFC 2744). One of the most popular security services available for GSS-API is the Kerberos v5, used in Microsoft’s Windows 2000 platform.

For a full discussion of LDAP authentication approaches, see RFC 2829 and RFC 2251.

Multiple Servers

You can use multiple LDAP servers to manage your users. The purpose is to enable connections for organizations using distinct LDAP servers for different user populations.

You cannot use multiple LDAP servers as a failover cluster. When a user authenticates for the first time via a specific LDAP server, their account is linked to that server. Subsequent authentication by the same user through a different LDAP server will result in the creation of a separate user account, leading to email address conflicts.

To configure multiple servers:

# List the different servers
ldap.servers=server1,server2
  
# Configure server1
ldap.server1.url=ldap://server1:1389
ldap.server1.user.baseDn=dc=dept1,dc=com
...
 
# Configure server2
ldap.server2.url=ldap://server2:1389
ldap.server2.user.baseDn=dc=dept2,dc=com
...

Authentication will be tried on each server, in the order they are listed in the configurations until one succeeds.

Note that all the LDAP servers must be available while (re)starting the SonarQube server.

Migrate users to a new authentication method

If you are changing your delegated authentication method and migrating existing users from your previous authentication method, you can use the api/users/update_identity_provider web API to update your users’ identity provider.

About user and identity provider IDs

To avoid the risk of misidentification, the following identification methods are used on all LDAP setups, including SonarQube instances with a single LDAP connection:

• The local login of a new account is made unique with a suffix to the identifier. eg. login_<additional_id>.

• The name of the External Identity Provider is also made unique with the addition of the server key provided in the configuration. eg. LDAP_<server_key> where ldap.servers=<server_key>,...

Troubleshooting

Troubleshooting

• Detailed connection logs (and potential error codes received from the LDAP server) are output to SonarQube’s <SONARQUBE_HOME>/logs/web.log, when logging is in DEBUG mode.

• If you experience time outs when running SonarQube analysis using LDAP, Java parameters are documented here. Such parameters can be set in sonar.web.javaAdditionalOpts in <SONARQUBE_HOME>/conf/sonar.properties.