Sunday, July 22nd, 2018

Обеспечение Клиентам Outlook полного доступа повсюду, используя Secure Exchange RPC Filter (Фильтр Безопасного Обмена RPC) брандмауэра ISA

Published on Февраль 6, 2009 by   ·   Комментариев нет

Вы можете разрешить удаленным клиентам Outlook 2000/2002/2003 соединиться с вашим Exchange Server через Интернет и получите выгоду от полной функциональности, обеспеченной полным клиентам Outlook MAPI. В отличие от Outlook Web Access, выполняемые функции полного клиента Outlook MAPI позволяют удаленным пользователям получать выгоду от целого набора почтовых возможностей и возможностей программ для рабочих групп, обеспечивающихся Exchange Server. И, в отличие от Outlook RPC через HTTP, вам не надо использовать Exchange 2003 и вам не надо также использовать Outlook 2003.

Все это можно достичь, используя возможности публикации Secure Exchange RPC брандмауэра ISA. Вы можете защитить публикации Exchange RPC предоставлением удаленным пользователям доступа к полному набору Exchange Services, не довольствуясь второстепенным. На самом деле, когда происходит доступ к данным Exchange , все, кто угодно, только не полный клиент Outlook MAPI, чувствуют себя вторым сортом.

Несколько причин, по которым вы должны бы рассмотреть публикации Secure Exchange RPC:

  • Публикация сервисов Exchange RPC безопасна, потому что информация уровня приложений обеспечивается фильтром Exchange RPC

Это общее мнение, что соединения RPC не защищено и это является веским основанием. Червь Blaster поразил многих из нас пару лет назад, и это было ассоциировано с выходом RPC. Хорошая новость, что, когда вы используете фильтр Exchange RPC брандмауэра ISA для публикаций Exchange Server, риск, связанный с появлением RPC в Интернете, снижен.

Фильтр RPC поддерживает соединение между удаленным клиентом Outlook MAPI и внутренним Exchange Server и создает динамические пакетные фильтры, которые могут быть использованы указанными клиентами Outlook. В дополнении к защищенному динамическому пакетному фильтру Exchange RPC и интеллекту управления соединением, защищенный Exchange RPC фильтр позволяет только допустимые связанные с Exchange Server соединения RPC; все другие соединения выкидываются фильтром. Эта уникальная возможность найдена только в брандмауэрах ISA Server.

  • Соединение между клиентом Outlook MAPI и Exchange Server может быть шифровано, а нешифрованные соединения могут быть отклонены брандмауэром ISA

Клиент Outlook может быть сконфигурирован так, чтобы шифровать канал данных между ним и Exchange Server. Однако это конфигурация клиентской стороны и зависит от конфигурации клиента Outlook пользователем. Фильтр Secure Exchange RPC брандмауэра ISA позволяет вам принуждать удаленных клиентов Outlook MAPI использовать безопасное соединение. Небезопасное соединение, пытающееся прийти от клиента Outlook MAPI, будет удалено Secure Exchange RPC фильтром брандмауэра ISA.

  • Exchange RPC Server Publishing (Публикация Exchange RPC Server ) — это просто

Публикация Exchange RPC является простой. Одиночное Server Publishing Rule (Правило Публикации Сервера) разрешает вашим удаленным клиентам Outlook MAPI доступ к внутреннему Exchange Server. Вам не надо создавать Destination Sets (Множества Получателей) или специальные Protocol Definitions (Протокольные Определения). Встроенное в Exchange RPC Protocol Definition работает вместе с фильтром RPC для обеспечения защищенного безопасного правила публикации.

  • Доступ ограничен только почтовыми сервисами — нет доступа ко всей сети

В порядке обеспечения доступа пользователей к полному спектру сервисов Exchange Server до полного клиента Outlook MAPI, администраторы брандмауэра традиционно разрешают VPN-подключения к корпоративной сети. Недостаток разрешения VPN-подключений (через не-ISA брандмауэры, VPN-подключения через ISA брандмауэры подвергаются контролю уровня приложений) в том, что в порядке разрешения клиентам Outlook MAPI доступа эти VPN-клиенты получают доступ ко всей сети.

В действительности вы хотите, чтобы пользователи имели доступ к ресурсам Exchange Server, используя клиента Outlook MAPI, и ни к чему более. Вы не хотите открывать всю сеть только ради обеспечения доступа полного клиента Outlook MAPI к полному спектру сервисов Exchange Server. Возможности Secure RPC Publishing брандмауэра ISA разрешают клиентам Outlook MAPI полный доступ ко всем сервисам Exchange Server, требуемым удаленным пользователям без их доступа к любым другим ресурсам в сети.

  • Пользователи могут продолжать использовать их привычные клиенты Outlook 2000/2002/2003

Пользователи часто жалуются, когда они должны использовать другие почтовые приложения-клиенты для доступа к ресурсам Exchange, когда они перемещаются между корпоративной сетью и удаленным местонахождением. Пользователи предпочитают использовать одинаковые почтовые клиенты вне зависимости от их местонахождения, когда они стандартизованы на Outlook 2000/2002/2003. Публикация Exchange RPC дает им возможность использовать привычный интерфейс, который они используют на работе, когда подключаются из дома или с пути.

«Outlook Just Works» (Outlook работает исправно)

Я люблю сценарий «Outlook Just Works» (Outlook работает исправно), потому что я использую его все время. Я много путешествую и нуждаюсь в уверенности, что я получу в любое время и отовсюду доступ к Exchange Server в моем офисе. Мы представляем собой небольшую компанию, но это не подразумевает, что мы не может получать выгоду от тех же технологий, что используют большие парни! «Outlook Just Works» позволяет мне использовать полного клиента Outlook повсюду и я никогда не должен думать о своем местонахождении.

Здесь сценарий «Outlook Just Works»:

  • Я использую полного клиента Outlook MAPI в офисе на моем рабом месте. Я открываю Outlook и он исправно работает.
  • Я также использую полного клиента Outlook MAPI на моем портативном компьютере (laptop). Мой laptop подключается к Exchange Server по беспроводному соединению. Мы имеем беспроводную сеть, отделенную от основной сети созданием беспроводного сегмента DMZ в брандмауэре ISA. Я открываю Outlook и он исправно работает.
  • Теперь я должен ехать по делам в Бостон. Я приезжаю в аэропорт и мне нужно проверить мою почту, потому что я забыл мою схему (которая лежит в виде почтового сообщения на моем Exchange Server). Я открываю laptop, пока я в аэропорту, и подключаюсь к беспроводной сети аэропорта. Я открываю Outlook и он исправно работает.
  • Самолет приземляется в Бостоне и я еду в гостиничный номер. Гостиница имеет DSL подключение в каждой комнате. Подключаю laptop в широкополосную сеть гостиницы, открываю его и, затем, открываю Outlook. Он исправно работает.
  • У нас встреча в отведенном месте для клиентов и там есть беспроводная сеть. Я подключаюсь к их WLAN и открываю Outlook. Outlook исправно работает!

Ключ к сценарию «Outlook Just Works» в том, что все, что я должен сделать, это открыть Outlook, и он работал. Я не должен был думать о том, где я был, и делать каких-либо изменений в Outlook. Никакой переконфигурации на клиентской стороне, никаких манипуляций с настройками, никакой необходимости использовать OWA или что-нибудь еще. Это превосходно!

Как работает Безопасный Exchange RPC Publishing

Обычные удаленные клиенты Outlook MAPI устанавливают соединение к Интернету через местного ISP или широкополосное Интернет-подключение с общедоступным адресом. В обоих этих сценариях удаленному компьютеру присваивается общедоступный IP-адрес. Удаленный Outlook MAPI работает в обоих случаях.

Следующие коммуникации происходят когда открывается Outlook:

  1. Outlook устанавливает соединение к TCP порту 135 (оконечный mapper RPC) на внешнем интерфейсе брандмауэра ISA. В это соединение включен запрос с особым Universal Unique Identifiers (UUIDs) (Универсальный Уникальный Идентификатор) от Exchange Server.
  2. Фильтр Exchange RPC брандмауэра ISA перехватывает запрос и пересылает его Exchange Server внутренней сети. Однако, перед тем, как запрос будет перенаправлен к Exchange Server, фильтр Secure Exchange RPC выполняет проверку RPC протокола на RPC коммуникациях. Только допустимые RPC коммуникации проходят сквозь него к Exchange Server.
  3. Внутрисетевой Exchange Server отвечает на запрос посылкой номера порта, на который клиент Outlook может посылать свои сообщения. Фильтр Secure Exchange RPC брандмауэра ISA перехватывает эти запросы и открывает динамический пакетный фильтр на своем внешнем интерфейсе, который клиент Outlook MAPI может использовать для подключения к Exchange Server. Динамический пакетный фильтр связан с портом на внешнем интерфейсе брандмауэра ISA, на который могут подключаться только эти особенные клиенты Outlook. Никакие другие Интернет-host’ы не могут использовать этот порт для входящего доступа. Брандмауэр ISA отображает этот порт на своем внешнем интерфейсе на номер порта, с которого Exchange Server ожидает получать сообщения от Интернет-клиентов Outlook. Дополнительно, когда клиент Outlook начинает работу, он регистрирует порт, на который он может принимать сообщения с уведомлениями о новой почте от Exchange Server. RPC-фильтр брандмауэра ISA также регистрирует этот порт, создает динамический пакетный фильтр и передает сообщения с уведомлениями о новой почте от Exchange Server к Интернет-клиенту Outlook client.
  4. Брандмауэр ISA пересылает ответы от Exchange Server. Клиент Outlook получает номер порта на внешнем интерфейсе ISA Server, на который он может отправлять свои сообщения к Exchange Server.
  5. Клиент Outlook MAPI устанавливает соединение к отображенному порту на внешнем интерфейсе брандмауэра ISA и через этот порт подключается к внутрисетевому Exchange Server.

Рассмотрите следующую диаграмму, чтобы увидеть последовательность событий.

Доступ к outlook через интернет

Примечание: Для более глубокого технического объяснения того, как работает фильтр Exchange RPC, защищая трафик Windows, откройте http://www.microsoft.com/technet/prodtechnol/isa/2000/maintain/rpcwisa.mspx

Подготовка Сетевой Инфраструктуры для Публикации Exchange RPC

Есть несколько элементов сетевой инфраструктуры, которые должны быть заменены перед тем, как вы сможете выполнить успешный сценарий Публикации Exchange RPC. Эти сетевые элементы включают:

  • Поддержка DNS-инфраструктуры, которая позволяет клиенту Outlook MAPI корректно различать имя Exchange Server вне зависимости от своего местонахождения
  • Правила Протоколов DNS и SMTP, поддерживающих исходящие DNS- и SMTP-трафики от Exchange Server во внутреннюю сеть
  • Конфигурация Exchange Server, которая устанавливает метод отсылки аутентификации на Exchange Server
  • Конфигурации маршрутизатора NAT и брандмауэра для поддержки исходящих безопасных соединения Exchange RPC

Создание поддерживаемой инфраструктуры DNS

Инфраструктура DNS должна быть разработана таким образом, чтобы позволять клиенту Outlook MAPI корректно различать имя Exchange Server вне зависимости от его месторасположения. Пользователь никогда не должен переконфигурировать настройки клиента Outlook MAPI для поддержки текущего местонахождения. Outlook должен «исправно работать» вне зависимости от текущего местонахождения клиента. Прозрачность разрешения имени — это ключ к претворению в жизнь сценария «Outlook исправно работает» для вашей организации.

Идеальная конфигурация DNS для поддерживающих хостов, что перемещают между корпоративной сетью и удаленными местами — это разделенный DNS. Разделенная инфраструктура DNS требует, чтобы вы поддерживали две раздельные зоны DNS, которые контролируют один и тот же домен.

Одна из этих зон поддерживает клиентов внутренней сети, а другая зона поддерживает клиентов внешней сети. Эти две зоны DNS обслуживают один и тот же домен или домены. Различие в том, что записи ресурсов на внутренней зоне DNS имеют личные IP-адреса Exchange Server(s), а внешняя зона имеет публичный IP-адрес, чтобы удаленные пользователи имели доступ для подключения к вашему Exchange Server(s).

Например, если Exchange Server имеет имя exchange.domain.com во внутренней сети, вам надо убедиться, что exchange.domain.com также доступен для хостов внешней. Вы можете достигнуть этого с раздельной конфигурацией DNS созданием записи о Host (A) для exchange.domain.com на вашем внешнем DNS сервере так, что он отображает адрес на внешнем интерфейсе ISA Server, который вы используете правилом публикации Exchange RPC.

Разделение DNS требует включать имена всех ваших Exchange Servers. В действительности, любой сервер содержащий информацию, требуемую удаленного доступа, должен быть включен в DNS. Например, если ваша организация имеет два Exchange Server, exchange.domain.com и exchange2.domain.com, вам следовало бы включить оба сервера в раздельный DNS и отобразить их на IP-адреса, которые вы используете на брандмауэре ISA для публикации их посредством Secure Exchange RPC. Вам нужно создать Server Publishing Rule (Серверное Правило Публикации) для каждого компьютера, владеющего пользовательскими почтовыми ящиками.

Если ваша организация не использует одинакового доменного имени для ресурсов, которые доступны и из внутри и снаружи, то вы можете все же получить доступ к Exchange Server через правила публикации RPC, используя распознавание локального host-имени, которое обходит потребности DNS-сервера.

Проблема с решением файлом HOSTS в том, что это все не очень масштабируемо и применимо только для сред типа SBS или там, где ваши пользователи технически грамотны. Вам нужно в файле HOSTS создать запись с NetBIOS-именем компьютера с Exchange Server (иногда ссылающимся как «имя компьютера»). Вам не нужно включать FQDN (полное доменное имя компьютера) Exchange Server в файл HOSTS; требуется только NetBIOS-имя.

Примечание: Часть имени хоста (самая левая надпись) полного доменного имени компьютера должна быть такая же, как и имя компьютера с Exchange Server, опубликованного с помощью Exchange RPC Server Publishing Rule. Клиент Outlook MAPI должен быть сконфигурирован на использование имени компьютера Exchange Server и должен быть способен корректно уточнять это имя полностью. Дополнительно, компьютер клиента Outlook должен использовать первичное доменное имя или доменное имя, зависящее от адаптера, что позволит клиенту корректно полностью уточнять имя NetBIOS для Exchange Server.

Как указано в примечании сверху, есть небольшая хитрость при распознавании имени, зависящая от версии используемого вами Outlook. Это проявляется в том, что Outlook 2003 более «Интернет-направленный» и соблюдает использование FQDN, но прежние версии Outlook требуют, чтобы host-компьютер был способен корректно уточнять неточные имена. Если кажется, будто я немного расплывчит в этом, то да, так и есть.

Создание правил для DNS и SMTP протоколов

Exchange Server нуждается в пересылки почты, полученной им от клиентов Outlook MAPI, к серверам SMTP в Интернете. Могут потребоваться Правила Доступа, позволяющие выходящий доступ к следующим протоколам:

  • DNS (TCP и UDP 53)
  • SMTP (TCP 25)

Правила Доступа к DNS позволяют сервису Exchange SMTP определять доменные имена почтового обмена. Вы можете сконфигурировать Правила Доступа для разрешения доступа к нему только Exchange Server или для разрешения всем компьютерам в сети использовать его.

Управление доступом по Правилу Доступа DNS зависит от того, который компьютер отвечает за поддержку доменных имен почтового обмена. Вы можете захотеть пересылать DNS-запросы от Exchange Server на внутренний DNS-сервер и позволять DNS-серверу в вашей сети заботится о разрешении имен.

Правило Доступа SMTP требуется, чтобы Exchange Server отсылал почту внешним почтовым доменам. Управление доступом по Правилу Протокола SMTP зависит от того, какой компьютер реально отправляет почту внешним SMTP-серверам.

Если Exchange Server отправляет почту непосредственно в Интернет SMTP-серверам, разрешается только Exchange Server доступ к Правилу Протокола SMTP. Если вы используете выходной SMTP ретранслятор, то разрешается ретранслятору доступ к Правилу Протокола SMTP. Если вы используете почтовый ретранслятор, убедитесь, что сервер ретранслятора SMTP также хорошо имеет доступ к Правилу Протокола DNS, так как это понадобится для разрешения почтовых доменов MX Интернета. Исключением из этого требования является то, что если SMTP ретранслятор (или Exchange Server) сконфигурирован для использования внутреннего DNS-сервера, то разрешается только внутреннему DNS-серверу разрешать имена Интернет-хостов.

Конфигурирование метода аутентификации

Когда клиент Outlook регистрируется на Exchange Server, то Exchange Server приказывает клиенту Outlook MAPI идентифицироваться в контроллере Active Directory домена. Однако, Active Directory напрямую недоступен для удаленных хостов. Вы можете избежать этой проблемы настройкой Exchange Server на замещение идентификации клиента Outlook MAPI.

Двигайтесь до следующего ключа в реестре для конфигурирования Exchange Server на замещение запросов идентификации для клиентов Outlook MAPI:

HKLM\System\CurrentControlSet\Services\MSExchangeSA\Parameters

Добавьте следующее:
Value (Параметр): No RFR Service
Type (Тип): REG_DWORD
Data (Значение): 1

Заметьте, что параметр (No RFR Service) имеет пробелы внутри. Перезапустите Exchange Server после добавления параметра. Перезапустите Exchange Server после выполнения этого изменения.

Клиенты Outlook MAPI позади NAT Маршрутизаторов/Брандмауэров/ISA Серверов

Если клиент Outlook находится позади маршрутизатора NAT или обычного брандмауэра, основанного на NAT, то он не будет способен получать извещения о новой почте или вообще не будет способен соединиться с Exchange Server. Некоторые ISP (провайдеры интернет-услуг.) с их бесконечной мудростью решили, что с тех пор, как прорвался Blaster, нет причин разрешать внешние TCP 135 сквозь их сеть. Это блокирует подключения клиентов Outlook MAPI к оконечным точкам RPC. Мое мнение, что это плохое решение этой части ISP, так как если они хотят блокировать порты для предотвращения деяний, им надо блокировать порты 25 и 80.

Запросы на уведомления о новой почте не ассоциированы с существующими сессиями RPC между клиентом Outlook MAPI и Exchange Server. Поэтому информационные сообщения о новой почте выглядят для брандмауэра как невостребованные внутренние запросы, и маршрутизатор/брандмауэр NAT выкинет этот пакет.

Если клиент Outlook MAPI находится позади сложного семиуровневого брандмауэра, такого как ISA firewall, то клиент Outlook MAPI будет способен принимать прямые оповещения, когда прибывает новое сообщение. Клиенты Outlook MAPI, расположенные позади ISA firewall не имеют проблем с приемом информационных сообщений о новой почте.

Для внешних подключений сквозь брандмауэр ISA, клиент Outlook MAPI может использовать новый и улучшенный RPC Protocol Definition (Протокольное Определение), который связан с фильтром приложений ISA RPC. Этот фильтр разумно управляет соединениями между клиентом Outlook MAPI и Exchange Server. Разумное управление соединением позволяет перейти уведомлениям о новой почте, исходящим от Exchange Server к удаленному клиенту Outlook MAPI, расположенному позади брандмауэра ISA.

Это не означает, что вы никогда не получите никакой новой почты, если клиент Outlook MAPI находится позади маршрутизатора NAT или простого брандмауэра, основанного на NAT. Если вы посылаете почту на Exchange Server, уведомление о новой почте будет передано через активный канал RPC.

Однако если возникнет ошибка в каком-либо из пакетов RPC, несущих уведомление о новой почте, уведомительное сообщение не достигнет клиента Outlook MAPI, расположенного позади маршрутизатора NAT или обычного брандмауэра. Вы можете обойти это, щелкнув на любом файле или папке или нажав кнопку Send/Receive в Outlook 2000 или вы можете сконфигурировать клиента Outlook 2002/2003 для осуществления автоматической отправки/получения каждые несколько минут на заднем плане.

На практике, я натолкнулся на несколько проблем на этом пути. За последний год я потратил много времени на поиски гостиниц и конференц-центров, которые принимали во внимание факт, что «блокировка портов» не является самым разумным решением сетевой безопасности. Однако, за последние несколько месяцев, я нашел даже, что когда я даю личный адрес, провайдеры широкополосных сервисов разрешают уведомлениям о новой почте нормально проходить. Может быть, они используют брандмауэр ISA? Или, может быть, они используют не-ISA брандмауэр/NAT-устройство с повышенным разумом RPC замещения. Однако, факт, наш сценарий «Outlook Just Works» снова работает где-то на до-Blaster’ных уровнях.

Хорошая новость, что все остальное (кроме сообщений уведомлений о новой почте) работает прекрасно, когда клиенты Outlook находятся позади маршрутизатора NAT или обычного брандмауэра. Если вы используете Windows 2000 или Windows Server 2003 RRAS NAT сервис, не требуется никакой конфигурации для Протокола Маршрутизации NAT. Если здесь есть маршрутизатор NAT перед клиентом Outlook MAPI, требуется редактор RPC NAT. Большинство маршрутизаторов NAT имеют установленный редактор RPC NAT.

Если обычный фильтрующий пакеты брандмауэр находится спереди от клиента Outlook MAPI, администратору брандмауэра требуется конфигурировать простой брандмауэр для разрешения основного соединения на TCP 135 и, затем, вторичных соединений, входящих в и выходящих из всех кратковременных портов. Эти вторичные соединения являются частью подобной «соединительной связки» и частью сессии уровня приложений, поддерживаемой первичным соединением.

Если вы используете брандмауэр ISA, вы можете создать простое Правило Доступа, позволяющее клиенту Outlook MAPI выходящий доступ сквозь брандмауэр.

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

  1. Откройте консоль управления Microsoft Internet Security and Acceleration Server 2004 и раскройте имя сервера. Щелкните узел Firewall Policies. Выберете страницу Tasks на панели задач и затем щелкните ссылку Create New Access Rule.
  2. На странице Welcome to the New Access Rule Wizard введите имя для правила в поле Access Rule name. В нашем примере, введите Outbound Exchange RPC. Нажмите Next.
  3. На странице Rule Action выберете опцию Allow и нажмите Next.
  4. На странице Protocols выберете опцию Selected protocols в выпадающем списке This rule applies to . Нажмите кнопку Add.
  5. В диалоговом окне Add Protocols щелкните папку All Protocols. Сделайте двойной щелчок на протоколе RPC (all interfaces). Нажмите Close.

    Доступ к outlook через интернет

  6. Нажмите Next на странице Protocols.

    Доступ к outlook через интернет

  7. На странице Access Rule Sources нажмите кнопку Add.
  8. В диалоговом окне Add Network Entities щелкните папку Networks и, затем, дважды щелкните Internal. Нажмите Close.
  9. Нажмите Next на странице Access Rule Sources.

    Подключения к exchange server

  10. На странице Access Rule Destinations нажмите Add.
  11. В диалоговом окне Add Network Entities щелкните папку Networks и, затем, дважды щелкните элемент External. Нажмите Close.
  12. Нажмите Next на странице Access Rule Destinations.
  13. На странице Users Sets примите элемент по умолчанию All Users и нажмите Next.
  14. Нажмите Finish на странице Completing the New Access Rule Wizard.
  15. Новое правило появится на вкладке Firewall Policy на панели детализации.

Создание Exchange RPC Server Publishing Rule (Правила Публикации Exchange RPC Server)

Exchange RPC Server Publishing Rule использует Protocol Definition обеспеченное фильтром приложений RPC. Если вы запретите Application Filter (Фильтр Приложений), вы потеряете Protocol Definition, поэтому убедитесь, что фильтр разрешен. Вы можете проверить состояние RPC Filter в узле Add-ins, находящемся под узлом Configuration на левой панели консоли управления Microsoft Internet Security and Acceleration Server 2004.

Не забудьте создать Secure Exchange RPC Server Publishing Rule для каждого Exchange Server поддерживающего почтовые ящики. Например, если вы имеете четыре Exchange Server, поддерживающие почтовые ящики пользователей, вам надо будет публиковать каждый из этих Exchange Servers. Заметьте, что если вы имеете входной Exchange Server, то вам не нужно опубликовывать этот входной Exchange Server, так как он не замещает реальные протоколы RPC. В противоположность, входной Exchange Server может замещать RPC соединения, проходящие сквозь HTTP, (RPC через HTTP).

Выполните следующие шаги для создания безопасного Server Publishing Rule для доступа клиента Outlook MAPI:

  1. В консоли управления Microsoft Internet Security and Acceleration Server 2004 раскройте имя сервера на левой панели и затем выберете вкладку Tasks на Панели задач. Нажмите ссылку Create a New Server Publishing Rule.
  2. На странице Welcome to the New Server Publishing Rule Wizard введите имя для правила в поле Server publishing rule name. В этом примере, введите Publish Secure Exchange RPC. Нажмите Next.
  3. На странице Select Server введите IP-адрес сервера Exchange Server в поле Server IP address. Нажмите Next.
  4. На странице Select Protocol нажмите стрелочку вниз в списке Selected protocol. Выберете элемент Exchange RPC Server. Заметьте, чтобы фильтровались входящие SMTP сообщения на спам и ключевые слова, вы должны использовать SMTP Message Screener. Нажмите Next.

    Порты exchange mapi

  5. На странице IP Addresses выберете элемент External и нажмите Address. Нам надо выбрать специальный External (Внешний) адрес, потому что сетевой адаптер на внешней границе рассматривается в это время, как внешний адаптер.

    Порты exchange mapi

  6. В диалоговом окне External Network Listener IP Selection выберете опцию Specified IP addresses on the ISA Server computer in the select network. В списке Available IP Addresses щелкните IP-адрес на внешнем интерфейсе компьютера брандмауэра ISA Server 2004. В нашем примере, щелкните 192.168.1.70. Нажмите Add. Теперь адрес появится в списке Selected IP Addresses. Нажмите OK.

    Порты exchange mapi

  7. Нажмите Next на странице IP Addresses.

    Доступ к exchange из интернета

  8. Нажмите Finish на странице Completing the New Server Publishing Rule Wizard.

Новое Server Publishing Rule появится в списке Firewall Policy на Details Pane (панели детализации).

Конфигурирование Outlook 2003 Client для подключения через Secure Exchange RPC

Вы можете протестировать безопасный Exchange RPC Server Publishing Rule используя любую версию клиента Microsoft Outlook MAPI. В этом примере мы будем тестировать это правило, используя клиента Outlook 2003. MAPI клиенты Outlook 2000 и Outlook 2002 конфигурируются точно также.

В этой репетиции мы будем использовать файл HOSTS для отображения IP-адреса Exchange Server на внешний адрес на компьютере брандмауэра ISA Server 2004.

Примечание: В производственной среде, Вам лучше бы использовать разделенную инфраструктуру DNS для поддержки распознавания имени для клиента Outlook MAPI. Разделенная инфраструктура DNS — это предпочтительный метод разрешения имен для организаций, которые поддерживают компьютеры, которые перемещаются между внутренней и внешней сетями, и требуется поддержка решения безопасной публикации Exchange RPC Server.

Выполните следующие шаги для создания записи в файле HOSTS на компьютере EXTCLIENT (которое является именем MAPI клиента Outlook 2003 в этом примере):

  1. Выполните щелчок правой кнопкой мыши на Start и выберете Explore.
  2. Переместитесь в \systemroot\system32\drivers\etc и откройте файл HOSTS, используя Notepad.В Notepad, добавьте следующую строку в список отображенных адресов:

    192.168.1.70 exchange2003be.msfirewall.org

  3. Этот элемент отобразит имя компьютера Exchange Server, используемого в нашем примере, на IP-адрес на внешнем интерфейсе брандмауэра ISA Server 2004, используемого безопасным Exchange RPC Server Publishing Rule для приема входящих соединений. Убедитесь, что нажали ENTER после добавления строки, чтобы курсор вставки указывал на следующую строку. Иначе отображаемое имя не сохранится.

    Доступ к exchange из интернета

    Закройте Notepad и сохраните изменения.

  4. Откройте командную строку, введите ipconfig /displaydns и нажмите ENTER. Вы должны увидеть, что отображаемое имя, введенное вами в файл HOSTS, сразу же появилось.

Конфигурирование Outlook 2003 Client

Следующий шаг — это конфигурирование профиля Outlook, который подключается к Exchange Server. Выполните следующие шаги для конфигурирования профиля Outlook:

  1. Нажмите Start и затем правой кнопкой мыши щелкните на иконке E-mail Microsoft Office Outlook. Выберете Properties.
  2. В диалоговом окне Mail нажмите кнопку Add.
  3. В диалоговом окне New Profile введите Administrator в поле Profile Name. Нажмите OK.
  4. На странице E-mail Accounts выберете опцию Add a new e-mail account и нажмите Next.
  5. На странице Exchange Server Settings введите NetBIOS-имя Exchange Server в поле Microsoft Exchange Server. Отметьте поле Use Cached Exchange Mode. Введите Administrator в поле User Name. Нажмите Check Name.
  6. Заметьте, что это имя Microsoft Exchange Server изменяется до полного доменного имени Exchange Server. Нажмите кнопку More Settings.

    Клиент exchange

  7. В диалоговом окне Microsoft Exchange Server выберете страницу Security. На странице Security отметьте поле Encrypt data between Microsoft Office Outlook and Microsoft Exchange Server. Нажмите Apply и затем нажмите OK.

    Клиент exchange

  8. Нажмите Next на странице Exchange Server Settings.
  9. Нажмите Finish на странице Congratulations!.
  10. Нажмите OK в окне диалога Mail.

Теперь мы готовы выполнить подключение к Microsoft Exchange Server посредством безопасного Exchange RPC Server Publishing Rule. Выполните следующие шаги для подключения:

  1. Нажмите Start и щелкните E-mail Microsoft Office Outlook.
  2. В диалоговом окне Choose Profile подтвердите, что Administrator появился в поле Profile Name и нажмите OK.
  3. Введите msfirewall\Administrator в поле User name в диалоговом окне Connect to. Введите пароль Администратора в поле Password. Нажмите OK.
  4. Почтовый ящик Administrator открыт в Outlook.

Итог

Нет причин, по которым ваши пользователи должны бы постоянно быть без их полного клиента Outlook MAPI. Когда вы принесли брандмауэр ISA в вашу организацию, сконфигурировали Secure Exchange RPC Server Publishing Rules (Правила Публикации RPC Сервера Безопасного Обмена) и начали сочетать это с промышленным стандартом разделенной DNS инфраструктуры, ваши пользователи осознали всю мощь услуг, которые хлынули из сценария «Outlook Just Works» (Outlook работает исправно). Мы используем его каждый день, и то же самое делают наши клиенты. Попробуй это и ты убедишься сам! Эта статья подтверждает все в подробностях.

Источник www.isaserver.org





Смотрите также:

Tags: , , , , , , , ,

Readers Comments (Комментариев нет)




Да человек я, человек! =)

Exchange 2007

Проведение мониторинга Exchange 2007 с помощью диспетчера System Center Operations Manager 2007 (часть 3)

Если вы хотите прочитать предыдущие части этой серии статей, перейдите по ссылкам: Проведение мониторинга Exchange 2007 с помощью диспетчера System ... [+]

Практическое рассмотрение перехода с Exchange 2003 на Exchange 2007 (часть 1)

Введение В этой статье из нескольких частей я хочу показать вам процесс, который недавно использовал для перехода с существующей среды Exchange 2003 ... [+]

Использование инструмента Exchange Server Remote Connectivity Analyzer Tool (часть 2)

Если вы пропустили первую часть этой серии, пожалуйста, прочтите ее по ссылке Использование инструмента Exchange Server Remote Connectivity Analyzer Tool (Часть ... [+]

Мониторинг Exchange 2007 с помощью диспетчера System Center Operations Manager 2007 (часть 2)

Если вы пропустили предыдущую часть этой серии статей, перейдите по ссылке Мониторинг Exchange 2007 с помощью диспетчера System Center Operations ... [+]

Подробное рассмотрение подготовки Active Directory для Exchange 2007 (часть 5)

Если вы пропустили предыдущие части этой серии статей, перейдите по ссылкам: Подробное рассмотрение подготовки Active Directory для Exchange 2007 (часть 1) ... [+]

Установка и настройка Exchange 2007 из командной строки (Часть 3)

If you missed the previous parts in this article series please read: Exchange 2007 Install and Configuration from the command line (Part ... [+]

Использование инструмента Exchange Server Remote Connectivity Analyzer Tool (часть 1)

Инструмент ExRCA Текущий выпуск инструмента предоставляется только в целях тестирования и оснащен 5 опциями: Тест подключения Outlook 2007 Autodiscover Тест подключения Outlook 2003 RPC ... [+]

Развертывание сервера Exchange 2007 Edge Transport (часть 5)

Если вы хотите прочитать предыдущие части этой серии статей, перейдите по ссылкам: Развертывание сервера Exchange 2007 Edge Transport (часть 1) Развертывание ... [+]

Установка и настройка Exchange 2007 из командной строки (часть 2)

Если вы пропустили первую статью данного цикла, пожалуйста, перейдите по ссылке: Exchange 2007 Install and Configuration from the command line (Part ... [+]

Использование интегрированных сценариев Using Exchange Server 2007 – часть 2: генерирование отчетов агента Transport AntiSpam Agent

Если вы пропустили предыдущую часть этой серии статей, перейдите по ссылке Использование интегрированных сценариев Using Exchange Server 2007 – часть ... [+]