To my knowledge we are only supporting Basic authentication type. The fact it works when switching to Bearer make me think you may have a proxy in front of your SonarQube server.
Also, decoding your credentials (please change your password) looks weird:
MTE2OTg4YzRiZTQ4MzdkMTRiYjYwZGY3OGJkYTg1ZWM4N2FhOGI1YjpNdmFjQDIwMThj
decode to:
116988c4be4837d14bb60df78bda85ec87aa8b5b:Mvac@2018c
which seems to be a mix of token and password.
I would have expected either:
<username>:<password>
or
<token>:
Hey Julien, there is a IIS acting as reverse proxy to put SSL on it.
It is set up as described by the link at the SonarQube doc. This is the link: https://jessehouwing.net/sonarqube-configure-ssl-on-windows/
Hi @marcusvnac
Would you mind trying to bypass the IIS proxy, just to ensure it is not the cause of the problem? For example, change the endpoint configuration (or better, create a new endpoint configuration) to point directly to the SQ server (without SSL).
I already tried that and got the same error.
Here are my tests on SonarCloud.io, trying to access a private resource:
No credentials provided:
$ curl -v https://sonarcloud.io/api/settings/values?component=com.sonarsource.vbnet%3Asonar-vbnet-plugin
[...]
HTTP/1.1 403
[...]
Wrong credentials provided:
$ curl -v --user "foo:bar" https://sonarcloud.io/api/settings/values?component=com.sonarsource.vbnet%3Asonar-vbnet-plugin
[...]
Authorization: Basic Zm9vOmJhcg==
[...]
HTTP/1.1 401
[...]
Using a generated token (I have revoked it, so that’s expected you can’t reproduce):
$ curl -v --user "18d7a965611b571ddc2d18b02a1a9d5ae284c233:" https://sonarcloud.io/api/settings/values?component=com.sonarsource.vbnet%3Asonar-vbnet-plugin
[...]
Authorization: Basic MThkN2E5NjU2MTFiNTcxZGRjMmQxOGIwMmExYTlkNWFlMjg0YzIzMzo=
[...]
HTTP/1.1 200
[…]
Switching from Basic to Bearer:
$ curl -v -H "Authorization: Bearer MThkN2E5NjU2MTFiNTcxZGRjMmQxOGIwMmExYTlkNWFlMjg0YzIzMzo=" https://sonarcloud.io/api/settings/values?component=com.sonarsource.vbnet%3Asonar-vbnet-plugin
[...]
Authorization: Bearer MThkN2E5NjU2MTFiNTcxZGRjMmQxOGIwMmExYTlkNWFlMjg0YzIzMzo=
[...]
HTTP/1.1 403
So in my opinion you are looking in the wrong direction. The issue is not the authentication type, but more the fact that the authentication is tried with username = token + password. This might be a sign that your endpoint is not correctly configured.
I’m sorry to ask you again, but could you please:
- delete your SonarQube endpoint definition
- create a new one, choosing token authentication mode
- ensure that authentication header is
Authorization: Basic base64(<token>:)
Hi, this would be a good idea if we have this option to choose the authentication mode. However, the extension doesn’t have this option: https://marketplace.visualstudio.com/items?itemName=SonarSource.sonarqube
My bad, it used to be an option, but now it’s no more proposed to authenticate with username/password.
Still I remember we had some issues for people migrating from an old version of the extension (where is was possible to declare an endpoint with username + password) to the new version, accepting tokens only.
That’s why I was suggesting to delete the enpoint definition, and create a new one, to be sure only the token is persisted.
I already deleted and recreated this definition and removed and reinstalled the extension a number of times, and nothing changed.
Hi Marcus,
Then I have no idea from where this password might come. For sure the extension is not inventing it 
Me either 
Also, can you edit your post and remove it, pls?
Well, good news for me. Our company moved the On-Premises TFS to Azure DevOps last weekend and now the SonarQube seems to be working properly.
I have no further explanation, but we can close this issue now.
Thank you @Julien_HENRY for trying to help on this issue
Thanks Marcus for the follow up.
I have on-prem TFS. I have 2 builds, one that works successfully, and another doesnt. The “Prepare analysis on SonarQube” step in one case seems to use the token, and the other a login/pwd and fails with this error “The token you provided doesn’t have sufficient rights to check license”. The steps I have taken to setup the Service (with the sonar URL and token), and the build analysis steps are identical in both builds. I’ve attached a screenshot of the logs comparing the good and the bad builds. Any thoughts?
