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

- начальник жмот, есть один сервер и дистрибутив
Microsoft Small Business Server 2003. Сервер является одновременно и контроллером домена и сервером
Exchange.
Задача: организовать полнофункциональный доступ к сервисам
Exchange из Интернета.
Закатали рукава и прежде всего внимательно ознакомились со статьёй на сайте Микрософта
http://support.microsoft.com/?kbid=833401
Теперь приступаем. Прежде всего скачиваем все сервис-паки и хот-фиксы и устанавливаем их. Затем вставляем дистрибутив в привод компакт-дисков и устанавливаем компонент
RPC over HTTP Proxy, который относится к
Networking Services. Затем устанавливаем службу сертификатов
СА. В этот момент нас спросят имя сервера сертификатов, в качестве имени даем NETBIOS-имя нашего контроллера домена.
Теперь надо создать сертификат авторизации и организовать доступ к
Exchange по протоколу
HTTPS. Для этого идем в консоль управления
IIS, разворачиваем ее и делаем правый клик на
Default Web Site, где выбираем
Properties. Теперь идем на закладку
Directory Security, где кликаем на кнопке
Server Certificate в разделе
Secure Communicstions. Запустится мастер сертификатов. Здесь выбираем
Create a new certificate, затем говорим
Send the request immediately to an online certification authority, далее в поле
Name вписываеем полный
внешний доменный адрес вашего сервера
Exchange, например
mail.my_cool_exchange.com и идем дальше. Теперь мастер спросит про вашу организацию и подразделение - смело пишем любую чушь и идем дальше. А вот тут осторожно! В поле
Common Name опять нужно вписать полный
внешний доменный адрес вашего сервера
Exchange, например
mail.my_cool_exchange.com. Далее вписываем желаемый порт или оставляем дефолтовый 443 и жмем кнопку
Next до завершения работы мастера.
Итак мы создали собственный сертификат. Дело за малым - применить его.

Для этого опять идем в закладку
Directory Security, где кликаем на кнопке
Edit раздела
Authentication and access control, убираем все галки и ставим галку
Basic authentication (password is sent in clear text) (Таким образом пароль будет послан в плайн-тексте, но так как сама сессия будет шифрованной, то это не страшно). Жмем
ОК и жмем на кнопке
Edit раздела
Secure Communicstions. Здесь отмечаем галками чекбоксы
Require secure channel (SSL) и
Require 128-bit encryption. Жмем везде
ОК.
IIS в прцессе "океев"

скажет, что эти изменения будут применены и к следующим сервисам (напишет в отдельном окошечке эти сервисы) - соглашаемся с ним.
Теперь проверяем, что наш
Web Access через
HTTPS работает. Для этого в браузере пишем
https://mail.my_cool_exchange.com/exchange, в ответ мы должны получить предупреждение
Security Alert с которым мы смело согласимся и получим окно для ввода логин/пароль авторизации
Exchange. Вводим необходимые данные и наслаждаемся.
Но это еще не все. Ведь функции работы
Exchange в браузере сильно кастрированы. Поэтому мы двигаемся дальше. И настраиваем порты для работы
RPC proxy. Для этого открываем редактор реестра и идем в ветку
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Rpc\RpcProxy, где открываем параметр
ValidPorts, зачеркиваем все, что там написано и, вместо этого, вписываем свои данные в следующем формате
ServerNETBIOSName:6001-6002;ServerFQDN:6001-6002;ServerNetBIOSName:6004;ServerFQDN:6004 , например:
my_server:6001-6002;my_server.my_cool_exchange.local:6001-6002;mail.my_cool_exchange.com:6001-6002;my_server:6004;my_server.my_cool_exchange.local:6004;mail.my_cool _exchange.com:6004; Важно: строчка должна заканчиваться точкой с запятой!
Сейчас раскрываем оснастку управления сервером
Exchange и переходим
Administrative Groups > First Administrative Group > Servers. Правый клик на нашем сервере и идем в закладку
RPC-HTTP. Здесь мы отмечаем радиобокс
RPC-HTTP Back-End Server и не обращая внимания на ругательства сервера (в общем-то справедливые), что он вовсе не бек-енд сервер говорим
ОК.
Рестартуем сервер.
Вот, в общем-то, и все.
Осталось настроить Аутглюк на работу через
НТТРS. Для этого заводим новый аккунт
Exchange, в имени сервера вписываем
полное локальное имя сервера Exchange, например
my_server.my_cool_exchange.local, вписываем имя пользователя и жмем на кнопку
More Settings, идем в закладку
Connection и отмечаем чекбокс
Connect to my Exchange mailbox using HTTP, жмем на
Exchange Proxy Settings. В открывшимся окне отмечаем галками все чекбоксы, в верхнем поле ввода (урл) пишем
mail.my_cool_exchange.com, в нижнем поле ввода (мутуальная авторизация) пишем:
msstd:mail.my_cool_exchange.com, в самом низу (в выпадающем комбобоксе) выбираем
Basic authentication. Теперь жмем
ОК до победного конца

.
А теперь грабли: дело в том, что вы получите окно авторизации
Exchange, но как бы вы не бились авторизация не пройдет. Как выяснилось, все дело в сертификате. Если ваш сертификат создан специальной организацией, подписи которой доверяет ваш браузер, то нет проблем, но, поскольку начальник - жмот, то сертификат мы создавали сами и теперь его надо внести в список доверенных.
Для этого открываем браузер и пишем
https://mail.my_cool_exchange.com/CertSrv, получаем
Security Alert, соглашаемся с ним, получаем окно для ввода логин/пароль, вводим их и попадаем на страницу, откуда можно инсталлировать наш сертификат. Для этого кликаем на ссылке
Install CA, выслушиваем ругательства браузера по поводу того, что устанавливать сертификаты с неизвестными подписями очень опасно и настаиваем на том, что хотим установить этот сертификат.
Вот теперь действительно все должно работать.
А в качестве заключительно штриха, тобы проверить, что вы действительно работаете с
Exchange через
HTTPS запустите Аутглюк таким образом:
outlook /rpcdiag. В этом случае вместе с Аутлуком откроется дополнительное окно, в котором вы можите видеть с каким протоколом вы работаете.
Удачи.