В данной статье мы рассмотрим проблемы, возникающие при использовании SSL-сертификатов и касающиеся настроек RPC-прокси и Exchange-сервера.
Если вы хотите прочесть первую часть статьи, воспользуйтесь ссылкой:
Использование RPC поверх HTTPS является одной из самых полезных функций Exchange 2003 и Outlook 2003, но также одной из самых трудных в смысле поиска и устранения неполадок. В первой части мы рассмотрели вопросы устранения неисправностей на стороне клиента и на стороне брандмауэра. Во второй части мы обсудим проблемы, возникающие при использовании SSL-сертификатов и касающиеся настроек RPC-прокси и Exchange-сервера.
RPC поверх HTTPS не слишком трудно для внедрения, однако есть некоторые моменты, которые могут все испортить. Для устранения неисправностей протокола RPC поверх HTTPS следует предпринять несколько шагов для решения самых распространенных проблем:
Из своего опыта я знаю, что главная проблема в работе RPC поверх HTTPS связана с ошибками в SSL-сертификатах. Для связи с помощью RPC поверх HTTPS у вас ОБЯЗАТЕЛЬНО должен быть верный SSL-сертификат из доверенного центра сертификации.
Для проверки установленного SSL-сертификата откройте консоль управления IIS, далее Servername | Web Sites | Default Web Site (Имя сервера | Web-сайты | Web-сайт по умолчанию). В окне свойств web-сайта по умолчанию откройте вкладку Directory Security (Безопасность). Если сертификат установлен, то кнопка View Certificate (Просмотр сертификата) будет активна (если нет, то вам необходимо установить сертификат). Нажмите ее и просмотрите сертификат. В моем примере (см. Рисунок 1) SSL-сертификат не из доверенного центра сертификации, он не будет работать с соединениями RPC поверх HTTPS до тех пор, пока центр сертификации не будет добавлен в доверенные корневых центры.
Рисунок 1: Ошибка SSL-сертификата
Если вы не используете сертификат от стороннего производителя, т.е., к примеру, у вас есть свой центр сертификации, который сам создает и подписывает сертификаты, вам необходимо добавить ваш центр в список доверенных центров сертификации на сервере и на всех клиентах.
Последнее, что следует проверить, это соединение с RPC-прокси с помощью SSL-соединения. В зависимости от пакета обновлений вашей операционной системы, соединение можно проверить, открыв Internet Explorer и указав браузеру следующий адрес:
Для Windows Server 2003 RTM и SP1 – https://полностью.определенное.имя.домена/RPC Для Windows Server 2003 SP1 – https:// полностью.определенное.имя.домена /RPC/rpcproxy.dll
На серверах, на которых установлена версия до SP1, если IIS работает правильно и SSL-сертификат и центр сертификации верны, вы получите сообщение об ошибке HTTP Error 403.2 – Forbidden: Read access is denied (Чтение запрещено). Это значит, что все работает. Если вы используете Windows Server 2003 с SP1 и первый URL из указанного ранее списка, у вас трижды запросят учетные данные, после чего появится ошибка HTTP Error 401.3 — Unauthorized: Access is denied due to an ACL set on the requested resource (Доступ запрещен из-за установок списка контроля доступа на запрашиваемом ресурсе). При использовании Windows Server 2003 SP1 и второго URL результатом будет чистая страница с замком SSL в правом нижнем углу. Все это означает, что IIS работает правильно.
Если при проведении этих тестов вы получили предупреждение системы безопасности (см. Рисунок 2), вы должны исправить источник этой ошибки (недоверенный центр сертификации, SSL-сертификат и истекшим сроком действия, несовпадение имен и т.п.), иначе соединения RPC поверх HTTPS работать не будут.
Рисунок 2: Предупреждение системы безопасности
Программа Outlook не показывает никаких ошибок или предупреждений SSL. Если по какой-либо причине сертификат неверен, соединение прерывается. Использование собственных сертификатов само по себе является ошибкой, я настоятельно рекомендую пользоваться сертификатами от доверенного стороннего производителя.
Если на клиентской стороне все в порядке, то необходимо проверить настройки Exchange-сервера и сервера RPC-прокси. Начнем с внутреннего Exchange-сервера, а затем перейдем к внешнему Exchange/RPC-прокси серверу.
Внутреннему Exchange-серверу нужно немного настроек для поддержки RPC поверх HTTPS, но в тех случаях, когда служба RPC поверх HTTPS настроена на одном сервере, вам придется выполнить дополнительные установки. Вначале убедитесь, что служба World Wide Web Publishing (W3SVC) работает. Это очень просто сделать путем проверки доступа к Outlook Web Access.
После этого убедитесь в правильности настройки портов. Компания Microsoft поставляет средство RPCDump из пакета Windows Server 2003 Resource Kit, которое вы можете использовать для теста. RPCDump – это превосходное средство для проверки работы всего, что связано с RPC. На внутреннем Exchange-сервере запустите команду RPCDump.exe /v и просмотрите настройки протокола ncacn_http (Рисунок 3). Убедитесь, что прослушивание происходит на нужном порту.
Рисунок 3: Результаты работы средства RPCDump
Если вы используете RPC поверх HTTPS на единственном Exchange-сервере, вам необходимо настроить отдельный порт для доступа к Глобальному каталогу. Настроить порт можно с помощью редактора реестра. В редакторе реестра найдите раздел:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters
Создайте параметр NSPI interface protocol sequence типа Multi-string и установите его значением ncacn_http:6004. Для того чтобы изменения вступили в силу, перегрузите компьютер. Проверьте установки программой RPCDump.
На сервере RPC-прокси (или на Exchange-сервере в случае использования одного сервера) необходимо проверить, что библиотека RPCProxy.dll загружена. Откройте Event Viewer (Просмотр событий) и отфильтруйте события для поиска следующей записи:
Event Source: RPC Proxy
Event Category: Startup
Event ID: 2
Date: 4/25/06
Time: 7:12:47 AM
User: N/A
Computer: EX02-FE
Description: The following ValidPorts could not be parsed. The RPC Proxy cannot load. The ValidPorts registry key might have been configured incorrectly. User Action Verify that the ValidPorts registry value is set correctly. If the value is not correct, edit the registry key to reflect the correct value (Описание: Невозможно проанализировать параметр ValidPorts. RPC-прокси не загружен. Возможно, раздел реестра ValidPorts настроен неправильно. Действие: Проверьте настройки раздела реестра ValidPorts. Если установки не верны, исправьте их.)
Если вы нашли такую ошибку, значит, вы неправильно настроили раздел реестра ValidPorts, например, неверно указали имя сервера или номера портов. Часто проблема в том, что вы поставили точку с запятой вместо двоеточия!
Последнее, что нужно проверить, это метод аутентификации сервера RPC-прокси. Часто возникает проблема постоянного запроса учетных данных. Это случает при настройке сервера RPC-прокси на использование строенной аутентификации, которая не работает в соединениях поверх HTTP-прокси. Даже если у вас вместе со встроенной аутентификацией используется базовая аутентификация, первая имеет более высокий приоритет, и это и вызывает ошибку.
Откройте консоль управления IIS, далее Servername | Web Sites | Default Web Site | RPC (Имя сервера | Web-сайты | Web-сайт по умолчанию | RPC). На странице свойств RPC выберите вкладку Directory Security (Безопасность). В параметре Authentication and access control (Аутентификация и контроль доступа) нажмите Edit (Изменить). Проверьте, что опция Enable anonymous access (Включить анонимный доступ) не выбрана, и единственный отмеченный метод аутентификации – это Basic Authentication (Базовая аутентификация) (Рисунок 4).
Рисунок 4: Установки аутентификации
RPC поверх HTTPS — это прекрасная функциональность, которая облегчает работу с электронной почтой для удаленных пользователей. Но помимо всего прочего, при использовании данной возможности возникает много проблем, и, надеюсь, данная статья поможет вам решить их за достаточно короткий срок.
Источник http://www.msexchange.org