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.

[anaximander23]

I get a 401 for the root address, but on the defaultCollection one I get a 200, and some JSON containing data describing the owner of the token.

[anaximander23]

@sadjadbp

• https://mon-tfs-2017/_apis/connectionData with the new PAT returns a 401
• https://mon-tfs-2017/defaultCollection/_apis/connectionData returns a 200 with the expected identity info JSON

Does this reveal anything useful? What else can I try to narrow down a cause?

[lezardo]

Hi all,
Same issue here trying to register agent (2.160.1) against Azure DevOps Server 2019.1.1 using PAT.
Works with Negotiate as workaround but we do need PAT to work as well.
Agent_20191203-122540-utc.log

Any news Please ?

---

---

/ _ \ | ___ () | ()
/ /\ ____ _ _ __ ___ | |/ / _ __ | | _ __ ___ ___
| _ | / | | | '/ _ \ | /| | ' \ / _ \ | | ' \ / _ / |
| | | |/ /| || | | | __/ | | | | |) | / | | | | | /_
_| |/|_,|_| _| _| |_| ./ _|||| ||_||__/
| |
agent v2.160.1 || (commit 8c04bd1)

Connect:

Error reported in diagnostic logs. Please examine the log for more details.
- D:\agentDebug_diag\Agent_20191203-122540-utc.log
TF400813: Resource not available for anonymous access. Client authentication req
uired.

[lezardo]

Hi all,
Same issue here trying to register agent (2.160.1) against Azure DevOps Server 2019.1.1 using PAT.
Works with Negotiate as workaround but we do need PAT to work as well.
Agent_20191203-122540-utc.log

Any news Please ?

/ _ \ | ___ () | ()
/ /\ _____ _ _ __ ___ | |/ /_ _ __ | | _ __ ___ ___ | _ | / | | | '/ _ \ | /| | ' \ / _ \ | | ' \ / _ / | | | | |/ /| || | | | __/ | | | | |) | / | | | | | / | |/|,|| | | || ./ **|||| ||**||_/ | | agent v2.160.1 || (commit 8c04bd1)

Connect:

Error reported in diagnostic logs. Please examine the log for more details.

• D:\agentDebug_diag\Agent_20191203-122540-utc.log
  TF400813: Resource not available for anonymous access. Client authentication req
  uired.

Update: This is Azure DevOps Server 2019.1.1 RC. we have the error against (I missed "RC"), our TEST env.

Update2: It does works using PAT (and Negotiate) with agent version (2.160.1) but against TFS 2018.3 on prem. This is our PROD env. not upgraded yet.
--> So I guess this is due to Azure DevOps Server itself, not the agent, since both our environments are the same as well as agent version and user chosen for PAT (TEST database was refreshed from PROD just before upgrade) ?

[jtpetty]

Closing since this is not an agent issue.

[alexanderwieland]

Use "https://[servername]/[organizationname]"
Infos: https://developercommunity.visualstudio.com/solutions/802663/view.html

[janis-veinbergs]

@anaximander23 could it be that you generated organization scoped PAT? I was like: "been there done that" (regarding agent registration with PAT) and then battled this same issue. Only to realize, when generating token, Organization by default was set to some specific org, and had to set: "All accessible organizations"

[anaximander23]

Actually, I'm no longer at the company where I was having this issue, and the company I'm with now use the dev.azure.com version rather than self-hosted.

On the one hand, this means I won't be able to help work out what was causing this issue. On the other hand, it means I no longer have a problem.

[risabara]

@janis-veinbergs, thank you for posting that. saved me a ton of time troubleshooting!

[RomBrz]

@janis-veinbergs thanks! Same situation here ("been there done that")

[bml104]

Use "https://[servername]/[organizationname]" worked for me. Thanks!

[DFranklet]

Oh it's such a fiddly business isn't it? Microsoft really doesn't want us to use on prem resources.
Contrary to the above, what worked for me under server URL was https://servername/tfs

My deployment target is in AWS and Azure DevOps on prem, so that's got its own hurdles. [servername] can't be an IP address and needs a cert which matches. You may not like opening up your DevOps to the internet, and you didn't have to with Web Deploy, but you will have to now. (You can lock it down to the resources in question)

I don't know if it was strictly necessary but I did follow the advice upthread about choosing "All accessible organisations" when generating the PAT

[sandeepnegi1996]

my issue is solved by changing the option while creating the token set it to organizational level

[soroshsabz]

I think https://docs.microsoft.com/en-us/azure/devops/pipelines/agents/v2-windows?view=azure-devops-2020 must be updated and add all these details