Разъяснение Http доступа в Exchange 2003 (Часть 2)

Введение

В Части 1 статьи рассматривалось, как HTTP клиенты могут получать доступ и управлять 'Web Store? в Exchange. В этой статье мы будет рассматривать, как Outlook Web Access (OWA), Outlook Mobile Access (OMA) или Exchange ActiveSync (EAS) используют эти механизмы, чтобы обеспечивать удалённых пользователей Exchange сообщениями и сервисами совместной работы.

Это не урок по конфигурированию OWA, OMA или EAS; взамен обсуждается работа механизма стоящего за этими сервисами. Часть 1 иллюстрирует несколько причудливые механизмы, используемые для доступа к данным Exchange, а в этой статье мы пойлем даже ещё дальше, потому что OWA, OMA и EAS -все используют эти механизмы по-разному! Если Вы бились на тем чтобы заставить эти методы HTTP доступа работать вместе, Вы можете легко найти причину в данной статья.

Эта статья также охватывает усовершенствования, сделанные для OWA в SP1 для Exchange.

Технический обзор Outlook Web Access

OWA-это приложение, состоящее из выполняемых DLL файлов, сконфигурированных по умолчанию в IIS виртуальной директории, названной 'Exchange? в IIS виртуальном сервере 'Default Web Site? (если Ваш Exchange установлен на серверном кластере, по умолчанию директория 'Exchange? создаётся в виртуальном сервере, названном 'Exchange Virtual Server? вместо этого). Пользователи получают доступ к OWA, набирая URL по умолчанию:

HTTPS://ServerName/Exchange

Когда новый OWA запрос поступает на сервер, пользователи запрашиваются на их мандаты(credentials) и аутентифицируются по отношению к Active Directory (AD). Приложение OWA со стороны сервера затем выполняет LDAP запросы на получаемую пользовательскую информацию от AD, которая включает пользовательские SMTP адреса (proxy адреса), псевдонимы почтовых ящиков и Exchange home(домашний) сервер (тот, который хранит пользовательский почтовый ящик). То, что случится дальше, зависит от того, является ли этот сервер также пользовательским домашним сервером или нет.

Если сервер, принимающий клиентские запросы, не является пользовательским домашним сервером, то сервер осуществляет редирект(HTTP 302 ответ). Однако, если сервер является внешним(front-end) Exchange, он связывается с соответствующим внутренним на стороне клиента, фактически становясь Web proxy. Вне зависимости от маршрута, актуальный домашний сервер повторит LDAP процесс, когда он получает перенаправленный запрос, так, как если бы клиент подсоединился к нему напрямую.

Рис. 1: Начальные OWA связи, здесь с множеством внутренних серверов.

Приложение OWA на домашнем сервере (будет это другой сервер или нет) проверяет пользовательские SMTP адреса на любое соответствие SMTP домену, сконфигурированному для виртуальной директории 'Exchange?. Левая сторона (LHS) этого подходящего адреса используется, чтобы составить ссылки на HTML страницу, приготавливаемую для клиента. Эти ссылки выглядят как-то так:

HTTPS://ServerName/Exchange/LHSofSMTPAddress/…

Прежде, до SP1 для Exchange 2003, если приложение OWA не могло подобрать email адрес к SMTP домену, сконфигурированному для виртуальной директории 'Exchange?, вход в систему был невозможен. Начиная с SP1 OWA разрешает эту ситуацию, беря полный первичный SMTP адрес для пользователя (находит в течение LDAP процесса) и создаёт ссылки в таком формате:

HTTPS://ServerName/Exchange/PrimarySMTPAddress/…

Когда клиент принимает страницу, именно эти ссылки обеспечивают доступ к содержанию почтового ящика и некоторые из этих ссылок являются WebDAV запросами, которые на самом деле выполняют различные функции почтового ящика. Страница будет также содержать ссылки на статический контент, такой как графика, найденная в директории 'ExchWeb?.

OWA может также просматривать публичные папки и по умолчанию он делает это через виртуальную директорию 'Public? . Процесс очень похож на доступ к почтовому ящику, включая proxy запросы, когда контента нет на сервере, но LDAP поиски домашнего сервера, email адресов и т.д. не требуются, т.к. виртуальная директория 'Public? не конфигурируется для SMTP домена, как виртуальная директория 'Exchange?.

Внешние серверы(Frontends) Exchange

Как только вовлекается внешний сервер(frontend), запросы передаются через proxy к внутреннему(backend) домашнему серверу. Исключение составляют запросы статического контента, которые обрабатываются внешним сервером(frontend). Proxied-запросы используют модифицированный URL по строкам:

HTTP://HomeServerName/Exchange/…

Важная вещь, на которую следует обратить внимание- эти proxy-запросы используют HTTP, никогда HTTPS, плюс то, что пользователю придётся опять регистрироваться на целевом сервере. Внешний сервер(frontend) использует мандат(credentials), уже запрошенный от клиента и применяет интегрированную аутентификацию(Kerberos или NTLM), чтобы скрыть пароль, который иначе появился бы как обычный текст в HTTP передаче.

Что касается внешних серверов(frontends), директория 'Exchange? на обоих серверах должна быть сконфигурирована для одного и того же SMTP домена. В противном случае соответствие LHS и SMTP домена будет, вероятно, утеряно и запрос не исполнится. Неоднородные конфигурации будут работать, если у пользователя есть адрес в обоих сконфигурированных SMTP доменах с идентичными LHS, но такая конфигурация не рекомендуется. Подобно изменениям в SP1, которые могут проигнорировать всё это, LHS business может позволить неоднородные конфигурации, но не всегда.

Рис. 2: Начальные OWA связи, здесь во внешне-внутреннем серверном(frontend-backend) окружении. Обратите внимание на HTTP (не HTTPS!) proxy запросы между внешним(frontend) и внутренним(backend) серверами.

OWA и делегирование доступа

Вы можете укоротить часть этого процесса, используя более специфический URL для Вашего оригинального запроса. Эта уловка очень полезна, если Вы являетесь делегатом, скажем, календаря коллеги. Например:

HTTPS://ServerName/Exchange/LHSofColleaguesSMTPAddress/Calendar

SMTP адрес Вашего коллеги должен быть в SMTP домене, сконфигурированном для директории 'Exchange?, используемой в URL, а Вы должны будете узнать эту частицу LHS. Это всё немного болезненно, но начиная с Exchange 2003 SP1 Вы можете забыть о том, какой SMTP домен сконфигуриван для какого URL и использовать любой из email адресов Вашего коллеги в формате:

HTTPS://ServerName/Exchange/Colleague@SMTPDomain/Calendar

Вы всё ещё входите в систему в качестве себя самого, но OWA знает, что надо модифицировать LDAP запросы для того, чтобы найти домашний сервер Вашего коллеги, а не Ваш.

Технический обзор OMA и Exchange ActiveSync

Exchange 2003 представил новые выполняемые функции, не присутствующие в Exchange 2000, включая OMA и EAS компоненты, которые были впервые предложены отдельным серверным приложением, называвшемся Mobile Information Service (MIS). Когда эти MIS компоненты были перенесены в Exchange 2003, им придали тот же самый внешний вид, который используется для OWA.

OMA и EAS имеют IIS директории по умолчанию, к которым подключаются клиенты, а именно 'OMA? и 'Microsoft-Server-ActiveSync?. Директория 'OMA? содержит Active Server Pages (ASP), которые вызывают исполняемые (DLL) файлы, чтобы выполнять работу по запросу содержания почтового ящика и созданию ответных страниц для клиента. Директория EAS управляет всеми запросами от приложения (massync.dll), которое запрашивает и поставляет содержание почтового ящика для клиента. EAS контент не создаётся для броузера, потому что он просматривается специальными приложениями на клиенте. OMA и EAS приложения выполняют некоторые функции как OWA приложение, включая аутентификацию и LDAP поиски для пользовательского домашнего сервера, SMTP адреса и т.п. Если вовлечены внешние серверы(frontends), то эти процессы совершаются на внешнем сервере, так как OMA и EAS не могут выполнять proxy запросы к внутреннему серверу(backend), как делает OWA. Другое отличие от OWA заключается в том, что оба приложения запрашивают содержание почтового ящика от имени клиента, подготавливая HTTP и WebDAV запросы, выглядящие как-то так:

HTTP://HomeServerName/Exchange/LHSofSMTPAddress/…

Обратите внимание на 'Exchange? в этом URL; приложения OMA и EAS используют OWA, чтобы выполнить эти запросы. Это очень важно понять, потому что, подобно внешне-внутренним серверным (frontend-backend) OWA связям, эти OMA и EAS запросы используют HTTP, не HTTPS, вместе с 'Integrated? регистрацией(authentication): виртуальные директории OWA 'Exchange? на всех внутренних серверах должны принимать 'Integrated? регистрацию и не-SSL соединения, и здесь нет соответствия, есть ли внешние серверы(frontends) или нет, потому что OMA и EAS создают эти запросы и в развёртываниях единственного сервера Exchange тоже!

Рис. 3: Начальные OMA связи. Здесь внешний сервер(frontend) выбирает контент из домашнего сервера, а не передаёт(proxies) полный клиентский запрос, подобно OWA. Директория 'oma? (и 'exchange?) была сконфигурирована для 'abc.tld? SMTP домена, так что 'bob? выбирается из пользовательских SMTP адресов, потому что домены соответствуют. Только внутренне-серверный (backend) сценарий должен проработать точно такой же, кроме того, что контентные запросы пройдут в пределах того же самого сервера.

Виртуальные директории 'OMA? конфигурируются для специфических SMTP доменов почти так же, как для OWA и должны быть сконфигурированы так же, как директория 'Exchange?, обрабатывающая HTTP и WebDAV запросы, посланные от имени клиента. EAS берётся за эти вещи немного иначе и виртуальные директории 'Microsoft-Server-ActiveSync?, обрабатывающие EAS запросы, не конфигурируются для специфического SMTP домена. Вместо этого, когда EAS производит начальные LDAP поиски пользовательских атрибутов, он только выбирает пользовательский первичный(primary) SMTP адрес и последующие WebDAV запросы используют LHS этого адреса. Это означает, что SMTP домен, используемый как первичный адрес(primary address), должен быть сконфигурирован для виртуальной директории 'Exchange?, которая обрабатывает WebDAV запросы. Требуется некоторая продуманная конфигурация, чтобы заставить это работать в окружении с множеством SMTP доменов, в которых пользователи имеют разные первичные SMTP адреса!

Рис. 4: Как на рис. 3, но в этом случае PDA пытается выполнить Exchange ActiveSync. Всё происходит, как и с OMA, но EAS, который не сконфигурирован для SMTP домена, выбирает пользовательский первичный SMTP адрес '[email protected]?. Директория 'exchange? внутреннего сервера, сконфигурированная для 'abc.ltd? не может соответствовать '[email protected]?, так что контентный запрос внешнего сервера будет неудачен!

К счастью, EAS может быть сконфигурирован для специфического SMTP домена с установкой в реестре, чтобы он работал немного более похоже на OWA и OMA: в этом режиме он может обрабатывать только один SMTP домен. Несмотря на этот очевидный недостаток в окружении при множестве SMTP доменов, режим единичного домена — это наиболее просто для администрирования и решение, которое должно преодолеть ограничения других средств.

Установкой реестра является параметр REG_SZ, названный SMTPProxy? (Вам придётся создать его), который имеет значение, соответствующее SMTP домену, который Вы решили закрепить за EAS. Это значение должно появиться на всех Ваших внешних серверах(frontends) (или внутренних(backends), если Вы не используете внешние(frontends)) и располагаться здесь:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MasSync\Parameters

Как всегда, не делайте изменения в реестре, пока не сделаете резервные копии и не поймёте, что Вы делаете.

Будущее Mobile Access?

Почему OMA и EAS не обновлены в SP1 подобно OWA? Мне хотелось бы думать, что они оба подвергаются значительной перестройке. OMA был разработан для ранних мобильных телефонов с ужасными скоростями загрузки данных, не то что GPRS/3G полноцветные игрушки сегодняшнего дня. EAS теперь конкурирует с многочисленными сторонними предложениями, которые имеют гораздо больше излишеств. Может быть, в этом объяснение, но подождём и увидим.

Управление сайтами Exchange 2003 в IIS

HTTP виртуальные серверы и директории, используемые для удалённого доступа к Exchange, конфигурируются с использованием двух плагинов Microsoft Management Console (MMC); консоли Exchange System Manager (ESM) и консоли Internet Information Service (IIS) Manager. Сначала это может показаться запутанным и, что ещё хуже, может привести Вас к совершению некоторых очень сбивающих с толку ошибок. Изменения, сделанные в ESM консоли, всегда имеют приоритет над изменениями, сделанными в консоли IIS Manager, однако, изменения, сделанные с последней консолью, кажется, аннулируют прежде упомянутое. Эта иллюзия возникает из-за асинхронного способа, которым Exchange применяет конфигурации, о которых он знает.

Процесс DB2MB

Большая разница между двумя консолями в том, что ESM применяет изменения к конфигурации Active Directory 'naming context(обозначение контекста)? (раздел), тогда как IIS Manager применяет изменения напрямую к IIS Metabase, XML файлу, содержащему конфигурацию для IIS. ESM конфигурации, сохраняемые в AD, применяются к IIS Metabase через Exchange процесс, известный как Directory Service to Metabase (DS2MB). Этот процесс происходит всякий раз, когда Exchange перезапускается или когда DS2MB обращает внимание на любые важные изменения в AD (не обязательно мгновенно). DS2MB применяет конфигурации с комплексным подходом, который не проявляет никакого уважения к любой существующей конфигурации, сделанной любыми другими средствами!

Не все конфигурации, сделанные Exchange-ем, видимы из IIS Manager, включая приложения, стоящие за OWA и полную конфигурацию SMTP, NNTP, IMAP и POP. Эти аспекты по крайней мере сохраняются скрытыми от вмешательства инструментом IIS Manager!

Фокус состоит в том, чтобы всегда использовать ESM консоль для конфигурирования тех опций, которые он может конфигурировать, таких как создание виртуальных директорий и серверов, регистрация(authentication) и контроль доступа, выполнение разрешений(permissions). Используйте IIS консоль только для остальных функций, таких как SSL сертификаты и IP ограничения. Знайте, что некоторые из DS2MB влияний превосходят то, что видимо в ESM консоли, включая конфигурацию виртуальных директорий 'ExchWeb?.

Резюме

Следующий список суммирует некоторые проблемы, упомянутые выше, и добавляет ещё одну или две. Microsoft может обратиться к этим проблемам в будущем, и они, конечно, сделали изменения в этом направлении в SP1.

Microsoft опубликовала статью из Knowledge Base(база знаний) под номером 817379, которая обращена к некоторым из этих проблем. Эти исправления не очень изящны и могут быть и лучшие способы решения этих проблем. Однако, Microsoft показала часть намеченного ими направления для Exchange HTTP доступа в SP1, так что, между тем, не ожидайте никаких альтернатив KB817379 исправлениям от Microsoft.

OWA имеет опцию для 'forms based? метода аутентификации. Если это включено на внутреннем сервере(backend server), то директория 'Exchange? будет автоматически сконфигурирована только для базовой аутентификации(Basic authentication) и будет рекомендован только SSL. Внешние сервера(frontend servers) OWA, OMA и EAS все требуют 'Integrated? аутентификацию, а не SSL на директории 'Exchange. Поэтому это не будет работать когда 'forms based? аутентификации включена таким способом.
Приложение OMA создаёт его WebDAV и контентные запросы без хост-заголовка( host-header) от оригинальных клиентских запросов. В результате только один виртуальный HTTP сервер, сконфигурированный с не хост-заголовками на порт 80, может собирать эти запросы. Поэтому OMA может поддерживать только один сконфигурированный SMTP домен.
EAS использует другой механизм для обработки запросов, чем это делают OWA и OMA. Это отличие делает обработку множества SMTP доменов очень неуклюжим, если EAS оставляется в его заданном по умолчанию конфигурационном состоянии. Преодоление включает хитрое редактирование реестра и препятствует работе EAS с более чем одним SMTP доменом.
Директория 'Exchange? по умолчанию, которую Exchange создаёт в IIS, конфигурируется для SMTP домена по умолчанию и это не может быть изменено. Когда имеешь дело с множеством SMTP доменов до SP1 для Exchange 2003, это раздражало при конфигурировании OWA (см. далее); это остаётся раздражителем с OMA и EAS, если эти средства остаются сконфигурированными в заданной по умолчанию манере.
До SP1 для Exchange 2003, виртуальные директории и сервера для OWA были бы доступны только для пользователей, которые имели email адрес в SMTP домене, сконфигурированном для этой виртуальной директории или сервера. Это могло быть полезно для контроля доступа на хостовую Exchange систему, но в SP1 Microsoft удалила это ограничение.

Так как OMA работает только с одним SMTP доменом и EAS лучше конфигурировать для работы с одним SMTP доменом, разумно конфигурировать OWA таким же способом даже при поддержке множества SMTP доменов! Способ сделать это заключается в том, чтобы назначить всем вторичный email адрес в обычном SMTP домене, так что фактически Вы должны поддерживать только единичный SMTP домен.

Заключения

Начиная с Exchange 2003 было реализовано конфигурирование новых HTTP методов доступа, что причиняет много головной боли администраторам. Большинство из этих проблем являлись следствием плохо документированного и иногда причудливого способа, которым эти средства работают. Эта статья попыталась объяснить многие из механизмов, стоящих за этими средствами, в надежде на просвещение читателей, чтобы идти дальше и позволить им решать некоторые из проблем при конфигурировании HTTP доступа.

Введение SP1 для Exchange 2003 обеспечивает некоторое облегчение проблем с конфигурированием OWA, но относящиеся к делу изменения в SP1 в основном находятся в стадии разработки и не предлагают законченного решения; OMA и EAS всё ещё придерживаются старого способа действий. Возможно, в SP2 мы увидим, что будет изобретено что-то ещё лучшее.