Публикация Outlook Web Access и Outlook RPC/HTTP с брандмауэрами ISA Server 2006 Enterprise Edition (RC) с использованием проверки подлинности на основе форм (одночленный массив без NLB) — Часть 3. Ра

Публикация Outlook Web Access и Outlook RPC/HTTP с брандмауэрами ISA Server 2006 Enterprise Edition (RC) с использованием проверки подлинности на основе форм (одночленный массив без NLB) — часть 3. Развертывание сертификатов и создание правил веб-публикации

Обсудите эту статью на веб-доске по адресу: http://tinyurl.com/fvflv

• Публикация Outlook Web Access и Outlook RPC/HTTP с брандмауэрами ISA Server 2006 Enterprise Edition с использованием проверки подлинности на основе форм (одночленный массив без NLB)
• Публикация OWA и Outlook RPC/HTTP с брандмауэрами ISA Server 2006 EE с использованием проверки подлинности на основе форм (одночленный массив без NLB): Часть 2. Проблемы развертывания DNS и сертификатов

В первой части этой серии статей о том, как публиковать сайты OWA и RPC/HTTP с помощью брандмауэра ISA, я обсуждал сетевое окружение, на котором основана эта серия, некоторые ключевые концепции сети и брандмауэра ISA, а также проблемы, связанные с использованием нового брандмауэра ISA., ISA Server 2006. Во второй части серии статей я подробно рассказал о важных аспектах DNS, которые необходимо учитывать перед развертыванием решения.

В этой статье мы сосредоточимся на следующем:

• Размещение сертификатов на внешних серверах Exchange и брандмауэре ISA.
• Настройка DNS для поддержки нашей разделенной инфраструктуры DNS
• Создание веб-фермы
• Создание правил веб-публикации OWA и RPC/HTTP
• Тестирование правил веб-публикации OWA и RPC/HTTP

Одна вещь, которую я не буду касаться в этой серии статей, — это настройка серверов FE и BE Exchange. В прошлом конфигурация была несколько сложной, и вам нужно было пройти через множество обручей, чтобы все работало правильно. С выпуском Microsoft Exchange 2003 SP2 Microsoft сделала за вас всю тяжелую работу, и вам не нужно возиться с реестром, чтобы внешний/внутренний интерфейс Exchange работал правильно с первого раза.

Размещение сертификатов на внешних серверах Exchange и брандмауэре ISA

Прежде чем настраивать правила веб-публикации брандмауэра ISA, необходимо убедиться, что все сертификаты развернуты. Нам нужно сделать следующее:

• Установите сертификат веб-сайта на каждый интерфейсный сервер Exchange.
• Установите сертификат веб-сайта на брандмауэр ISA, чтобы брандмауэр ISA мог олицетворять внешние серверы Exchange.

В этой серии я использую чистую разделенную инфраструктуру DNS, что очень упрощает задачу. Это позволяет мне использовать одно и то же имя от начала до конца. Использование одного и того же имени из конца в конец позволяет следующее:

• Внешний пользователь отправляет запрос на https://owa.msfirewall.org/exchange и подключается к IP-адресу внешнего интерфейса брандмауэра ISA, используемого веб-прослушивателем, который используется правилом веб-публикации, публикующим сайт.
• Брандмауэр ISA перенаправляет (проксирует) запрос от себя на https://owa.msfirewall.org/exchange и подключается к фактическому IP-адресу сайта OWA во внутренней сети. На самом деле, в нашем сценарии публикации веб-фермы все немного сложнее, и я укажу на это, когда мы перейдем к созданию правила веб-публикации.
• Внутренние пользователи в корпоративной сети отправляют запрос на https://owa.msfirewall.org/exchange, и этот запрос разрешается во внутренний IP-адрес на брандмауэре ISA, что позволяет брандмауэру ISA передавать запрос на внешний сервер Exchange. Серверы. Эта «обратная петля» через брандмауэр ISA позволяет внутренним пользователям получать те же преимущества, что и возможности публикации веб-фермы брандмауэра ISA, без необходимости прибегать к NLB на внешней веб-ферме Exchange Server. Хотя я не являюсь поклонником повторного прохождения через брандмауэр ISA для доступа к внутренним ресурсам, это допустимая конфигурация для организаций, использующих модель развертывания на основе целей, когда брандмауэры ISA или массивы брандмауэров ISA развертываются для определенной цели. Например, один массив предназначен для VPN-подключения типа site-to-site и для удаленного доступа, другой массив предназначен для управления исходящим доступом, а еще один массив предназначен для публикации в Интернете и на сервере.

Я рассматривал развертывание сертификатов в ряде других статей здесь, на ISAserver.org, и не буду подробно описывать этот процесс в этой статье. Если вам нужна дополнительная информация о возможностях развертывания ЦС и о том, как получить сертификаты для сценариев веб-публикации Exchange, лучше всего начать с ISA Server 2000 Exchange Deployment Kit. По моему не очень скромному мнению, это один из лучших проектов документации всех времен, и я потратил сотни часов на его сборку. Хотя они нацелены на ISA Server 2000, многие принципы остаются теми же. Вы можете найти комплект развертывания ISA Server 2000 Exchange по адресу http://www.isaserver.org/img/upl/exchangekit/.

Я также сделал комплект развертывания Exchange ISA 2004, который содержит аналогичную информацию, но может не вдаваться в такой же уровень детализации при установке новой PKI. Однако он проведет вас через все шаги, необходимые для установки сертификатов на веб-серверы Exchange и брандмауэры ISA. Вы можете найти это на http://www.microsoft.com/technet/prodtechnol/isa/2004/deployment/default.mspx.

Ниже приводится сводка того, что я сделал для развертывания сертификатов в сценарии, обсуждаемом в этой серии статей:

1. Установите ЦС предприятия на контроллере домена. Вам не нужно устанавливать корпоративный ЦС на контроллер домена, его можно установить на рядовой сервер, но я хотел уменьшить количество машин, необходимых для этой лаборатории. Преимущество использования ЦС предприятия Windows Server 2003 SP1 состоит в том, что он автоматически заполняет хранилище сертификатов компьютера каждого члена домена сертификатом ЦС предприятия, так что каждый член домена доверяет сертификатам, подписанным этим ЦС.
2. После установки ЦС предприятия я воспользовался мастером запроса сертификата веб-сайта IIS на одном из серверов FE Exchange, чтобы запросить сертификат веб-сайта. Обычное имя сертификата веб-сайта — owa.msfirewall.org.
3. Затем я экспортировал этот сертификат вместе с его закрытым ключом в файл. Затем я скопировал файл на другой FE Exchange Server и на брандмауэр ISA.
4. Скопировав файл на внешний сервер Exchange и брандмауэр ISA, я импортировал сертификат с его закрытым ключом в личную папку хранилища сертификатов машины. Это очень важно. Вы импортируете его в хранилище сертификатов машины ; вы не импортируете сертификат в хранилище сертификатов пользователя или службы.

Убедитесь, что на всех машинах установлен сертификат центра сертификации предприятия. Это не должно быть проблемой для серверов Exchange, но вы можете столкнуться с проблемами с брандмауэром ISA, если вы установили программное обеспечение брандмауэра ISA до присоединения брандмауэра ISA к домену. Причина этого в том, что фильтр RPC нарушает способность брандмауэра ISA автоматически получать сертификат ЦС предприятия. В этом случае вам нужно будет вручную импортировать сертификат CA в хранилище сертификатов машины Trusted Root Certification Authorities брандмауэра ISA.

Если в конце настройки вы обнаружите, что сертификаты кажутся проблемой, запустите BPA брандмауэра ISA. Он отлично справляется с выявлением проблем, связанных с сертификатами, и предоставляет рекомендации по их решению.

Загрузите BPA брандмауэра ISA по адресу http://www.microsoft.com/downloads/details.aspx?familyid=d22ec2b9-4cd3-4bb6-91ec-0829e5f84063&displaylang=en.

Настройка DNS для поддержки нашей инфраструктуры разделенного DNS

Используя разделенную инфраструктуру DNS, мы позволяем пользователям использовать одни и те же имена для доступа к одним и тем же ресурсам независимо от их местоположения. В нашем текущем примере пользователи смогут получить доступ к https://owa.msfirewall.org/exchange как из внутренней, так и из внешней сети. Единственная разница в том, что внешние пользователи будут подключаться к внешнему IP-адресу брандмауэра ISA, а внутренние пользователи будут подключаться к внутреннему IP-адресу брандмауэра ISA.

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

Нам нужно сделать две вещи:

• Создайте запись в файле HOSTS на брандмауэре ISA, которая преобразует имя сертификата веб-сайта, связанного с интерфейсным веб-сайтом Exchange, в IP-адрес одного из членов массива. Как вы узнаете позже, это несколько лишнее, так как возможность публикации веб-фермы позволяет обойти эту проблему. Однако я включаю эту информацию для людей, которые могут не использовать публикацию Web Farm.
• Настройте внутренний DNS для преобразования общего имени сертификата веб-сайта, связанного с интерфейсным веб-сайтом Exchange, в IP-адрес, используемый во внутреннем интерфейсе брандмауэра ISA. Это позволяет вашим внутренним клиентам подключаться к брандмауэру ISA, а не напрямую к внешним серверам Exchange. Это необходимо, если вы хотите, чтобы ваши внутренние клиенты получали преимущества от балансировки нагрузки веб-фермы.

На рисунке ниже показаны требования к конфигурации.

фигура 1

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

Обсудите эту статью на веб-доске по адресу: http://tinyurl.com/fvflv

Например, предположим, что одним из реальных имен компьютеров одного из интерфейсных серверов Exchange является OWA, и этот компьютер является членом домена msfirewall.org. Теперь предположим, что сертификат веб-сайта, который вы хотите использовать, имеет общее/тематическое имя owa.msfirewall.org. Это вызвало бы у нас большую проблему, потому что реальная машина должна была бы иметь запись DNS, введенную в базу данных DNS во внутренней сети. Это помешает нам настроить DNS для перенаправления подключений от внутренних клиентов к внешнему массиву на внутренний интерфейс брандмауэра ISA, в результате чего внутренние клиенты не смогут воспользоваться преимуществами FBA и веб-фермы брандмауэра ISA. Особенности публикации.

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

Создание веб-фермы

В ISA Server 2006 есть замечательная новая функция, которая позволяет вам публиковать «фермы» веб-серверов, расположенных за брандмауэром ISA, и делает это без необходимости использования NLB на веб-ферме. Функция публикации веб-фермы нового брандмауэра ISA решает несколько проблем, с которыми мы столкнулись при публикации веб-фермы в ISA 2004:

• Когда в веб-ферме была включена балансировка сетевой нагрузки и включена одиночная привязка, все соединения перенаправлялись на одного и того же члена фермы. Причиной этого было то, что настройка по умолчанию в правилах веб-публикации заключалась в замене исходного IP-адреса клиента на IP-адрес брандмауэра ISA (или массива брандмауэра ISA, если NLB был включен для массива). Поскольку веб-ферма NLB всегда видела один и тот же исходный IP-адрес, одно соответствие всегда направляло подключение к одному и тому же серверу в ферме, что нарушало функцию балансировки нагрузки NLB.
• Решением этой проблемы было изменение правила веб-публикации, чтобы сохранить исходный IP-адрес клиента. Проблема с этим решением заключалась в том, что вам нужно было установить шлюз по умолчанию на членах фермы серверов, чтобы массив брандмауэра ISA находился на пути ответа к Интернету. Многие организации хотели избежать этой ситуации, чтобы предотвратить ненужные и бессмысленные дебаты с «сетевыми парнями», которые, кажется, бесконечно пытаются загарпунить наши усилия по защите сетевых активов.

Решение Web Farm Publishing проверяет работоспособность служб на каждом из членов фермы. Если член фермы недоступен, то брандмауэр ISA удаляет его из фермы и не перенаправляет подключения к отключенному члену. Когда брандмауэр ISA обнаруживает, что участник фермы снова в сети, брандмауэр ISA повторно активирует членство этого члена в ферме и снова начинает балансировать нагрузку соединений с сервером. Во внешнем сценарии Exchange пользователи, подключенные к одному из членов фермы, никогда не узнают об отключенном сервере и прозрачно перенаправляются на другой сервер в ферме.

Публикация веб-фермы предоставляет вам следующие преимущества:

• Вам никогда не понадобится использовать NLB на веб-ферме
• Он хорошо работает, когда NLB включен в массиве брандмауэра ISA, но не требует, чтобы NLB был включен в массиве.
• Он обеспечивает балансировку нагрузки и прозрачную отработку отказа и восстановление после отказа.
• Вам больше не нужны F5, Cisco Content Engine или любой другой внешний балансировщик нагрузки, что может сэкономить вам десятки или сотни тысяч долларов (одна только эта функция должна принести вам бонус здоровья в конце года).
• Вам не нужно беспокоиться о проблемах сходства, потому что NLB не используется для балансировки нагрузки соединений. Брандмауэр ISA может использовать механизм балансировки нагрузки на основе файлов cookie.
• Вы можете очистить сервер перед удалением его из веб-фермы, как и в случае с NLB, но без необходимости использования NLB в веб-ферме.

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

ПРИМЕЧАНИЕ:
Термин «серверная ферма» немного неверен. На языке брандмауэра ISA существует два типа правил публикации: правила веб-публикации и правила публикации сервера. Правила веб-публикации публикуют только веб-серверы, а правила публикации серверов могут публиковать любой протокол. Правильным термином для этого сетевого элемента было бы «веб-ферма», если бы мы придерживались согласованной номенклатуры брандмауэра ISA.

Выполните следующие задачи, чтобы создать сетевой элемент фермы серверов:

1. В консоли брандмауэра ISA разверните имя массива, а затем щелкните узел «Политика брандмауэра» в левой панели консоли. Щелкните вкладку Панель инструментов на панели задач. Щелкните ссылку «Сетевые объекты» на панели инструментов.
2. В разделе «Сетевые объекты» откройте меню «Создать» и выберите «Ферма серверов».
3. Введите имя веб-фермы в текстовом поле «Имя фермы серверов» на странице «Добро пожаловать в мастер создания фермы серверов» и нажмите « Далее».
4. На странице Серверы нажмите кнопку Добавить.

фигура 2

5. На странице «Сведения о сервере» нажмите кнопку «Обзор», чтобы найти первый сервер FE Exchange. Имейте в виду, что серверы, доступные для просмотра, зарегистрированы в Active Directory. Однако, поскольку серверы FE Exchange должны находиться в Active Directory, их будет легко найти. Нажмите ОК.

Рисунок 3

6. Повторите шаги, чтобы добавить другие серверы в веб-ферму, затем нажмите «Далее».

Рисунок 4

7. На странице Server Farm Connectivity Monitoring вы настраиваете, как вы хотите, чтобы брандмауэр ISA подтверждал текущее состояние работоспособности серверов в веб-ферме. Настройка по умолчанию настраивает брандмауэр ISA на отправку HTTP- или HTTPS-запроса GET на полное доменное имя и путь, которые вы настроили в правиле веб-публикации, которое будет использовать этот сетевой элемент фермы серверов. У вас также есть возможность использовать запрос ICMP PING или установить соединение с настраиваемым сокетом TCP (вы вводите номер порта для прослушивающего сокета, к которому хотите подключиться, в текстовом поле Подключиться к порту ).

   Вы можете дополнительно настроить конфигурацию монитора подключения для этой фермы серверов, нажав кнопку «Настроить».
   
   

Рисунок 5

8. В диалоговом окне Advanced Farm Connectivity Verification можно настроить URL-адрес, используемый для определения состояния работоспособности опубликованного сервера. Используйте этот параметр, если вы хотите переопределить URL-адрес, используемый правилом веб-публикации. Хотя я не могу придумать сценарий, в котором вы хотели бы это сделать, на небе и на земле есть больше вещей, чем то, что выдумано в моей философии. У вас также есть возможность настроить собственный заголовок HOST, если вам нужно использовать заголовок, отличный от заголовка HOST, который будет отправлен на основе правила веб-публикации, которое публикует эту веб-ферму. Нажмите ОК.

Рисунок 6

9. Нажмите «Далее» на странице «Мониторинг подключения фермы серверов ».
10. Нажмите «Готово» на странице « Завершение работы мастера создания новой фермы серверов».
11. Диалоговое окно, информирующее вас о том, что правило системной политики Разрешить запросы HTTP/HTTPS от ISA Server к выбранным серверам для проверки подключения будет включено. Нажмите Да, чтобы включить это правило системной политики.

Рисунок 7

12. Нажмите «Применить», чтобы сохранить изменения и обновить политику брандмауэра.
13. Нажмите «ОК» в диалоговом окне «Применить новую конфигурацию».

Если вы опытный администратор брандмауэра ISA 2004, вас могут волновать проблемы с несоответствием имен сертификатов. Возможно, вы задавались этим вопросом при настройке имен серверов в массиве. Из вашего опыта работы с ужасной ошибкой сервера 500 вы можете задаться вопросом, как она будет работать, поскольку в прошлом вам приходилось перенаправлять соединения с использованием полного доменного имени, используемого в общем/субъектном имени сертификата веб-сайта, связанного с веб-сайтом Exchange FE.

Причина, по которой это работает, заключается в том, что имена серверов, которые вы вводите в определение веб-фермы, используются внутри; они не используются для создания запроса, который делает брандмауэр ISA к опубликованному веб-сайту, когда брандмауэр ISA проксирует запрос. Имя, которое будет использоваться в CONNECT, будет именем, которое вы настроили брандмауэру ISA для использования в правиле веб-публикации, которое публикует веб-ферму. Мы увидим, как вы это сделаете, в следующем разделе, посвященном созданию правил веб-публикации для сайтов OWA и RPC/HTTP.

Похоже, я израсходовал все свое пространство на этой неделе, поэтому нам придется завершить статью частью 4, где я планирую подробно рассмотреть правила веб-публикации OWA и RPC/HTTP, а затем показать вам, как чтобы протестировать решение и убедиться, что все работает правильно.

Обсудите эту статью на веб-доске по адресу: http://tinyurl.com/fvflv

Резюме

В этой статье мы начали настройку сети для поддержки публикации веб-фермы OWA и RPC/HTTP. Мы начали с настройки поддерживающей инфраструктуры DNS и файлов HOSTS для поддержки решения. Затем мы перешли к обсуждению того, как работает функция балансировки нагрузки веб-фермы нового брандмауэра ISA, а затем завершили создание новой веб-фермы с помощью мастера создания новой фермы серверов. В следующей статье я надеюсь закончить рассмотрением деталей правил веб-публикации, а затем продемонстрирую, как вы можете убедиться, что балансировка нагрузки и аварийное переключение работают правильно. Увидимся на следующей неделе! -Том.

• Публикация Outlook Web Access и Outlook RPC/HTTP с брандмауэрами ISA Server 2006 Enterprise Edition с использованием проверки подлинности на основе форм (одночленный массив без NLB)
• Публикация OWA и Outlook RPC/HTTP с брандмауэрами ISA Server 2006 EE с использованием проверки подлинности на основе форм (одночленный массив без NLB): Часть 2. Проблемы развертывания DNS и сертификатов
• Публикация Outlook Web Access и Outlook RPC/HTTP с брандмауэрами ISA Server 2006 Enterprise Edition (RC) с использованием аутентификации на основе форм (одночленный массив без NLB) — часть 4. Создание правил веб-публикации и тестирование конфигурации