Invalid Azure URL or Personal Access Token Azure DevOps Service

[Defqon123 (Felix)]

Hello!
I’m trying to configure Sonarqube with our Azure Devops Service (Cloud Version). But everytime I’m trying to connect to the service I get the following error:

Invalid Azure URL or Personal Access Token

I looked though your forum and found these threads

Invalid Azure URL or Personal Access Token for ALM Integration

Trial Developer Edition SonarQube Version: 8.6.1.40680 Trying to configure Azure DevOps Server ALM configuration and get the following: [image] Following is the network traffic: [image] I have tried resetting my PAT in Azure DevOps Server 2019 and insured the server URL was correct. Of note - Azure DevOps and SonarQube are running on the same server. DevOps is accessible via HTTPS only and SonarQube is accessible via HTTP only. Is this the possible cause? Thank you…troy

Invalid Azure URL or Personal Access Token

We use the Azure DevOps ALM Integration for pull request decoration. After the update to Sonarqube 8.9.0 build 43852 this functionality has stopped working. In the configuration section for the ALM Integration I get the error “Invalid Azure URL or Personal Access Token”. At first I tried to generate a new access token (with full access) just to verify that this was still correct and double checked the url. I searched for this error and came across this post: Invalid Azure URL or Personal Acces…

But both of them are using the Azure Devops Server. I checked also the web.log for the “check pat” statement. It is available but nothing else.
I’m running SonarQube behind a Proxy but I think it works correctly, because the marketplace is working.

Is there something I’m missing when I’m using the service and not the server version?

I’m using
Windows Server 2016
SonarQube LTS 8.9
openjdk 11.0.11 2021-04-20

Best regards
Felix

Edit:

SonarQube Connection Issues With Azure Devops Integration

Ok, so that’s normal. SonarQube can work only with other OnPrem CI tools (Azure DevOps Server). If you want to use Azure DevOps Services (cloud), you have to use SonarCloud instead.

I found this answer? Is this still correct today that the onPrem SonarQube Version only works with the onPrem Version of DevOps?

[Christophe_Havard]

Hi @Defqon123 and welcome to our community

@Defqon123

I found this answer? Is this still correct today that the onPrem SonarQube Version only works with the onPrem Version of DevOps?

This is not true anymore since version… I don’t remember. Anyway it should work. I personally have no idea why this do not work but I will ping some experts who might have the answer

Kind regards,
Christophe

[Belen_Pruvost (Belén Pruvost)]

Hey Felix,

Even though the threads you found are related to Azure DevOps Server, they could be a good standing point to start the investigation on why you’re currently getting this error.

I would suggest you to follow this specific post to get a better look at the debug level logs, and to try the suggestions described there (fix the URL and PAT, attempt some simple curl requests).

Let us know how that goes, and feel free to share debug level logs with us so that we can help you further.

Kind regards,
Belén

[tnapplications (IT)]

that link is a zoom meeting? can you please correct?

have the exact same issue happening

[Belen_Pruvost (Belén Pruvost)]

Hey @tnapplications, sorry about the wrong link. I’ve updated it in my original message, and you can also found it here.

[tnapplications (IT)]

so finally worked out what the issue is for us, the sslpoke utility someone referenced pointed me in the right direction… something has changed between older versions of SonarQube (v8.5 for us) compared to v8.9 LTS in regards to cert enforcement

As described by others, SonarQube would not connect to our DevOps hosted version. connecting to https://devopstst.ourdomain.com.au/ourproject/ worked perfectly fine in 8.5. Immediately after upgrading to v8.9 the same error as others have posted was received.

Seemingly has to do with something around trusting certificates. Solution was to import our root and subordinate certs for into the java store. I.e. whatever java instance you have configured in your wrapper.conf, the wrapper.java.command value.

The certs to be imported are the ones that make up the certificate path as used in your Azure Devops chain.

Suspect if you dirty work around is to just use http all the way through

Hope this helps someone else.

[Christophe_Havard]

@tnapplications thanks for sharing!

[logan_Kishore]

azure devops access token has not valid reason, the token doesn’t have the required (code: read and write ) permission
can you please support on this