Я использую накопительный пакет обновлений Forefront TMG SP1 3. На всех клиентах настольных ПК будет установлен клиент межсетевого экрана. Серверов не будет.
Я хотел бы разделить свой исходящий сетевой трафик в соответствии с трафиком, который был успешно аутентифицирован одним правилом, и тем, который не был аутентифицирован в другом. Это разделение в конечном итоге будет использоваться для другой обработки трафика.
Учитывая, что у меня есть два Internal-> External HTTP / HTTPS позволять перечисленные правила - первое требует аутентификации, а второе нет - обеспечит ли это желаемое поведение? Я знаю, что любое правило, требующее аутентификации, которое блокирует трафик, по своей сути будет блокировать любой трафик, для которого не включена аутентификация. Я немного не уверен, возникнет ли аналогичная проблема с оператором allow. Меня также беспокоит, если добавление правила, содержащего аутентификацию для HTTP / HTTPS, как это, повлияет на любые правила, отличные от HTTP *, например SMTP, который я хотел бы оставить ниже в цепочке правил.
Ответ выше описывает проблему упорядочивания правил.
Анонимные правила должны обрабатываться до аутентифицированных правил; Невозможно спекулятивно попросить клиента пройти аутентификацию, исходя из того, в каком направлении, по вашему мнению, это закончится.
С точки зрения HTTP, первый GET всегда анонимен, поэтому правила анонимности должны идти первыми, чтобы не проходить аутентификацию.
На практике это означает, что вы можете иметь несколько аутентифицированных правил, относящихся к одному и тому же месту назначения, или сначала одно анонимное правило, но не аутентифицированное правило, которое не вызывает аутентификации пользователя, а затем анонимное правило. Я не уверен, что есть дизайн, который может это приспособить.
Правила аутентификации для клиентов веб-прокси разделены по протоколу, источнику, пространству имен и различным другим параметрам, так что да, у вас могут быть правила, применимые к HTTP, которые не обязательно аутентифицируют SMTP (верхний совет: разделяйте веб-сайты и не- правила веб-протокола); имеют правила, которые применяются только на основе исходной подсети или набора целевых URL и т. д.
Тем не менее, лучшая ссылка на обработку правил ISA / TMG:
Я создал тестовую среду и применил предложенную конфигурацию к одному IP. К сожалению, похоже, что если в Forefront используется правило с проверкой подлинности, проверка подлинности не рассматривается как часть правила, а подвергается постобработке - весь трафик направляется в это правило, и если трафик анонимный, он автоматически отбрасывается.
Я надеялся, что в хорошо спроектированном продукте критерии пользователя будут рассматриваться как часть определения основного правила - если критерии не соблюдаются, трафик перейдет к следующему правилу в цепочке. Это не вариант.