Проверка подлинности Kerberos для подключения клиента MAPI к массиву серверов клиентского доступа

  • Статья
  • Применяется к:
    Exchange Server 2010

Сводка

Для развертываний Microsoft Exchange Server 2010, имеющих несколько серверов клиентского доступа на сайте Active Directory, топологии часто требуется массив серверов клиентского доступа и решение балансировки нагрузки для распределения трафика между всеми серверами клиентского доступа на сайте. Из-за изменений в Exchange Server 2010 почтовые клиенты MAPI не могут использовать проверку подлинности Kerberos для подключения к почтовому ящику при использовании массива серверов клиентского доступа. Чтобы обойти это поведение, Microsoft Exchange Server с пакетом обновления 1 (SP1) включает новые функции, позволяющие настроить проверку подлинности Kerberos для почтовых клиентов MAPI в массиве серверов клиентского доступа.

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

Рекомендация. Включение проверки подлинности Kerberos для клиентов MAPI

Дополнительные сведения

Служба узла службы Microsoft Exchange, которая работает на сервере клиентского доступа (CAS), расширена в Exchange Server 2010 с пакетом обновления 1 (SP1) для использования учетных данных общей альтернативной учетной записи службы (ASA) для проверки подлинности Kerberos. Это расширение узла службы отслеживает локальный компьютер. При добавлении или удалении учетных данных обновляются пакет проверки подлинности Kerberos в локальной системе и контекст сетевой службы. После добавления учетных данных в пакет проверки подлинности все службы клиентского доступа могут использовать их для проверки подлинности Kerberos. Сервер клиентского доступа также сможет проверять подлинность запросов служб, адресованных напрямую, в дополнение к использованию учетных данных ASA. Это расширение, известное как служба, запускается по умолчанию и не требует выполнения настройки или действий по запуску.

Возможно, вам потребуется использовать проверку подлинности Kerberos для организации Exchange Server 2010 по следующим причинам:

  • Для локальной политики безопасности требуется проверка подлинности Kerberos.

  • Вы столкнетесь с проблемами масштабируемости NTLM, такими как прямое подключение MAPI к службе клиентского доступа RPC, что приводит к периодическим сбоям NTLM.

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

Чтобы настроить проверку подлинности Kerberos, вы должны быть знакомы с Active Directory и настройкой массивов серверов клиентского доступа. Вы также должны иметь рабочие знания о проверке подлинности Kerberos.

Чтобы развернуть учетные данные ASA для проверки подлинности Kerberos, выполните следующие действия.

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

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

Создайте учетную запись компьютера вместо учетной записи пользователя для альтернативной учетной записи службы (ASA), так как учетная запись компьютера не разрешает интерактивный вход. Таким образом, учетная запись компьютера может иметь более простые политики безопасности, чем учетная запись пользователя, и является предпочтительным решением для учетных данных ASA.

Дополнительные сведения о создании учетной записи компьютера см. в разделе Создание учетной записи компьютера.

Примечание.

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

Примечание.

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

Нет особых требований к имени учетных данных ASA. Можно использовать любое имя, следующее за схемой именования. Учетным данным ASA не требуются специальные привилегии безопасности. Если вы развертываете учетную запись компьютера для учетных данных ASA, это означает, что учетная запись должна быть членом группы безопасности "Компьютеры домена". Если вы развертываете учетную запись пользователя для учетных данных ASA, это означает, что учетная запись должна быть только членом группы безопасности "Пользователи домена".

Определение имен субъектов-служб для связывания с учетными данными альтернативной учетной записи службы

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

  • http Используйте это имя субъекта-службы для веб-служб Exchange, загрузки автономной адресной книги и службы автообнаружения.
  • exchangeMDB Используйте это имя субъекта-службы для клиентского доступа RPC.
  • exchangeRFR Используйте это имя субъекта-службы для службы адресной книги.
  • exchangeAB Используйте это имя субъекта-службы для службы адресной книги.

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

Снимок экрана: малый бизнес, содержащий один сайт Active Directory.

Чтобы определить имена субъектов-служб, которые будут использоваться в этом примере, необходимо просмотреть полные доменные имена (FQDN), которые используются внутренними клиентами Outlook на предыдущем рисунке. В этом примере вы развернете следующие имена субъектов-служб в учетных данных 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, не будут использовать проверку подлинности Kerberos. Поэтому вам не нужно добавлять полные доменные имена, которые эти клиенты используют в качестве имен субъектов-служб, в учетные данные ASA.

Если ваш сайт больше одного сайта Active Directory, дополнительные примеры см. в разделе Настройка проверки подлинности Kerberos для серверов клиентского доступа Load-Balanced .

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

Виртуальный каталог автономной адресной книги (OAB) не является веб-приложением. Таким образом, он не контролируется службой узла службы Microsoft Exchange. В результате учетные данные ASA не могут расшифровать запросы проверки подлинности Kerberos в виртуальный каталог OAB.

Чтобы преобразовать виртуальный каталог OAB в веб-приложение IIS, выполните скрипт ConvertOABVDir.ps1 для каждого члена CAS. Скрипт также создаст пул приложений с именем MSExchangeOabAppPool для виртуального каталога OAB. Чтобы скачать скрипт, перейдите на страницу ConvertOABDir.ps1 в Центре сценариев Майкрософт.

Развертывание учетных данных ASA для членов CAS

Exchange Server 2010 с пакетом обновления 1 (SP1) включает скрипт для развертывания учетных данных ASA. Скрипт называется RollAlternateServiceAccountPassword.ps1 и находится в каталоге Скрипты.

Чтобы использовать скрипт для отправки учетных данных на все серверы клиентского доступа в лесу для первой настройки, выполните следующие действия.

  1. В командной консоли Exchange выполните следующую команду:

    .\RollAlternateserviceAccountPassword.ps1 -ToEntireForest -GenerateNewPasswordFor "Your_Domain_Name\Computer_Account_Name$" -Verbose

  2. Выполните следующую команду, чтобы запланировать запланированную задачу автоматического роллинга паролей раз в месяц с именем Exchange-RollAsa. Эта задача, запланированная командой, обновит учетные данные ASA для всех серверов клиентского доступа в лесу новым паролем, созданным скриптом. Запланированная задача создана, но сценарий не запущен. При выполнении запланированной задачи сценарий запускается в автоматическом режиме.

    .\RollAlternateServiceAccountPassword.ps1 -CreateScheduledTask "Exchange-RollAsa" -ToEntireForest -GenerateNewPasswordFor "Your_Domain_Name\Computer_Account_Name$"

Дополнительные сведения об использовании скрипта RollAlternateserviceAccountPassword.ps1 см. в статье Использование скрипта RollAlternateserviceAccountPassword.ps1 в оболочке .

Проверка развертывания учетных данных ASA

В командной консоли Exchange выполните следующую команду, чтобы проверка параметры на серверах клиентского доступа:Get-ClientAccessServer -IncludeAlternateServiceAccountCredentialStatus | fl name,*alter*

Результат этой команды будет выглядеть следующим образом:

Name : CASAAlternateServiceAccountConfiguration : Latest: 8/2/2010 3:48:38 PM, contoso\newSharedServiceAccountName$ Previous: <Not set>Name : CASBAlternateServiceAccountConfiguration : Latest: 8/2/2010 3:48:51 PM, contoso\newSharedServiceAccountName$ Previous: <Not set>

Связывание имен субъектов-служб с учетными данными ASA

Перед настройкой имен субъектов-служб убедитесь, что целевые имена субъектов-служб еще не настроены для другой учетной записи в лесу. Учетные данные ASA должны быть единственной учетной записью в лесу, с которой связаны эти имена субъектов-служб. Вы можете убедиться, что ни у другой учетной записи в лесу нет связанных имен субъектов-служб, открыв командную строку и выполнив команду setpn с параметрами –q и –f . В следующем примере показано, как выполнить эту команду. Команда должна не возвратить никаких данных. Если возвращается значение, с имени субъекта-службы, которое вы хотите использовать, уже связана другая учетная запись.

Примечание.

Вы можете использовать параметр для проверки дубликатов леса (-f) вместе с командой setpn на компьютерах под управлением Windows Server 2008.

Setspn -q -f exchangeMDB/outlook.**domain.domain.domain_root**

В этой команде exchangeMDB/outlook.domain.domain.domain_root — это имя субъекта-службы для клиентского доступа RPC, например exchangeMDB/outlook.corp.contoso.com.

Следующая команда показывает, как задать имена субъектов-служб для общих учетных данных ASA. Необходимо выполнить команду setpn с этим синтаксисом один раз для каждого целевого имени субъекта-службы, которое вы идентифицируете.

Setspn -S exchangeMDB/outlook.corp.contoso.com contoso\newSharedServiceAccountName$

После настройки имен субъектов-служб убедитесь, что они были добавлены, выполнив следующую команду.

Setspn -L contoso\newSharedServiceAccountName

После успешной настройки Kerberos и развертывания скрипта RollAlternateServiceAccountPasswordl.ps1 убедитесь, что клиентские компьютеры могут успешно пройти проверку подлинности.

Проверка работы службы Microsoft Exchange Service Host

Убедитесь, что вы установили Exchange Server 2010 с пакетом обновления 1 (SP1) 3 или более поздней версии на всех серверах клиентского доступа в вашей среде. Служба узла службы Microsoft Exchange на серверах клиентского доступа отвечает за управление учетными данными ASA. Если эта служба не запущена, проверка подлинности Kerberos не будет работать. По умолчанию служба настроена для автоматического запуска при запуске компьютера. Чтобы убедиться, что служба запущена, выполните следующие действия.

  1. Откройте службы в cas-сервере. Чтобы открыть компонент "Службы", нажмите кнопку Пуск, выберите пункт Панель управления, дважды щелкните значок Администрирование, а затем дважды щелкните значок Службы.
  2. В списке служб найдите службу узла службы Microsoft Exchange.
  3. В столбце Состояние убедитесь, что состояние запущено. Если служба не запущена, щелкните правой кнопкой мыши службу узла службы Microsoft Exchange и выберите пункт Пуск. Чтобы настроить автоматический запуск службы, щелкните правой кнопкой мыши службу узла службы Microsoft Exchange, выберите пункт Свойства, выберите пункт Автоматическив списке Тип запуска и нажмите кнопку ОК.
    Проверка подлинности из Outlook

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

  1. Убедитесь, что Outlook настроен для указания правильного массива серверов клиентского доступа с балансировкой нагрузки.
  2. Настройте параметры безопасности сервера учетной записи электронной почты для использования проверки подлинности согласования безопасности сети для входа. Примечание. Вы можете настроить клиент для использования проверки подлинности по паролю Kerberos, но если имена субъектов-служб когда-либо будут удалены, клиентские компьютеры не смогут пройти проверку подлинности, пока не измените механизм проверки подлинности обратно на Согласование проверки подлинности.
  3. Убедитесь, что для клиентского компьютера не включено приложение Outlook Anywhere. Если Outlook не удается пройти проверку подлинности с помощью проверки подлинности по паролю Kerberos, он попытается вернуться к Outlook Anywhere, поэтому для этого теста outlook Anywhere должен быть отключен.
  4. Перезапустите Outlook.
  5. Если настольный компьютер работает под управлением Windows 7, можно запустить klist.exe, чтобы узнать, какие билеты Kerberos предоставляются и используются. Если вы не используете Windows 7, вы можете получить klist.exe из комплекта ресурсов Windows Server 2003.

Дополнительные ресурсы

Подробные сведения об этой проблеме и ее устранении см. в следующей статье TechNet:

Использование проверки подлинности Kerberos для массива серверов клиентского доступа или решения балансировки нагрузки

Дополнительные сведения об использовании проверки подлинности Kerberos на серверах клиентского доступа с балансировкой нагрузки см. в следующей статье TechNet:

Настройка проверки подлинности Kerberos для серверов клиентского доступа Load-Balanced