Monday, December 11th, 2017

Создание множественных периметров безопасности с использованием Multihomed ISA-брандмауэров Часть 3: Сертификация соглашений по наименованию и проектированию инфраструктуры DNS

Published on Февраль 13, 2009 by   ·   Комментариев нет

В первой части этой серии, посвященной конфигурации брандмауэра ISA на нескольких зонах сетевой безопасности, мы рассмотрели концептуальные и проектные решения, связанные с интеллектуальной периметризацией сети. Во второй части, я описал пример сети, используемой в этой серии статей, цели проекта и природу трафика, который необходим для прохождения через брандмауэр ISA в различные зоны сетевой безопасности.

В этой, третьей части нашей серии, мы рассмотрим часто непонятные разделы, касающиеся соглашений по наименованию и инфраструктуры DNS, необходимой для поддержки конфигурации. Очень многие запутываются в этой области, поэтому необходимо уделить очень пристальное внимание к понятиям, обсуждаемым в этой статье. После того, как вы поймете принципы и проблемы, связанные с правильной инфраструктурой наименования сертификатов, вы никогда не встанете перед вопросом, почему ваши безопасные правила публикации Web и сервера (Server Publishing Rules) работают неправильно.

Если вы пропустили другие статьи из этой серии, то можете найти их здесь:

Соглашения по наименованию сертификатов Web Site Certificates

Первая тема, которая всегда вызываем замешательство – это соглашения по наименованию сертификатов, которые используются для поддержки SSL соединений к и через брандмауэр ISA. Вы должны заблаговременно решить, какие названия в сертификатах Web site должны быть связаны со следующими сетевыми элементами:

  • Web Listener, используемый для публикации сайта OWA
  • Web Listener, используемый для публикации OMA/ActiveSync/RPC на HTTP сайте
  • Web сайт для front-end сервера Exchange
  • Web сайт для back-end сервера Exchange

Соглашения по наименованию сертификатов для Web Listeners брандмауэра ISA

Сперва немного отвлечемся. Мы должны создать два Web listener для поддержки OWA, опубликованного с помощью механизма аутентификации брандмауэра ISA на основе форм. OWA FBA значительно повышает уровень безопасности, который брандмауэр ISA может предоставить для доступа к удаленным OWA соединениям. Для этого также необходимо отключить функцию FBA на front-end сервере Exchange.

В добавок, вы не можете использовать тот же самый listener для правила OWA Web Publishing Rule и правила OMA/ActiveSync/RPC-HTTP Web Publishing Rule, потому что клиентское программное обеспечение OMA/ActiveSync/RPC-HTTP не умеет работать с предоставляемыми им формами, и прекращает соединение, не информируя вас, почему оно было прекращено.

Теперь, когда вы знаете, что у вас должно быть два Web listener, вы также должны знать, что вы не можете создать два Web listener, используя одни и тот же сокет. Сокет – это комбинация IP адреса, протокола и порта.

Например, если мы создаем Web Listener, который будет использоваться для правила OWA Web Publishing Rule, которое слушает по TCP порту 443 по IP адресу 192.168.1.70, то мы не можем создать второй Web listener, который будет использоваться для правила OMA/ActiveSync/RPC-HTTP Web Publishing Rules, используя тот же самый сокет, т.е. этот сокет не может быть определен на TCP потру 443 по IP адресу 192.168.1.70. В этом и заключается причина того, что мы должны связывать второй IP адрес с внешним интерфейсом брандмауэра ISA для поддержки создания второго Web listener.

Примечание:
Вы можете обойти проблему необходимости двух IP адресов во внешнем интерфейсе брандмауэра ISA для поддержки правил OWA FBA Web Publishing Rules и OMA/ActiveSync/RPC-HTTP с помощью использования очень хорошего средства от Collective Software (www.collective.com) под названием FlexAuth. FlexAuth позволяет вам использовать один IP адрес для всех ваших опубликованных служб Exchange Web. Подробное описание FlexAuth я приведу в другой статье на этом сайте.

Последняя проблема, касающаяся сертификатов, связанных с Web listener, с которой мы будем иметь дело, заключается в том, что мы не можем связать один и тот же сертификат с несколькими listener (слушателями). Если мы создаем сертификат с общим названием owa.msfirewall.org и связываем его с первым Web Listener (который мы используем для правила OWA FBA Web Publishing Rule), то мы не можем использовать то же самый сертификат для второго Web Listener, который мы будем использовать для правила OMA/ActiveSync/RPC-HTTP Web Publishing Rule. Мы должны создать второй сертификат с другим названием, таким как rpc.msfirewall.org и связать этот сертификат со вторым Web listener.

Соглашения по наименованию сертификатов для Web сайтов Front-end и Back-end серверов Exchange

Однако, проблемы с сертификатами еще не закончились. Т.к. брандмауэр ISA выполняет связь SSL к SSL, то первое соединение от удаленного клиента завершается на внешнем интерфейсе брандмауэра ISA. Затем брандмауэр ISA расшифровывает соединение, выполняет полную проверку содержимого прикладного уровня, затем заново шифрует содержимое и направляет информацию по второму SSL каналу между ним самим и front-end сервером Exchange. Брандмауэр ISA должен быть настроен для использования названия сертификата, связанного с Web сайтом на front-end сервере Exchange для того, чтобы установить второе безопасное SSL соединение.

Т.к. вы можете связать один сертификат Web site, то вы связываете Web Listener на брандмауэре ISA с Web сайтом на front-end сервере Exchange, я предпочитаю создать третий сертификат Web site и связать этот сертификат с front-end сервером Exchange.

Например, вы можете создать сертификат Web site под названием feexchange.msfirewall.org и связать этот сертификат с Web сайтом front-end сервера Exchange. Если вы настраиваете правило Web Publishing Rules для передачи соединений на feexchange.msfirewall.org и используете запись в файле HOSTS на брандмауэре ISA, таким образом, чтобы название feexchange.msfirewall.org соответствовало IP адресу front-end сервера Exchange.

Примечание:
Причина, по которой мы используем запись в файле HOSTS, заключается в том, что название в сертификате будет таким же, что и название, которое front-end сервер Exchange зарегистрировал в интегрированном DNS Active Directory. Альтернативой использования записи в файле HOSTS является ручное создание записи Host (A) в DNS для поддержки названия в сертификате Web сайта front-end сервера Exchange.

Наконец, вы должны придумать название для сертификата, связанного с Web сайтом OWA на back-end сервере Exchange. В то время как внешние пользователи не затрагиваются конфигурацией на back-end сервер Exchange, то внутренних пользователей это касается напрямую. Вам необходимо связать сертификат с back-end сервером Exchange, который имеет такое же название, как и название, которое вы хотите использовать для доступа к сайту.

Например, вы хотите создать сертификат под названием be.msfirewall.org и связать этот сертификат с back-end сервером Exchange. Тогда пользователи, которые соединяются с OWA сайтом back-end сервера Exchange, должны использовать URI https://be.msfirewall.org/exchange для доступа к сайту. Мы еще подробно обсудим соглашения об инфраструктуре DNS, и то, как работать со схемами наименования, которые требуют различные названия для использования внешними и внутренними пользователями.

Соглашения по наименованию сертификатов, которые используются в SMTP, POP3 и IMAP4 сайтах

Соглашения по наименованию сертификатов для SMTP, POP3 и IMAP4 сайтов немного проще, чем соглашения по наименованию Exchange Web сайтов. Причина этого заключается в том, что мы должны использовать правила Server Publishing Rules для публикации этих безопасных сайтов на front-end сервере Exchange. Правила Server Publishing Rules в основном противоположны правилам NAT, на основе которых соединения к брандмауэру ISA проходят проверку на прикладном уровне. Безопасные соединения не прекращаются на брандмауэре ISA, конечная остановка – это сам front-end сервер Exchange.

Существуют два основных требования, касающиеся связи сертификатов для SMTP, POP3 и IMAP4 сайтов с front-end сервером Exchange:

  • Внешний пользователь должен быть в состоянии сопоставить название или названия, используемые в сертификате или сертификатах IP, адресам, используемым для прослушивания соединений с помощью правила Server Publishing Rule для этого протокола. Например, если мы используем название smtp.msfirewall.org для службы SMTP на front-end брандмауэре ISA, то название smtp.msfirewall.org должно соответствовать IP адресу внешнего интерфейса на брандмауэре ISA, используемого в правиле Server Publishing Rule, на основе которого опубликован SMTP сайт (или, по крайней мере, соответствовать IP адресу устройства, которое передает соединения на IP адрес внешнего интерфейса брандмауэра ISA, который слушает входящие SMTP соединения на основе правила SMTP Server Publishing Rule).
  • Клиентские приложения должны быть настроены для использования названия в сертификате для соединения к безопасному SMTP сайту. Например, если вы хотите, чтобы Outlook Express или Outlook 2003 соединялся с безопасным SMTP сервером на front-end сервере Exchange, то вы должны настроить параметры клиентского SMTP сервера для безопасного соединения с smtp.msfirewall.org. Если вы не настроите клиент для использования такого же названия, как в сертификате сайта, то получите ошибку «certificate name mismatch error» и клиентское приложение будет не в состоянии установить безопасное соединение с безопасным сайтом. То же самое справедливо для POP3S и IMAP4 сайтов

Вы можете создать три сертификата с различными названиями и связать их с каждым из сайтов. Например, сертификаты imap.msifrewall.org, pop.msfirewall.org и smtp.msfirewall.org могут быть связаны соответственно со службами IMAP4, POP3 и SMTP. Однако, я обычно советую использовать одинаковые названия для всех сайтов. Однако, помните, что если вы используете одинаковые сертификаты для всех сайтов, и по каким-то причинам вам надо аннулировать этот сертификат, то будет аннулированы сертификаты для всех трех сайтов. Напротив, если вы создаете различные сертификаты для каждого сайта, то вы можете удалить один сертификат не трогая сертификаты для других сайтов.

Соглашения по наименованиям сертификатов, используемых в тестовой сети

В тестовой сети мы будем использовать следующие соглашения по наименованию сертификатов для Web сайтов:

  • Сертификат Web сайта, связанного с первым Web Listener, который используется в правиле OWA Web Publishing Rule, будет иметь название owa.msfirewall.org и внешние пользователи будут иметь к нему доступ с помощью URI https://owa.msfirewall.org/exchange.
  • Сертификат Web сайта, связанного со вторым Web Listener, который используется в правиле OMA/ActiveSync/RPC-HTTP Web Publishing Rule, будет иметь название rpc.msfirewall.org. Хотя это название интуитивно не понятно для пользователей, на практике, им не надо запоминать это название, т.к. клиентское приложение должно быть жестко связано с этим названием, за исключением Web клиента OMA. Конечно, вы можете использовать любое название, которое захотите, только если оно не совпадает с названием, используемым в сертификате Web сайта OWA
  • Сертификат Web сайта, связанного с Web сайтом сервера Exchange на front-end сервере Exchange, будет использовать название feexchange.msfirewall.org. Если мы создаем правила Web Publishing Rules для Web служб сервера Exchange, мы будем использовать это название для передачи. Мы также должны настроить запись в файле HOSTS, которая будет сопоставлять это название IP адресу front-end сервера Exchange. Это позволяет избавиться от необходимости создания записи DNS для поддержки названия в сертификате
  • Сайты SMTP, POP3S и IMAP4S также должны иметь связанные с ними сертификаты Web сайтов. Название сертификата для Web сайта, связанного с ними, будет mail.msfirewall.org. Обратите внимание, что вы не используете консоль Internet Information Services для связи сертификатов Web сайта с этими службами. Вместо этого, вы используете Exchange Server System Manager.
  • Back-end сервер Exchange Server не будет иметь сертификат для Web сайта, связывающего его с тестовой сетью. Причина этого заключается в том, что мы не тестируем прямой доступ (Direct Access) к back-end серверу Exchange от корпоративных сетевых клиентов. Если вы планируете включить SSL доступ к back-end серверу Exchange, то вам необходимо связать сертификат Web сайта с сайтом и убедиться, что название сертификата соответствует действительному IP адресу back-end сервера Exchange (или, по крайней мере, устройству, которое передает соединения back-end серверу Exchange). Также, если вы используете конфигурацию Web proxy client для компьютеров в корпоративной сети, то убедитесь, что вы настроили ваши внутренние домены и IP адреса для прямого доступа (Direct Access), что вы должны сделать в любом случае, согласно рекомендациям для брандмауэра ISA.

На рисунке ниже показано участие серверов в этих соединениях и названия сертификатов, связанные с соответствующими Web Listener/Web сайтами.

Инфраструктура dns

Рисунок 1

Примечания по установке сертификатов

Далее я думаю рассказать о деталях по установке сертификатов и о том, как запрашивать и устанавливать сертификаты на брандмауэра ISA, front-end сервере Exchange и back-end сервере Exchange. Проблема с установкой сертификатов заключается в том, что методы, используемые для установки сертификатов, отличаются в зависимости от инфраструктуры PKI, на которую производится установка.

Если вы решите использовать службы Microsoft Certificate Services, то у вас есть выбор установки либо корпоративной CA, либо отдельно стоящей CA. Практически во всех ситуациях, когда установлен брандмауэр ISA, лучше использовать корпоративный CA. Я установил корпоративный CA на контролере домена в корпоративной сети в тестовой сети, используемой в этой статье.

Брандмауэр ISA, back-end сервер Exchange и front-end сервер Exchange Server являются членами одного домена, что и компьютеры корпоративной CA. Это позволяет сертификатам корпоративной CA автоматически устанавливаться для всех членов домена. Следствием этого является то, что все члены домена будут доверят сертификатам, выпускаемым этой корпоративной CA. Единственный недостаток такого сценария заключается в том, что front-end сервер Exchange автоматически не получит сертификат CA, не смотря на то, что он является членом домена. Причина этого заключается в том, что существует ошибка в фильтре RPC (или может быть это специальная возможность?), которая запрещает автоматическую регистрацию, когда включена опция strict RPC compliance.

Но это не основная проблема, потому что вы можете включить сертификат Ca в файл сертификатов, который также содержит сертификат Web сайта. Вы можете затем поместить CA сертификат в хранилище Trusted Root Certification Authorities machine certificate store на front-end сервере Exchange Server.

Обратите внимание, что существует много способов, с помощью которых вы можете решить проблему установки сертификатов как для корпоративной, так и для отдельно стоящей CA.

Для этой статьи я установил сертификаты с помощью мастера IIS Certificate Request Wizard на back-end сервер Exchange Server с помощью следующей процедуры:

  1. Выполнить запрос к CA (корпоративной CA) за сертификатом под названием owa.msfirewall.org.
  2. После получения сертификата, я экспортировал сертификат (вместе с его первичным ключом) и сертификат CA в файл.
  3. Затем я снова запустил мастер IIS Certificate Request Wizard, чтобы удалить сертификат с Web сайта.
  4. Снова запустите мастер IIS Certificate Request Wizard и запросите сертификат под названием rpc.msfirewall.org.
  5. После получения сертификата, экспортируйте сертификат вместе с его первичным ключом в файл.
  6. Запустите мастер IIS Certificate Request Wizard и удалите сертификат rpc.msfirewall.org с Web сайта.
  7. Запустите мастер IIS Certificate и запросите сертификат под названием feexchange.msfirewall.org
  8. После получения сертификата, экспортируйте сертификат вместе с его первичным ключом в файл.
  9. Запустите мастер IIS Certificate Request Wizard и удалите сертификат feexchange.msfirewall.org с Web сайта.
  10. Запустите мастер IIS Certificate Request Wizard и запросите сертификат под названием mail.msfirewall.org.
  11. Экспортируйте сертификат mail.msfirewall.org вместе с его первичным ключом в файл.
  12. Скопируйте файлы сертификатов feexchange.msfirewall.org и mail.msfirewall.org на front-end сервер Exchange.
  13. Импортируйте сертификат Web сайта feexchange.msfirewall.org в хранилище “machine certificate store” front-end сервера Exchange. Скопируйте сертификат CA, который был включен в импорт, в хранилище Trusted Root Certification Authorities.
  14. Импортируйте сертификат Web сайта mail.msfirewall.org в хранилище “machine certificate store” front-end сервера Exchange. Нам не надо копировать сертификат CA в хранилище Trusted Root Certification Authorities store, потому что мы уже сделали это.
  15. Свяжите feexchange.msfirewall.org с Web сайтом front-end сервера Exchange.
  16. Свяжите mail.msfirewall.org с SMTP, POP3 и IMAP4 службами на front-end сервере Exchange.
  17. Скопируйте файлы сертификатов owa.msfirewall.org и rpc.msfirewall.org на брандмауэр ISA (нам необходимо сделать это потому, что автоматическая регистрация также не пройдет на брандмауэре ISA, потому что фильтр RPC также защищает и сам брандмауэр ISA).
  18. Импортируйте сертификат Web сайта owa.msfirewall.org в хранилище “machine certificate store” брандмауэра ISA. Скопируйте сертификат CA, включенный в импорт в хранилище Trusted Root Certification Authorities store брандмауэра ISA.
  19. Импортируйте сертификат Web сайта rpc.msfirewall.org в “machine certificate store” брандмауэра ISA. Нам не надо копировать сертификат CA в хранилище Trusted Root Certification Authorities store, потому что мы уже сделали это на этой машине.
  20. Затем, мы свяжем сертификаты Web сайтов в “machine certificate store” брандмауэра ISA с соответствующими Web Listener.

Может показаться, что это очень длительный процесс, но вы можете завершить всю процедура менее чем за десять минут. Конечно, существуют другие способы получить машинные сертификаты, например, использование регистрации Web сайта на CA. Однако, эти сайты различаются в зависимости от того, устанавливаете вы корпоративный CA или отдельно стоящий CA. Более подробно вы можете узнать об этом в VPN Deployment Kit или в Exchange Deployment kit.

DNS инфраструктура

Хорошо спроектированная инфраструктура DNS очень важна, если соединения на удаленный доступ образуют пару с PKI. Причина для этого теперь может быть очевидной: названия сертификатов должны соответствовать названиям, включенным в запросы, посланные клиентами. В добавок, названия, используемые внешними корпоративными клиентами при подключении к SSL/TLS ресурсам, должны также соответствовать названиям сертификатов Web сайтов, связанными с сетевыми службами, к которым эти клиенты подключаются.

Чудеса DNS инфраструктуры

Ключ к успеху – это раздельная DNS инфраструктура. Теперь, перед тем как вы убежите в ужасе, я должен объяснить это:

Раздельная DNS инфраструктура никак не связана с использованием одного и того же названия для внешнего и внутреннего сетевых доменов. Для поддержки раздельной DNS инфраструктуры вам не надо изменять название вашего домена Active Directory или любого другого внутреннего DNS домена.

Раздельная DNS инфрастуктура – это ни что иное, чем две зональных DNS базы данных, обслуживающие доменные названия, одна для пользователей корпоративной сети, а другая для пользователей, располагающихся вне корпоративной сети, например, пользователи, которые используют удаленных доступ с помощью интернет.

Например, предположим, что название вашего внутреннего домена сети isafirewall.local. Вы знаете, что не можете использовать название домена верхнего уровня .local в интернет, поэтому вы регистрируете доменное название isafirewall.org, чтобы разрешить удаленный доступ к сервисам вашего сервера Exchange.

Вы настраиваете ваш внешний DNS сервер, который авторизован для домена isafirewall.org так, чтобы owa.isafirewall.org соответствовал ISA адресу внешнего интерфейса брандмауэра ISA, который будет использоваться Web Listener на основе правила OWA Web Publishing Rule, чтобы разрешить входящие Web запросы. Сертификат, связанный с Web listener имеет название owa.isafirewall.org. Внешние пользователи могут успешно устанавливать соединения с сайтом OWA, т.к. их клиентские системы расположены на удаленных сайтах в интернет и используют интернет DNS сервера, которые сопоставляют доменное имя isafirewall.org IP адресам, связанными с внешним интерфейсом брандмауэра ISA (или по крайней мере адресам устройства, которое маршрутизирует входящие соединения на внешний интерфейс брандмауэра ISA.)

Но что происходит, когда те же самые пользователи возвращаются назад в корпоративную сеть, после того как их путешествие завершилось? Пользователи попытаются получить доступ к серверу OWA с помощью того же названия http://owa.isafirewall.org и у них это не получиться. Почему? Потому что название owa.isafirewall.org соответствует внешнему IP адресу, а не действительному IP адресу сервера Exchange в корпоративной сети.

Как решить эту проблему? С помощью использования раздельной DNS инфраструктуры. Вам не надо изменять название вашего внутреннего домена DNS Active Directory. Все что вам необходимо, это настроить DNS на ваших внутренних сетевых DNS серверах на такое же доменное название isafirewall.org. Единственное различие между внутренними и внешними зонами в том, что названия DNS зон соответствуют адресам доступным из вне, а внутренние зоны соответствуют внутренним адресам, например действительный IP адрес сервера или сетевое устройство, которое обеспечивает доступ к сетевым службам.

DNS инфраструктура, используемая в тестовой сети

DNS инфраструктура в тестовой сети использует, то что я считаю наилучшим решением для DNS инфраструктуры, поддержку сценариев удаленного доступа. Эта DNS инфраструктура использует одно и то же название домена для внутренних сетевых ресурсов и для внешних сетевых ресурсов. Существует странное и необъяснимое заблуждение по поводу того, что использование одного и того же имени домена и для внутренних и для внешних ресурсов каким-то образом не является безопасным, однако, это в высшей степени ошибочное мнение, и вы должны игнорировать тех людей, которые заявляют, что это верно.

Наша тестовая сеть, используемая в этой статье использует одно и то же название домена msfirewall.org как для внутренних, так и для внешних ресурсов. Преимущество такого подхода заключается в том, что пользователям не нужно знать о своем местоположении, для того чтобы подключиться к ресурсам, которые доступны как для внешних, так и для внутренних пользователей. Пользователям не нужно перенастраивать клиентские приложения для поддержки перемещений между корпоративной сетью и внешним размещением.

Тестовая сеть имеет внешние и внутренние зоны, авторизованные для домена msfirewall.org. Внешние зоны поддерживаются сервером DNS, размещенном где-то извне, по отношению к корпоративной сети, а внутренняя зона поддерживается интегрированным сервером DNS в Active Directory в корпоративной сети.

На рисунке ниже показан пример того, что случится, если пользователь из внешней сети попытается подключиться к сайту OWA через периметр брандмауэра ISA.

  1. Сначала, клиентское приложение побудит операционную систему выполнить запрос к серверу DNS за названием owa.msfirewall.org. Сервер DNS вернет клиентскому программному обеспечению IP адрес, соответствующий owa.msfirewall.org.
  2. Затем клиентское приложение запустит запрос на соединение по IP адресу, который вернул DNS сервер для названия owa.msfirewall.org. Включая в запрос заголовок Host Header, который правило Web Publishing Rule брандмауэра ISA использует для соответствия с записью в закладке Public Name в правиле Web Publishing Rule
  3. Если запрос на соединение соответствует параметрам, содержащимся в правиле Web Publishing Rule, то он будет передан серверу под тем названием, которое было записано в закладке To правила Web Publishing Rule. В нашей тестовой сети в закладке To правила Web Publishing Rule записано название feexchange.msfirewall.org. Брандмауэр ISA может использовать запись в файле HOSTS, или запись в DNS. Если вы используете запись в DNS, то вы вручную должны создать запись Host (A), сопоставляющую название в сертификате Web сайта реальному IP адресу front-end сервера Exchange Server.

    Exchange сертификаты для Android ошибка соединения

    Рисунок 2

Рисунок ниже описывает процесс, упомянутый в шаге 3. После того, как брандмауэр ISA подтвердит, что запрос, который был запущен внешним клиентом, соответствует параметрам в правиле Web Publishing Rule, затем он сопоставляет название в закладке To в правиле Web Publishing Rule. Файл HOSTS на брандмауэре ISA содержит запись, которая ставит в соответствие название front-end сервера Exchange в сертификате Web сайта действительному IP адресу front-end сервера Exchange Server в авторизованном для доступа DMZ сегменте. Затем, запрос передается этому IP адресу брандмауэром ISA.

По наименованию

Рисунок 3

На рисунке ниже показана последовательность соответствия названий для внешнего клиента, которые подключается к опубликованному сайту с помощью правила Server Publishing Rule вместо правила Web Publishing Rule. Внешний клиент выполняет запрос к основному серверу DNS за названием mail.msfirewall.org, а затем соединяется с IP адресом, который вернул DNS сервер, и который является IP адресом внешнего интерфейса брандмауэра ISA, используемый слушателем Server Publishing Rules listener.

Различие заключается в том, что соединение совершается не брандмауэром ISA, брандмауэр ISA совершает реверсивный NAT и передает соединение front-end серверу Exchange Server. Только после того, как соединение достигает front-end сервера Exchange, все содержимое расшифровывается. В этом случае, вам не надо беспокоиться о связи сертификатов со слушателями на брандмауэре ISA.

Согласование используемого уровня безопасности IP isa

Рисунок 4

Резюме

В этой статье мы обсудили насущные проблемы в инфраструктуре наименований сертификатов, необходимых для поддержки безопасного удаленного доступа с помощью брандмауэра ISA. Мы рассмотрели связь сертификатов с Web Listener брандмауэра ISA, front-end сервером Exchange Server и back-end сервером Exchange. Затем мы рассмотрели проблемы DNS инфраструктуры, связанные с безопасной публикацией. В следующей статье из этого цикла, мы рассмотрим подробности конфигурации брандмауэра ISA и правил Web Publishing Rules, Server Publishing Rules и Access Rules, необходимых для поддержки соединений с front-end сервером Exchange.

www.isaserver.org




Смотрите также:

Tags: , , , , , ,

Readers Comments (Комментариев нет)




Да человек я, человек! =)

Exchange 2007

Проведение мониторинга Exchange 2007 с помощью диспетчера System Center Operations Manager 2007 (часть 3)

Если вы хотите прочитать предыдущие части этой серии статей, перейдите по ссылкам: Проведение мониторинга Exchange 2007 с помощью диспетчера System ... [+]

Практическое рассмотрение перехода с Exchange 2003 на Exchange 2007 (часть 1)

Введение В этой статье из нескольких частей я хочу показать вам процесс, который недавно использовал для перехода с существующей среды Exchange 2003 ... [+]

Использование инструмента Exchange Server Remote Connectivity Analyzer Tool (часть 2)

Если вы пропустили первую часть этой серии, пожалуйста, прочтите ее по ссылке Использование инструмента Exchange Server Remote Connectivity Analyzer Tool (Часть ... [+]

Мониторинг Exchange 2007 с помощью диспетчера System Center Operations Manager 2007 (часть 2)

Если вы пропустили предыдущую часть этой серии статей, перейдите по ссылке Мониторинг Exchange 2007 с помощью диспетчера System Center Operations ... [+]

Подробное рассмотрение подготовки Active Directory для Exchange 2007 (часть 5)

Если вы пропустили предыдущие части этой серии статей, перейдите по ссылкам: Подробное рассмотрение подготовки Active Directory для Exchange 2007 (часть 1) ... [+]

Установка и настройка Exchange 2007 из командной строки (Часть 3)

If you missed the previous parts in this article series please read: Exchange 2007 Install and Configuration from the command line (Part ... [+]

Использование инструмента Exchange Server Remote Connectivity Analyzer Tool (часть 1)

Инструмент ExRCA Текущий выпуск инструмента предоставляется только в целях тестирования и оснащен 5 опциями: Тест подключения Outlook 2007 Autodiscover Тест подключения Outlook 2003 RPC ... [+]

Развертывание сервера Exchange 2007 Edge Transport (часть 5)

Если вы хотите прочитать предыдущие части этой серии статей, перейдите по ссылкам: Развертывание сервера Exchange 2007 Edge Transport (часть 1) Развертывание ... [+]

Установка и настройка Exchange 2007 из командной строки (часть 2)

Если вы пропустили первую статью данного цикла, пожалуйста, перейдите по ссылке: Exchange 2007 Install and Configuration from the command line (Part ... [+]

Использование интегрированных сценариев Using Exchange Server 2007 – часть 2: генерирование отчетов агента Transport AntiSpam Agent

Если вы пропустили предыдущую часть этой серии статей, перейдите по ссылке Использование интегрированных сценариев Using Exchange Server 2007 – часть ... [+]