Я тестирую клиентскую машину, которая отправляет запросы на сервер biztalk, используя машину переднего плана в качестве веб-прокси. При первом тесте я ввел неверное имя / пароль в порт приема и получил правильное сообщение об ошибке (407). Затем я установил правильное имя / пароль, и все работало правильно.
Оттуда я сохранил правильную информацию в порту приема, но ввел неверное имя / пароль в адаптер отправки, но процесс завершился успешно (должен был завершиться неудачно с 407).
Я удостоверился, что порты приема и отправки не обходят прокси для локальных адресов.
Таким образом, единственное, что кажется логичным, это то, что TMG кэширует запрос аутентификации, исходящий от машины, над которой я работаю.
Правильно ли это мышление, и если да, то кто-нибудь знает, как отключить его в TMG?
Проверять учетные данные каждые (секунды) - этот параметр включает кэширование учетных данных клиента в течение настраиваемого периода времени.
Этот параметр доступен в разделе «Проверка подлинности - Дополнительно» в прослушивателе.
который не должен быть вашей проблемой, но шаги по настройке правил обратного кэширования можно найти здесь: Настройте Forefront TMG в качестве прокси-кеша
смотрите также Настройте TMG как прокси-сервер кеша
Нет, аутентификация не кэшируется, но сеанс NAT будет отмечен как "прошедший аутентификацию"
Это очень похоже на то, что произойдет, если вы: - определите правило - получите доступ к сайту - создается сеанс nat - вы удалите правило
Пока этот сеанс NAT не истечет или вы вручную не истечете его из (Мониторинг / Сеансы), вы продолжите доступ к ресурсу, даже если для него больше не существует правила брандмауэра