Рекомендация: используйте аутентификацию Kerberos для MAPI-клиентов

Artykuł
05/16/2011

Главное изменение в Exchange 2010 заключается в том, как клиенты подключаются к почтовому ящику. В отличие от предыдущих версий для доступа к информации в почтовом ящике клиенты больше не подключаются непосредственно к хранилищу на сервере почтовых ящиков . Вместо этого клиенты подключаются к некоторому набору служб на сервере клиентского доступа, и эти службы обращаются от имени пользователя к данным почтового ящика на сервере почтовых ящиков, используя MAPI/RPC.

Это архитектурное изменение предоставляет много преимуществ:

• Для преобразования содержимого тела письма используется один и тот же код для различных типов клиентов.
• Логика проверки данных. Например, управление версиями календаря, которое используется Mailbox Assistant и Calendar Repair Assistant.
• Функции соответствия вроде восстановления отдельных элементов и юридического удержания.
• Улучшение взаимодействия с пользователем во время переключений/отказов путем скрытия сервера почтовых ящиков, который держит активную копию базы.
• Единый интерфейс к информации адресной книги.

Для обеспечения высокой доступности и отказоустойчивости заказчикам следует развертывать несколько серверов клиентского доступа в пределах каждого сайта Active Directory, где расположены серверы почтовых ящиков. Чтобы добиться высокой доступности и отказоустойчивости, вам необходимо внедрить одно или более единых пространств имен, которые отображаются на виртуальные адреса балансировщика нагрузки. Балансировщик нагрузки должен быть сконфигурирован так, чтобы принимать запросы на заданных TCP-портах и обеспечивать сохранение состояния для используемого клиентского протокола.

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

Обычно клиенты/приложения в домене используют для аутентификации либо NTLM, либо Kerberos. Другие клиенты, вроде веб-браузеров, могут также использовать базовую аутентификацию, защищенную с помощью SSL, независимо от расположения клиентов (внутри или снаружи корпоративной сети). То, какой механизм аутентификации используется, фактически зависит от конфигурации и клиента, и сервера: во время установления соединения они договариваются между собой, какую аутентификацию использовать. MAPI поддерживает аутентификацию Kerberos, настройка по умолчанию в Outlook 2007 и более поздних версиях - выбирать наиболее строгую аутентификацию из доступных, но только если режим не Outlook Anywhere.

В Exchange 2010 клиенты MAPI подключаются к массиву серверов, выполняющих балансировку нагрузки, а не к отдельному серверу с его собственной уникальной сетевой идентификацией. Это изменение в архитектуре почтовой системы представляет проблему. В предыдущих версиях Exchange клиенты подключались прямо к серверу почтовых ящиков, который имел единственный идентификатор в сети. Это означало, что клиент при наличии возможности мог использовать аутентификацию Kerberos для установления сеанса с сервером почтовых ящиков.

Чтобы понять поведение предыдущих версий, и то, как оно изменилось в Exchange 2010, давайте посмотрим описание аутентификации Kerberos в документации How the Kerberos Version 5 Authentication Protocol Works:

1. Клиент обращается к центру распространения ключей (Key Distribution Center, KDC) за временным билетом (это сообщение, содержащее идентификатор клиента и – для Windows клиентов – SID-ды), именуемым билетом на выдачу билета (ticket-granting ticket, TGT).
2. Сервис аутентификации (authentication service, AS) создает TGT и генерирует ключ сеанса, который клиент может использовать для того, чтобы шифровать передачу информации с помощью службы выдачи билетов (ticket-granting service, TGS). TGT имеет ограниченное время жизни. В момент, когда клиент получил TGT, он не получил доступ ни к каким ресурсам, даже ресурсам на локальном компьютере.
3. Клиент хочет получить доступ к локальным и сетевым ресурсам. Чтобы получить доступ, клиент посылает запрос к TGS, чтобы получить билет для локального компьютера или сетевого сервера (сервиса). Этот билет называется билетом службы (service ticket). Чтобы получить билет, клиент предоставляет TGT, аутентификатор и имя целевого сервера ( Service Principal Name, SPN).

Важно: SPN-ны являются уникальными идентификаторами для сервисов, работающих на серверах. Любой сервис, который использует аутентификацию Kerberos, должен иметь SPN, чтобы клиенты могли идентифицировать этот сервис в сети. Если SPN для сервиса не определен, клиенты не смогут найти этот сервис. Без правильно установленных SPN-нов аутентификация Kerberos невозможна. Кроме того, в Windows Server 2003 центры распространения ключей не будут создавать билеты службы для учетных записей, которые не имеют SPN.

4. TGS анализирует TGT и аутентификатор. Если они допустимые, то TGS создает билет службы. Идентификатор клиента берется из TGT и копируется в билет службы. Затем этот билет отправляется клиенту.
5. После того, как клиент получил билет службы, он посылает этот билет и новый аутентификатор целевому серверу, к которому нужен доступ. Сервер расшифрует билет, проверит аутентификатор и, если это сервис Windows, создаст маркет доступа (access token) для пользователя на основе SID-дов в билете.
6. При необходимости клиент может запросить, чтобы целевой сервер проверил его собственный идентификатор. Это называется взаимной аутентификацией (mutual authentication). Если запрошена взаимная аутентификация, то целевой сервер возьмет из аутентификатора клиентского компьютера временную метку, зашифрует ее ключом сессии, который предоставляет TGS, и отправит ее клиенту.

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

• exchangeMDB/<FQDN сервера почтовых ящиков>
• exchangeRFR/<FQDN сервера почтовых ящиков>
• exchangeAB/<FQDN сервера почтовых ящиков>

Эти три SPN-на позволяют клиенту, который был сконфигурирован для аутентификации Negotiate или Kerberos, успешно получать билет службы от TGS. В свою очеред,ь сервер почтовых ящиков может расшифровать билет службы, создать маркер доступа и обеспечить доступ к данным почтового ящика.

Exchange 2010, с другой стороны, использует пространство имен балансировки нагрузки для доступа к данным почтового ящика. Полное доменное имя FQDN, которое клиент использует для подключения к Exchange, преобразуется в группу серверов клиентского доступа с балансировкой нагрузки. Учитывая, что SPN может быть зарегистрирован только для одной уникальной сущности в среде Active Directory, это означает, что:

1. Во время установки роли сервера клиентского доступа Exchange Setup не может создать SPN–ны пространства имен балансировки нагрузки, а именно SPN–ны для адресной книги, переадресации и клиентского доступа RPC.
2. Администраторы не могут вручную зарегистрировать SPN–ны пространства имен балансировки нагрузки для каждой учетной записи серверов клиентского доступа.

Чтобы понять эту проблему, и почему любой из выше упомянутых элементов не будет работать, давайте предположим, что профиль Outlook сконфигурирован на использование пространства имен балансировки нагрузки outlook.contoso.com, которое задано в параметре домашнего сервера, и что Outlook подключается к серверу клиентского доступа с именем cas1.contoso.com:

1. Клиент обращается к KDC и получает TGT.
2. Клиент посылает запрос в TGS на основе TGT, аутентификатора и имени целевого сервера. В этом случае имя целевого сервера outlook.contoso.com, а не FQDN сервера клиентского доступа.
3. Клиент получает билет службы и отправляет его в outlook.contoso.com, балансировщик нагрузки случайным образом направляет его, например, на cas1.contoso.com.
4. cas1.contoso.com не может расшифровать этот билет службы, потому что:

а. его имя не совпадает с outlook.contoso.com.
б. этот SPN не связан с cas1.contoso.com или несколько объектов в Active Directory имеют SPN, связанный с необходимым сервисом и outlook.contoso.com.

5. Клиент не может получить access token. используя аутентификацию Kerberos.

В результате, когда почтовый ящик перемещен на Exchange 2010, Outlook и другие MAPI-клиенты, которые сконфигурированы на использование Negotiate, будут, в конце концов, обречены на использование аутентификации NTLM.

Проблемы аутентификации NTLM

Почему использование аутентификации NTLM для Outlook и других MAPI-клиентов – это проблема? Давайте рассмотрим процесс аутентификации:

1. Пользователь запускает Outlook.
2. Компьютер пользователя отправляет запросы на сервер (пространство имен балансировки нагрузки) указанный в профиле Outlook. Эти запросы включают в себя информацию об аутентификации пользователя (другими словами, аутентификацию NTLM).
3. Балансировщик нагрузки направляет эти запросы на один из серверов клиентского доступа в массиве.
4. Сервер клиентского доступа должен проверить учетные данные пользователя. Он делает это путем отправки запроса на контроллер домена, с которым он связан защищенным каналом, запрашивая проверку учетных данных пользователя.
5. Контроллер домена отвечает серверу клиентского досткпа, присылая информацию об учетных данных пользователя.
6.Сервер клиентского доступа генерирует маркер доступа и обслуживает запрос.

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

1. Сервер клиентского доступа использует только один контроллер домена для всех запросов аутентификации. Кроме того, в массиве серверов клиентского доступа не существует механизма распределения нагрузки, который бы гарантировал, что каждый сервер клиентского доступа использует свой контроллер домена для привязки безопасного канала.
2. Windows ограничивает число одновременно создаваемых безопасных каналов. Существует определенное количество потоков, которые могут обрабатывать аутентификацию NTLM (контролируется значением параметра MaxConcurrentAPI, по умолчанию равным 2).

Каждый из этих потоков может работать одновременно только с одним запросом аутентификации. Однако некоторые факторы вроде сетевых задержек, число хопов, через которые запросы аутентификации должны пройти, и объем запросов могут создать узкое место в процессе аутентификации, что приводит к тому, что некоторые из этих транзакций находятся в ожидании больше, чем удаленный клиент может себе позволить. Если у вас высокая нагрузка, то вы скорее всего столкнетесь с этим ограничением, когда клиенты аутентифицируются через NTLM. Вы можете следить за событиями NTLM failure events, используя счетчики производительности для Netlogon (смотрите KB 928576), а так же частоту появления события ID 5783.

Windows Server имеет средства увеличения числа одновременно установленных безопасных каналов до 150, если вы установите KB 975363. Однако увеличение числа одновременно установленных безопасных каналов до 150 также не рекомендуется, так как это может иметь неблагоприятные последствия для производительности контроллера домена.

Создание учетной записи, которая будет использоваться как ASA

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

Вы можете создать учетную запись компьютера или учетную запись пользователя для использования в качестве ASA. Т.к. учетная запись компьютера не позволяет выполнять локальный вход на компьютер, это может упростить политики безопасности по сравнению с использованием учетной записи пользователя, и поэтому это будет предпочтительным решением для ASA. Если вы создаете учетную запись компьютера, то срок действия пароля не ограничен, но мы все же рекомендуем вам периодически обновлять пароль. Локальная групповая политика может задавать максимальный срок жизни учетной записи, а периодически запускаемые сценарии могут удалять учетные записи компьютеров, которые не соответствуют текущим политикам. Чтобы гарантировать, что ваши учетные записи компьютеров не будут удалены как не соответствующие локальным политикам, обновляйте пароли для учетных записей компьютеров. Ваша локальная политика безопасности будет определять, когда пароль должен быть обновлен.

Настройка ASA на серверах клиентского доступа в массиве балансировки нагрузки

Для настройки учетных данных ASA был создан сценарий, который распространяется вместе с Exchange 2010 SP1. Этот сценарий называется RollAlternateServiceAccountPassword.ps1 и расположен в директории Scripts. Дополнительная информация о том, как использовать сценарий, вы найдете в документации Использование сценария RollAlternateserviceAccountPassword.ps1 в консоли.

Преобразование виртуального каталога OAB в приложение

Изначально виртуальный каталог OAB не является веб-приложением, и поэтому не находится под управдением службы Exchange Service Host. В результате запросы аутентификации Kerberos к виртуальному каталогу OAB не могут быть расшифрованы с помощью учетных данных ASA.
Чтобы преобразовать виртуальный каталог OAB в веб-приложение, выполните сценарий ConvertOABVDir.ps1 на каждом из серверов клиентского доступа в массиве. Этот сценарий будет также создавать новый пул приложений для виртуального каталога OAB. Вы можете загрузить сценарий отсюда.

Назначение SPN-нов компьютерной учетной записи ASA

После того, как вы создали учетную запись ASA вы должны определить Exchange service principal names (SPNs), которые будут ассоциированы с учетными данными ASA. Список Exchange SPN-нов может отличаться в вашей организации, но должен включать как минимум следующее:

• http: используйте этот SPN для Exchange Web Services, загрузок адресной книги и сервиса автообнаружения.
• exchangeMDB: используйте этот SPN для сервиса клиентского доступа RPC.
• exchangeRFR: используйте этот SPN для сервиса адресной книги.
• exchangeAB: используйте этот SPN для сервиса адресной книги

Значения SPN должны быть сконфигурированы так, чтобы соответствовать имени используемому на балансировщике нагрузки, а не именам отдельных серверов.

Например, если у вас единственный сайт Active Directory, то ваше окружение может выглядеть примерно так:

Исходя из полных доменных имен, которые использованы внутренними клиентами Outlook на предыдущем рисунке, должны быть созданы следующие SPN-ны для учетных данных ASA:

• http/mail.corp.contoso.com
• http/autod.corp.contoso.com
• exchangeMDB/outlook.corp.contoso.com
• exchangeRFR/outlook.corp.contoso.com
• exchangeAB/outlook.corp.contoso.com

Внешние клиенты (Интернет), которые используют Outlook Anywhere, не могут использовать аутентификацию Kerberos, т.к. они не подключаются напрямую к KDC. Поэтому полные доменные имена, которые используются этими клиентами, не должны добавляться как SPN-ны для учетных данных ASA.

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

Дополнительная информация, в том числе о том, как планировать, какие SPN-ны вы должны прописать для учетных данных ASA, находится в документации Настройка проверки подлинности Kerberos для серверов клиентского доступа с балансировкой нагрузки.

Заключение

Из-за ограничений при использовании аутентификации NTLM, Microsoft рекомендует внедрять решение с учетными данными ASA, так чтобы клиенты Outlook, так же как и другие MAPI-клиенты, могли использовать аутентификацию Kerberos.

Росс Смит IV

Перевод: Илья Сазонов, MVP

Udostępnij za pośrednictwem