Я работаю над проектом, в рамках которого мы работаем над разделением веб-уровня на отдельный сервер от уровня приложений в соответствии с нашими требованиями безопасности. Это действительно хорошо сработало, за исключением одного предмета. При доступе к сайту TFS загружается все, кроме статических битов страницы (некоторые шрифты, изображения баннеров и значки). Я подтвердил через журналы на сервере приложений, что учетной записи службы, похоже, предоставлен доступ к файлам, но они фактически не отображаются на странице. Кроме того, для каждого из этих элементов, который пытается загрузить, появляется приглашение входа в систему, а учетные данные пользователя не работают при вводе. Проблема в основном возникает только тогда, когда применяется только HTTPS. Если я оставлю 8080 / HTTP в качестве основного URL-адреса и не буду применять SSL, это будет работать лучше, потому что больше не будет непрерывных запросов на вход в систему, но некоторые значки все еще отсутствуют. При проверке страницы при загрузке принудительной SSL-страницы контент, который не загружается, показывает HTTP / 1.0 с ошибкой 401, но в указанном URL-адресе указан HTTPS. При использовании прямого URL-адреса HTTPS для значка или файла изображения он будет загружен нормально. Затем, поскольку файл кэширован, я могу обновить страницу TFS, и этот значок / изображение будут правильно загружаться без запроса на вход, пока я не очищу кеш браузера. Мне кажется, что в TFS что-то не так. У меня правильно настроены групповые политики для учетной записи службы с олицетворением входа в систему и входа в систему в качестве службы, установленной как на веб-серверах, так и на серверах уровня приложений, поэтому я не считаю, что это проблема. Я пробовал это на нескольких разных сборках 2017 года, все с аналогичными результатами. В настоящее время в обновлении 3,1 2017 г., патч 6, и TFS настроен на использование согласования, поскольку в среде есть ограничения NTLM.
ОБНОВИТЬ: Хотел вернуться сюда и объяснить более подробно, но я был занят. Мы следуем требованиям NIST 800-53 и придерживаемся уровня 2 CIS. Таким образом, рекомендуемая конфигурация веб-приложения должна быть трехуровневой (веб, приложение и данные). TFS по умолчанию технически допускает до 2 уровней, на которых приложение и веб находятся в одном блоке. Мне нужно переместить Интернет в другой ящик для настоящей трехуровневой архитектуры. Итак, я думаю, что мне удалось найти способ своего рода `` обмануть '' TFS, заставив думать, что существует третий сервер для Интернета, который на самом деле не использует службы приложений, как уровень приложений, и по существу разделяет два уровня в результате .
Так я добился того, что я сейчас нахожусь. Это все коробки Server 2016.
TFS добавит веб-блок в список серверов приложений в консоли администратора, но ни одна из функций в веб-блоке не настроена. TFS рассматривает его почти как прокси-сервер TFS, поскольку он включает локальную группу безопасности TFS_Proxy в веб-блоке, но фактически не создает группу безопасности TFS_Application_Tier, как это делается на сервере приложений. Веб-сервер также не работает в качестве обычного «прокси-сервера TFS», поскольку он не кэширует данные локально для использования, как если бы вы настроили функцию прокси.
Я думаю, что это быстрая грязная работа, но я вернусь к тому описанию, которое я сделал, просматривая все это, чтобы отслеживать, что я делал, и убедиться, что я не пропустил ничего подходящего.