Ошибка настройки агента DevOps TF400813: пользователь «пользователь» не имеет прав на доступ к этому ресурсу. Не удалось подключиться. Попробуйте еще раз или нажмите Ctrl-C, чтобы выйти
Попытка добавить агент для нашего локального Azure DevOps на новый веб-сервер. Следуя инструкциям здесь, на сайте Microsoft. Я загрузил zip-файл со своего сервера Devops и выполнил команды PowerShell, указанные на странице загрузки:
PS C:\> mkdir agent ; cd agent
PS C:\agent> Add-Type -AssemblyName System.IO.Compression.FileSystem ; [System.IO.Compression.ZipFile]::ExtractToDirectory("$HOME\Downloads\vsts-agent-win-x64-2.153.1.zip", "$PWD")
Затем я запустил инструмент настройки:
PS C:\agent> .\config.cmd
Следуя инструкциям:
Enter the server url > https://tfs.domain.com/mycollection
Enter authentication type > Negotiate
Enter username > agentuser
Enter password > ******
Результат:
TF400813: The user 'ORG\AgentUser' is not authorized to access this resource.
Failed to connect. Try again or ctrl-c to quit
Указанный пользователь управляет другими агентами на разных серверах. Я являюсь администратором сервера, и моя учетная запись имеет права администратора для всех пулов агентов.
Есть ли какое-то разрешение сервера, которого я не вижу в документации? Возможно ли, что «Переговоры» не являются допустимым методом аутентификации на этом сервере? Если да, то как я могу его добавить? Где мне искать более конкретный журнал ошибок?
Обновлять Дополнительная информация о журнале (я нашел журнал агента):
[2024-08-15 16:11:45Z WARN VisualStudioServices] Authentication failed with status code 401.
X-TFS-SoapException:
<?xml version = "1.0" encoding = "utf-8"?>
<soap:Envelope xmlns:soap = "http://www.w3.org/2003/05/soap-envelope">
<soap:Body>
<soap:Fault>
<soap:Code>
<soap:Value>soap:Receiver</soap:Value>
<soap:Subcode>
<soap:Value>UnauthorizedRequestException</soap:Value>
</soap:Subcode>
</soap:Code>
<soap:Reason>
<soap:Text xml:lang = "en">TF400813: Resource not available for anonymous access. Client authentication required.</soap:Text>
</soap:Reason>
</soap:Fault>
</soap:Body>
</soap:Envelope>
[2024-08-15 16:11:45Z WARN VisualStudioServices] Windows issued token provider instance 43205102 requires an interactive prompt which is not allowed by the current settings
[2024-08-15 16:11:45Z ERR VisualStudioServices] GET request to https://tfs.domain.com/mycollection/_apis/connectionData?connectOptions=1&lastChangeId=-1&lastChangeId64=-1 is not authorized. Details: TF400813: The user 'ORG\AgentUser' is not authorized to access this resource.
Ответы 2
Есть ли какое-то разрешение сервера, которого я не вижу в документации?
Я протестировал проблему на своем сервере Azure DevOps 2019.
Я создал нового пользователя на своем сервере и добавил его в группу администраторов Team Foundation. Затем пользователь сможет успешно войти в систему с типом аутентификации Negotiate. Вы можете просмотреть шаги на моем скриншоте.
Результат:
Enter server URL > http://vmxxx/DefaultCollection
Enter authentication type (press enter for Integrated) > Negotiate
Enter user name > testuser
Enter password > ****
Connecting to server ...
>> Register Agent:
Возможно ли, что «Переговоры» не являются допустимым методом аутентификации на этом сервере? Если да, то как я могу его добавить?
Да. Во время теста мне нужно добавить Negotiate к поставщикам проверки подлинности Windows. В противном случае произойдет еще одна ошибка при входе в систему с использованием типа аутентификации Negotiate.
Где мне искать более конкретный журнал ошибок?
Вы можете просмотреть подробный журнал в папке C:\agent\_diag, когда ваш агент находится в C:\agent.
Привет @Matt, спасибо за твои новости. Рад узнать, что вы решили проблему. Приятного кодирования!
В конечном итоге я не думаю, что правильно понял задание, а предоставленные мне инструкции были либо устаревшими, либо неверными.
Я нашел новые инструкции, в которых рекомендовалось использовать PAT вместо согласования аутентификации, и они сработали отлично, и теперь оба моих новых агента установлены и работают. По моему мнению, метод переговоров потребует от меня ввода МОЕГО имени пользователя и пароля, а не имени пользователя и пароля учетной записи агента. Я думаю, это, вероятно, сработало бы. Потому что позже при установке я ввел учетную запись агента и все заработало нормально.
Я понял проблему, которую думаю, и создал для нее свой собственный ответ.