Публикация Exchange 2007 OWA, Exchange ActiveSync и RPC/HTTP с помощью 2006 ISA Firewall (Часть 1)

Публикация веб-служб Exchange 2007, расположенных на сервере Exchange Client Access Server (CAS), довольно проста. Другими словами, весьма проста настройка ISA Firewall. Загвоздка в том, чтобы догадаться, как настроить Exchange Server для того, чтобы он поддерживал безопасный сценарий удаленного доступа. В отличии от Exchange Server 2003, где все, от инсталляции и настройки до назначения сертификатов, было легким и понятным, в Exchange 2007 имеется запутанная и исключительно сложная установка, настройка и процесс назначения сертификатов. Моя цель – немного упростить это для вас и помочь вам пробраться сквозь минные поля, которые вы встретите по дороге.

Несмотря на то, что я много часов изучал этот проект, чтобы заставить его работать, я должен представить вам два важных источника информации, что помогли мне понять, как опубликовать службу Client Access Server OWA, службу Exchange ActiveSync и RPC/HTTP. Этими источниками являются:

• Встроенный файл справки по Exchange Server 2007. По большей части справка была весьма полезна на первых порах, позволив избежать возможных проблем с настройкой. Однако я нашел ее не очень-то полезной при переходе к более сложным вопросам конфигурации, таким как удаленный доступ к общим файлам через OWA.
• Официальный документ команды разработчиков ISA Firewall, посвященный тому, как опубликовать Exchange 2007 вместе с ISA 2006, который вы можете найти здесь: Publishing Exchange Server 2007 with ISA Server 2006

Несмотря на то, что эти источники были очень полезны в деле указания мне правильного направления, они не предоставляли достаточно информации, чтобы создать полностью работающее решение, даже просто работающее решение в тестовом окружении. Я надеюсь, что к тому времени, как вы закончите читать эту часть о том, как опубликовать Exchange 2007 Client Access Server, чтобы позволить защищенный удаленный доступ к веб-службам Exchange, у вас будет полностью работающее тестовое решение и, что более важно, вы будете понимать, как все это работает, так что сможете подстроить это решение под свои производственные нужды.

На рисунке ниже показано тестовое окружение, с которым мы будем работать. Есть несколько вещей, на которые я должен обратить ваше внимание:

• Эта конфигурация не является ни предпочтительной, ни той, что я бы разместил в продуктивном окружении. Причина в том, что Client Access Server должен быть размещен в зоне DMZ с авторизированным доступом, в зоне безопасности, отделенной от серверов без выхода в Интернет. Вы можете спросить: «Том, зачем ты тратишь мое время, рассказывая о не одобренном тобой сценарии, почему бы просто не пропустить это и не показать мне, как нужно публиковать Client Access Server?» Причина, по которой я еще не сделал это, в том, что я пока что не определил, какие протоколы требуется для связи между Client Access Server, почтовым сервером и транспортным сервером-концентратором. Когда я узнаю это, я выпущу новую статью. Еще одной причиной, почему я рассказываю об этом сейчас, будет то, что многие и так игнорируют лучшие решения с точки зрения безопасности (потому что веб-сайт Microsoft не расхваливает их), и таким образом эти ребята уже смогут сделать что-либо с помощью информации из этой серии.
• В этом сценарии не используется Edge Server. При защищенной организации производства его разместили бы в зоне DMZ с анонимным доступом. Опять же, я не знаю, какие протоколы нужны Edge Server для соединения с транспортным сервером-концентратором, так что вам придется подождать объяснений до следующей статьи.
• В этом сценарии не используется выделенный транспортный сервер-концентратор. И транспортный сервер-концентратор, и почтовый сервер установлены на одном и том же компьютере.
• Я не буду рассказывать о действиях, необходимых для публикации служб Exchange IMAP4/S или POP3/S. Здесь нет графического интерфейса для настройки этих служб, что является огромной дырой в управлении Exchange Server. Возможно, я расскажу об этих проблемах в будущем, но пока что мы подождем, пока Exchange 2007 SP1 не исправит эту грубую ошибку. Давайте помолимся, чтобы они сделали запрос сертификата и его назначение для служб POP3 и IMAP4 легче, чем это сделано для веб-служб Client Access Server.
• Я не буду рассказывать о действиях, необходимых для публикации SMTP или SMTPS. Причина в том, что я еще не до конца понимаю, как Exchange 2007 использует SMTP. В отличие от Exchange 2003, где вы могли с легкостью настроить доступную службу IIS SMTP, большая часть «службы» SMTP (Я поставил «службу» в кавычки, поскольку на самом деле службы SMTP в Exchange 2007 нет) в Exchange 2007 скрыта за интерфейсом Powershell, которого я стараюсь всеми силами избегать
• Я не буду рассказывать о функции OWA, включающей доступ к общим файлами сети и библиотекам SharePoint. Я пытался заставить ее работать, но там должны быть какие-то незадокументированные действия, необходимые для работы этой функции. Мне стыдно, поскольку я думаю, что это была бы очень крутая возможность, если бы она действительно работала.

Если вы фанат командной строки, то вас будут раздражать мои комментарии и критика в этой серии, посвященной публикации веб-служб Exchange 2007 Client Access Server. Я твердо убежден, что «метод Microsoft» заключается в том, чтобы делать программное обеспечение легким в использовании, и отказ от функциональности в управлении, что была в предыдущих версиях, не согласуется с методом Microsoft. Мне хочется, чтобы команда разработчиков Exchange вынудила меня взять свои слова назад, включив всю недостающие функциональные средства в SP1. Я недоволен, когда мне приходится ругаться из-за программ Microsoft – я хочу, чтобы они работали, я хочу, чтобы они легко настраивались и я хочу, чтобы они получали восторженные отзыва за свою высокую функциональность и легкость в использовании. Однако Exchange 2007 RTM не соответствует этим критериям.

Теперь, когда с шумными речами покончено, снова взглянем на рисунок ниже. Это все виртуальные компьютеры, работающие на VMware 5.5.

Рисунок 1

Краткое описание каждого компьютера:

• DC Этот компьютер является контроллером домена в домене msfirewall.org. Все компьютеры в этом сценарии – часть домена msfirewall.org. Дополнительно к роли контроллера домена, этот компьютер также является сервером DHCP, сервером DNS, интегрированным с Active Directory, сервером WINS, Microsoft Certificate Server и сервером RADIUS. Хотя RADIUS не используется в сценарии, обсуждаемом в этой части.
• EXCH2007MB Это компьютер под управлением Windows Server 2003 SP2, выполняющий роль почтового сервера Exchange 2007 и транспортного сервера-концентратора. На нем не установлено других служб, кроме тех, что требуются для установки Exchange Server.
• EXCH2007CAS Это компьютер под управлением Windows Server 2003 SP2, выполняющий роль Client Access Server Exchange 2007. На нем не установлено других служб, кроме тех, что нужны при установке Exchange.
• ISA2006SE Это компьютер под управлением Windows Server 2003 SP2 с установленным ISA 2006 Standard Edition. На нем установлены все обновления, доступные на Microsoft Update. Это важно, потому что имеется критическое обновление для ISA 2006, требующееся для публикации веб-служб Exchange. Это обновление доступно на сайте Microsoft Update, и обозначено как обновление ISA Server. Кроме того, на компьютере был установлено исправление RSS, на тот случай, если это могло вызвать затруднения.
• VISTA Это компьютер под управлением Vista RTM. На самом деле я был совсем не уверен, использовать ли мне для этого примера Vista или же Windows XP SP2. Но я подумал, что если будут какие-либо проблемы и затруднения с конфигурацией, они скорее появятся в Vista чем в Windows XP SP2, так что я решил использовать Vista, чтобы увидеть, какие проблемы могут возникнуть.

Чтобы помочь вам привести ваше тестовое окружение в такой же вид, я привел таблицу ниже, содержащую важные аспекты конфигурации компьютеров для каждой виртуальной машины в этом сценарии.

Тут я должен заметить, что вам нужно полностью установить и настроить ваш ISA Firewall, перед тем как устанавливать серверы Exchange. Причина в том, что вам будет нужен доступ в Интернет, чтобы скачать все требуемые файлы, которые не включены на DVD Exchange Server. Я просто создал единственное правило доступа, позволяющее исходящий доступ для всех протоколов из внутренней сети во внешнюю сеть. Однако если вы хотите сделать все как следует, вам стоит позволить исходящий DNS с компьютера DC, и исходящий HTTP и HTTPS трафик с компьютеров EXCH2007MB и EXCH2007CAS. Вы должны иметь возможность скачивать обновления для ISA Firewall с сайта Windows Update, используя правила системной политики, данные по умолчанию, так что нет нужды в каких-либо изменениях ISA Firewall для поддержки обновлений. Все машины в сети настроены как клиенты SecureNET.

В этом сценарии мы произведем над компьютерами следующие действия:

• Настроим DNS для поддержки перемещающихся пользователей.
• Инсталлируем роли почтового сервера Exchange 2007 и транспортного сервера-концентратора на компьютер EXCH2007MB. Мы обсудим действия, необходимые для инсталляции. Это не так просто, как вы думаете!
• Настроим компьютер, используемый как почтовый сервер и транспортный сервер концентратор с помощью встроенного файла помощи. После установки ролей почтового сервера и транспортного сервера-концентратора мы воспользуемся встроенным руководством, чтобы выполнить первоначальные настройки. Заодно мы отключим новую функцию «back pressure», чтобы все это правильно работало на виртуальной машине.
• Установим Exchange 2007 Client Access Server на компьютер EXCH2007CAS. Мы обсудим действия, необходимые для установки Client Access Server на этот компьютер. Опять же, это будет не так просто, как вы думаете!
• Настроим Exchange 2007 Client Access Server, используя информацию, взятую из встроенного файла помощи. Мы обсудим действия, описанные во встроенном руководстве по роли Client Access Server.
• Выполним дополнительные шаги по настройке Exchange 2007 Client Access Server, включая запрос сертификата, инсталляцию сертификата, настройку прав доступа, настройку RPC/HTTP и другое. Есть несколько настроек, которые мы должны тут выполнить, чтобы заставить нашу конфигурацию работать, и не все они задокументированы!
• Настроим клиент Outlook 2007. Настройка клиента Outlook 2007 очень похожа на настройку клиента Outlook 2003. Однако в этом сценарии я не настраиваю Exchange, используя специальные папки, которые может использовать только Outlook 2007.

Наконец, я должен обратить ваше внимание на то, что я использую 32-хбитную пробную версию Exchange. Причина заключается в том, что хоть VMware и поддерживает работу 64-битных компьютеров на 32-хбитных операционных системах, процессор, если это Intel, должен поддерживать VT. Это означает, что ваш процессор должен быть Pentium D серии 900 или новее. К сожалению, мой — Pentium D 820.

Внимание: Кошмарный сценарий публикации Exchange

Прежде чем мы перейдем к обсуждению DNS для нашей конфигурации, я должен обратить ваше внимание на сценарий, который вы никогда не должны использовать. Это то, что я называю кошмарным сценарием публикации Exchange. На рисунке ниже показана его топология.

Рисунок 2

В этом сценарии ISA Firewall отделен от внутренней сети третьим брандмауэром. Как показано на рисунке выше, уставлено два «железных» брандмауэра, один на краю корпоративной сети, и внутренний брандмауэр перед корпоративной сетью. Зона DMZ видна на внутреннем «железном» брандмауэре, где расположен единственный сетевой интерфейс «мертвого» ISA Firewall. У этого дизайна есть несколько серьезных недостатков:

• Внутренний «железный» брандмауэр представляет собой ненужное уязвимое звено
• Внутренний «железный» брандмауэр также является для вас еще одним шансом неправильно настроить брандмауэры, что считается наиболее распространенной причиной проблем безопасности, связанных с ними
• ISA Firewall подвержен слабостям в системе защиты внутреннего «железного» брандмауэра. Быстрый просмотр сайта http://www.secunia.com/ показывает, что ISA Firewall (2004 и 2006) не имеет проблем безопасности. Сравните это с любым «железным» брандмауэром и вы увидите, что ISA Firewall безопасней любого другого аппаратного брандмауэра

В одном из вариантов этого кошмарного сценария «мертвый» ISA Firewall расположен в зоне DMZ между «железными» брандмауэрами, это то, что я называю «мертвым сэндвичем». Проблема в этом сценарии, как и в изображенном на рисунке, в том, что ISA Firewall, поставленный в «мертвый» режим, обесценивает весь набор брандмауэров. Нет технических причин для расположения такого рода. Единственной причиной может быть либо политика, либо незнание. Если вы хотите, или вам нужно использовать внутренний брандмауэр, разместите ISA Firewall как можно ближе к ресурсам, нуждающимся в защите, так как брандмауэр, обеспечивающий наибольшую безопасность, должен быть ближе всего к защищаемому ресурсу, а ISA Firewall, скорее всего, наиболее безопасный брандмауэр в этом сценарии.

Настройка DNS для поддержки перемещающихся пользователей

В большинстве компаний есть пользователи, которые входят и выходят из корпоративной сети, используя одни и те же устройства, по большей части ноутбуки. Эти пользователи должны иметь доступ к сайтам OWA и RPC/HTTP, равно как и к сайту ActiveSync, без того, чтобы перенастраивать свои устройства для использования другого имени. Мы можем сделать это, используя инфраструктуру с раздельным DNS. При работающем раздельном DNS доступ к этим страницам для пользователей прост и открыт; им не приходится перенастраивать свои клиентские приложения, чтобы достигнуть той информации, что им нужна.

Чтобы решить эту проблему, мы используем раздельный DNS. При его использовании, одно и то же доменное имя располагается на двух разных DNS серверах, относящихся к разным DNS зонам. Обычное есть две зоны: внешняя, обслуживающая клиентов внешней сети, и внутренняя, обслуживающая клиентов внутренней сети. Клиенты разрешают имена, основываясь на том, в какой зоне они находятся в настоящий момент.

Пользователи из внешней зоны будут разрешать имя owa.msfirewall.org как адрес внешнего интерфейса, который они будут использовать для веб-прослушивателя в наших правилах публикации веб-служб Exchange. Внутренние пользователи будут разрешать имя owa.msfirewall.org как IP адрес внутреннего интерфейса ISA Firewall, который будет использоваться веб-прослушивателем, используемым для правил публикации веб-служб Exchange.

Это немного отличается от моих обычных рекомендаций, так как обычно я использую раздельный DNS для того, чтобы позволить внутренним пользователям подключаться к Client Access Server напрямую, минуя ISA Firewall. Хоть это и подходящая конфигурация для раздельного DNS, проблема, с которой мы сталкиваемся, заключается в том, что внутренние пользователи, подключающиеся напрямую к Exchange Client Access Server, не получат преимуществ от использования авторизации на базе форм и защищенности ISA Firewall.

Причина, по которой внутренние пользователи, подключающиеся напрямую к Client Access Server, не выиграют от авторизации на базе форм, в том, что нам будет нужно отключить авторизацию на базе форм для Exchange Client Access Server при его публикации с использованием ISA Firewall. Вместо этого, пользователи будут использовать авторизацию на базе форм ISA Firewall. Кроме того, если пользователи будут напрямую подключаться к Exchange Server, они смогут обойти настройки безопасности, введенные на ISA Firewall. По этим двум причинам я отказался от «обратных запросов» с уходом от ISA Firewall.

Наша сеть, взятая для примера, использует то, что я назвал инфраструктурой с «интегрированным» раздельным DNS. В подобной инфраструктуре действительное доменное имя Active Directory совпадает с внешним доменным именем, которое пользователи будут использовать для соединения с ресурсами Exchange Client Access Server. Во многих случаях это невозможно, потому что компания уже разместила Active Directory, или же недоступно доменное имя (потому что кто-то другой уже зарегистрировал их доменное имя для использования в Интернет) или же у них стандартизировано доменное имя верхнего уровня.

Мы можем решить эти проблемы, используя то, что я называю «параллельным» раздельным DNS. В параллельном раздельном DNS имена DNS зон отличаются от действительного доменного имени Active Directory. Это очень легко осуществить, так как вам нужно лишь создать новое имя зоны, которую вы будете использовать для ваших перемещающихся пользователей, и создать зоны для пользователей из внутренней и внешней сетей на двух отдельных DNS серверах.

На рисунке ниже показана последовательность событий и для внутренних клиентов, и для внешних.

Рисунок 3

Для внутренних клиентов происходит следующее:

1. Внутренний клиент совершает DNS запрос для owa.msfirewall.org к DNS серверу внутренней сети.
2. Внутренний DNS сервер, авторитетный для домена msfirewall.org, возвращает IP адрес 10.0.0.1 для имени owa.msfirewall.org
3. Внутренний клиент посылает запрос для owa.msfirewall.org/OWA по IP адресу внутреннего интерфейса ISA Firewall (10.0.0.1).
4. ISA Firewall аутентифицирует, авторизует и инспектирует соединение, после чего перенаправляет его к Exchange Client Access Server.
5. Exchange Client Access Server возвращает данные на внутренний интерфейс ISA Firewall; ISA Firewall инспектирует ответ
6. ISA Firewall возвращает данные к клиенту, совершившему запрос

Для внешних клиентов происходит следующее:

1. Внешний клиент совершает DNS запрос к внешнему DNS серверу, авторитетному для домена msfirewall.org.
2. Внешний DNS сервер возвращает клиенту IP адрес внешнего интерфейса ISA Firewall, используемый веб-прослушивателем для правил публикации веб-служб Exchange.
3. Внешний клиент посылает запрос для owa.msfirewall.org/OWA к IP адресу внешнего интерфейса ISA Firewall.
4. ISA Firewall аутентифицирует, авторизует и инспектирует соединение, после чего перенаправляет запрос к Exchange Client Access Server.
5. Exchange Client Access Server возвращает ответ ISA Firewall.
6. ISA Firewall инспектирует ответ и затем перенаправляет его внешнему клиенту, совершившему запрос.

Для нашего сценария нам нужно создать запись Host (A) для owa.msfirewall.org на внутреннем и внешнем DNS серверах. В примере мы рассмотрим только внутренний DNS сервер, так как внешней зоны вы, скорее всего, будете использовать DNS сервер не на базе Windows.

Откройте консоль DNS, нажав на ссылку в меню Administrative Tools. В консоли DNS раскройте список Forward Lookup Zones и нажмите на зону msfirewall.org. Щелкните правой кнопкой на пустое место в правой части и выберите команду New Host (A).

Рисунок 4

В диалоговом окне New Host введите имя owa в поле Name (uses parent domain name if blank). Введите внутренний IP адрес ISA Firewall в поле IP address. Если вы создавали для своей внутренней сети зону обратных запросов, отметьте поле Create associated pointer (PTR) record (Я уже сделал такую зону для внутренней сети на этом DNS сервере). Нажмите Add Host.

Рисунок 5

Новая запись создана. В диалоговом окне New Host нажмите Done. Теперь вы можете видеть новую запись в средней части консоли DNS. После создания записи перезапустите службу DNS.

Рисунок 6

Заключение

В первой части нашей серии, посвященной публикации веб-служб Exchange 2007 с помощью ISA 2006, мы обсудили конфигурацию нашей сети, взятой для примера, и подробности топологии тестовой сети, которую мы будем использовать в оставшихся частях этой серии статей. В этой статье мы сделали акцент на том, что дизайн, обсуждаемый в этой серии, не обеспечивает наиболее высокого уровня безопасности, но данная топология часто используется на производстве из-за относительной легкости в использовании. Также мы особо отметили кошмарный сценарий публикации Exchange, где защищенность ISA Firewall подорвана использованием ненужных брандмауэров и размещением ISA Firewall в «мертвом режиме». Были высказаны важные соображение по поводу DNS, с упором на инфраструктуру с раздельнымt DNS. В следующий раз мы начнем устанавливать Exchange 2007, что само по себе настоящее приключение! Увидимся!

www.isaserver.org

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

Tags: dns, domain, Exchange, forward, imap, ISA Server, mac, Windows XP