Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
anaximander23 opened this issue Nov 1, 2019 · 29 comments
Assignees

Comments

@anaximander23
Copy link

anaximander23 commented Nov 1, 2019

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

Diagnostic Logs

Agent_20191101-114308-utc.log

@nmdange2
Copy link

nmdange2 commented Nov 1, 2019

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
Copy link
Author

anaximander23 commented Nov 4, 2019

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

@jtpetty
Copy link
Member

jtpetty commented Nov 4, 2019

@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
Copy link
Author

anaximander23 commented Nov 5, 2019

#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
Copy link

spashx commented Nov 5, 2019

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:
IIS Capture

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

Please advise, thanks.

@jtpetty
Copy link
Member

jtpetty commented Nov 5, 2019

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

@anaximander23
Copy link
Author

anaximander23 commented Nov 5, 2019

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

Agent_20191105-134553-utc.log

@jtpetty
Copy link
Member

jtpetty commented Nov 5, 2019

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

@anaximander23
Copy link
Author

anaximander23 commented Nov 5, 2019

I did. No change.

@jtpetty
Copy link
Member

jtpetty commented Nov 7, 2019

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
Copy link
Author

anaximander23 commented Nov 8, 2019

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
Copy link
Member

jtpetty commented Nov 8, 2019

@anaximander23
Copy link
Author

anaximander23 commented Nov 8, 2019

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
Copy link

sadjadbp commented Nov 12, 2019

@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
Copy link

sadjadbp commented Nov 12, 2019

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

@anaximander23
Copy link
Author

anaximander23 commented Nov 13, 2019

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
Copy link
Author

anaximander23 commented Nov 19, 2019

@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
Copy link

lezardo commented Dec 3, 2019

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
Copy link

lezardo commented Dec 3, 2019

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 jtpetty self-assigned this Dec 9, 2019
@jtpetty
Copy link
Member

jtpetty commented Dec 9, 2019

Closing since this is not an agent issue.

@alexanderwieland
Copy link

alexanderwieland commented Jan 22, 2020

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

@janis-veinbergs
Copy link

janis-veinbergs commented Mar 12, 2020

@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
Copy link
Author

anaximander23 commented Mar 12, 2020

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
Copy link

risabara commented Jun 19, 2020

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

@RomBrz
Copy link

RomBrz commented Jul 29, 2020

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

@bml104
Copy link

bml104 commented Aug 26, 2020

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

@DFranklet
Copy link

DFranklet commented Dec 9, 2020

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
Copy link

sandeepnegi1996 commented Feb 1, 2021

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

@soroshsabz
Copy link

soroshsabz commented Apr 30, 2021

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests