Агент сборки TFS не может подключиться к ленте пакетов

Question

Небольшая информация о нашей настройке:

• On-Prem TFS 2018, обновление 2 (работает как учетная запись службы домена A)
• Отдельная виртуальная машина Win2k16, на которой размещается агент сборки (с использованиемУчетная запись службы домена B для запуска агента)
• Фид пакетов, размещенный в коллекции на TFS

Так что это работает уже несколько месяцев (новый кусок - фид пакетов длянаши собственные пакеты NuGet).В проекте MVC, использующем наши серверы сборки, задача NuGet Restore завершается неудачно при попытке подключиться к нашей ленте пакетов.В случае неудачи сообщение:

http://TFS_URL:8080/tfs/Development/_packaging/CustomNuGetFeed/nuget/v3/index.json: Unable to load the service index for source http://TFS_URL:8080/tfs/Development/_packaging/CustomNuGetFeed/nuget/v3/index.json.
Response status code does not indicate success: 401 (Unauthorized).

Это вся информация, которую выдает журнал сборки;Я углубился и развернул WireShark и получил следующее:

Запрос

GET /tfs/Development/_packaging/CustomNuGetFeed/nuget/v3/index.json HTTP/1.1
user-agent: NuGet Command Line/4.4.1 (Microsoft Windows NT 6.2.9200.0)
X-NuGet-Client-Version: 4.4.1
Accept-Language: en-US
Accept-Encoding: gzip, deflate
Authorization: Basic <base64_token>
Host: tfs:8080

Ответ

HTTP/1.1 401 Unauthorized
Content-Type: text/html
Server: Microsoft-IIS/8.5
X-TFS-ProcessId: d9a45aba-cc82-4f2c-98a3-e4441bfa456f
ActivityId: e780f2d6-1216-46ac-8c66-cb89379c7811
X-TFS-Session: e780f2d6-1216-46ac-8c66-cb89379c7811
X-VSS-E2EID: e780f2d6-1216-46ac-8c66-cb89379c7811
X-FRAME-OPTIONS: SAMEORIGIN
WWW-Authenticate: Bearer
WWW-Authenticate: Negotiate
WWW-Authenticate: NTLM
WWW-Authenticate: Basic realm="tfs"
X-Powered-By: ASP.NET
P3P: CP="CAO DSP COR ADMa DEV CONo TELo CUR PSA PSD TAI IVDo OUR SAMi BUS DEM NAV STA UNI COM INT PHY ONL FIN PUR LOC CNT"
Lfs-Authenticate: NTLM
X-Content-Type-Options: nosniff
Date: Tue, 16 Oct 2018 19:57:17 GMT
Content-Length: 1293

Сообщение страницы ответа

401 - Unauthorized: Access is denied due to invalid credentials.
You do not have permission to view this directory or page using the credentials that you supplied.

Тем не менее, есть приложение .NET Core, которое, насколько я могу судить, все еще восстанавливает пакеты нормально (если только оно не извлекает пакеты только из кэша).

Учетные данные для учетной записи службы не изменились вообще.Я удостоверился, что учетные записи службы имеют доступ к каналу, в соответствии с этими документами: https://docs.microsoft.com/en-us/azure/devops/artifacts/feeds/feed-permissions?view=vsts&tabs=previous-nav

Я также попытался отключить обычную аутентификацию в IIS для сайта TFS на сервере TFS и включить Windowsавт.Ни то, ни другое не сработало.

Так что я в растерянности, в чем проблема может быть из всего, что я пробовал / изучал.

Answer 1

Даже после обновления до Azure DevOps Server 2019.0.1 я по-прежнему получал 401 Несанкционированный при попытке аутентификации в фиде пакетов, который был размещен в той же коллекции.

Обходное решение

Обходной путь, который я использовал, заключался в том, чтобы поместить двоичные файлы пакета в папку кэша пакетов на сервере сборки, расположенную здесь: C: \ Users \ .nuget \ packages

Рабочее решение

Однако решение было найдено с помощью Microsoft VS Community.Обновленный поставщик кредитов должен использоваться с задачей восстановления NuGet.

Необходимо использовать Nuget 4.8+, чтобы это работало, а затем необходимо добавить 2 переменные сборки в определение сборки: NuGet_ForceEnableCredentialProviderV2 = true NuGet.ForceEnableCredentialProvider = false

Согласно Microsoftресп, это будет включено по умолчанию при обновлении ADOS 2019.1.

Вы можете просмотреть полную тему здесь: https://developercommunity.visualstudio.com/content/problem/360323/tfs-build-agent-cant-connect-to-package-feed.html

Answer 2

TL; DR;nuget был слишком стар.Обновление помогло.

У нас возникла та же проблема после настройки нового компьютера агента сборки для TFS 2018 в Windows 2019. Однако мы не использовали wireshark для проверки трафика, поэтому это может быть не связано.Симптомы все же: одно решение работало (с использованием пакета), другое не работало (с использованием nuget).

Проблема заключалась в том, что решение другое использовалоnuget (версия 2.x) из преданного стороннего каталога.Nuget предназначен для использования «глобального» nuget из% localappdata% \ nuget, если он доступен.И эта глобальная версия Nuget не существует.Обновление nuget по мере того, как пользователь агента сборки исправил проблему, и поместил последнюю версию nuget в% localappdata%:

nuget.exe update -self

Я думаю, что TFS 2018 требует проверки подлинности NTLM вместо базовой проверки подлинности (которая все еще казаласьподдерживается TFS 2017).Мне все еще кажется странным, что установленная VS 2017.9.5 не обновляла nuget.