Сосуществование Exchange 2007/2010 и двойной запрос пароля в OWA

При миграциях довольно часто возникает период, в который старая и новая системы сосуществуют. В это время производится поэтапный перенос данных пользователей из старой системы в новую и переключение клиентских рабочих мест. В момент, когда в организации есть и Exchange 2007, и Exchange 2010, нужно таким образом обеспечить клиентский доступ (извне и изнутри локальной сети) как для тех пользователей, которые ещё “сидят” на старой системе, так и для тех, кто уже переехал на новую.

Рассмотрим следующую модель инфраструктуры: один сайт AD, сервер Exchange 2007, сервер Exchange 2010, публикация сервисов вовне с помощью сервера TMG (включенного в домен). URL для доступа к сервису OWA извне и изнутри сделаем одинаковым: https://mail.contoso.com/owa. Согласно лучшим практикам, настроили перенаправление запросов с 2010 на 2007 с помощью имени legacy.contoso.com. Это значит, на TMG создано 2 публикации OWA (на mail = ES2010 и на legacy = ES2007) с разными слушателями, также на ES2007 CAS в качестве ExternalURL указан legacy.contoso.com. Доступ извне на legacy.contoso.com через DNS завернут на отдельный ip-адрес (что логично).

Что происходит, когда пользователи, чьи почтовые ящики ещё находятся на Exchange 2007, обращаются к серверам по OWA?

Изнутри сети для доменного пользователя будет дважды возникать окошко с просьбой ввода имени и пароля. Первый раз запрос будет от ES2010, второй раз – от ES2007. Это будет не веб-страничка, а окошко basic-аутентификации. Извне сети пользователь увидит два последовательно возникающих окна с запросом пароля: оба от TMG, но от разных правил. Первое – от правила публикации на OWA mail.contoso.com (ES2010), второе – от правила публикации на legacy.contoso.com (ES2007).

Почему так происходит?

Согласно дизайну Exchange, внутри одного сайта AD сервер Exchange 2010 CAS может осуществлять только перенаправление (redirection) запросов на CAS ES2007. Перенаправление будет осуществляться прозрачно (без запроса пароля) только если оба сервера CAS в качестве метода аутентификации используют Forms-Based Authentication (FBA). На эту тему есть замечательная статья, помимо официального источника. Поэтому, так как клиентский доступ изнутри и извне “завёрнут” на ES2010, то сперва он проверяет пользователя, а потом это делает ES2007. Мы помним, что для того, чтобы при публикации OWA проверка пользователя осуществлялась на TMG, нужно отключить FBA в настройках OWA на ES, оставив аутентификацию Basic/Windows. Поэтому на ES2010, как “internet-facing”-сервере, мы FBA включить не можем (иначе пропадёт ценность TMG). На ES2007 включить FBA мы можем, но т.к. требование “FBA на обоих CAS” не выполнено, ES2007 всё равно запросит пароль, только уже в виде веб-странички.

Конечно, пользователям двойной запрос пароля неудобен. Как решать проблему?

Есть несколько способов.

1). Включить FBA на обоих ES CAS, и настроить на TMG проброс пакетов на OWA без аутентификации напрямую на ES2010. Но едва-ли это архитектурно правильно, потому что исключает из процесса TMG. А в некоторых ситуациях (например, если к тому же руководство желает добавить в процесс аутентификацию по сертификатам) – не будет работать.

2). На TMG для mail.contoso.com и legacy.contoso.com создать вместо двух раздельных – одно правило публикации со слушателем FBA и включенным SSO. Можно почитать тут.

3). На время миграции создать группу AD, в которую поместить пользователей, уже перешедших на ES2010 (имею в виду почтовые ящики). Далее создать на TMG два правила публикации. Первое для mail.contoso.com, перенаправляющее на ES2010 CAS. Оно должно применяться только для членов группы AD, созданной шагом ранее. Второе правило публикации, следующее за первым, должно отслеживать запросы на mail.contoso.com, но перенаправлять их на ES2007 CAS. Это правило может выполняться уже для всех проаутентифицировавшихся пользователей. Таким образом, мы исключаем механизм Exchange redirection из алгоритма обработки запросов, и избавляемся от двойного запроса пароля.

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

Что же касается решения вопроса с двойным запросом пароля изнутри локальной сети, то это можно решить, добавив URL https://legacy.contoso.com в список Local Intranet – сайтов в браузере.