Monday, January 22nd, 2018

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

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

В последние годы на доске объявлений http://forums.isaserver.org/ и в списках рассылки время от времени поднимается вопрос об использовании коммерческого сертификата при web-публикации сайта OWA. Коммерческие сертификаты предоставляют некоторые преимущества для отдельных вариантов web-публикации OWA, в связи с этим я решил, что настало время предоставить руководство по решению этой задачи.

Вы, вероятно, знаете, что ISA-сервер предоставляет для защиты удаленного доступа к Microsoft Exchange Outlook Web Access механизмы проверки и на уровне приложений, и на уровне обычных пакетов. Также вам может быть известно, что ISA-сервер предоставляет повышенную безопасность для безопасного удаленного доступа к Microsoft Exchange OWA, и что ISA-сервер является лучшим решением для безопасного удаленного доступа не только к OWA, но и к почтовым службам Exchange-сервера.

Но знаете ли вы, как использовать коммерческий сертификат web-сайта для публикации сайтов OWA, OMA и Exchange ActiveSync?

Скорее всего, нет, поскольку в данный момент в Интернете нет документации на этот счет. Эта статья восполнит пробел в ваших знаниях.

Зачем использовать коммерческий сертификат web-сайтов?

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

Главное преимущество в использовании коммерческих сертификатов в том, что вам не надо беспокоиться о заполнении хранилища Trusted Root Certification Authorities (Доверенные корневые центры сертификации) сертификатами, выданными центрами сертификации web-сайтов. Клиентские операционные системы Windows поставляются с набором доверенных корневых центров сертификации, и при использовании коммерческого сертификата, выданного одним из этих центров сертификации, снимается вопрос о росте хранилища Trusted Root Certification Authorities (Доверенные корневые центры сертификации).

Почему следует обратить на это внимание? Если клиентское web-приложение соединяется с SSL-сайтом, предлагающим сертификат web-сайта, и этот сертификат выдан центром сертификации, которому система клиента не доверяет, то приложение клиента выдаст ошибку. Иногда такие ошибки не очень важны, например, при использовании Internet Explorer. Когда Internet Explorer встречается с сертификатом web-сайта, выданным центром сертификации, которому клиент не доверяет, появляется диалоговое окно, сообщающее, что ваш компьютер не настроен на доверенные отношения с данным сайтом, но вы можете продолжить работу.

На рисунке ниже показано данное диалоговое окно.

Outlook web access

Рисунок 1: Диалоговое окно Предупреждение системы безопасности (Security Alert), выдаваемое программой Internet Explorer, которое показывает, что система клиента не доверяет центру сертификации, выдавшему данному web-сайту сертификат

Другие приложения более требовательны. Основной пример – работа Outlook 2003 и RPC поверх HTTP. Многие администраторы серверов Exchange и ISA приходили в замешательство, когда OWA-сайты работали отменно, но RPC/HTTP-соединения не функционировали, не смотря на то, что вроде все было настроено правильно. Почти все было настроено правильно, однако один момент был упущен: не включен сертификат центра сертификации, выдавшего сертификат web-сайта, привязанного к SSL-приемнику ISA-сервера.

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

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

Обычные/привязанные имена сертификатов

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

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

Outlook web access

Рисунок 2: Защищенное SSL-сопряжение позволяет создавать шифрованные соединения с OWA-сайтом и одновременно производить проверку обычных пакетов на уровне приложений связей OWA-сайта

  1. Внешний клиент посылает запрос на сайт mail.msfirewall.org. Клиент запрашивает открытый DNS-сервер и разрешает это имя в IP-адрес внешнего интерфейса ISA-сервера, используемого web-приемником SSL. После этого запрос направляется на данный IP-адрес. К web-приемнику SSL привязан сертификат web-сайта с именем mail.msfirewall.org.
    Если бы имя сертификата былоwww.domain.com, а запрос происходил бы к имени mail.msfirewall.org, то запрос бы не был выполнен, поскольку имена в запросе и в сертификате не совпадают.
    Помимо этого, имя в запросе должно совпадать с именем, указанным на закладке Public Name (Имя) правила Web-публикации для публикации данного OWA-сайта. Если вы еще не работали с правилами web-публикации, ниже в статье вы увидите, где находится поле Public Name (Имя), и я снова повторю о важности использования правильного имени на закладке Public Name (Имя).
  2. ISA-сервер настроен на использование правила web-публикации, которое разрешает входящие SSL-запросы на сайт mail.msfirewall.org. Вначале ISA-сервер производит проверку на уровне обычных пакетов, а после ее прохождения соединения проходят проверку на уровне приложений, в данном случае через фильтр web-прокси ISA-сервера.
    До прохождения фильтра web-прокси ISA-сервера, ISA-сервер дешифрует SSL-соединения. Дешифрованные данные проверяются фильтрами web-прокси и HTTP-безопасности, параметры соединения сравниваются с ограничениями, установленными на этих фильтрах. Такая проверка на уровне приложений гарантирует, что между ISA-сервером и web-службами Exchange-сервера существуют только разрешенные соединения. Если соединения не проходят такую проверку на уровне приложений, они разрываются.
    Если соединение прошло проверку и на уровне пакетов, и на уровне приложений, то оно снова шифруется, и создается второй SSL-туннель между внутренним интерфейсом ISA-сервера и web-сайтом Exchange (содержащим OWA, OMA и Exchange ActiveSync).
    При установке второго SSL-туннеля ISA-сервер работает как web-клиент для web-сайта Exchange-сервера. В примере, указанном на рисунке, ISA-сервер настроен на отсылку запроса к сайту https://owa.msfirewall.org. Для успешного прохождения этого запроса сертификат web-сайта, привязанный к сайту OWA, должен иметь имя owa.msfirewall.org. Если имя сертификата на Exchange-сервере не совпадает с именем в запросе от ISA-сервера, соединение разрывается.

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

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

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

  • Создание запроса на сертификат web-сайта на OWA-сервере. Первый шаг – это создание запроса на сертификат на OWA-сервере. Это текстовый файл, который вы используете для подтверждения вашего запроса к коммерческому центру сертификации.
  • Получение сертификата web-сайта от коммерческого центра сертификации. После создания текстового файла запроса на сертификат, вы заходите на сайт коммерческого центра сертификации и заполняете формы для подтверждения вашей подлинности. Также вы вставляете содержимое файла запроса на сертификат в web-форму для создания запроса.
  • Установка коммерческого сертификата web-сайта и сертификатов центра сертификации на OWA-сайт Коммерческий центр сертификации высылает вам либо файл сертификата, либо текст, который вы вставляете в Блокнот для создания файла сертификата. На OWA-сайте, где вы создавали файл запроса на сертификат, вы устанавливаете полученный сертификат.
  • Экспорт сертификата web-сайта с закрытым ключом и цепью сертификатов в файл и копирование его на ISA-сервер. Теперь, когда сертификат web-сайта установлен на OWA-сервере, вы можете экспортировать его вместе с закрытым ключом в файл. В файле будут содержаться все сертификаты данного сертификата. Далее вы копируете файл на ISA-сервер, где устанавливаете сертификат в хранилище сертификатов ISA-сервера.
  • Удаление сертификата web-сайта с OWA-сайта. На OWA-сайте мы будем использовать некоммерческий сертификат. Мы создадим закрытый сертификат, используя встроенный сервер сертификатов от Microsoft (Microsoft Certificate Server). Следует удалить коммерческий сертификат с OWA-сайта до установки нового сертификата.
  • Запрос на закрытый сертификат web-сайта для OWA-сайта. В данной статье мы используем корпоративный центр сертификации. Это позволит нам создать запрос к любому постоянному центру сертификации. Мы используем мастер запросов на сертификат для создания запроса и автоматической установки и привязки его к OWA-сайту.
  • Импорт коммерческого сертификата web-сайта и создание SSL-приемника. SSL-приемник – это программный компонент ISA-сервера, который принимает входящие SSL-запросы к фильтру web-прокси. Фильтр web-прокси – это фильтр приложений, которое связывается со службой брандмауэра ISA-сервера и выполняет проверку входящих SSL-соединений на уровне приложений. Мы используем этот SSL-приемник в правиле web-публикации на OWA-сайте.
  • Создание правила web-публикации. Правило web-публикации содержит инструкции о том, как ISA-сервер будет обрабатывать входящие SSL-соединения к OWA-сайту.
  • Настройка общего и частного разрешения имен. Разрешение имен важно для любых схем развертывания ISA-сервера. В данной статье я отойду от привычного для меня использования разделенной структуры DNS и буду использовать разные имена для внутреннего и внешнего доступа. Служба DNS должна быть настроена на поддержку публикации OWA для работы и внутренних, и внешних клиентов сети.
  • Проверка Мы закончим данную статью проверкой нашего решения и просмотром файлов журнала для того, чтобы увидеть, как ISA-сервер управляет соединениями.

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

Outlook web access

Рисунок 3: Дорожная карта нашего решения для коммерческого центра сертификации

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

Тестовая сеть, с которой мы будем работать, выглядит так, как показано на рисунке.

Outlook web access

Рисунок 4: Топология тестовой сети, используемой в данной статье

В нашей сети Exchange-сервер выполняет следующие функции:

  • Контроллер домена Active Directory
  • DNS-сервер
  • Корпоративный центр сертификации
  • WINS-сервер
  • DHCP-сервер
  • Используется схема с одним сервером Exchange 2003

Имя домена Active Directory – msfirewall.org, домен управляется сервером Windows Server 2003. Имя компьютера – EXCHANGE2003BE.msfirewall.org, его NetBIOS-имя совпадает с DNS-именем.

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

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

Внешние клиенты не являются членами домена и используют операционную систему Windows XP Service Pack 2. В нашей тестовой сети внешние клиенты имеют адреса той же подсети, что и внешний интерфейс ISA-сервера. Это сделано для удобства. Можно было бы расположить клиентов в любом удаленном месте в интернете и применять те же самые принципы.

ПРЕДУПРЕЖДЕНИЕ:
Целью данной статьи не является предоставление полного руководства по публикации OWA и других сайтов Exchange-сервера. Этому посвящены множество статей как на этом сайте (http://www.isadocs.ru/), так и на сайте Microsoft (www.microsoft.com/isaserver). Вы также можете обратиться к книге Configuring ISA Server 2004 (Настройка ISA Server 2004) за информацией не только по публикации OWA-сайтов, но и для более глубокого ознакомления с настройкой правил web-публикации.

Резюме

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

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