NetworkDoc.Ru В помощь системному администратору

EasyBlog

This is some blog description about this site

  • Home
    Home This is where you can find all the blog posts throughout the site.
  • Categories
    Categories Displays a list of categories from this blog.
  • Tags
    Tags Displays a list of tags that have been used in the blog.
  • Bloggers
    Bloggers Search for your favorite blogger from this site.
  • Team Blogs
    Team Blogs Find your favorite team blogs here.
  • Login
    Login Login form

Как работают внешние серверы Exchange

Posted by on in Почтовые сервисы
  • Font size: Larger Smaller
  • Hits: 6296
  • 0 Comments
  • Subscribe to this entry
  • Print

Организации, развернувшие Microsoft Outlook Web Access (OWA) на базе Exchange Server 2003 или Exchange 2000 Server, часто отказываются от непосредственных соединений между клиентскими браузерами и сервером Exchange, на котором размещены почтовые ящики пользователей. Вместо этого устанавливается клиентское соединение OWA с внешним (front-end) сервером Exchange, который в свою очередь подключен к внутреннему (back-end) серверу с почтовыми ящиками пользователей.

Источник: Windows & .NET Magazine/RE

Как работают внешние серверы Exchange

Киран Маккорри
26.01.2004

Организации, развернувшие Microsoft Outlook Web Access (OWA) на базе Exchange Server 2003 или Exchange 2000 Server, часто отказываются от непосредственных соединений между клиентскими браузерами и сервером Exchange, на котором размещены почтовые ящики пользователей. Вместо этого устанавливается клиентское соединение OWA с внешним (front-end) сервером Exchange, который в свою очередь подключен к внутреннему (back-end) серверу с почтовыми ящиками пользователей.

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

Я расскажу, как работает традиционная модель, и в чем заключаются недостатки ее метода аутентификации. Кроме того, будет рассмотрен альтернативный вариант с использованием настройки конфигурации внешнего сервера, упрощающей пространство имен для OWA. Альтернативный подход позволяет избежать недостатков базового метода аутентификации и дает возможность всем пользователям обращаться к электронной почте по одному и тому же URL.

Настройка внешнего сервера

Внешние серверы имеют две особенности. Во-первых, установлен флажок This is a front-end server на странице Properties сервера; если флажок не установлен, то сервер представляет собой обычный внутренний сервер. Для того чтобы настроить систему для работы в качестве внешнего сервера, следует открыть оснастку Exchange System Manager (ESM) консоли Microsoft Management Console (MMC) и перейти в папку Administrative Groups/AGName/Servers/Servername, где AGName - имя административной группы, к которой принадлежит сервер, а Servername - имя сервера. Щелкнув правой кнопкой мыши на сервере, следует выбрать пункт Properties и установить флажок This is a front-end server (см. Экран 1).

Экран 1. Настройка внешнего сервера.

Во-вторых, особенность внешних серверов заключается в том, что на них нет почтовых ящиков пользователей: все почтовые ящики расположены на внутренних серверах.

Как правило, на внешних серверах нет даже групп хранения (storage group - SG) или базы данных. База данных нужна внешнему серверу только для работы с входящими соединениями SMTP. База данных необходима службе SMTP для подготовки отчетов об ошибках доставки - nondelivery report (NDR).

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

Как работают внешние серверы

При традиционном методе использования внешних и внутренних серверов с OWA клиентский браузер пользователя устанавливает HTTP-соединение с внешним сервером. Внешний сервер запрашивает сервер глобального каталога (GC) Active Directory (AD), чтобы определить, на каком внутреннем сервере размещен почтовый ящик конкретного пользователя, а затем организует сеанс HTTP-DAV для этого сервера.

Весь последующий обмен данными между браузером и внутренним сервером происходит через внешний сервер (см. Экран 2).

Экран 2. Традиционная реализация внешнего сервера.
(1) Браузер устанавливает соединение с внешним сервером (например, http://webmail.bigcorp.com/).
(2) Внешний сервер запрашивает GC, чтобы определить нужный внутренний сервер.
(3) Внешний сервер играет роль посредника для внутреннего сервера.

Модель с внешним сервером полезна, так как позволяет обращаться ко многим внутренним серверам почтовых ящиков через одно пространство имен. Предположим, что компания Bigcorp располагает большим числом почтовых серверов, каждый с собственным полным доменным именем (Fully Qualified Domain Name, FQDN - например, server1.bigcorp.com, server2.bigcorp.com). В отсутствие внешнего сервера все пользователи OWA должны помнить имя конкретного внутреннего сервера, на котором расположены их почтовые ящики (например, server1, server2), и вводить в браузер URL этого сервера. Если некоторые или все почтовые ящики будут перемещены на другой сервер, то их пользователям придется запомнить и использовать новое имя сервера.

При наличии внешнего сервера все пользователи OWA, независимо от того, на каком внутреннем сервере находятся их почтовые ящики, могут просто указывать в OWA в качестве URL имя внешнего сервера. Предположим, что имя внешнего сервера Exchange - webmail.bigcorp.com. Если переместить почтовые ящики пользователей на другой внутренний сервер, то внешний сервер установит соединение с нужным внутренним сервером, так как имя webmail.bigcorp.com по-прежнему принадлежит внешнему серверу. Пользователи о сложной структуре именования внутренних серверов могут ничего и не знать.

Использование нескольких внешних серверов

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

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

Во-первых, при использовании нескольких серверов общий URL должен направлять клиентские браузеры на один из этих серверов, распределяя трафик между ними. Для этого можно задействовать службу Windows NT Load Balancing Service (WLBS), циклическую ротацию DNS или аппаратные коммутаторы балансировки нагрузки.

Во-вторых, необходимо, чтобы URL, вводимый пользователем, указывал на виртуальный сервер Exchange. Типичный прием в этом случае - добавление пользователями OWA фрагмента /exchange к основному адресу (например, http://webmail.bigcorp.com/exchange/). Чтобы избежать удлинения URL, можно перенаправлять соединения в корневой каталог Web-сервера с помощью функции перенаправления Microsoft IIS.

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

  1. Запустить IIS Manager (ранее известный как Internet Services Manager - ISM).
  2. Щелкнуть правой кнопкой мыши на Default Web Site и выбрать пункт Properties.
  3. Щелкнуть на вкладке Home Directory и выбрать режим A Redirection to a URL.
  4. В поле Redirect To следует ввести /exchange, а затем щелкнуть на пункте A directory below this one.

Явная и косвенная регистрация

Чтобы понять, как работает OWA в режиме с внешним/внутренним сервером, необходимо знать типы регистрации в OWA. Пользователи могут обращаться к своим почтовым ящикам через OWA с помощью явных и косвенных процедур входа. URL для явной регистрации указывает сервер и почтовый ящик, к которому хочет получить доступ пользователь, в форме http://servername/exchange/username/, где servername - имя внешнего или внутреннего сервера OWA, а username - имя учетной записи Windows для пользователя. Например, явный URL для пользователя с именем Flint может иметь вид http://webmail.bigcorp.com/exchange/flint/.

Получив от клиентского браузера явный URL, внешний сервер извлекает из URL фрагмент username и объединяет его с именем домена SMTP, ассоциированного с виртуальным каталогом Exchange, тем самым генерируя SMTP-адрес для пользователя. Например, если пользователь Flint вводит свой URL, то внешний сервер объединяет фрагмент username (flint) с именем домена SMTP (bigcorp.com), чтобы получить SMTP-адрес пользователя - This email address is being protected from spambots. You need JavaScript enabled to view it.. Внешний сервер использует этот SMTP-адрес в запросе к GC, чтобы идентифицировать внутренний сервер, на котором размещен почтовый ящик пользователя Flint. Затем внешний сервер пересылает запрос в неизменном виде внутреннему серверу, который обрабатывает запрос так, как будто он поступил непосредственно от браузера пользователя.

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

Косвенный URL входа имеет форму http://servername/exchange/, где servername может быть именем внешнего или внутреннего сервера OWA. Косвенная регистрация более удобна для пользователей, чем явная, так как URL короче и проще. Как было указано выше, можно опустить фрагмент /exchange в URL, если соединение перенаправляется на виртуальный каталог Exchange. Таким образом, URL косвенной регистрации в простейшей форме может иметь следующий вид:

http://webmail.bigcorp.com/.

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


{mospagebreak}

Аутентификация

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

  • Pass-through authentication (сквозная аутентификация) - внешний сервер просто передает запрос внутреннему серверу, который выполняет аутентификацию.
  • Dual authentication (двойная аутентификация) - внешний сервер аутентифицирует начальный запрос пользователя, а затем пересылает запрос соответствующему внутреннему серверу, который вновь аутентифицирует запрос.

Перед пересылкой запроса на соответствующий внутренний сервер внешнему серверу необходимо идентифицировать пользователя, поэтому сквозная аутентификация подразумевает явную процедуру регистрации. Я не рекомендую применять сквозную аутентификацию для доступа к OWA. Сквозная аутентификация обеспечивает передачу анонимных запросов HTTP непосредственно на внутренний сервер, в результате сервер открыт для ложных запросов HTTP и уязвим для атак типа отказ в обслуживании (Denial of Service - DoS). Кроме того, двойная аутентификация предпочтительнее сквозной, так как большинство пользователей OWA желает вводить как можно более простые URL. На Экране 3 показана процедура явной регистрации со сквозной аутентификацией.

Экран 3. Явная регистрация со сквозной аутентификацией.
Аутентификация только на внутреннем сервере.

Двойная аутентификация - более удачный подход, поддерживающий косвенную регистрацию и более простые URL. Хотя для двойной аутентификации требуются как внешние, так и внутренние серверы (см. Экран 4), пользователям приходится вводить свои учетные данные лишь однажды. После того, как внешний сервер аутентифицирует пользователя, сервер кэширует учетные данные в клиентском браузере.

Экран 4. Косвенная регистрация с двойной аутентификацией.

В архитектурах с внешним и внутренним сервером почти всегда используется двойная аутентификация. Единственное исключение - ситуация, в которой внешний сервер не может вызывать удаленные процедуры (remote procedure call - RPC) для связи с DC; такая ситуация может возникнуть, если внешний сервер отделен от DC брандмауэром. В этом случае необходима сквозная аутентификация.

Внешние серверы обеспечивают лишь базовую (Basic) аутентификацию HTTP, имеющую ряд недостатков. При этом методе аутентификации учетные данные пользователя не шифруются, поэтому я рекомендую всегда устанавливать между клиентами OWA и внешними серверами соединения Secure Sockets Layer (SSL). Еще один недостаток аутентификации HTTP Basic - невозможность реализации единой процедуры входа (single sign-on - SSO), для которой необходима интегрированная с Windows процедура аутентификации (NT LAN Manager - NTLM - или Kerberos).

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

Псевдо-внешние серверы

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

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

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

Как показано на Экране 5, пользователи могут обращаться к псевдо-внешнему серверу (который, в сущности, представляет собой один из внутренних серверов), указав общий URL вида http://webmail.bigcorp.com/.

Экран 5. Структура с псевдо-внешним сервером.
(1) Нормализованный URL обеспечивает соединение с псевдо-внешним сервером.
(2) Псевдо-внешний сервер запрашивает AD и идентифицирует целевой внутренний сервер.
(3) Косвенный вход с интегрированной аутентификацией Windows выполняет перенаправление на целевой внутренний сервер.
(4) Клиент подключается к нужному внутреннему серверу.

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

Как выбрать оптимальный подход?

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

Псевдо-внешние серверы полезны, если требуется задействовать простое пространство имен OWA и интегрированную аутентификацию Windows, или снизить затраты ресурсов и времени, связанные с многократной аутентификацией. Однако традиционные внешние серверы также полезны - в частности, они упрощают публикацию служб OWA в Web.

Киран Маккорри – Главный консультант подразделения Consulting and Integration Technology Group компании HP, работающий в Ирландии. Он является соавтором книги Microsoft Exchange 2000 Infrastructure Design (Digital Press). С ним можно связаться по адресу: This email address is being protected from spambots. You need JavaScript enabled to view it.">This email address is being protected from spambots. You need JavaScript enabled to view it..


Windows & .NET Magazine/RE // Издательство "Открытые системы" (http://www.osp.ru/)
Постоянный адрес статьи: http://www.osp.ru/win2000/exchange/401_2.htm


 

 

0

Comments

  • No comments made yet. Be the first to submit a comment

Leave your comment

Guest Saturday, 01 February 2025
Loading ...

Joomla! Debug Console

Session

Profile Information

Memory Usage

Database Queries