Новая возможность Outlook 2003 для доступа к почтовому ящику Exchange

Благодаря сочетанию Microsoft Outlook 2003, Windows Server 2003 и Microsoft Exchange Server 2003 открываются новые возможности для подключения клиента Outlook 2003 к Exchange 2003 по каналам HTTP. Соединение не просто использует HTTP: Outlook заключает вызов удаленных процедур (RPC) к Exchange 2003 в оболочку HTTP, обеспечивая соединение локального клиента Outlook 2003 с удаленным сервером Exchange 2003 с любой машины, располагающей Web-браузером. Это полезный метод, особенно если учесть недостатки других способов: Outlook Web Access (OWA), который совершенствуется, но по-прежнему уступает полноценному клиенту Outlook, или доступ к Outlook через соединение VPN, которое часто блокируется сетевыми провайдерами. Чтобы использовать RPC over HTTP, необходимо понимать механизм и требования к конфигурациям как клиента, так и сервера.

Взаимодействие Outlook и Exchange

Во всех версиях Outlook для взаимодействия с любой версией Exchange Server применяется интерфейс Messaging API (MAPI) и вызовы удаленных процедур (RPC) для обработки вызовов MAPI. Протокол RPC не располагает встроенными функциями повышения надежности, это свойство определяется базовым транспортным протоколом, таким как TCP/IP. При использовании менее надежного транспортного средства, например UDP, приложение на базе RPC должно обеспечить функции тайм-аута и повторной пересылки.

RPC-соединения Outlook-Exchange начинаются с процедуры квитирования между клиентом Outlook и сервером Exchange через хорошо известный порт (например, UDP-порт 135 — порт подключения конечных точек RPC) с последующей организацией канала связи через динамически назначаемый порт (обычно в диапазоне от 1024 до 1100). Назначать порты можно с помощью параметров реестра, но обычно администраторы сетей и брандмауэров не разрешают организовывать соединения RPC через общедоступные сети TCP/IP. Кроме того, из-за серьезных проблем с безопасностью RPC-службы Windows NT в прошлом большинство сетевых администраторов блокируют порты 135, 137, 139 и 445, чтобы помешать проходу внешних тестовых сообщений RPC через брандмауэр. Эти ограничения приводят к тому, что нельзя использовать Outlook в сети одной компании, чтобы установить соединение через Internet с сервером Exchange в сети другой компании. Вместо того чтобы возложить согласование RPC по каналам TCP/IP на администраторов сетей и брандмауэров, разработчики Microsoft модернизировали механизм RPC в Outlook и Exchange, обеспечив связь поверх протокола HTTP.

Благодаря новым функциям можно установить возвратный proxy-сервер (reverse proxy server) HTTP и использовать протокол HTTP для внешних соединений. Как правило, для связи применяется стандартный порт 80 или какая-нибудь его разновидность (например, 8080 или 8088). После настройки браузера Microsoft Internet Explorer (IE) на клиентском компьютере для работы с proxy-сервером любое приложение может задействовать протокол HTTP для соединений клиент/сервер. Протокол Secure HTTP (HTTPS) также обычно доступен через порт 443.

Требования RPC over HTTP

Для соединения RPC over HTTP между Outlook и Exchange необходимо, чтобы на клиентском компьютере были установлены Windows XP Service Pack 1 (SP1) и исправление, описанное в статье Microsoft «Outlook 11 Performs Slowly or Stops Responding When Connected to Exchange Server 2003 Through HTTP» (http://support.microsoft.com/?kbid=331320). На клиенте должен работать Outlook 2003 (при подготовке данной статьи использовалась вторая бета-версия, сборка 4920).

На сервере должна быть установлена Windows 2003, чтобы использовать службу Microsoft Internet Information Services (IIS) 6.0 в режиме Worker Process Isolation Mode. Windows 2003 должна работать на всех системах, устанавливающих связь с клиентом Outlook 2003, в том числе серверах Exchange, серверах глобального каталога (Global Catalog, GC) и контроллерах домена (DC).

Архитектура RPC over HTTP

Архитектура RPC over HTTP напоминает модель внешний/внутренний сервер (front end/back end server), впервые примененную Microsoft в Exchange 2000 Server и используемую в OWA, IMAP и POP3. Outlook 2003 связывается через протокол 2003 с proxy-сервером RPC, также известным как внешний proxy-сервер RPC. Proxy-сервер RPC действует от имени клиента, устанавливая RPC-соединения с внутренним сервером, на котором размещается почтовый ящик клиента. Соединения показаны на рисунке 1.

Рисунок 1. Архитектура RPC over HTTP для Outlook и Exchange

Следует отметить важные особенности архитектуры. Во-первых, RPC-посредник не обязательно должен быть системой Exchange 2003, так как proxy-сервер не использует в своей работе компонентов Exchange. Функции посредника возлагаются на фильтр Internet Server API (ISAPI) в IIS 6.0, поэтому единственное требование к системе — наличие Windows 2003. Во-вторых, proxy-сервер RPC — простая функция IIS 6.0, поэтому его можно разместить на системе Exchange 2003. И в-третьих, на системе Exchange 2003 можно разместить и GC-сервер, хотя делать этого не рекомендуется, чтобы не снижалась производительность и сохранялась корректность технических решений. Поэтому все серверные компоненты, показанные на рисунке 1, могут сосуществовать на одной серверной машине.

Следует также рассмотреть возможность размещения сервера относительно внутренних и внешних брандмауэров и образуемой в результате демилитаризованной зоны (DMZ). Proxy-сервер RPC можно разместить в DMZ, а серверы Exchange и другие серверы Active Directory (AD) — во внутренней части сети (рисунок 2). Но поскольку во внутреннем брандмауэре требуется открыть больше портов, данная конфигурация связана с излишним риском и использовать ее обычно не рекомендуется. Риск особенно высок при динамическом назначении портов, которые открываются для RPC-соединений между proxy-сервером RPC и почтовым сервером Exchange 2003. Теоретически эти порты лежат в диапазоне от 1024 до 65535, но в процессе реализации RPC over HTTP требуется определить более узкий диапазон (от порта 6001 до порта 6004). Диапазон задается с помощью параметров реестра, которые будут рассмотрены в следующем разделе. В дополнение к портам, показанным на рисунке 2, proxy-сервер RPC может затребовать порт 88 (UDP/TCP) для служб Kerberos, порт 53 (UDP/TCP) для запросов DNS, порт 445 для Server Message Block (SMB) службы NetLogon и порты для любых других протоколов, необходимых для управления и мониторинга служб.

Рисунок 2. Proxy-сервер RPC, расположенный внутри DMZ.

Лучше разместить proxy-сервер RPC во внутренней части сети и использовать универсальный ретранслятор HTTP в DMZ (рисунок 3). В данной конфигурации предусматривается лишь одно соединение от ретранслятора HTTP в DMZ (в данном случае Microsoft Internet Security и Acceleration-ISA-server) к proxy-серверу RPC во внутренней сети. Данное соединение может быть установлено через базовый протокол HTTP (порт 80) или зашифровано с использованием SSL (Secure Sockets Layer — порт 443). Можно также задействовать функции шифрования RPC over HTTP программы Outlook 2003. При использовании данного подхода можно применять несколько способов защиты соединений. Самый обычный метод — завершить SSL-соединение на proxy-сервере ретрансляции HTTP и установить простое соединение HTTP с RPC-посредником. Этот подход широко распространен, так как подобные proxy-серверы HTTP обычно оснащены аппаратными акселераторами шифрования SSL. Альтернативный подход — провести туннель для входящего SSL-соединения через proxy-сервер HTTP и возложить задачу SSL-шифрования на proxy-сервер RPC. Или же proxy-сервер HTTP может завершить исходящий сеанс SSL и установить новый сеанс SSL с proxy-сервером RPC.

Рисунок 3. Proxy-сервер RPC, расположенный во внутренней сети

Конфигурирование RPC over HTTP на серверах

Для реализации RPC over HTTP необходимо выполнить на серверах несколько изменений. Прежде всего нужно убедиться, что на сервере, применяемом в качестве сервера-посредника RPC, установлена служба RPC over HTTP Proxy. Для этого следует открыть утилиту Add/Remove Programs панели управления и щелкнуть на вкладке Add/Remove Windows Components. Затем нужно отметить пункт Networking Services, убедиться, что выбрана служба RPC over HTTP (экран 1) и щелкнуть на кнопке OK, чтобы развернуть службу.

Экран 1. Установка службы RPC over HTTP Proxy

После установки службы RPC over HTTP Proxy необходимо перейти к объекту Web SitesDefault Web SiteRPC Virtual Directory в оснастке IIS Manager консоли управления Microsoft Management Console (MMC) и открыть диалоговое окно Properties объекта (экран 2). Следует перейти к вкладке Directory Security, выбрать раздел Authentication and access control, а затем запретить Anonymous access и разрешить режим Integrated Windows Authentication или, если используется SSL, режим Basic authentication. Если выбран режим Basic authentication, то мандат передается открытым текстом, но соединение защищено благодаря SSL, поэтому такой подход вполне приемлем.

Далее требуется настроить конфигурацию сервера для работы в качестве посредника RPC. Для этого необходимо открыть редактор реестра, перейти в раздел реестра HKEY_LOCAL_MACHINESOFTWAREMicrosoftRpc RpcProxy и присвоить параметру ValidPorts значение с типом данных REG_SZ.

Устанавливая значение ValidPorts, необходимо указать каждый сервер, с которым может установить связь proxy-сервер RPC, в том числе все почтовые серверы Exchange 2003 и любые DC и GC, и назначить порт 593 для каждого сервера. Служба RPC over HTTP Endpoint Mapper использует порт 593 для организации соединения путем квитирования. В строке параметров также указывается диапазон портов для соединений. На экране 3 показан пример такой строки для сервера с именем osbex01. В зависимости от конкретной среды, расположения сервера и способа разрешения имен, иногда следует указать Fully Qualified Domain Name (FQDN) серверов в элементе реестра ValidPorts (если имена в сокращенном формате не обеспечивают корректного преобразования). На экране 6 видно, что в дополнение к параметрам для osbex01 указаны и соответствующие параметры для osbex01.osb.cantaz.net. Если роль GC-сервера выполняет тот же сервер, на котором работает Exchange 2003, то нет необходимости указывать GC отдельно от системы Exchange.

Очевидно, что при наличии десятков или сотен почтовых и GC-серверов обновление параметров ValidPorts реестра с указанием значений для каждого сервера — труднейшая задача. Поэтому мы надеемся, что Microsoft дополнит пакет Exchange 2003 утилитой, которая будет анализировать среду Exchange и автоматически обновлять данный параметр реестра.

Ограничение соединений RPC-посредника

Диапазон портов proxy-сервера RPC определяет область функционирования RPC over HTTP. Однако можно явно назначить порты, которые будут использоваться каждым сервером — участником соединений RPC over HTTP. Следует обратить внимание, что в бета-версиях Exchange 2003 в разделе реестра ValidPorts можно указать принимаемый по умолчанию диапазон 1024-65535, и любые внутренние серверы или GC будут динамически выбирать рабочие порты в этом диапазоне без дополнительной настройки. Из версии Release Candidate 0 эта функция удалена.

Самые существенные изменения требуется внести во внутренние почтовые серверы. Во-первых, необходимо определить порт, через который внутренний сервер устанавливает соединения RPC over HTTP с хранилищем Exchange Store. Для этого нужно присвоить параметру реестра HKEY_LOCAL_MACHINESYSTEMCurrentControlSet ServicesMSExchangeISParametersSystemRPC/HTTP Port значение 6001 типа REG_DWORD.

Затем следует настроить внутренний сервер для перенаправления Directory Service (DS) Referral, присвоив параметру реестра HKEY_LOCAL_MACHINESYSTEMCurrentControlSet ServicesMSExchangeSAParametersHTTP Port значение 6002 типа REG_DWORD. Затем внутренний сервер настраивается для доступа DS Proxy. Для этого параметру HKEY_LOCAL_MACHINESYSTEMCurrentControlSet ServicesMSExchangeISParametersSystemRPC/HTTP NSPI Port присваивается значение 6003 типа REG_DWORD. Эти изменения должны быть выполнены на всех внутренних серверах Exchange 2003, которые могут устанавливать соединения с proxy-сервером RPC.

Кроме того, необходимо настроить любые DC и GC, указанные в разделе реестра ValidPorts proxy-сервера RPC, для связи с proxy-сервером RPC через порты ограниченного диапазона. Следует перейти к элементу HKEY_LOCAL_MACHINESYSTEMCurrentControlSet ServicesNTDSParametersNSPI interface protocol sequences реестра DC или GC-сервера и присвоить этому параметру значение ncacn_http:6004 типа REG_SZ.

Безопасные соединения

Соединения RPC over HTTP желательно устанавливать по каналам SSL, избегая незащищенных линий. В рекомендуемой конфигурации (см. рисунок 3) ретрансляционный proxy-сервер HTTP (ISA Server) завершает любые клиентские SSL-соединения и устанавливает отличные от SSL соединения с proxy-сервером RPC. Для этого необходимо установить серверный сертификат на ретрансляционном посреднике HTTP. Соответствующие сертификаты можно получить из коммерческой организации Certificate Authority (CA), такой как VeriSign или Thawte, либо использовать службу Microsoft Certificate Services для создания собственных сертификатов.

Раздел реестра HKEY_LOCAL_MACHINESOFTWAREMicrosoftRpc RpcProxyAllowAnonymous управляет работой proxy-сервера RPC с соединениями, отличными от SSL. Если данного раздела не существует или значение его параметра равно 0, то proxy-сервер RPC отвергает все отличные от SSL и неаутентифицированные соединения. Когда ретранслятор HTTP завершает SSL-соединение, последующее соединение с посредником RPC обычно не защищено SSL и поэтому будет отвергнуто. В данном случае можно присвоить параметру реестра значение 1-го типа REG_DWORD. Изменение вступает в силу после перезапуска службы IIS на proxy-сервере RPC.

В целях безопасности в текущей документации Microsoft такие изменения рекомендуется вносить только на непроизводственных системах. Однако во многих рабочих средах необходима следующая конфигурация: SSL-соединение завершается на proxy-серверах HTTP, а с proxy-сервером RPC устанавливаются отличные от SSL соединения. Необходимо взвесить все за и против и выбрать оптимальную конфигурацию для конкретной среды.

Настройка клиента

Некоторые изменения требуется внести и в профиль Messaging API (MAPI), чтобы позволить клиенту Outlook 2003 установить связь с сервером по HTTP. Если у пользователя уже имеется профиль MAPI, то доступ к его свойствам можно получить, выбрав соответствующий профиль MAPI в утилите Mail панели управления. Нужно выбрать пункты Change, More Settings, а затем перейти к вкладке Connection. Затем следует установить флажок Connect to my Exchange mailbox using HTTP и щелкнуть на кнопке Exchange Proxy Settings, чтобы завершить настройку конфигурации. В диалоговом окне (экран 4) требуется ввести URL, чтобы направить клиента на proxy-сервер RPC. Этот URL может быть значением, объявляемым ретрансляционным proxy-сервером HTTP (для последующего перенаправления пакетов в proxy-сервер RPC). В режиме Basic Authentication префикс URL автоматически изменяется с http на https, поэтому может использоваться только безопасное соединение. Если режим с подключением через протокол HTTP отключен, необходимо убедиться, что установлены XP SP1 и упомянутая выше программа коррекции. Можно установить флажок Mutually authenticate the session when connecting with SSL. В результате proxy-сервер RPC (или ретрансляционный proxy-сервер HTTP) аутентифицирует подключающегося клиента с помощью как клиентского, так и серверного сертификата. В этом режиме клиент должен передать в модуль Security Support Provider (SSP) сервера ожидаемое имя сервера Principal name. Согласно стандартным синтаксическим правилам Microsoft, за префиксом msstd: следует FQDN proxy-сервера RPC (экран 4).

Экран 4. Настройка конфигурации клиента RPC over HTTP.

И наконец, чтобы использовать для соединения протокол HTTP, необходимо установить флажок Connect using HTTP first, then connect using my Local Area Network (LAN). Как правило, Outlook 2003 сначала пытается установить связь с сервером Exchange через TCP/IP. Если попытка не удается, Outlook пробует соединиться через HTTP. После установки этого флажка Outlook делает попытку сначала соединиться через HTTP, что позволит избежать задержки, связанной с тайм-аутом протокола.

При обсуждении смены профиля MAPI предполагалось, что профиль на клиентском компьютере уже существует. Если требуется создать профиль, следует помнить, что для этого необходим прямой RCP-доступ к серверу Exchange через TCP/IP. Если нужно создать профили MAPI для удаленных пользователей (т. е. прямой TCP/IP-доступ к серверу Exchange отсутствует), следует задействовать утилиту генерации профиля MAPI, такую как profgen.exe — инструмент из набора ресурсов Microsoft Office 2003 Resource Kit. В идеале для управления системами необходимо автоматизировать все изменения в MAPI-профилях пользователей, чтобы значительно снизить вероятность возникновения пользовательских ошибок.

Применение RPC over HTTP для подключения клиентов Outlook 2003 к почтовым серверам представляет собой гибкий способ обращения к домашним почтовым ящикам пользователей без ограничений туннелирования или громоздкого клиента на базе Web. Однако в стандартной конфигурации эта функция не работает. Ее запуск требует планирования и настройки конфигурации со стороны администратора систем отправки сообщений. Прежде чем внедрять службу RPC over HTTP на всем предприятии, следует выполнить пилотный проект, чтобы исследовать влияние данной службы на инфраструктуру.

Киран Маккорри (kieran.mccorry@compaq.com) - живет в Ирландии, является старшим консультантом группы Technology Leadership Group в Compaq. Автор книги «Connecting Microsoft Exchange Server» (Digital Press)