Протокол RPC поверх HTTPS – одна из самых полезных функций Exchange 2003/Outlook 2003. Однако, это одна и из самых разочаровывающих возможностей, поскольку с ней связано большое количество проблем, ведущих к ошибкам соединения.
Если вы хотите прочесть вторую часть статьи, воспользуйтесь ссылкой:
- RPC поверх HTTPS: Устранение неисправностей (Часть 2).
Вступление
Раньше удаленных пользователей принуждали использовать VPN для связи Outlook с корпоративными серверами Exchange, или же им приходилось использовать ограниченные функции Outlook Web Access. С выходом Exchange 2003 и Outlook 2003 была представлена новая возможность для связи: RPC поверх HTTPS. RPC поверх HTTPS туннелирует удаленные вызовы процедур через HTTPS-соединение, позволяя вам, в случае нахождения вне корпоративной локальной сети, соединяться с Exchange-сервером без установления VPN-соединения. Для того чтобы понять, как устранять неисправности, вам нужно знать, что происходит при создании RPC-соединения. На Рисунке 1 показан типичный вариант использования RPC поверх HTTPS. К данному рисунку можно обращаться при рассмотрении каждого шага создания соединения.
- Компьютер клиента разрешает DNS-имя прокси-сервера RPC и соединяется через SSL, используя Internet Explorer для обработки сертификатов. Далее происходит аутентификация прокси-сервера RPC.
- Прокси-сервер RPC соединяется с внутренним сервером Exchange 2003 и устанавливает TCP-сессию с нужным компьютером
- Прокси-сервер RPC передает учетные данные удаленного пользователя для авторизации в домене Active Directory и регистрирует удаленного пользователя на Exchange-сервере.
Для устранения неисправностей протокола RPC поверх HTTPS следует предпринять несколько шагов для решения самых распространенных проблем:
- Проверить настройки Outlook 2003
- Проверить настройки брандмауэра
- Проверить доверие центра сертификации SSL (часть 2)
- Проверить настройку прокси-сервера RPC (часть 2)
Проверка настроек Outlook 2003
Мой опыт говорит, что самые распространенные проблемы связаны с настройками клиента. Часто проблема в том, что Outlook не использует базовую аутентификацию или же неправильно настроены имена серверов и параметры соединения. Одна из обычных проблем: у пользователя не установлена правильная версия Outlook или же он работает не в нужной операционной системе. Для установления соединений RPC поверх HTTPS компьютер клиента должен удовлетворять следующим минимальным требованиям:
- Outlook 2003 (Установка пакетов обновлений необязательна, но рекомендуется)
- Windows XP SP1 (Установка SP2 необязательна, но рекомендуется)
Часто администраторы вынуждены разрешать пользователям самим настраивать сой профиль, и причиной ошибки может быть обычная описка или неотмеченная опция. Для проверки установок выполните следующее:
- Откройте Панель управления и запустите апплет настройки почты.
- Для запуска мастера настройки нажмите Email Accounts (Учетные записи электронной почты).
- Выберите View or change existing e-mail accounts (Просмотреть или изменить существующие учетные записи электронной почты) и нажмите Next (Далее).
- На странице учетных записей выберите профиль RPC поверх HTTPS и нажмите Change (Изменить).
- На странице параметров Exchange-сервера нажмите More settings (Дополнительные параметры).
- Перейдите на вкладку Connections (Соединения).
- Убедитесь, что отмечен параметр Connect to my Exchange mailbox using HTTP (Соединяться с моим почтовым ящиком Exchange с помощью HTTP), и нажмите Exchange Proxy Settings (Настройки Exchange-прокси).
В этом окне (Рисунок 2) мы должны удостовериться, что следующие параметры установлены верно:
- URL для связи с моим прокси-сервером для Exchange является правильным полностью определенным доменным именем (Fully qualified domain name – FQDN), используемым для доступа к RPC-прокси вне организации
- Отмечена опция Connect using SSL only (Соединять только с использованием SSL)
- Отмечена опция Mutually authenticate the session when connecting with SSL (При соединении с помощью SSL использовать двухстороннюю аутентификацию сессии)
- Главное имя прокси-сервера – это имя FQDN, использующееся для доступа к прокси-серверу RPC вне организации
- Главное имя должно начинаться с msstd:
- Метод аутентификации прокси: Basic Authentication (Базовая аутентификация)
- Отметьте On fast networks, connect using HTTP first, then connect using TCP/IP (В быстрых сетях: соединяться, вначале используя HTTP, а затем TCP/IP) (необязательно, но рекомендуется)
- Отметьте On slow networks, connect using HTTP first, then connect using TCP/IP (В медленных сетях: соединяться, вначале используя HTTP, а затем TCP/IP) (необязательно, но рекомендуется)
Если вы используете групповой SSL-сертификат, то главное имя прокси-сервера следует вводить так:
msstd:*.ваш_домен.tld
Две другие распространенные проблемы, случающиеся на стороне клиента, связаны с вводом UPN (имя_пользователя@ваш_домен.tld) и постоянным запросом учетных данных, или же с проблемами производительности и зависания Outlook 2003. Обе эти проблемы легко устраняются установкой Windows XP SP2.
Outlook 2003 разрешает протестировать RPC-соединение путем запуска Outlook из командной строки со следующим параметром:
Outlook.exe /rpcdiag
Перед вами появится окно с информацией о соединении (Рисунок 3), в котором, если вы соединялись с помощью RPC поверх HTTPS, тип соединения будет указан как HTTPS.
И, наконец, известно, что Outlook 2003 SP1 отключает параметр Exchange поверх Интернет на вкладке Connection (Соединение) установок Microsoft Exchange в почтовом профиле. Это защищает от настройки и изменения профиля RPC. Если у клиента данный параметр отключен, откройте реестр с помощью программы regedit и найдите ключ:
HKEY_CURRENT_USER\Software\Microsoft\Office\11.0\Outlook\RPC
Создайте параметр EnableRPDtunnelingUI типа REG_DWORD и установите его значение равным 1.
Проверка настроек брандмауэра
Вам повезло, если вашим брандмауэром является сервер ISA 2004, поскольку на нем настройка RPC поверх HTTPS очень проста. В ISA 2004 встроена поддержка соединений по протоколу RPC поверх HTTPS, что позволяет легко создавать правила доступа для разрешения трафика такого вида. При публикации Exchange-сервера на ISA 2004 включение доступа RPC поверх HTTPS - это просто отметка на странице выбора служб (Рисунок 4).
Как вы видите, правило для RPC в ISA 2004 очень простое, но проблемы происходят в ISA 2000 и брандмауэрах не от компании Microsoft. Есть возможность настройки RPC поверх HTTPS и в ISA 2000, и рекомендации по решению этой задачи вы можете найти по ссылкам, приведенным в конце статьи.
Часто проблемы в настройках брандмауэра связаны с использованием брандмауэра отличного от ISA 2004. В этом случае проблемы могут возникать при создании профиля RPC. В таких случаях профиль должен быть настроен на использование RPC поверх HTTP, чтобы клиент соединялся с внутренней сетью и получал доступ к Exchange-серверу по TCP-порту 135. Если вы используете ISA 2004, то все это выполняет созданное вами правило публикации, разрешающее RPC поверх HTTPS, однако, если вы используете другой брандмауэр, учтите этот факт.
Заключение
Мы рассмотрели наиболее распространенные проблемы на стороне клиента и проверили настройки брандмауэра. Во второй части мы рассмотрим проблемы, связанные с SSL-сертификатами, а также с неправильными настройками прокси-сервера RPC и установками Exchange-сервера.
Настройка ISA Server 2000 для поддержки RPC поверх HTTP в Outlook 2003:
http://www.msexchange.org/articles/rpchttppart1.html
http://www.isaserver.org/articles/rpchttppart2.html
http://www.isaserver.org/tutorials/rpchttppart3.html
Настройка Exchange 2003 и Outlook 2003:
http://www.msexchange.org/tutorials/outlookrpchttp.html
http://www.msexchange.org/tutorials/Outlook_2003_Connect_Exchange_2003.html
Средства Windows Server 2003:
http://www.microsoft.com/downloads/details.aspx?FamilyID=9d467a69-57ff-4ae7-96ee-b18c4790cffd&DisplayLang=en
