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

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

В части 1 статьи о том, как переадресовывать пользователей Outlook Web Access (OWA) на правильные папки и протоколы, обсуждались проблемы, связанные с созданием переадресаций для пользователей, которые вводят неверные адреса и протоколы для доступа к сайту OWA. Мы также рассмотрели начальные шаги конфигурации таких переадресаций. Во второй, и последней, части мы пройдемся по всему процессу конфигурации от начала и до конца, логически обосновывая все этапы. После того, как вы предпримите все эти шаги, пользователи смогут вводить неправильные пути и неверные протоколы, однако все равно они будут переадресованы на нужный OWA-сайт. Конечным результатом является уменьшение звонков в службу поддержки пользователей.

В этой статье мы обсудим следующие темы:

• Установка программы 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.

Создание правила переадресации HTTP на HTTPS

Последнее правило, которое защитит нас от пользователей, вводящих неправильный протокол. Когда пользователь вводит адрес http://owa.msfirewall.org (неважно, с указанием полного пути или нет), он будет автоматически переадресован на https://owa.msfirewall.org. Эта переадресация отсылает их к правилу переадресации пути на Exchange, которое дает им доступ к папке /Exchange и не дает свернуть с верного пути.

Для создания правила переадресации HTTP на HTTPS выполните следующие шаги:

1. В консоли ISA-сервера щелкните на имени сервера и выберите пункт Firewall Policy. Выберите закладку Tasks в панели задач, а затем ссылку Publish a Web Server.
2. На странице мастера Welcome to the New Web Publishing Rule Wizard введите имя для правила в текстовое поле Web Publishing Rule name. В нашем примере мы назовем правило Redirect HTTP to HTTPS. Нажмите Next.
3. На странице Select Rule Action выберите Allow и нажмите Next.
4. На странице Define Website to Publish в текстовом поле Computer name or IP address введите полностью определенное имя домена (FQDN) для доступа к сайту. В нашем случае, пользователи имеют доступ к OWA-сайту, используя имя owa.msfirewall.org, поэтому мы вводим его в текстовом поле. Поскольку мы хотим доступ ко всем путям, то в текстовое поле Path мы вводим /* и нажимаем Next.
5. На странице Public Name Details выберите опцию This domain name (type below) из выпадающего списка Accept requests for. В текстовое поле Public name введите полностью определенное имя домена (FQDN) OWA-сайта во внутренней сети. Поскольку мы используем хорошо организованную конфигурацию сети с раздельным DNS, полностью определенные имена домена (FQDN) OWA-сайта во внутренней и внешней сети совпадают, поэтому в текстовое поле Public name мы вводим owa.msfirewall.org. Нам не важен внутренний адрес, поскольку он не участвует в переадресации, следовательно, в текстовом поле Path мы вводим /* и нажимаем Next.
6. На странице Listener нажмите кнопку New. Мы должны создать новый web-сервер для приемки, поскольку нам нужен новый HTTP-приемник запросов, а в наличии у нас только SSL-приемник запросов.
7. На странице Welcome to the New Web Listener Wizard вводим имя нового HTTP-приемника запросов в тектовое поле Web listener name. В нашем примере это HTTP Listener. Нажимаем Next.
8. На странице IP Addresses отметьте пункт External. Поскольку у нас есть только один IP-адрес, связанный с внешним интерфейсом ISA-сервера, просто отмечаем этот пункт. Однако, в случае наличия нескольких IP-адресов, связанных с внешним интерфейсом ISA-сервера, следует нажать кнопку Address и выбрать нужный адрес, разрешающий имя FQDN сайта OWA. Нажмите Next.
9. На странице Port Specification убедитесь, что выбрана опция Enable HTTP и что по умолчанию установлен 80-й порт. Нажмите Next.
10. Нажмите Finish на странице Completing the New Web Listener Wizard.
11. Нажмите Next на странице Select Web Listener.
12. На странице Users Sets можете оставить пункт All Users, поскольку на этой стадии аутентификация не обязательна. Пользователи будут немедленно переадресованы на https://-сайт, запрос на ввод учетных данных только увеличит издержки и может породить другие проблемы. Нажмите Next.
13. Нажмите Finish на странице Completing the New Web Publishing Rule Wizard.
14. Правой кнопкой мыши нажмите на правило Redirect HTTP to HTTPS и выберите Properties.
15. В диалоговом окне Redirect HTTP to HTTPS Properties выберите закладку WebDirect.
16. На закладке WebDirect отметьте пункт Send HTTP Redirect. В текстовое поле All requests matching this rule will be redirected to this target server введите имя FQDN, на которое вы хотите сделать переадресацию. В нашем примере, мы хотим сделать переадресацию на тот же самый адрес, но другой протокол. В текстовое поле введите owa.msfirewall.org, затем выберите опцию HTTPS в разделе Protocol of target server. Нажмите Apply, а затем OK.

Последний шаг — расставить правила в правильном порядке:

1. Правило web-публикации OWA
2. Правило переадресации пути на Exchange
3. Правило переадресации HTTP на HTTPS

Нажмите Apply для сохранения сделанных изменений в политике ISA-сервера, а затем в диалоговом окне Apply New Configuration нажмите OK.

Тестирование и анализ конфигурации

Теперь протестируем нашу конфигурацию, чтобы проверить, действительно правила, которые мы создали, защищают нас от невнимательных и упрямых пользователей, которые вводят неправильный путь или протокол. Проведем тест, используя следующие адреса:

• http://owa.msfirewall.org Это самый крайний вариант, когда пользователь вводит неправильный путь и неверный протокол
• https://owa.msfirewall.org В этом случае пользователь ввел правильный протокол, но поленился вводить путь полностью
• https://owa.msfirewall.org/exchange В этом случае ответственный пользователь ввел и правильный путь, и верный протокол.

Для первого теста введем в web-браузере адрес http://owa.msfirewall.org и нажмем ENTER. Появится экран с формой для аутентификации OWA. Вводим правильные данные и нажимаем Log On. Значения файла журнала в этом случае таковы:

Посмотрим, что произошло. Первый запрос вызывает к действию правило переадресации HTTP на HTTPS, которое делает переадресацию на http://redirect:https:/owa.msfirewall.org. Это отсылает пользователя к правилу переадресации пути на Exchange и создает форму для ввода учетных данных. После прохождения пользователем аутентификации автоматически запускается на выполнение правило web-публикации OWA, поскольку оно стоит выше других правил в политике и включает в себя правильный путь (на самом деле, OWA-сайт возвращает этот путь клиенту, вот почему пользователь не должен заново вводить учетные данные или адрес).

Теперь Мы протестируем второе правило, введя верный протокол, но неправильный адрес https://owa.msfirewall.org. Мы видим, что правило переадресации HTTP на HTTPS не сработало, а работает правило переадресации пути на Exchange. Затем запускается правило web-публикации OWA и пользователь получает доступ к сайту.

Мы не будем отдельно тестировать правило web-публикации OWA, поскольку в предыдущих примерах мы видели, что оно работает. Когда пользователи вводит правильный путь и протокол (https://owa.msfirewall.org/exchange), перед ними сразу возникает форма для ввода учетных данных и они получают доступ на сайт OWA.

Принудительная аутентификация на ISA-сервере

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

Если Вы не используете принудительную аутентификацию и форму для ввода учетных данных в правиле переадресации пути на Exchange, могут произойти непредвиденные вещи. Так, перед Вами может высветиться обычное диалоговое окно для аутентификации, а не форма для ввода учетных данных, созданная ISA-сервером. После ввода данных Ваш браузер зависнет в бесконечном цикле.

Однако если Вы не используете принудительную аутентификацию в правиле переадресации пути на Exchange, но используете форму для ввода учетных данных, перед Вами высветится обычное диалоговое окно для аутентификации, а затем — форма для ввода учетных данных. После регистрации в форме доступ на сайт откроется.

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

Резюме

В этой статье мы рассмотрели, что следует предпринят для помощи пользователям, которые вводят неправильный протокол и путь для доступа к сайту Outlook Web Access (OWA) сервера Exchange. Были созданы три правила: одно с помощью мастера OWA Web Publishing Rule Wizard, другое, которое переадресует на правильный адрес, если верный путь отсутствует (или же указанный путь неверный), и третье, которое переадресует запросы протокола HTTP на протокол HTTPS. Хотя переадресация может быть безопасно выполнена с использованием встроенных возможностей ISA-сервера, для переадресации и пути, и протокола одновременно требуется более серьезное решение. Эту проблему решает программа WebDirect. Также она предоставляет важную функциональность протоколу HTTP, которая отсутствует в стандартной установке ISA-сервера.

Источник  http://www.msexchange.org

• Wds служба развертывания
• K exchange servers как удалить
• Nat Windows 2003
• Ограничение времени выполнения хранимой процедуры oracle
• Уникальные шрифты