На главную страницу
 
  Главная 
  Новости 
  Статьи  RSS
  Программное обеспечение 
  Форум 
  Опросы 
  Полезные ссылки 
MSExchange.ru ISADocs.ru WinSecurity.ru NetDocs.ru

Exchange 5.5
Exchange 2000
Exchange 2003
Exchange 2007
Общее
Exchange 2010

Поиск по сайту


Авторизация

Запомнить меня на этом компьютере
  Забыли свой пароль?
  Регистрация

Подписка

Изменение параметров

Статистика

Hits 2746636
11329
Hosts 1649526
399
Visitors 229593
455

7
Мониторинг активности принтеров

Главная / Статьи / Exchange 2003 / Прояснение процесса входа в OWA 2003 FE/BE


SurfCop

Прояснение процесса входа в OWA 2003 FE/BE

Версия для печати Версия для печати

Эта статья переведена силами и средствами компании Red Line Software. Размещение данного переведенного материала на других сайтах без разрешения компании Red Line Software запрещается.

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

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

  • DSAccess – внутренний компонент Exchange 2000/2003, который используется для получения доступа к информации о директории.
  • Eprox.dll – это DLL, которая отвечает за обмен между front-end сервером Exchange и IIS
  • DaveX.dll – это DLL, которая отвечает за обмен между back-end Серверами Exchange и IIS
  • Epoxy.dll – это DLL, отвечающая за внутренние коммуникации между Exchange и IIS
  • Exoledb.dl – это DLL, отвечающая за связь с Хранилищем данных (Information Store).

Как работает аутентификация в OWA

Давайте начнем с того, что посмотрим на типичный сценарий для Exchange 2003 c применением Front-end и Back-end серверов. В этом сценарии мы имеем два сервера Exchange 2003, контроллер доменов, глобальный каталог и DNS сервер. Контроллер доменов, глобальный каталог и DNS могут быть расположены на одном сервере, на нескольких серверах или быть разбросаны по серверам. Также вы можете видеть, что есть фаервол между серверами и удаленным клиентом. Смотрите рисунок 1.

Рисунок 1

Первый шаг наиболее очевиден, клиент открывает свой браузер и вводит в нем http://domain.com/exchange или, если у него настроено SSL, то https://domain.com/exchange. DNS используется для того, чтобы преобразовать имя домена в IP адрес, и затем сделать запрос на соответствующий порт, TCP 80 для HTTP, или TCP 443 для SSL. А если есть еще и брандмауэр, а он должен быть, то соответствующий порт должен еще и быть открытым.

Здесь то и начинается все самое интересное. Служба IIS на Front-end сервере Exchange 2003 будет слушать порт 80/443 и будет определять, какой вебсайт получит запрос. В совершенном мире, front-end сервер будет просто front-end сервером для Exchange, и только. В этом случае у Вас будет просто “Веб Сайт по умолчанию” и запрос отправиться туда. Как бы то ни было, если front-end сервер еще и веб сервер, на котором находятся другие сайты IIS, то потребуется как-то выбрать нужный вебсайт, чтобы именно ему передать запрос. Это делается используя или порт, или IP адрес, или заголовок хоста.

Теперь, когда IIS отправил запрос на нужный вебсайт, вебсайт должен перенаправить его в нужную директорию на вебсайте. Для Outlook Web Acces эта директория называется Exchange. Вот здесь и становится очень важным провести процесс входа в систему. Когда запрос попал в соответствующую директорию, IIS вызовет специальный метод аутентификации (Authentication Method). Методы аутентификации настраиваются через Менеджер Интернет Служб (Internet Services Manager (IIS) MMC). На страничке Properties (Свойства) для вебсайта Virtual Directory выберите вкладку Directory Security (Безопасность директории) и нажмите кнопку Edit (Редактировать) в секции Authentication and Access Control (Управление аутентификацией и доступом). Смотрите рисунок 2.

Рисунок 2

Затем, используя RPC через порт TCP 135, IIS аутентифицирует пользователя в контролере доменов. IIS будет также использовать LogonUserEx API (Application Programming Interface) для того, чтобы получить для пользователя Идентификатор Безопасности (Security Identifier, SIS).

После того, как IIS применила метод для входа в систему, на сцену выходит Eprox.dll. Eprox.dll – это DLL, которая управляет коммуникациями между front-end сервером Exchange 2003 и IIS. По умолчанию, на все запросы, которые не направлены определенным приложениям, отвечает Eprox.dll. Используя SID, Eprox.dll запросит Глобальный Каталог (Global Catalog) DSAccess и соберет информацию о пользователе. Эта информация будет включать почтовый ящик пользователя и SMTP адрес. Эта транзакция пройдет через порт 3268 и очень важно знать, если у Вас есть фаервол между вашими серверами.

Теперь, когда Eprox.dll знает SMTP адрес пользователя и у back-end сервера есть почтовый ящик пользователя, она сравнит  путь к Виртуальной Директории Exchange (Exchange Virtual Directory) и SMTP адрес пользователя. Тут может быть по-разному, в зависимости от сервис пака, установленного на машине. В Pre-Exchange 2003 SP1 если они не совпадают пользователю выдастся сообщение об ошибке. Но в Exchange 2003 SP1 это было изменено. И больше уже не требуется совпадение SMTP адреса и Виртуальной Директории Exchange. Eprox.dll теперь передает запрос через TCP 80 на back-end сервер Exchange 2003, который содержит почтовый ящик пользователя.

Теперь, когда запрос попал на back-end сервер, IIS должна определить вебсайт и путь к Виртуальной Директории Exchange (Exchange Virtual Directory). Этот запрос снова аутентифицируется используя LogonUserEX API, но  в этот раз, когда определен метод входа в систему, запрос передается Davex.dll, а не Eprox.dll, как раньше. Davex.dll – это DLL, которая управляет связью между back-end сервером Exchange 2004 и IIS. Теперь Davex.dll использует DSAccess для того, чтобы сделать запрос в Глобальный каталог (Global Catalog) и определить SMTP адрес пользователя и информацию о почтовом ящике. А потом проверяет, соответствует ли эта информация. Опять же, в Pre-Exchange 2003 SP1 если информация не совпадает, то пользователь получит сообщение об ошибке. Но в Exchange 2003 SP1 и более поздних версиях нет уже необходимости в этом соответствие.

Теперь Davex.dll отправит запрос через Epoxy.dll. Epoxy.dll – это DLL, отвечающая за внутренние коммуникации между Exchange 2003 и IIS. Epoxy.dll передаст запрос на Exoledb.dll. Exoledb.dll – это DLL, отвечающая за связь с Хранилищем информации (Information Store). Данные извлекаются из Хранилища и возвращаются по тому же пути к Davex.dll.

Davex.dll берет данные и отправляет их к front-end серверу Exchange через TCP 80. А front-end сервер Exchange возвращает данные клиенту через соответствующий порт, который зависит от того, используется или нет SSL.

Примените свои знания

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

Во-вторых, Exchange 2003 требует как минимум один Контроллер Доменов (Domain Controller), который в тоже время и сервер Глобального Каталога (Global Catalog server) на том же сайте Active Directory. Без доступа к Глобальному Каталогу процесс входа прервется, так как DSAccess не сможет получить нужную информацию из Active Directory.

Заключение

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





Рейтинг:  
4.2 (голосов 5)  
 1   2   3   4   5    

Автор: Родни Бьюик (Rodney Buike)
Родни Бьюик имеет степень Microsoft MVP. Он получил свой сертификат MCSE в области Windows 2000 и 2003. Работает системным инженером в крупной канадской промышленной компании и публикуется на http://thelazyadmin.com.
Эта статья переведена и опубликована с разрешения http://www.msexchange.org

Эта статья переведена силами и средствами компании Red Line Software. Размещение данного переведенного материала на других сайтах без разрешения компании Red Line Software запрещается.





Работает на «Битрикс: Управление сайтом»
Работает на «Битрикс:
 Управление сайтом»
© MSExchange.ru, 2005-2010