Unable to register agent against on-premise Azure Dev Ops Server: TF400813 Resource not available for anonymous access. Client authentication required.

[anaximander23]

Problem

I'm trying to install an agent and connect it to an on-premise install of Azure Dev Ops Server. I've copied the Powershell script from the settings page and run it on the app server where we need the agent. The script downloads the agent successfully, but when attempting to configure it, we get the following error:

TF400813: Resource not available for anonymous access. Client authentication required.
Failed to connect.  Try again or ctrl-c to quit

We've tried two different PATs - one for a user with the agent pool administrator role, and one for a user who is the server administrator. The agent pool administrator's PAT had the "Agent Pools (Read & manage)" and "Deployment Groups (Read & manage)" permissions set, and no others. The server administrator's PAT was set to "full access". Both PATs were set to a 30-day expiry and were generated on the day we used them, so they definitely hadn't expired.

Under IIS, the app running Azure Dev Ops has Anonymous and Windows authentication enabled, and everything else disabled.

Agent Version and Platform

We're running Azure Dev Ops Server version 17.153.29226.8 on Windows Server 2012 R2.

The agent we're trying to configure is version 2.153.1 on Windows Server 2012.

Both are x64.

Similar issues

• TFS Build Agent config failing with TF400813: Resource not available for anonymous access. Client authentication required. #1839 was solved by disabling Basic Authentication; this is disabled on our server
• Cannot configure an agent on a Windows Server 2012 Standard #1543 was closed because the user found a workaround; problem looks similar but they never solved it
• TFS Build Agent failing against TFS 2017 on premise TF400813: Resource not available for anonymous access. Client authentication required. #759 was solved by uninstalling "Client Certificate Mapping With Active Directory"; this is not installed on our server

Diagnostic Logs

Agent_20191101-114308-utc.log

[nmdange2]

I just hit this same issue. This is the first time deploying an agent since installing the September 2019 patch. I worked around the issue by using "Negotiate" for authentication instead of "PAT"

[anaximander23]

Tried again with "Negotiate" and entered the credentials for the agent pool administrator. Same error message.

[jtpetty]

@anaximander23 - take a look at #2214 and let me know if that helps.

Also, for #1543, the issue was that the proxy was stripping off auth key from requests

[anaximander23]

#2214 describes an issue where the user had successfully registered an agent, and was then experiencing errors when switching to HTTPS. We are unable to even register the agent, and have been on https for a while now. Nonetheless, I tried the steps mentioned, but there is no change in behaviour.

Our sysadmin assures me that there is no proxy that should be interfering, but I'm going to try to run Fiddler on the machine in question to check what's happening with the network traffic.

[spashx]

Hi,

We have the same issue here.

• Windows 2012 R2 64 bits
• Azure Devops Server 2019 UPD1 17.153.29207.5 (AzureDevOps2019.Update1)
• Build agent 2.153.1
• IIS auth settings for /tfs site: All disabled, Windows auth: NTLM+Negociate

Use case: Trying to authenticate for the configuration of a build agent with a PAT on the machine hosting Devops Server (so no proxy/network stuff in between).

• The identity is agent pool administrator, and local machine administrator
• The PAT for the identity has full acccess

The config.cmd call with PAT authentication returns:

Enter authentication type (press enter for Integrated) > PAT
Enter personal access token > ****************************************************
TF400813: Resource not available for anonymous access. Client authentication required.

_diag.txt

using Chrome wit the identity on the server and hitting the URL provided in the _diag:
/tfs/_apis/connectionData?connectOptions=0&lastChangeId=32&lastChangeId64=32
does return a JSON content with values in it (not sure if it is safe to post it here).

logging Failed requests within IIS returns:

I verified that the Basic token from request is correct, the decoded value is "VstsAgent:<value_of_the_PAT>"

Please advise, thanks.

[jtpetty]

@anaximander23 and @spashx, can you try using the latest agent? Either 2.159.2 or 2.160.0 would be good.

[anaximander23]

Tried again with agent v2.160.0; no change in behaviour. Attached is the logfile.

Agent_20191105-134553-utc.log

[jtpetty]

@anaximander23 - and just for completeness, did you try Negotiate auth instead of PAT?

[anaximander23]

I did. No change.

[jtpetty]

Can you try creating a new PAT?

Also, could you try hitting that url with Chrome or Fiddler using PAT authentication?

looping in @stephenmichaelf for more ideas.

[anaximander23]

Which URL?

I can use Insomnia; if I'm reading these docs correctly then it needs to be a Basic Auth header with a value of {username}:{PAT} in base64, where the username is blank. Is this correct?

[jtpetty]

The URL in the log is: https://mon-tfs-2017/_apis/connectionData?connectOptions=0&lastChangeId=22&lastChangeId64=22

[anaximander23]

Hitting that URL in Firefox or Chrome shows me a JSON response with what I presume is information about my connection to Azure Dev Ops Server (contains an authenticatedUser block, an authorisedUser block, and some info on the servier instance). Hitting that URL in Insomnia using NTLM auth shows the same thing.

Trying to access that URL using Basic auth with a blank username and the PAT as password returns a 401 Unauthorized. This happens when using a PAT for the agent pool administrator, or for the server administrator.

Is there any information from either of those responses that is useful in diagnosing this?

[sadjadbp]

@anaximander23 let's debug the PAT problem outside the builds/agents first to make the process easier.

Let's create a brand new PAT, will scopes and all organizations selected (a global PAT) and hit the url https://mon-tfs-2017/_apis/connectionData or the one with collection name like https://mon-tfs-2017/defaultCollection/_apis/connectionData

with "Authorization: Basic Base64(:<>)" so if you PAT looks like 'ABCD' you need to Base64 ":ABCD" which would be "OkFCQ0Q=" and then you header would look like

"Authorization: Basic OkFCQ0Q=". You can use curl/PowerShell or Fiddler/PostMan to try the connection and you should get HTTP 200 with information about your identity as JSON.

[sadjadbp]

If that works then your PAT authentication module works, otherwise there is an issue with that.