На главную страницу
 
  Главная 
  Новости 
  Статьи  RSS
  Программное обеспечение 
  Форум 
  Опросы 
  Полезные ссылки 
MSExchange.ru ISADocs.ru WinSecurity.ru NetDocs.ru

Exchange 5.5
Exchange 2000
Exchange 2003
Exchange 2007
Общее
Exchange 2010

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


Авторизация

Запомнить меня на этом компьютере
  Забыли свой пароль?
  Регистрация

Подписка

Изменение параметров

Статистика

Hits 20083278
38829
Hosts 2192984
1165
Visitors 1367566
1769

6
Мониторинг активности принтеров

Главная / Статьи / Exchange 2003 / Конфигурирование ISA-сервера для переадресации пользователей Outlook Web Access (OWA) на правильные папки и протоколы (Часть 1)


SurfCop

Конфигурирование ISA-сервера для переадресации пользователей Outlook Web Access (OWA) на правильные папки и протоколы (Часть 1)

Версия для печати Версия для печати

Эта статья переведена силами и средствами компании Red Line Software. Размещение данного переведенного материала на других сайтах без разрешения компании Red Line Software запрещается.

Очень часто на досках объявлений на ISAServer.org и в почтовых рассылках мне попадаются вопросы о том, как помочь несчастным пользователям, которые не могут набрать правильный путь или указать правильный протокол доступа к сайту Outlook Web Access (OWA) сервера Exchange. И хотя вроде бы достаточно просто ввести в адресной строке web-браузера путь https://owa.domain.com/exchange и нажать ENTER, опыт подсказывает нам, что это не всегда так.

Обычными ошибками, которые делают пользователи, пытаясь зайти на сайт OWA, являются:

  • Ввод неправильного пути. Например, вместо https://owa.domain.com/exchange пользователи вводят https://owa.domain.com
  • Ввод неправильного протокола. Например, вместо https://owa.domain.com/exchange пользователи вводят http://owa.domain.com/exchange.
  • Есть пользователи, которые всегда идут наперекор всему. Вместо https://owa.domain.com/exchange они вводят http://owa.domain.com/, т.е. неправильный и адрес, и протокол.

В этой статье мы рассмотрим способы устранения всех этих проблем, а так же я представлю вам прекрасный продукт, под название WebDirect.

Переадресация пользователей на папку /Exchange

Обычное желание администраторов ISA-сервера — перенаправить соединения с корневой папки сайта Outlook Web Access (OWA) на папку /Exchange. Переадресацию можно легко сделать с использованием закладки Пути (Paths) и правилах Web-публикации (Web Publishing Rule).

В случае OWA, внешний путь будет /* (что подразумевает все папки и директории на сайте), а внутренний путь будет /Exchange\. Обратите внимание на использование обратной косой черты в конце пути, поскольку мастер правил web-публикации OWA (OWA Web Publishing Rule Wizard) сам прописывает путь /Exchange/. Закладка Пути (Paths) при данной конфигурации должна выглядеть так, как на рисунке.

Рис. 1

Эти переадресации делают следующее:

  • При вводе пользователем в браузере https://owa.domain.com/exchange он попадает в папку /Exchange сайта Outlook Web Access (OWA)
  • При вводе или нажатия на ссылку https://owa.domain.com/exchweb, он попадает в папку /Exchweb сайта Outlook Web Access (OWA)
  • При вводе или нажатия на ссылку https://owa.domain.com/public, он попадает в папку /Public сайта Outlook Web Access (OWA)
  • При вводе или нажатия на ссылку https://owa.domain.com/, он попадает в папку /Exchange сайта Outlook Web Access (OWA)

Такие переадресации возможны, поскольку сайт Outlook Web Access (OWA) способен «понять» пользователей, не различающих UNC-пути (Universal Naming Convention -универсальное соглашение об именовании) и URL-пути (Uniform Resource Locators — унифицированный локатор ресурса). OWA-сайт принимает обратную косую черту как верный запрос и конвертирует его «на лету» в левую косую черту. Это позволяет использовать установки внутреннего пути (Internal Path) /Exchange\ и /exchange/* в закладке Пути (Paths), а верная работа сервера была бы невозможно при использовании простых косых черт для обеих записей, поскольку ISA-сервер не разрешает использование многократных привязок к путям с одинаковым префиксом.

Чтобы было более ясно, причина, по которой мы вводим /Exchange\ для получения переадресации, в том, что у нас уже есть переадресация /Exchange/*, которая служит для соединения при вводе пользователем адреса https://owa.domain.com/exchange. Мы можем ввести этот адрес дважды, поэтому мы должны «обмануть» правила Web-публикации (Web Publishing Rule) ISA-сервера используя /Exchange\ , что связано с вводом адреса https://owa.domain.com/.

Итак, это решило проблему пути для пользователей, но как же протокол? Теперь нам нужен способ для переадресации неправильного протокола на правильный.

Переадресация HTTP-пользователей на SSL-сайт

Даже если Вы потратите месяцы и годы на обучение пользователей, как набирать путь /exchange после ввода полностью определенного имени домена (FQDN), вы закончите эту борьбу поражением, поскольку всегда будет огромного количество пользователей, которые будут набирать http:// вместо https://. На самом деле, эти пользователи не затрудняют себя вводом протокола, они просто набирают путь, даже если они знают, что должны вводить https:// .

Поэтому нам нужен способ переадресации пользователей, использующих http:// вместо https://. Существует насколько путей решения этой проблемы:

  • Создайте web-страницу, на которой будет ссылка, ведущая на адрес https://owa.domain.com/exchange. Замените страницу ошибки протокола HTTP 403.4. Замените страницу ошибки протокола HTTP 403.4 ISA-сервера этой страницей.
  • Создайте web-страницу с мета-переадресацией, указывающей пользователям путь к сайту https://owa.domain.com/exchange и используйте ее для замены страницы ошибки протокола HTTP 403.4 ISA-сервера.
  • Создайте .asp страницу, как описано в бюллетене Microsoft по адресу http://support.microsoft.com/default.aspx?scid=kb;en-us;555126&Product=exch2003, которая поможет переадресовать пользователя на правильный протокол
  • Используйте мета-переадресацию Джима Харрисона или страницы, написанные на java script для замены страниц в папке HTML-файлов ошибок ISA-сервера.

Лучшим решением является использование страниц Джима Харрисона. Когда пользователи используют для соединения неправильный протокол, они автоматически переадресуются на правильный протокол и адрес URL. Джим проделал огромную работу и сделал все для простого решения этой проблемы. Скачайте его файлы, заархивированные в ISA_Redirects.zip с сайта www.isatools.org.

Теперь, когда мы защитили себя от пользователей, которые не помнят правильный путь, и смогли укрепить защиту против пользователей, которые не знают правильный протокол, что нам делать с пользователями, которые отказываются вводить правильный адрес и протокол?

Лучшим из известных мне решений является программа WebDirect, которую можно скачать по адресу www.collectivesoftware.com В следующем разделе мы увидим, как WebDirect решает эту проблему.

Переадресация пути и протокола с использованием программы WebDirect

WebDirect — простое средство, которое позволяет ISA-серверу отправлять HTTP-переадресацию пользователю. Можно использовать WebDirect для переадресации пользователя на другой сайт, используя то же протокол, или же другой сайт, используя другой протокол. WebDirect дает ISA-серверу функциональность, которая могла бы быть в нем включена.

Можно использовать WebDirect вместе с функциями ISA-сервера по переназначению путей, что обезопасит нас от действий пользователей, обсуждаемых в этой статье: забытый путь, неправильный протокол и комбинация неправильного пути и протокола.

Для выполнения этого следует создать три правила:

  • Правило Web-публикации OWA, созданное с помощью мастер правил web-публикации OWA ISA-сервера.
  • Правило, переадресовывающее пользователей, забывших путь к папке /Exchange
  • Правило, переадресовывающее пользователей, забывших правильных протокол на правило, переадресовывающее пользователей, забывших путь к папке /Exchange

В консоли ISA-сервера это выглядит так:

Рис. 2

Начиная с нижней строки, эти правила работают так:

Правило Redirect HTTP to HTTPS (Переадресация HTTP на HTTPS) переадресует все соединения с адресом to http://owa.msfirewall.org и всеми его производными на верный ресурс. Это правило защищает нас от пользователей, которые набирают неправильные протокол и путь. Например, если пользователь вводит адрес http://owa.msfirewall.org, он будет переадресован на https://owa.msfirewall.org. Если пользователь вводит http://owa.msfirewall.org/stuff, он будет переадресован на https://owa.msfirewall.org. Таким образом, это правило защищает нас от пользователей, набирающих неправильный протокол, и от тех, кто думает, что набирает правильный адрес (хотя они вместе с неправильным адресом набирают и неправильный протокол)

Нижняя строка говорит о том, что правило Redirect HTTP to HTTPS (Переадресация HTTP на HTTPS) действует на все HTTP запросы, не смотря на то, какой адрес вводит пользователь, и переводит их на owa.msfirewall.org.

Правило Redirect Absent Path to Exchange (переадресация пути на Exchange) защищает нас от пользователей, которые набирают правильный протокол, но не помнят верный путь или просто вводят полностью определенное имя домена (FQDN) для сайта Outlook Web Access (OWA). Когда пользователь вводит адрес https://owa.msfirewall.org, его автоматически переадресуют в папку /Exchange сайта Outlook Web Access (OWA).

Правило OWA создается мастером правил web-публикации OWA (OWA Web Publishing Rule Wizard) ISA-сервера. Не нужно ничего менять в этом правиле. Оно относится к тем пользователям, которые вводят правильный протокол и путь.

Я не буду углубляться в то, как создавать правило web-публикации OWA (OWA Web Publishing Rule), поскольку это детально рассмотрено в нашей книге, на этом сайте и в наборе инструментов для ISA и Exchange серверов (ISA firewall/Exchange Deployment Kit). На чем я хочу заострить внимание, так это:

  • Установка программы WebDirect
  • Создание правила web-публикации OWA
  • Создание правила переадресации пути на Exchange
  • Создание правила переадресации HTTP на HTTPS

Установка программы WebDirect

Программа WebDirect устанавливается следующим образом:

  1. Откройте Internet Explorer и скачайте с сайта http://www.collectivesoftware.com/Products/ программу WebDirect.
  2. Двойным нажатием на файл WebDirect.msi запустите процесс инсталляции
  3. Выберите опцию Complete и нажмите Install.
  4. Нажмите кнопку Finish в окне Completing the Collective Software WebDirect v1.1.5 Setup Wizard.
  5. Нажмите OK в окне для перезагрузки сервиса брандмауэра, чтобы web-фильтр программы WebDirect установился без ошибок.
  6. Если консоль ISA-сервера открыта, закройте ее и откройте заново
  7. В консоли ISA-сервера щелкните на имени сервера и выберите пункт Monitoring. Выберите закладку Services. Правой кнопкой мыши щелкните на сервисе Microsoft Firewall и выберите Stop. После того, как сервис остановится, нажмите на него снова правой кнопкой мыши и выберите Start.

Создание правила web-публикации OWA

В этом примере я рассмотрю вариант публикации web-сайта OWA, доступного по адресу https://owa.msfirewall.org/exchange. В нашем случае, в сети существует хорошо организованная инфраструктура раздельного DNS, и пользователи и в корпоративной и во внешней сети используют одно и то же имя для доступа к сайту OWA.

Раздельный DNS — важный компонент для получения оптимального результата для служб Outlook Mobile Access (OMA), ActiveSync, протокола удаленного вызова процедур (RPC) поверх HTTP и защищенного RPC публикаций Exchange (secure Exchange RPC Publishing). Раздельный DNS позволяет внешним адресам разрешать адрес owa.msfirewall.org на внешний IP-адрес через ISA-сервер, а внутренним адресам разрешать адрес owa.msfirewall.org на IP-адрес сайта во внутренней сети.

Также нам нужно использовать SSL-сопряжение, для того, чтобы достигнуть максимального уровня безопасности и избежать серьезных ошибок, связанных с сопряжением SSL и HTTP (сопряжение SSL и HTTP упомянуто только для того, чтобы избежать его). Сертификат web-сайта, связанный с OWA-сайтом, обычно имеет имя вида owa.msfirewall.org и этот сертификат экспортируется с открытым ключом и устанавливается в хранилище сертификатов ISA-сервера.

Для создания правила web-публикации OWA предпринимаются следующие шаги:

  1. В консоли ISA-сервера щелкните на имени сервера и выберите пункт Firewall Policy.
  2. Выберите закладку Tasks в панели задач, а затем ссылку Publish a Mail Server.
  3. В окне мастера публикаций Welcome to the New Mail Server Publishing Rule Wizard, введите OWA в текстовом поле Mail Server Publishing Rule name и нажмите Next.
  4. В окне Select Access Type выберите опцию Web lcent access: Outlook Web Access (OWA), Outlook Mobile Access, Exchange Server ActiveSync и нажмите Next.
  5. В окне Select Services отметьте пункт Outlook Web Access и нажмите Next.
  6. В окне Bridging Mode выберите опцию Secure connection to clients and mail server и нажмите Next.
  7. В окне Specify the Web Mail Server введите имя для сертификата web-сайта, связанного с OWA-сайтом внутренней сети. В нашем примере это owa.msfirewall.org. Вводим его в текстовом поле Web mail server и нажимаем Next.
  8. В окне Public Name Details выберите опцию This domain name (type below) в выпадающем списке Accept requests for. Введите имя сертификата web-сайта, который будет связан web-сервером, обозначенном в правиле web-публикации (Web Publishing Rule). Поскольку зависимое имя сертификата web-сайта, связанное с этим правилом, owa.msfirewall.org, мы вводим это значение в текстовое поле Public name и нажимаем Next.
  9. На странице Select Web Listener нажмите New для создания нового web-сервера.
  10. На первой странице мастера Welcome to the New Web Listener Wizard введите OWA SSL в текстовое поле Web listener name и нажмите Next.
  11. На странице IP Addresses отметьте External. Если бы у нас было несколько IP-адресов для внешнего интерфейса ISA-сервера, мы бы выбрали кнопку Address и сконфигурировали бы сервер на использование специфического IP-адреса, чтобы сайт owa.msfirewall.org разрешал их. Нажмите Next.
  12. На странице Port Specification удалите отметку с пункта Port Specification. Отметьте пункт Enable SSL. Нажмите кнопку Select.
  13. В диалоговом окне Select Certificate выберите сертификат web-сайта из списка сертификатов Certificates и нажмите OK.
  14. Нажмите Finish на странице Completing the New Web Listener Wizard.
  15. Нажмите Edit на странице Select Web Listener.
  16. В диалоговом окне OWA SSL Properties выберите закладку Preferences.
  17. На закладке Preferences нажмите кнопку Authentication.
  18. Уберите отметку с пункта Integrated. Нажмите OK в диалоговом окне, подтверждая, что не выбран ни один из протоколов аутентификации
  19. Отметьте пункт OWA Forms-Based.
  20. Отметьте пункт Require all users to authenticate.
  21. Нажмите OK в диалоговом окне Authentication.
  22. Нажмите OK в диалоговом окне OWA SSL Properties.
  23. Нажмите Next на странице Select Web Listener.
  24. На странице User Sets нажмите All Users, и затем нажмите Remove. Нажмите Add.
  25. В диалоговом окне Add Users дважды кликните на All Authenticated Users и нажмите Close.
  26. Нажмите Next на странице User Sets.
  27. Нажмите Finish на странице Completing the New Mail Server Publishing Rule Wizard.

Создание правила переадресации пути на Exchange

Следующим шагом является создания правила web-публикации, которое защитит нас от пользователей, вводящих правильный протокол, но забывающих вводить путь к папке /exchange. Это правило использует возможности переадресации ISA-сервера, так что все соединения к сайту https://owa.msfirewall.org будут перенаправляться на папку /Exchange OWA-сайта.

Для создания этого правила сделайте следующее:

  1. В консоли ISA-сервера щелкните на имени сервера и выберите пункт Firewall Policy. Выберите закладку Tasks в панели задач, а затем ссылку Publish a Secure Server.
  2. На странице Welcome to the SSL Web Publishing Rule Wizard введите в текстовом окне SSL Web publishing rule name значение Redirect Absent Path to Exchange и нажмите Next.
  3. На странице Publishing Mode выберите пункт SSL Bridging и нажмите Next.
  4. На странице Select Rule Action выберите пункт Allow и нажмите Next.
  5. На странице Bridging Mode выберите пункт Secure connection to clients and Web server и нажмите Next.
  6. На странице Define Website to Publish введите имя, которое в сертификате web-сайта связано с OWA-сайтом внутренней сети. В нашем примере это имя owa.msfirewall.org, поэтому мы вводим это значение в текстовое поле Computer name or IP address. В текстовом окне Path введите путь, на который вы желаете переадресовывать запросы, т.е. /Exchange\. Отметьте пункт Forward the original host header instead of the actual one (specified above). Нажмите Next.
  7. На странице Public Name Details убедитесь, что выбрана опция This domain name (type below) в выпадающем списке Accept request for. Введите имя сертификата web-сайта, связанного с web-сервером, через который проходят все запросы, отвечающие этому правилу. В нашем случае это owa.msfirewall.org, поэтому мы вводим это имя в текстовое поле Public name. В текстовом поле Path введите /*. Это позволит ISA-серверу переадресовывать любые запросы на папку /Exchange OWA-сайта. Нажмите Next.
  8. На странице Select Web Listener стрелками в списке Web listener выберите OWA SSL. Нажмите Next.
  9. На странице User Sets выберите All Users и нажмите Remove. Нажмите Add.
  10. В диалоговом окне Add Users дважды кликните на All Authenticated Users и нажмите Close.
  11. Нажмите Next на странице User Sets.
  12. Нажмите Finish на странице Completing the New SSL Web Publishing Rule Wizard.

Резюме

В этой статье мы рассмотрели вопросы, касающиеся переадресации пользователей, которые вводят неправильные протоколы и пути в web-браузере при попытке зайти на web-сайт OWA. Мы детально рассмотрели проблемы, связанные с вводом неправильного протокола, а также и проблемы пользователей, вводящих неверный путь. Было представлено два мощных решения этих проблем: первое — использование встроенных в ISA-сервер возможностей для привязки путей, второе — использование программы WebDirect, которая дает возможность для ISA-сервера генерировать HTTP-переадресацию. Во второй части завершим конфигурацию и протестируем ее.





Рейтинг:  
5.0 (голосов 1)  
 1   2   3   4   5    

Автор: Томас Шиндер (Thomas Shinder)
Доктор Томас Шиндер (Thomas W. Shinder) является MCSE, MCP+I и MCT. Он работает в качестве инструктора и консультанта по технологиям в Dallas-Ft. Worth муниципальном районе, помогая в разработке и внедрении коммуникационных стратегий, основанных на IP, для таких больших фирм, как Xerox, Lucent и FINA.
Эта статья переведена и опубликована с разрешения http://www.msexchange.org

Эта статья переведена силами и средствами компании Red Line Software. Размещение данного переведенного материала на других сайтах без разрешения компании Red Line Software запрещается.





Печать пластиковых карт - это часть процесса изготовления и производства пластиковых карт