Monday, December 11th, 2017

Использование коммерческого сертификата web-сайта для публикации Outlook Web Access (OWA) Часть 4

Published on Февраль 13, 2009 by   ·   Один комментарий

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

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

Во второй части мы рассмотрели детали процесса настройки и запросили коммерческий сертификат web-сайта, который мы привяжем к web-приемнику в правиле web-публикации ISA-сервера.

В третьей части статьи мы экспортировали коммерческий сертификат web-сайта с закрытым ключом в файл, скопировали этот файл на ISA-сервер, отвязали коммерческий сертификат от OWA-сайта и запросили закрытый сертификат с другим именем для OWA-сайта. Мы закончили созданием web-приемника и привязкой коммерческого сертификата к этому приемнику, который используем в этой части для создания правила web-публикации.

Если вы пропустили первые три части статьи, прочтите их:

В четвертой части статьи об использовании коммерческих сертификатов при публикации OWA-сайтов мы обсудим следующее:

  • Создание правила web-публикации
    Мы закончили предыдущую часть созданием SSL-приемника, к которому привязан коммерческий сертификат web-сайта. Мы используем его в правиле web-публикации для публикации OWA-сайта.
  • Настройка частного и общего разрешения имен
    Если и есть причина, которая может сломать самое идеальное решение по публикации OWA-сайта, так это неверно настроенная инфраструктура DNS. Создать безупречную, хорошо настроенную инфраструктуру DNS не сложно. Нужно только обратить внимание на несколько рекомендаций, которые помогут создать быстрый и простой доступ к опубликованным web-сайтам для клиентов внутренней и внешней сети.
  • Проверка решения
    Нельзя узнать вкус блюда, пока его не попробуешь! Мы закончим статью проверкой решения и просмотрим файлы журнала ISA-сервера, чтобы узнать, что происходит во время соединения.

Начнем!

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

Отключить сертификат owa

Рисунок 1: Сейчас вы находитесь здесь

Поскольку наш web-приемник уже готов, можно создавать правило web-публикации OWA. Это правило будет принимать соединения с https://mail.msfirewall.org/exchange и переадресовывать их на OWA-сайт во внутренней сети. Все пользователи до установки любого соединения с OWA-сайтом должны пройти аутентификацию на ISA-сервере. Это позволит нам получить более высокий уровень безопасности в сравнение с тем, который предоставляется так называемыми «аппаратными» брандмауэрами, просто переадресовывающими SSL-соединения на OWA-сайт.

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

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

  1. В консоли управления ISA-сервера раскройте имя сервера и выберите узел Firewall Policy (Политики сервера).
  2. В панели задач узла Firewall Policy (Политики сервера) выберите Tasks (Задачи) и Publish a Mail Server (Публикация почтового сервера).
  3. На странице Welcome to the New Mail Server Publishing Rule Wizard Начало работы мастера правил публикации нового почтового сервера) в текстовом окне Mail Server Publishing Rule name (Имя правила публикации почтового сервера) введите название правила. В нашем примере это OWA Site. Нажмите Next (Далее).
  4. На странице Select Access Type (Выбор типа доступа) выберите опцию Web client access: Outlook Web Access (OWA), Outlook Mobile Access, Exchange Server ActiveSync и нажмите Next (Далее).
  5. На странице Select Services (Выбор сервисов) примите значения по умолчанию, при которых включены опции Outlook Web Access (Web-доступ к Outlook) и Enable high bit characters used by non-English character sets(Разрешить символы, используемы в не-английских наборах символов). Нажмите Next (Далее).
  6. На странице Bridging Mode (Способ сопряжения) выберите опцию Secure connection to clients and mail server (Безопасные соединения клиентов и почтового сервера) и нажмите Next (Далее).
  7. На странице Specify the Web Mail Server (Укажите почтовый web-сервер) введите в поле Web mail server (Почтовый web-сервер) имя внутреннего OWA-сайта. Это имя должно совпадать с именем сертификата web-сайта, привязанного к OWA-сайту. Если вы введете что-либо, отличное от имени коммерческого сертификата web-сайта, соединения не пройдут. В нашем примере это имя owa.msfirewall.org. Введите его в поле и нажмите Next (Далее).

    Outlook коммерческое использование

    Рисунок 2

  8. На странице Public Name Details (Подробности имени) из списка Accept requests for (Принимать запросы для) выберите This domain name (type below) (Этот домен (обозначен ниже)). Введите имя, которое пользователи внешней сети будут использовать для доступа к OWA-сайту в текстовое поле Public name (Имя). Это имя должно совпадать с именем сертификата web-сайта, привязанного к приемнику в правиле web-публикации. В нашем случае это имя mail.msfirewall.org. Нажмите Next (Далее).

    Сертификаты по публикации

    Рисунок 3

  9. На странице Select Web Listener (Выбор web-приемника) выберите из списка Web listener (Web-приемник) запись SSL Listener. Нажмите Next (Далее).

    Как загрузить коммерческий сертификат на сервер?

    Рисунок 4

  10. На странице User Sets (Установки пользователей) примите значения по умолчанию и нажмите Next (Далее).
  11. На странице Completing the New Mail Server Publishing Rule Wizard (Завершение создания правила публикации нового почтового сервера) нажмите Finish (Завершить).
  12. Для того чтобы изменения политики брандмауэра вступили в силу, нажмите Apply (Применить).
  13. В диалоговом окне Apply New Configuration (Применить новые настройки) нажмите OK.

Настройка частного и общего разрешения имен

Публикация owa по другому имени

Рисунок 5: Сейчас вы находитесь здесь

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

В начале вам нужно настроить доступ внутренних клиентов к OWA-сайту с использованием внутреннего имени сайта. Внутреннее имя сайта должно быть тем же, что и у сертификата OWA-сайта. В нашем примере имя сертификата, привязанного к OWA-сайту, owa.msfirewall.org. Для доступа к сайту пользователи должны использовать это имя, а внутренний DNS-сервер должен разрешать имя owa.msfirewall.org в реальный IP-адрес сайта во внутренней сети.

Замечание:
Должен заметить, что данное правило не является жестким. Вам не обязательно привязывать IP-адрес внутреннего имени OWA-сайта к реальному IP-адресу этого сайта. Однако для большинства администраторов ISA-серверов данное правило более понятно. В более сложных конфигурациях не стоит использовать реальный адрес OWA-сайта во внутренней DNS. Примером может служить схема, при которой OWA-сервер расположен во внутреннем сегменте сети, т.е. за внутренним ISA-сервером, и настроено сетевое правило NAT для связи между сегментом сетевых служб и пользовательской сетью. В такой сети внутренний DNS-сервер привязывает имя owa.msfirewall.org к IP-адресу внешнего интерфейса ISA-сервера, который используется в web-приемнике для правила web-публикации внутреннего OWA-сайта, расположенного в сегменте сетевых служб.

Далее, внешний DNS-сервер должен быть настроен на поддержку имени сертификата, привязанного к web-приемнику, который используется в правиле web-публикации для публикации OWA-сайта. В нашем примере имя на web-приемнике mail.msfirewall.org, и внешние пользователи должны использовать это имя в запросах для доступа к OWA-сайту через ISA-сервер. Если они введут другое имя, соединения не будет не только из-за несовпадения имени в сертификате и запросе, но и потому, что правило web-публикации настроено на прием соединений, у которых в заголовке хоста обозначено имя mail.msfirewall.org.

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

Теперь я должен сделать признание. В начале статьи я говорил, что мы не будем использовать разделенную структуру DNS. Однако, это не совсем правда. Даже совсем не правда, поскольку мы используем одинаковое доменное имя второго уровня для внутреннего и внешнего доступа. Разница между обычными статьями по публикации OWA и этой в том, что мы не использовали одно и то же полностью определенное имя домена от начала до конца.

Например, в большинстве статей по OWA-публикации я использую имя owa.msfirewall.org для внешней и внутренней зон DNS. Это делает возможным использование имени owa.msfirewall.org в независимости от места расположения – внутренние пользователи используют такое же имя, как и внешние. Просто, не правда ли?

Проблема использования недопустимых имен доменов верхнего уровня

Проблема состоит в том, что некоторым приходится использовать во внутренней сети недопустимые имена доменов верхнего уровня, такие как .local. Обычно это не высокопроизводительные сети, похожие на сети типа SOHO, где существует строгая привязка к поставщику, который требует использования такой непродуктивной схемы именования. Если вы столкнулись с таким типом конфигурации, не пугайтесь, все можно легко и просто настроить.

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

В нашей сети у внешних клиентов есть запись в файле HOSTS для имени mail.msfirewall.org, которое привязывается к IP-адресу внешнего интерфейса ISA-сервера, в нашем случае это 192.168.1.71. Во внутренней сети встроенный в Active Directory DNS-сервер на Exchange-сервере Server привязывает имя owa.msfirewall.org к IP-адресу OWA-сайта Exchange-сервера, который, так уж получилось, является IP-адресом контроллера домена. Поскольку реальное имя компьютера Exchange-сервера EXCHANGE2003BE.msfirewall.org, запись для имени mail.msfirewall.org нужно добавить в базу данных зон DNS вручную.

Проверка решения

Сертификат на публикацию

Рисунок 6: Сейчас вы находитесь здесь

Теперь проверим то, что мы сделали! Но не так быстро. Прежде чем проверить наше решение в тестовой сети, нам нужно импортировать пробные сертификаты центра сертификации в хранилище сертификатов компьютеров внешних клиентов. Обратите внимание, что также, как и в случае, когда мы должны были сделать данную процедуру на ISA-сервере, данный шаг используется только в тестовой сети. Вам не придется делать это при использовании коммерческого сертификата web-сайта, поскольку коммерческий сертификат корневого центра сертификации провайдера автоматически устанавливается в хранилище сертификатов на внешних клиентских компьютерах под управлением Windows XP.

Для установки тестовых сертификатов центра сертификации выполните следующее:

  1. На клиентском компьютере под управлением Windows XP откройте Internet Explorer и зайдите на сайт http://www.verisign.com/server/trial/faq/index.html
  2. Нажмите ссылку Secure Site Trial Root CA Certificate (Пробный корневой сертификат центра сертификации безопасного сайта).
  3. На странице Root CA Certificates (Cертификаты корневого центра сертификации) скопируйте текст из текстового окна в Блокнот и сохраните файл под именем commcacert.txt
  4. В Internet Explorer зайдите в меню Tool (Средства) и нажмите Internet Options (Свойства Интернет).
  5. На вкладке Content (Содержание) в разделе Certificates (Сертификаты) нажмите кнопку Certificates (Сертификаты).
  6. Нажмите кнопку Import (Импорт).
  7. В окне Welcome to the Certificate Import Wizard (Начало работы мастера импорта сертификатов) нажмите Next (Далее).
  8. На странице File to Import (Файл импорта) нажмите Browse (Просмотр) для указания места расположения файла commcacert.txt. Нажмите Next (Далее)
  9. На странице Certificate Store (Хранение сертификата) выберите опцию Automatically select the certificate store based on the type of certificate (Автоматически выбрать хранилище сертификата в зависимости от типа сертификата) и нажмите Next (Далее).
  10. На странице Completing the Certificate Import Wizard (Завершение работы мастера импорта сертификата) нажмите Finish (Завершить).
  11. На странице, сообщающей об установке сертификата, нажмите Yes.
  12. На странице, сообщающей об успешном импорте, нажмите Yes.
  13. Для закрытия диалогового окна Certificates (Сертификаты) нажмите Close (Закрыть).
  14. В диалоговом окне Internet Options (Свойства Интернет) нажмите OK.

Теперь откройте на компьютере внешнего клиента Internet Explorer и зайдите на сайт https://mail.msfirewall.org/exchange. Введите имя пользователя и пароль в форму для аутентификации и откройте свой почтовый ящик. В нашем примере мы открыли почтовый ящик администратора по умолчанию.

Если вы посмотрите файлы журнала ISA-сервера, вы увидите то, что показано на рисунках ниже. Вы видите, что первое соединение было к mail.msfirewall.org, а затем вы видите соединения ISA-сервера к внутреннему web-серверу и к owa.msfirewall.org.

Замечание:
Если вы не видите записи файла журнала, сообщите мне, и я размещу рисунки большего размера.

Использование частного сертификата

Публикация owa по другому имени

Рисунки 7 и 8

Резюме

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

Надеюсь, что вам понравилась статья, и вы приняли к сведению один или несколько изложенных фактов.

www.isaserver.org







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

Tags: , , , , ,

Readers Comments (Один комментарий)

  1. Карина:

    Очень интересная статья, буду ждать продолжения




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

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 – часть ... [+]