Invalid Azure URL or Personal Access Token for ALM Integration

Trial Developer Edition SonarQube Version:

Trying to configure Azure DevOps Server ALM configuration and get the following:

Following is the network traffic:

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

1 Like

I’m having the same issues, with the dame Dev version of the software, but I’m using Azure DevOps 2020

Same issue here. Azure Devops 2020 On-Prem

Hello @TroyG , @DotNetDeveloper and @teriansilva
Let me post a preliminary answer here for our community.
The “Invalid Azure URL or Personal Access Token” message is shown in the UI for any problem related to your PAT or AzDO URL you have set or, and that is important, to SonarQube connectivity to your Azure Devops.

In order to know which, on SonarQube 8.7, you need to

  • turn on the DEBUG logs for the SonarQube WEB component (in Administration → System page)
  • check your Azure Configuration again
  • open the web.log file and search for the “check pat” line as follows

The line(s) are shaped as follows (on SonarQube 8.7):

2021.03.11 08:06:53 DEBUG web[AXgBwW+6J0z4dDrXABFO][o.s.a.c.a.AzureDevOpsHttpClient] check pat : [<Azure URL>]

About 20 other DEBUG lines about http/https connectivity follow and the block ends with

2021.03.11 08:06:54 DEBUG web[AXgBwW+6J0z4dDrXABFO][o.s.a.c.a.AzureDevOpsHttpClient] Unable to contact Azure DevOps server: <Azure URL> 401

If you are in this case the remediation is probably simple; you need to fix the URL or the PAT you have set according to SonarQube documentation.
You need to make sure PATs are allowed with your Azure Devops setup too: IIS Basic Authentication invalidates using PATs - Azure DevOps | Microsoft Docs

In case you only see the initial line, then it means SonarQube is unable to establish the http/https connectivity to the address you have configured. A few root cause to investigate:

  • the address is unresolved in the context of your SonarQube instance (docker?)
  • SonarQube is unaware of some needed proxy for this connection
  • SonarQube (JVM) does not trust the certificate shown by the AzDO service (e.g. established by a corporate CA)

In order to confirm in which situation you are, you may use simple curl command lines, and then use some simple Java https client to check the JVM TrustStore and Java proxy settings.
Parameters for proxy and JVM TrustStore can be set either with your or with the environment variables (Docker case).

Side note about OCSPs / CRLs:
If your PKI issues some CRLs or OCSPs, the addresses for these services should also be reachable.


1 Like