-
Notifications
You must be signed in to change notification settings - Fork 35
Troubleshooting
Following are some common issues often encountered by users of the plugin, along with some troubleshooting tips for those issues.
- In most cases, this is due to permissions not being set and authorized properly. You should review the group sync documentation and make sure all steps are done, especially the granting of permissions.
- The group name on SonarQube must match the Azure AD group name exactly. For example, if you want the users in the "Lead Developers" Azure AD group to be synced, then the exact same group name should be created in SonarQube and permissions granted to that group. As each user logs into the SQ instance, their account will be created and added to the group there, assuming you allow new account creation.
- Releases before version 1.2.0 did not support indirect group memberships (user is a member of a group that is a member of a different group). For those versions, only groups that a user is a direct member of will be synced.
This is an intended behavior. Group sync will both add and remove group memberships in Sonarqube. If a user is part of any group on SonarQube, but there is no matching group membership in Azure AD, they will be removed from that group when group sync is enabled.
You can either create a group in your Azure AD named "sonar-administrators" and add users there or create a group in SonarQube that matches the administrator group in your AzureAD and grant the same global permissions as sonar-administrators to that group.
First, make sure you have done all the setup steps correctly as listed in the group sync documentation for the sync method you are using. If sync continues to fail, set the log level for "sonar.log.level.web" to "DEBUG" in the sonar.properties file, and try again. Check the "web.log" file for "graph.microsoft.com" to find the right location to examine. If the more detailed log messages don't help, you can request help and post a sanitized portion of the logs to an issue and one of the contributors will try to help as they can.
- Confirm that the Client ID, Client Secret, and Tenant ID are correct. They should match what is shown in the Azure Portal. The secret/key is only shown on generation, so you may need to create a new one.
- Make sure the key you are using for the Client Secret has not expired. All generated keys for registered applications in Azure have an expiration date, and the one you are using may have expired.
- If you are using an Azure "National Cloud" such as Azure for US Government or one of the other offerings, you need to make sure to set the directory location correctly. You may also need to make sure that the Multi-Tenant setting is off.
Upgrade the plugin to version 1.1 RC2 or newer. This issue is due to the way older versions of the plugin handle user authentication.
If you've set up a reverse proxy with IIS specifically using the recommended tutorial from SonarQube, it won't redirect to external sites for authentication. You will need to make a change to the configuration using the following steps to fix this:
- Inside IIS Manager, select the server in the Connections pane.
- Select and open
Application Request Routing Cache
in the main pane. - From the actions sidebar, select
Server Proxy Settings...
- Uncheck
Reverse rewrite host in response headers
and selectApply
from the actions sidebar.
In certain setups, SonarQube can't determine its public URL and it will send the wrong one. This often happens with reverse proxy setups. Make sure to configure the "Server base URL" (sonar.core.serverBaseURL) in SonarQube's settings. You can find it in the General tab of the SonarQube configuration.