Публикация OWA и RPC/HTTP с одним IP-адресом на ISA-сервере (Часть 3)

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

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

• Публикация OWA и RPC/HTTP с одним IP-адресом на ISA-сервере (Часть 1)
• Публикация OWA и RPC/HTTP с одним IP-адресом на ISA-сервере (Часть 2)
• Публикация OWA и RPC/HTTP с одним IP-адресом на ISA-сервере (Часть 4)
• Публикация OWA и RPC/HTTP с одним IP-адресом на ISA-сервере (Часть 5)

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

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

Создание правила web-публикации OWA и RPC/HTTP

Теперь, когда все подготовительные шаги завершены, мы может приступить к основному разделу – созданию правила web-публикации OWA и RPC/HTTP. Вначале мы создадим одно правило web-публикации, которое будет разрешать входящие соединения и с OWA, и с RPC/HTTP. Так мы сможем увидеть, что достаточно одного IP-адреса для публикации обоих служб, чего нельзя было сделать с сервером ISA 2004.

Но на сервере ISA 2006 данная схема будет работать, поскольку новый ISA-сервер может анализировать заголовок агента пользователя (User-agent) запроса. Если ISA-сервер не видит, что клиентом является браузер, будет произведен откат к базовой аутентификации. Такой откат необходим, поскольку клиенты, не являющиеся браузером, не могут правильно обработать форму.

Для создания правила web-публикации OWA и RPC/HTTP выполните следующее:

• В консоли управления ISA-сервера раскройте имя сервера, выберите узел Firewall Policy (Политики сервера) и нажмите Tasks (Задачи) в панели задач. Нажмите Publish Exchange Web Client Access (Публикация доступа web-клиента Exchange).
• На странице Welcome to the New Exchange Publishing Rule Wizard (Начало работы мастера создания нового правила публикации Exchange) введите в поле Exchange Publishing rule name (Название правила публикации Exchange) название правила. В нашем примере мы назовем правило OWA and RPC/HTTP. Нажмите Next (Далее).

  

  Рисунок 1

• На странице Select Services (Выбор служб) из списка Exchange version (Версия Exchange-сервера) выберите Exchange Server 2003. Отметьте пункты Outlook Web Access и Outlook RPC/HTTP(s). Нажмите Next (Далее).

• На странице Publishing Type (Тип публикации) выберите пункт Publish a single Web site or load balancer (Публиковать единственный web-сайт или балансировщик нагрузки).
  Другой параметр Publish a server farm of load balanced Web servers (Публиковать группу серверов или web-серверы с балансировкой нагрузки) следует использовать при наличии web-группы внешних Exchange-серверов. В таком случае ISA-серверу не нужны дорогие «аппаратные» балансировщики нагрузки. ISA-сервер сам осуществляет динамическую балансировку нагрузки без необходимости включения балансировки нагрузки на массиве ISA-серверов или на web-группе.
  Нажмите Next (Далее).

• На странице Server Connection Security (Защита соединений с сервером) выберите параметр Use SSL to connect to the published Web server or server farm (Использовать SSL для связи с опубликованным web-сервером или группой серверов). Это позволит ISA-серверу создавать второе безопасное соединение: с внутреннего интерфейса к сайту OWA. Таким образом, мы получим замкнутое безопасное соединение, и в то же самое время разрешим ISA-серверу выполнять проверку на уровне приложений содержимого SSL-туннеля.
  Вариант Use non-secured connections to connect the published Web server or server farm (Использовать незащищенные соединения для связи с опубликованным web-сервером или группой серверов) разрешает трафик незащищенных данных, передаваемых в явном виде, от внутреннего интерфейса ISA-сервера к сайту OWA. Такой трафик легко перехватывается анализатором сети. Хотя некоторые администраторы ISA-серверов любят данный вариант по причине возможности «уменьшения использования SSL», которую и предоставляет данная опция, улучшения производительности должны быть сбалансированы с реальными большими недостатками в защите.
  Нажмите Next (Далее).

• На странице Internal Publishing Details (Детали внутренней публикации) введите обычное имя сертификата web-сайта сайта OWA в поле Internal site name (Имя внутреннего сайта). Крайне важно ввести обычное имя сертификата в данное поле, поскольку если этого не сделать, то при попытке соединения с OWA-сайтом вы будете получать сообщение о внутренней ошибке сервера (Internal Server Error 500).
  Отметьте параметр Use a computer name or IP address to connect to the published server (Для соединения с опубликованным сервером использовать имя компьютера или IP-адрес). Данная опция – это новая функция сервера ISA 2006. В сервере ISA 2004 имя из поля Internal site name(Имя внутреннего сайта) использовалось как для разрешения OWA-сайта, так и для SSL CONNECT. Это создавало некоторые проблемы, которые требовали наличия в файле HOSTS записи для обычного имени сертификата web-сайта OWA-сайта. С помощью данной опции нам больше не нужны записи в файле HOSTS на ISA-сервере для поддержки web-публикации служб Exchange-сервера.
  В поле Computer name or IP address (Имя компьютера или IP-адрес) введите имя или IP-адрес Exchange-сервера. В нашем примере IP-адрес Exchange-сервера будет 10.0.0.3, поэтому его мы и вводим в это поле. Также мы может ввести имя sngbeexch2003.msfirewall.org, поскольку ISA-сервер настроен на использование внутреннего DNS-сервера для разрешения имен.
  Нажмите Next (Далее).

• На странице PublicNameDetails (Подробности имени) из списка Acceptrequestsfor (Принимать запросы для) выберите Thisdomainname (typebelow) (Этот домен (обозначен ниже)).
  В поле Public name (Имя) введите имя сертификата web-сайта, привязанного к web-приемнику из правила web-публикации. В нашем примере мы будем использовать тот же сертификат, который привязан к OWA-сайту, с именем owa.msfirewall.org, поэтому введите его в поле Public name (Имя).
  Должен отметить, что здесь вам не обязательно использовать одно и то же имя от начала и до конца. Например, вы можете использовать два различных сертификата, один привязанный к самому OWA-сайту, а другой – к web-приемнику ISA-сервера. Я не вижу практических причин для этого, поскольку это обычно не требуется. Я знаю, что некоторые администраторы ISA-серверов заботятся об обычных именах сертификатов, поскольку на ISA-сервере они используют и коммерческие сертификаты. Это не проблема. В этом случае вы можете использовать коммерческий сертификат на ISA-сервере и создать собственный с таким же именем и привязать его к OWA-сайту.
  Нажмите Next (Далее).

• На странице Select Web Listener (Выбор web-приемника) вы назначаете web-приемник к правилу публикации. У нас пока нет приемников, поэтому нужно его создать. Нажмите Next (Далее) для начала создания.

• На странице WelcometotheNewWebListenerWizard (Начало работы мастера новогоweb-приемника) введите в поле Weblistenername (Имяweb-приемника) название вашего приемника. В нашем примере это SSL Listener. Нажмите Next (Далее).

  

• На странице Client Connection Security (Защита клиентских соединений) выберите параметр Require SSL secured connection with clients (Для соединений с клиентами необходимо использовать защищенные SSL-соединения). Так мы включаем принудительное использование защищенных SSL-соединений между внешними клиентами OWA или RPC/HTTP и внешним интерфейсом ISA-сервера.
  Параметр Do not require SSL secured connection with clients(Для соединений с клиентами не нужно использовать защищенные SSL-соединения) позволяет внешним клиентам создавать незащищенные соединения с ISA-сервером. Это небезопасный вариант и его не нужно использовать при публикации служб Exchange-сервера.
  Нажмите Next (Далее).

На странице Web Listener IP Addresses (IP-адрес web-приемника) отметьте параметр External (Внешний). Это позволит web-приемнику принимать входящие соединения со всех IP-адресов, привязанных к внешнему интерфейсу ISA-сервера. Редко, а то и никогда, нам нужно прослушивать все IP-адреса внешнего интерфейса, поэтому нажмите кнопку Select IP Addresses (Выбор IP-адресов) для упорядочивания ситуации.

• В диалоговом окне External Network Listener IP Selection (Выбор внешних IP-адресов для приемника) выберите параметр Specified IP addresses on the ISA Server computer in the selected network (Указанные IP-адреса ISA-сервера в выбранной сети). Дважды щелкните по IP-адресу, привязанному к внешнему интерфейсу ISA-сервера, который показан в списке Available IP Addresses (Доступные IP-адреса). IP-адрес перейдет в список Selected IP Addresses (Выбранные IP-адреса).
  Обратите внимание, что в данном примере нам не нужно указывать IP-адрес, поскольку к внешнему интерфейсу ISA-сервера привязан только один адрес. Однако, далее мы рассмотрим дополнительные сценарии публикации Exchange-сервера, в которых мы будем привязывать дополнительные IP-адреса к внешнему интерфейсу ISA-сервера.
  Нажмите OK.

• На странице Web Listener IP Addresses (IP-адрес web-приемника) нажмите Next (Далее).
• На странице Listener SSL Certificates (SSL-сертификаты приемника) выберите параметр Assign a certificate for each IP address (Назначить сертификат к каждому IP-адресу). Это новая функция сервера ISA 2006. Здесь вы можете привязать к одному приемнику несколько сертификатов, а приемник будет принимать соединения на нескольких IP-адресах.
  Обратите внимание, что вы не можете привязать несколько сертификатов к единственному IP-адресу. Это не ограничение ISA-сервера, а проблема работы SSL и схем работы клиентов. В данный момент идет работа по обновлению протокола SSL и клиентов и серверов, так что в будущем это будет возможно.
  Нажмите кнопку Select Certificate (Выбор сертификата) для привязки выбранного сертификата к IP-адресу.

  

• В диалоговом окне Select Certificate (Выбор сертификата) вы увидите список подлинных сертификатов, установленных на ISA-сервере. Пол умолчанию выбран параметр Show only valid certificates (Показать только подлинные сертификаты). Если вы не видите ваш сертификат в списке Select a certificate from the list of available certificates (Выберите сертификат их списка доступных сертификатов), снимите отметку с этого пункта. В этом случае вам нужно устранить проблему с сертификатом. Раздел Certificate Installation Details (Подробности установки сертификата) даст вам детальную информацию о сертификате и поможет вам устранить проблему с тем сертификатом, который ISA-сервер не считает подлинным.
  Выберите сертификат owa.msfirewall.org и нажмите кнопку Select (Выбор).

• Теперь на странице Listener SSL Certificates (SSL-сертификат приемника) вы увидите, что сертификат web-сайта owa.msfirewall.org привязан к IP-адресу 192.168.1.71. Нажмите Next (Далее).

• На странице Authentication Settings (Настройки аутентификации) убедитесь, что опция HTML Form Authentication (Аутентификация с помощью HTML-формы) выбрана из выпадающего списка Select how clients will provide credentials to ISA Server (Выберите способ передачи учетных данных клиента ISA-серверу).
  Из списка Select how ISA Server will validate client credentials (Способ проверки учетных данных клиента ISA-сервером) выберите LDAP (Active Directory).
  Нажмите Next (Далее).

  

• На странице Single Sign On Settings (Настройки единственной регистрации) отметьте параметр Enable SSO for Web sites published with this Web listener (Включить единственную регистрацию на web-сайтах, опубликованных на данном web-приемнике). ISA-сервер дает возможность использования единственной регистрации, что позволяет пользователям переключаться с одного приложения на другое без необходимости аутентифицироваться всякий раз при перемене приложений. Например, аутентифицированный пользователь может спокойно просматривать сайты Outlook Web Access и SharePoint, просто нажимая не ссылки без дополнительной аутентификации.
  Единственная регистрация доступна для правил на одном приемнике. Например, если вы хотите использовать эту функцию для работы сайтах SharePoint и Outlook Web Access, правила публикации этих сайтов должны использовать один и тот же web-приемник. Приемник должен быть настроен на использование аутентификации с помощью HTML-формы и на нем должна быть включена функция единственной регистрации.
  Функция единственной регистрации работает в том домене, для которого она используется. Например, вы можете открыть домен msfirewall.org, а затем настроить функцию единственной регистрации для mail.msfirewall.org и team.msfirewall.org. Вы не сможете настроить данную функцию на работу между двумя сайтами с различными DNS-суффиксами, например mail.isaserver.org и mail.debshinder.com.
  Хотя мы не будем тестировать функцию единственной регистрации, введите в поле SSO domain name (Доменное имя для единственной регистрации) имя msfirewall.org.
  Нажмите Next (Далее).

• На странице Completing the New Web Listener Wizard (Завершение работы мастера создания нового web-приемника) просмотрите установки и нажмите Finish (Завершить).

  

• Имя приемника и некоторые из его свойств теперь появятся на странице Select Web Listener (Выбор web-приемника). Нажмите Next (Далее).

• На странице Authentication Delegation (Делегирование аутентификации) настройте, как ISA-сервер будет делегировать учетные данные на опубликованный Exchange-сервер. В нашем случае мы публикуем сайты OWA и RPC/HTTP, используя единственный IP-адрес, поэтому нам нужно делегирование базовой аутентификации. В других сценариях, в которых необходимо создание нескольких приемников на разных IP-адресах, мы могли бы использовать и другие типы делегирования, например, аутентификацией с помощью пользовательских сертификатов и принудительной аутентификацией Kerberos. Об этих двух видах делегирования мы поговорим позднее.
  Выберите параметр Basic authentication (Базовая аутентификация) из выпадающего списка Select the method used by ISA Server to authenticate to the published Web server (Выберите метод аутентификации ISA-сервером опубликованного web-сервера).
  Нажмите Next (Далее).

• На странице User Sets (Пользователи) установки по умолчанию — All Authenticated Users (Все аутентифицированные пользователи). Так мы разрешаем соединениям всех пользователей, успешно прошедших аутентификацию на ISA-сервере, переадресовываться на Exchange-сервер. Помимо этого вы можете ограничить доступ определенной группой, так что даже если пользователь успешно прошел аутентификацию, он должен быть членом группы, чтобы получить доступ на Exchange-сервере. Далее мы узнаем, как ограничивать доступ для определенных групп.
  В нашем примере мы принимаем значения по умолчанию. Нажмите Next (Далее).

• На странице Completing the New Exchange Publishing Rule Wizard (Завершение работы мастера создания нового правила публикации) нажмите Finish (Завершить).

• Для сохранения изменений и обновления политики нажмите Apply (Применить). Нажмите OK в окне Apply New Configuration (Применение новых настроек).

Теперь ISA-сервер настроен на прием входящих соединений от клиентов OWA и Outlook 2003 RPC/HTTP.

Резюме

В данной части мы создали правило web-публикации, которое публикует сайты OWA и RPC/HTTP. Мы детально рассмотрели настройки и объяснили выбор тех или иных параметров. В следующей части мы настроим клиент Outlook 2003 RPC/HTTP для связи с Exchange-сервером. До встречи!

www.isaserver.org

• Wds служба развертывания
• K exchange servers как удалить
• Isa server отключил не TCP соединение
• Скачать tmg
• Уникальные шрифты

Tags: dns, domain, Exchange, ISA Server, ldap