|
|
|
от Michael Bell |
|
|
Одним из наиболее часто задаваемых вопросов на группах новостей 2000trainers.com и Microsoft public newsgroup является вопрос об использовании SSL (Secure Sockets Layer) в OWA (Outlook Web Access) для обеспечения безопасности. Это особенно важно, если ваша двухзвенная конфигурация front-end/back-end настроена так, что только front-end сервера поддерживают базовую аутентификацию. На первый взгляд это может показаться не слишком значительной проблемой, но когда вы осознаете, что ваша информация пересылается по сети в незашифрованном виде, вы понимаете, насколько это важно. Некоторым администратором также требуется «понуждать» пользователей к использованию безопасного соединения автоматически. И, в заключение, большому числу людей хотелось бы задействовать опцию, включенную в OWA, которая позволяет изменять доменные пароли пользователя. Мы поговорим обо всех этих возможностях, но знайте, что последний из описанных выше шагов требует использования SSL на сервере OWA. Давайте начнем с разрешения SSL на Exchange Virtual Server. Для того чтобы сделать это я использовал цифровой сертификат моего собственного ЦС (Центра Сертификации). Можно также использовать сертификат, выпущенный любым ЦС из Интернета. Кто при этом издает сертификат, в принципе, не важно. Установка его в Exchange Virtual Server разрешает применение SSL в OWA, что очень важно для нас. Для начала раскроем Default Virtual Web Server при помощи Internet Services Manager, как это изображено на рисунке 1. Рис. 1.
После чего перейдем к свойствам Default Web Server, как это показано на рисунке 2. Рис. 2.
В окне свойств перейдем на вкладку Directory Security и выберем установку цифрового сертификата. Это вызовет запуск соответствующего мастера, что отражено на рисунке 3. Рис. 3.
После того, как вы выполните все шаги, предлагаемые мастером, вы сможете перейти к свойствам нового цифрового сертификата, только что установленного вами (рисунок 4.). Если вы на самом деле хотите выполнить все шаги мастера установки сертификата, вы можете найти его здесь. Рис. 4.
Эта была не самая несложная часть работы. Теперь, после того, как мы установили сертификат, мы хотим быть уверены, что наши клиенты могут использовать SSL при работе с OWA. После того, как мы убедимся, что SSL работает, мы сможем автоматизировать процесс настолько, что пользователю даже не потребуется печатать HTTPS в броузере: запросы будут перенаправляться на безопасное соединение автоматически. В заключение, мы настроим IIS так, что пользователи OWA смогут менять свои доменные пароли. Для того чтобы начать, мы должны убедиться, что HTTPS работает, для чего напечатаем в адресной строке броузера следующий URL: HTTPS://exchangeservername/exchange и проверим, получаем ли мы доступ к нашему почтовому ящику. Как видно из рисунка 5, все работает нормально. Рис. 5.
Единственной проблемой на этот момент является то, что пользователь также может продолжать получать доступ к своему почтовому ящику и по обычному (незашифрованному) соединению. Посмотрите на рисунок 6 и вы поймете, что я имею ввиду. Рис. 6.
Итак, проблема заключается в том, что хотя мы разрешили пользователям использовать SSL, они по-прежнему подключаются к своему почтовому ящику по обычному соединению. Это, конечно, нежелательно, но мы не можем каждый раз заставлять пользователей печатать HTTPS, когда они пытаются подключиться к своим почтовым ящикам через OWA. К счастью, мы можем автоматизировать эту задачу и не напоминать пользователям об этом. Принудительное использование SSL Давайте теперь посмотрим, как добиться того, чтобы пользователи использовали SSL для доступа к web-сайту и переключались бы на порт безопасного соединения, даже если они указали в адресной строке обычный (HTTP) порт. Прежде всего, мы должны перейти в каталог C:\inetpub\wwwroot и создать там папку, называемую Owaasp. Вот как это будет выглядеть: Рис. 7.
Теперь нам нужно создать файл, называемый owahttps.asp и поместить его в данную папку. Содержание файла приведено в листинге 8. Верьте мне, когда я говорю, что не умею кодировать. Я просто скопировал эту информацию из Q-статьи, взятой из Technet! Листинг 8. <% Теперь нам нужно перейти к свойствам нашего Exchange Virtual Directory при помощи ISM (Internet Services Manager). Перейдем на вкладку Custom Error Messages (настраиваемые сообщения об ошибках). Посмотрите на рисунок 9, чтобы увидеть, где мы оказались. Рис. 9.
На вкладке Custom Errors мы должны отредактировать свойства ошибки 403.4. Мы введем информацию, отображенную на рисунке 10. Рис. 10.
Далее мы перейдем на вкладку Directory Security, нажмем кнопку Edit, расположенную под кнопкой Certificates (в Exchange Virtual Directory) и установим флажок Require secure channel (SSL). Вот как это выглядит: Рис. 11.
Теперь, когда мы сделали это, давайте нажмем кнопку ОК и наше диалоговое окно закроется. Нам осталось только остановить IISadmin и затем перезапустить ее. Самым простым способом выполнить это является перезапуск сервера, но если это вам не подходит, можно использовать перезапуск службы из командной строки. Посмотрите на рисунок 12, чтобы видеть синтаксис команды, необходимый для остановки iisadmin. Рис. 12.
Следует заметить, что остановка службы iisadmin вызовет остановку ряда других служб. Как вы можете видеть на рисунке 13, некоторые службы зависят от службы iisadmin. Также запомните, что в зависимости от того, какие продукты и службы у вас установлены, эта информация может быть различной. И последнее: если вы не знаете синтаксис командной строки для запуска всех отдельных служб, помните, что вы всегда можете воспользоваться Менеджером Служб (Services Manager) для того, чтобы перезапустить их. Просто щелкните My Computer, выберите Manage, а затем Services. Используя командную консоль, как упоминалось выше, перезапустите все соответствующие службы. Рис. 13.
Теперь нам нужно удостовериться, что пользователи будут «вынуждены» использовать SSL соединения независимо от того, будут ли они указывать в браузере HTTP или HTTPS. Посмотрите на рисунок 14, чтобы узнать, чем увенчались наши труды. Рис. 14.
Мы видим, что все работает прекрасно, если мы напечатаем HTTPS, а теперь давайте посмотрим, что случится, если мы наберем HTTP. Рисунок 15 служит подтверждением того, что мы действительно перенаправляемся на безопасный сайт, несмотря на то, что использовали для запроса обычный порт (HTTP). Рис. 15.
Похоже на то, что мы выполнили две из поставленных нами трех задач. Мы включили SSL на нашем сервере OWA, а также мы настроили его так, что пользователи будут «вынуждены» использовать SSL соединение при подключении к серверу OWA. Все, что нам осталось, это настроить утилиту для изменения пароля. Изменение пароля через OWA. Для того чтобы разрешить пользователям изменять свои пароли через OWA, нам необходимо предварительно разрешить использование SSL на сервере OWA. Но, как вы помните, мы уже сделали это. Следующий шаг требует от нас создать виртуальный каталог в ISM. Виртуальный каталог будет называться lisadmpwd и соответствовать физическому каталогу, расположенному по адресу C:\winnt\system32\inetserv\iisadmpwd. Рисунок 16 демонстрирует нам первые шаги по созданию виртуального каталога. Рис. 16.
Не забудьте сопоставить Virtual Directory физическое расположение, указанное ранее. Запустив Мастер создания виртуального каталога, отметьте флажками только Read и Script Access. По умолчанию только эти две опции и должны быть выделены. И в заключение, откройте окно свойств папки lisadmpwd и убедитесь, что к ней обеспечен анонимный доступ. Может быть также выбран и другой метод аутентификации, но только этот позволит нам выполнить задуманное. Если выбран не этот метод, но пользователь, время действия пароля которого истекло, не сможет изменить свой пароль. Посмотрите статью Q275457 для получения более подробной информации, относящейся к этой настройке. И последнее: прежде чем мы закончим эту тему. Откройте командную строку и перейдите в каталог c:\inetpub\adminscripts. Далее напечатайте следующую команду: Adsutil.vbs set w3svc/passwordchangeflags 0. Заметьте, что при написании этой команды мы не использовали пробела в строке w3svc/passwordchangeflags. Знайте, что вы можете получить сначала уведомление о том, что текущая скриптовая машина (script engine) не может обработать запрос и предложение заменить вашу скриптовую машину. Выберите Yes и вы получите подтверждение успешного завершения команды. После того, как мы выполнили это, перейдем в OWA-клиент для того, чтобы убедиться, что можем изменить свое доменное имя из OWA. Как вы видите на рисунке 17, я подключаюсь к своему почтовому ящику, используя OWA и нажимаю кнопку Options. Стоит заметить, что у нас установлено безопасное соединение! Рис. 17.
Когда я щелкну кнопку Change password, я увижу диалоговое окно, представленное на рисунке 18. Рис. 18.
Отмечу, что я использовал в ходе выполнения этой работы Exchange 2000 SP3. Когда я добрался до места, я просто ввел ту информацию, которая потребовало от меня это диалоговое окно и все прекрасно сработало. Но этого не получилось, когда пытался использовать установки Domain\username, как это было описано в некоторых статьях Q, которые я читал. Вам стоит протестировать эти настройки, основываясь на SP, который используете вы и затем обучить им ваших пользователей. Ну вот и весь материал этой недели. Я бы хотел обратить ваше внимание на три статьи из сборника технических статей (Knowledge Base) Microsoft, которые, на мой взгляд, чрезвычайно полезны при выполнении этих задач. Я бы посоветовал вам прочесть их перед тем, как настраивать любую из описанных выше функций. Первая из них - Q320291 объясняет, как настроить OWA для использования SSL. Далее, я использовал Q279681 для настройки OWA так, как того требует SSL. И в заключение, Q267596 показывает нам, как использовать функцию изменения пароля в OWA и IIS. Я надеюсь, что вы найдете информацию этой статьи полезной для вас. До следующей встречи, суа! Michael Bell, MCSE, MCT. |
