*    SymRegFix – исправление ошибок в реестре после установки Windows XP SP3 - 2008-06-10 08:46:04    *    «Лаборатория Касперского» сообщает о появлении опасного вируса-шантажиста - 2008-06-06 08:15:28    *    Microsoft полностью виновата в проблемах с Windows XP SP3 - 2008-05-27 08:14:06    *    Тетрис и армрестлинг - адская смесь - 2008-04-17 11:40:14    *    BCI (Brain Computer Interface), которые берут за основу данные активности человеческого мозга - 2008-04-01 07:35:08    *    Активный "кулер без проводов" от MSI для северного моста - 2008-03-04 10:58:32    *    Microsoft взломает популярные крэки для Vista - 2008-02-24 11:35:48    *    Microsoft ответила на петицию Save XP - 2008-02-13 13:27:21    **

             Обратная связь | Внести в избранное | Сделать домашней

Реклама


Содержание
 Главная

 Навигация
 Статьи
 Форум
 Файлы
 Ссылки
 Ваш Профайл
 Связь с автором
 Мировые новости
 Экзамены MCSE
 Обзор фильмов
 Самое популярное
 Фотогалерея
 Куплю-Продам
 Статьи
 Форум

 Профессиональное обслуживание компьютеров и сетей в России и в Израиле

 Учебники on-line
 Flash MX
 ISA Server
 Office XP
 PhotoShop 7
 Linux Red Hat
 Visual Basic. NET
 Visual Studio.NET
 Citrix Metaframe
 Citrix MetaFrame XP
 ВСЕ КНИГИ

Наполнение сайта
 Добавить файл
 Добавить статью
 Добавить ссылку

 Статьи по разделам
 MCSE 2000
 MCSE 2003
 Операционные Системы
 Новости Microsoft
 Безопасность
 Software
 Hardware
 Новости Интернета
 MCSE 2000 за 15 минут
 MCSE 2003 за 15 минут
 CISCO Systems


Вход
Имя

Пароль

Ещё не зарегистрировались?
Вы можете это сделать ЗДЕСЬ.

Поиск по сайту



Барахолка
No Ads submitted yet

  


Exchange Server: Организация доступа к серверу Exchange с помощью технологии RPC over HTTPS





Опубликовал michaeldmitriev Thursday, October 26


Раздел: Exchange Server

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



Организация доступа к серверу Exchange с помощью технологии RPC over HTTPS

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

Итак, перед многими сисадминами начальство ставит задачу обеспечения доступа к их почте, календарю, задачам и т. д. извне. Как правило такие задачи решаются при помощи организации сети VPN и последующего подключения сперва к VPN, а потом к серверу Exchange. Но, к сожалению, это не всегда возможно (пересечения адресных пространств, недостаток производительности аппаратных ресурсов и т. п.) Как же быть? Конечно, есть еще Outlook Web Access (OWA). Но это не полноценный доступ к сервисам Exchange

На самом деле Microsoft уже обо всем позаботилась. Нам осталось только установить и правильно все настроить. Итак, приступим.

Рассматриваем классический случай - есть один сервер и дистрибутив Microsoft Small Business Server 2003 R2. Сервер является одновременно и контроллером домена и сервером Exchange.
Задача: организовать полнофункциональный доступ к сервисам Exchange из Интернета.

Прежде всего внимательно ознакомьтесь со статьёй на сайте Microsoft

Теперь приступаем. Прежде всего скачиваем все сервис-паки и хот-фиксы и устанавливаем их. Затем устанавливаем компонент RPC over HTTP Proxy, который находится в Networking Services. (Если Вы, как, например, я, установили Microsoft Small Business Server 2003 R2, то этот компонент у Вас уже существует, но проверить не помешеает).

RPC over HTTP

Рисунок 1. RPC over HTTP.

Затем устанавливаем службу сертификатов СА. Эта служба необходима нам для организации корневого сертификата. Этот пуект можно пропустить, если у Вас уже есть купленный снртификат от публичных CA, но и в этом случае я бы посоветовал использовать свой корневой сертификат.

Certifications Authority

Рисунок 2. Установка Certification Authority.

Затем, через остнаску Certification Authority сконфигурируем новый сертификат. Вам нужно установить Enterprise Root CA. Необходимо будет задать имя сервера сертификатов, в качестве имени даем NETBIOS-имя нашего контроллера домена, как показано на рисунке 3.

Конфигурирование Certifications Authority

Рисунок 3. Конфигурирование Certifications Authority.

Теперь нам надо создать сертификат авторизации и организовать доступ к Exchange по протоколу HTTPS. Для этого идем в консоль управления IIS, разворачиваем ее и делаем правый клик на Default Web Site, выбираем Properties (Рисунок 4.). Обратите внимание на красную галочку около вируальной директории Rpc - У Вас эта директория должна появиться после установки компонента RPC over HTTP.

Конфигурирование сертификата для IIS

Рисунок 4. Конфигурирование сертификата для IIS.

Теперь идем на закладку Directory Security, где кликаем на кнопке Server Certificate в разделе Secure Communicstions. Запустится мастер сертификатов. Я предлагаю Вам удалить старый сертификат, если Вы, конечно его не используете. Здесь выбираем Create a new certificate, отмечаем Send the request immediately to an online certification authority

Send the request immediately to an online certification authority

Рисунок 5. Получение сертификата.

Далее в поле Name вписываем полный внешний доменный адрес вашего сервера Exchange, например server.kamtest.com и идем дальше.

Примечание. Организация доступа извне к данному CA описывается ниже.

Теперь мастер спросит про Вашу организацию и подразделение - следует вписать (хотя и необязательно) данные Вашего предприятия и идем дальше. ВНИМАНИЕ! В поле Common Name обязательно нужно вписать полный внешний доменный адрес вашего сервера Exchange, например server.kamtest.com.

Конфигурирование сертификата

Рисунок 6. Конфигурирование сертификата.

Далее вписываем желаемый порт или оставляем дефолтовый 443 и жмем кнопку Next до завершения работы мастера.

Итак, мы создали собственный сертификат. Теперь осталось его применить. Для этого опять идем в закладку Directory Security, где кликаем на кнопке Edit раздела Authentication and access control, убираем все галки и ставим галку Basic authentication (password is sent in clear text) (Таким образом пароль будет послан открытым текстом, но так как сама сессия будет зашифрованной, то это не страшно). Жмем ОК

Конфигурирование доступа

Рисунок 7. Конфигурирование доступа.

и жмем на кнопке Edit раздела Secure Communicstions. Здесь отмечаем галками чекбоксы Require secure channel (SSL) и Require 128-bit encryption. Жмем везде ОК. IIS в процессе скажет, что эти изменения будут применены и к следующим сервисам (напишет в отдельном окошечке эти сервисы) - соглашаемся с ним.

Конфигурирование доступа

Рисунок 8. Конфигурирование доступа.

Теперь проверяем, что наш Web Access через HTTPS работает. Для этого в браузере пишем , в ответ мы должны получить предупреждение Security Alert

Установка сертификата

Рисунок 9. Установка сертификата.

с которым мы смело согласимся и получим окно для ввода логин/пароль авторизации Exchange. Вводим необходимые данные и получаем доступ к OWA.

Но это еще не все. Ведь функции работы Exchange в браузере сильно урезаны. Поэтому мы двигаемся дальше. Теперь будем настраивать порты для работы RPC proxy. Для этого на Сервереоткрываем редактор реестра и идем в ветку HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Rpc\RpcProxy, где открываем параметр ValidPorts, удаляем всё, что там написано и, вместо этого вписываем свои данные в следующем формате
ServerNETBIOSName:593;ServerFQDN:593;ServerNETBIOSName:6001-6002;ServerFQDN:6001-6002;ServerNetBIOSName:6004;ServerFQDN:6004
, например:
server:593;server.kamtest.local:593;server:6001-6002;server.kamtest.local:6001-6002;server.kamtest.com:6001-6002;server:6004;server.kamtest.local:6004;server.kamtest.com:6004;

Важно: строчка должна заканчиваться точкой с запятой!

Примечание: Возможно, нет необходимости "засвечивать" внешние имена Вашего сервера, но я сделал именно так. На самом деле, с клиентами (и через ISA Server, но об этом ниже...) сервер будет работать по протолоку SSL (по умолчанию - 443 порт).

Затем раскрываем оснастку управления сервером Exchange и переходим Administrative Groups > First Administrative Group > Servers. Правый клик на нашем сервере и идем в закладку RPC-HTTP. Здесь мы отмечаем радиобокс RPC-HTTP Back-End Server и не обращая внимания на ругательства сервера (в общем-то справедливые), что он вовсе не бек-енд сервер говорим ОК.
Рестартуем сервер.

RPC-HTTP Back-End Server

Рисунок 10. RPC-HTTP Back-End Server.

Примечание: В процессе конфигурирования я так и сделал, но потом таки снял этот радиобокс, без каких-либо изменений в работе связки сервер-клиент.

Осталось настроить Outlook 2003, 2007 на работу через НТТРS. Вот здесь, после "проверенного метода" проб и ошибок, я просто опишу порядок действия, которой ОДНОЗНАЧНО помог мне справиться с ситуацией.

    Во-первых, выход сервера в интернет и настройка файрвола.

    Повторюсь, для корректной работы Exchange Вам следует открыть порт 443 на соответствующий IP-адрес Вашей внутренней сети. Я испробовал два варианта. Отмечу только, что мой Exchange Server работает на вируальной машине Microsoft Virtual Server 2005 R2 и IP у него внутренний, скажем, 192.168.0.10. Сам компьютер, на котором запущена виртуальная машина, имеет два сетевых адаптера, один из которых "смотрит" в Интернет (через ADSL modem), второй интерфейс "смотрит" в локальную сеть, в которой установлен, кроме всего прочего, ISA 2004 другого домена (и леса). Внешний интерфейс настроен как ICS (Internet connection Sharing), ISA 2004 имеет свой канал Интернета.

  1. Вариант первый. Выход через ICS.

    Всё очень просто - открываем порт 443 на наш Exchange Server. Процедура закончена.

  2. Вариант второй. Выход через ISA 2004.

    После многих экспериментов с открытием SSL "по правилам", т.е. через публикацию Exchange Server как Mail Server Publishing Rule (проблема в открытии https с использованием "чужого" сертификата другого леса), просто сделал публикацию (Server Publishing Rule) и открыл HTTPS Server Port (443 порт). Это, конечно, похоже на публикацию через Mail Publishing Rule, но не требует использования сертификата для SSL.

    Конечно, в целях дополнительной безопасности, в моём случае, можно было бы и настроить вариант с RADIUS Server, но я решил не плодить зависимые друг от друга сервисы, их и так получается достаточно много.

    HTTPS Server Publishing Rule

    Рисунок 11. HTTPS Server Publishing Rule.

Кроме того, рекомендую Вам открыть (можно и через Mail Server Publishing Rule) порты 25 и 110 для функционирования стандартных почтовых протоколов - SMTP (25 порт) и POP3 (110 порт)

С серверами мы закончили, теперь перейдём к клиентам...

Сконфигурируем клиента в Outlook 2003

Примечание: При настройке использовался компьютер, находящийся вне локальной сети и не входящий в домен.

В самом начале необходимо получить доверенный корневой сертификат от ранее сконфигурированного Вами центра Сертификации (CA).В браузере пишем и выбираем пункт Download a CA certificate, certificate chain, or CRL

Download a CA certificate, certificate chain, or CRL

Рисунок 12. Установка доверенного корневого сертификата.

Затем, после перехода выбираем пункт "To trust certificates issued from this certification authority, install this CA certificate chain".

To trust certificates issued from this certification authority, install this CA certificate chain

Рисунок 13. Установка доверенного корневого сертификата, продолжение.

Соглашаемся со всеми предупреждениями (сами-то себе мы доверяем, не так ли?) и устанавливаем сертификат.

Далее, на том же клиентском компьютере идём в Registry и прописываем следующее:
В ветке HKEY_CURRENT_USER\Software\Microsoft\Office\11.0\Outlook\RPC создаём dword ключ с именем
EnableRPCtunnelingUI и равным 1.

Вот теперь мы закончили предварительную настройку клиентского компьютера. Переходим непосредственно к настройке Outlook 2003, 2007. Для этого, закрыв предварительно сам Outlook, заходим в Свойста Outlook, как указано на Рисунке 14a (или через панель управления - иконка "Почта")

Конфигурирование клиента Outlook

Рисунок 14a. Конфигурирование клиента Outlook.

Конфигурирование клиента Outlook для использования RPC-HTTPS

и заводим новый аккунт Exchange, где в имени сервера вписываем полное локальное имя сервера Exchange, например server.kamtest.local и вписываем имя пользователя.

Независимо от того, какие появятся окна с предупреждениями, нажимаем на More Settings, идем в закладку Connection и отмечаем чекбокс Connect to my Exchange mailbox using HTTP,

Конфигурирование клиента Outlook для использования RPC-HTTPS

Рисунок 15. Конфигурирование клиента Outlook, продолжение.

жмем на Exchange Proxy Settings. В открывшимся окне отмечаем галками все чекбоксы, в верхнем поле ввода (URL) пишем server.kamtest.com, в нижнем поле ввода (мутуальная авторизация) пишем: msstd:server.kamtest.com, в самом низу (в выпадающем комбобоксе) выбираем Basic authentication.

Конфигурирование клиента Outlook для использования RPC-HTTPS

Рисунок 16. Конфигурирование клиента Outlook. окончание.

Жмём ОК несколько раз.

Вот теперь действительно все должно работать.

А в качестве заключительно штриха, чтобы проверить, что Вы действительно подключились к Exchange через HTTPS, запустите Outlook через Run следующим образом образом: outlook.exe /rpcdiag. В этом случае вместе с Outlook откроется дополнительное окно, в котором Вы сможете увидеть, с каким протоколом Вы работаете.

Михаил Дмитриев, misha@kamtec.com, Microsoft Certified Trainer, CTEC "KAMTec" в Израиле

При перепечатке статьи прямая ссылка на сайт и автора обязательна!

 



Комментарии к статье
Ваше имя: Неизвестный [ Новый пользователь ]

Тема:

Комментарий:




Идея и воплощение: Михаил Дмитриев
Страница оптимирована под разрешение от 1024х768 для IE 5.0+
Copyright © 2001-2008 by Michael Dmitriev - Создание и поддержка сайтов

Сайт работает на домашнем компьютере. OS Windows Server 2003. Находится в Израиле.


Web site engine's code is Copyright © 2003 by . Время создания страницы - 1.245 сек. и 46 запрос (а,ов) к базе данных