Настройка проверки подлинности Kerberos для серверов клиентского доступа с балансировкой нагрузки

  • Статья

 

Применимо к: Exchange Server 2010 SP2, Exchange Server 2010 SP3

Последнее изменение раздела: 2016-11-28

Чтобы использовать проверку подлинности Kerberos в массиве серверов клиентского доступа с балансировкой нагрузки, необходимо выполнить несколько шагов. Дополнительные сведения об использовании проверки подлинности Kerberos в массиве серверов клиентского доступа или в решении балансировки нагрузки см. в разделе Использование проверки подлинности Kerberos для массива серверов клиентского доступа или решения балансировки нагрузки.

Создание учетных данных альтернативной учетной записи службы в службе каталогов Active Directory

На всех компьютерах в массиве серверов клиентского доступа необходимо включить общий доступ к одной и той же учетной записи службы. Также необходимо включить общий доступ к этой учетной записи службы на всех серверах клиентского доступа, которые могут быть вызваны в сценарии активации центра обработки данных. Обычно достаточно иметь одну учетную запись службы в лесу. Эта учетная запись называется учетными данными альтернативной учетной записи службы (учетными данными ASA).

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

Тип учетных данных

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

Имя учетных данных

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

Группы и роли

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

Пароль

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

Сценарии с несколькими лесами

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

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

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

  • http Это имя SPN необходимо использовать для веб-служб Exchange, загрузок автономных адресных книг и службы автообнаружения.

  • exchangeMDB Это имя SPN необходимо использовать для клиентского доступа RPC.

  • exchangeRFR Это имя SPN необходимо использовать для службы адресной книги.

  • exchangeAB Это имя SPN необходимо использовать для службы адресной книги.

Формат имен участников-cлужб должен соответствовать формату имени службы в подсистеме балансировки сетевой нагрузки, а не на отдельных серверах.

Чтобы лучше планировать развертывание значений SPN, необходимо рассмотреть следующие концептуальные сценарии:

  1. Один сайт Служба каталогов Active Directory

  2. Несколько сайтов Служба каталогов Active Directory

  3. Несколько сайтов Служба каталогов Active Directory с устойчивостью сайтов группы DAG

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

Одиночный сайт Active Directory

При наличии одиночного сайта Служба каталогов 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. Следовательно, полные доменные имена, используемые этими клиентами, не нужно добавлять в качестве имен участников-служб к учетным данным ASA.

ВажноВажно!
При развертывании разделенной инфраструктуры DNS внешние и внутренние клиенты используют одни и те же полные доменные имена, и эти имена должны быть представлены как имена участников-служб в учетных данных ASA.

Несколько сайтов Active Directory

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

На основе полных доменных имен, которые используются внутренними клиентами Outlook в предыдущем примере, следующие имена участников-служб должны быть развернуты на учетных данных ASA, которые используются для массива серверов клиентского доступа с сайтом ADSite1 Служба каталогов Active Directory:

  • 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 в предыдущем примере, следующие имена участников-служб должны быть развернуты на учетных данных ASA, которые используются для массива серверов клиентского доступа в пределах сайта ADSite2 Служба каталогов Active Directory:

  • http/mailsdc.corp.contoso.com

  • http/autodsdc.corp.contoso.com

  • exchangeMDB/outlooksdc.corp.contoso.com

  • exchangeRFR/outlooksdc.corp.contoso.com

  • exchangeAB/outlooksdc.corp.contoso.com

ПримечаниеПримечание.
Этот пример показывает, что возможно использование нескольких учетных данных ASA для этого конкретного сценария. Однако допускается применение одних учетных данных ASA для всех сайтов Служба каталогов Active Directory, на которых размещены массивы серверов клиентского доступа, где необходимо развертывание проверки подлинности Kerberos.

Несколько сайтов Active Directory с устойчивостью сайтов группы DAG

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

Поскольку данная архитектура содержит группу обеспечения доступности баз данных (DAG), развернутую на обоих сайтах Служба каталогов Active Directory, необходимо развернуть единые учетные данные ASA для использования членами массивов серверов клиентского доступа на сайтах ADSite1 и ADSite2. Если не используются единые учетные данные ASA, то клиенты будут испытывать проблемы с проверкой подлинности Kerberos при переключении центра обработки данных, так как члены массива серверов клиентского доступа дополнительного центра обработки данных не смогут расшифровать билет сеанса Kerberos. Дополнительные сведения об активации дополнительного центра обработки данных см. в разделе Переключения центра обработки данных.

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

  • 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

  • http/mailsdc.corp.contoso.com

  • http/autodsdc.corp.contoso.com

  • exchangeMDB/outlooksdc.corp.contoso.com

  • exchangeRFR/outlooksdc.corp.contoso.com

  • exchangeAB/outlooksdc.corp.contoso.com

Преобразование виртуального каталога автономной адресной книги в приложение

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

Чтобы преобразовать виртуальный каталог автономной адресной книги в веб-приложение, на каждом участнике-сервере клиентского доступа выполните сценарий ConvertOABDir.ps1. Сценарий также создаст новый пул приложений для виртуального каталога автономной адресной книги. Сценарий можно найти в каталоге сценариев Exchange 2010 с пакетом обновления 2 (SP2) или загрузить здесь.

Развертывание учетных данных альтернативной учетной записи службы

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

Затем можно запустить сценарий учетных данных AlternateServiceAccount в командной консоли Exchange. Дополнительные сведения см. в разделе Использование сценария RollAlternateserviceAccountCredential.ps1 в консоли. После выполнения этого сценария рекомендуется убедиться в том, что все целевые серверы правильно обновлены.

ПримечаниеПримечание.
Этот сценарий доступен только на английском языке.

Сведения по устранению ошибок сценария см. в разделе Устранение неполадок сценария RollAlternateServiceAccountCredential.ps1.

В показанном ниже примере выходных данных сценария RollAlternateServiceAccountPassword.ps1 используется учетная запись компьютера, созданная в качестве учетных данных ASA. Эта учетная запись носит имя contoso/newSharedServiceAccountName. В следующем примере сценарий применяет параметры учетных данных к каждому члену массива серверов клиентского доступа с именем outlook.corp.contoso.com.

Чтобы запустить сценарий, используйте следующую команду.

RollAlternateServiceAccountPassword.ps1 -ToArrayMembers outlook.corp.contoso.com -GenerateNewPasswordFor contoso\newSharedServiceAccountName$

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

========== Started at 08/02/2010 15:48:09 ==========Destination servers that will be updated:Name----CASACASBCredentials that will be pushed to every server in the specified scope (recent first):UserName                               Password--------                               --------contoso\newSharedServiceAccountName$                System.Security.SecureStringPrior to pushing new credentials, all existing credentials that are invalid or no longer work will be removed from the destination servers.Pushing credentials to server CASAPushing credentials to server CASBSetting a new password on Alternate Service Account in Active DirectoryPassword changeDo you want to change password for contoso\newSharedServiceAccountName$ in Active Directory at this time?[Y] Yes  [N] No  [S] Suspend  [?] Help (default is "Y"): yPreparing to update Active Directory with a new password for contoso\newSharedServiceAccountName$ ...Resetting a password in the Active Directory for contoso\newSharedServiceAccountName$ ...New password was successfully set to Active Directory.Retrieving the current Alternate Service Account configuration from servers in scopeAlternate Service Account properties:StructuralObjectClass QualifiedUserName       Last Pwd Update     --------------------- -----------------       ---------------     computer              contoso\newSharedServiceAccountName$ 8/2/2010 3:49:05 PM SPNs-----Per-server Alternate Service Account configuration as of the time of script completion:   Array: outlook.corp.contoso.comIdentity  AlternateServiceAccountConfiguration--------  ------------------------------------NAE14CAS  Latest: 8/2/2010 3:48:38 PM, contoso\newSharedServiceAccountName$          Previous: <Not set>NAE14CAS2 Latest: 8/2/2010 3:48:51 PM, contoso\newSharedServiceAccountName$          Previous: <Not set>

Также отобразятся два идентификатора событий в журналах событий. Одно событие предназначено для запуска сценария, а другое — для успешного завершения. Ниже приведен отрывок из события успешного завершения.

Log Name:      ApplicationSource:        MSExchange Management ApplicationEvent ID:      14002Task Category: KerberosLevel:         InformationDescription:Maintenance of the Alternate Service Accounts succeeded.

Проверка развертывания учетных данных 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>

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

Name                                 : NAE14CASAlternateServiceAccountConfiguration : Latest: 8/2/2010 4:32:38 PM, contoso\newSharedServiceAccountName$                                       Previous: 8/2/2010 4:32:24 PM, contoso\sharedkerbacct$Name                                 : NAE14CAS2AlternateServiceAccountConfiguration : Latest: 8/2/2010 4:32:38 PM, contoso\newSharedServiceAccountName$                                       Previous: 8/2/2010 4:32:24 PM, contoso\sharedkerbacct$

Сопоставление имен участников-служб с альтернативной учетной записью службы

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

ПримечаниеПримечание.
Только ОС Windows Server 2008 поддерживает параметр проверки дубликатов на уровне леса (-f) в команде setspn. 
Setspn -q -f exchangeMDB/outlook.corp.contoso.com

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

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

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

Setspn -L contoso\newSharedServiceAccountName$

Проверка проверки подлинности Kerberos для клиентов Exchange

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

Убедитесь, что запущена служба Microsoft Exchange Service Host.

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

Тестирование выполнения проверки подлинности для Outlook

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

  1. Убедитесь, что приложение Outlook настроено на выбор правильного массива серверов клиентского доступа с балансировкой нагрузки.

  2. Настройте параметры безопасности сервера для учетной записи электронной почты на использование параметров безопасного входа в сеть Проверка подлинности с согласованием. Можно также настроить клиент на использование метода Проверка подлинности Kerberos. Однако после удаления имен SPN клиенты не смогут выполнять проверку подлинности, пока механизм проверки подлинности не будет изменен обратно на метод Проверка подлинности с согласованием.

  3. Убедитесь, что функция Outlook Anywhere отключена для этого клиента. Если клиенту Outlook не удастся выполнить проверку подлинности Kerberos, он вернется к использованию функции Outlook Anywhere, поэтому необходимо отключить Outlook Anywhere на время этой проверки.

  4. Перезапустите приложение Outlook.

  5. Если настольный компьютер работает под управлением Windows 7, можно запустить служебную программу klist.exe, чтобы посмотреть, какие билеты Kerberos были предоставлены и используются. Если операционная система Windows 7 не установлена, можно получить программу klist.exe с помощью пакета ресурсов для Windows Server 2003.

Проверка с помощью командлета Test-OutlookConnectivity

Чтобы проверить правильность выполнения проверки подлинности Kerberos, используйте командлет Test-OutlookConnectivity. Это лучший способ проверки возможности подключения по протоколу TCP. По умолчанию этот командлет будет использовать проверку подлинности с согласованием для подключения по протоколу TCP. Поэтому, если проверка подлинности Kerberos настроена, командлет будет использовать ее. Программа klist.exe позволяет просматривать билеты Kerberos на компьютере. Его можно запустить на самом сервере клиентского доступа или с помощью средства автоматического отслеживания, такого как SCOM. При использовании командлета Test-OutlookConnectivity убедитесь, что в качестве значения свойства RPCClientAccessServer базы данных почтовых ящиков установлено имя массива серверов клиентского доступа. В противном случае командлет не будет проверять функциональность общих учетных данных ASA.

Test-OutlookConnectivity -Identity administrator -MailboxCredential $c -Protocol tcp

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

Тестирование выполнения проверки подлинности Kerberos на сервере клиентского доступа

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

  • На сервере клиентского доступа проверьте журналы протокола адресной книги. Эти журналы обычно расположены в следующей папке: C:\Program Files\Microsoft\Exchange server\v14\Logging\AddressBook Service.

  • Просмотрите последний файл журнала и найдите слово Kerberos после выполненного сценария. При отображении сведений о трафике Kerberos подключение установлено успешно. Строка в файле журнала должна выглядеть примерно следующим образом:

    2010-06-11T22:58:49.799Z,9,0,/o=First Organization/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=Administrator,,2001:4898:f0:3031:99f:ce35:750a:8b09,EXCH-A-363,ncacn_ip_tcp,Bind,,6,,,Kerberos,

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

Устранение неполадок, связанных с проверкой подлинности

Существует несколько распространенных ошибок, которые могут произойти при настройке проверки подлинности Kerberos.

Клиентам Outlook, настроенным только на проверку подлинности Kerberos, не удается установить подключение

Если клиенту Outlook, для которого настроено использование только проверки подлинности Kerberos, не удается установить подключение, выполните следующие шаги по устранению этой неполадки.

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

    Если подключение NTLM установлено успешно, но не удалось установить подключение Kerberos, убедитесь, что имена участников служб не зарегистрированы для других учетных записей, кроме альтернативной учетной записи службы. С помощью команды запроса setSPN убедитесь, что эти имена Exchange зарегистрированы для той учетной записи, которая используется общей альтернативной учетной записью службы, как описано выше в этом разделе.

  2. Убедитесь, что на всех серверах клиентского доступа и в службе каталогов Служба каталогов Active Directory используется один пароль. Для этого запустите сценарий в режиме с сопровождением и принудительно назначьте для него создание нового пароля.

  3. Убедитесь, что служба адресной книги Microsoft Exchange работает на серверах клиентского доступа.

  4. Если проверку подлинности по-прежнему не удается выполнить, убедитесь, что в виртуальных каталогах для тех служб, доступ к которым необходимо получить с помощью проверки подлинности Kerberos, включена встроенная проверка подлинности Windows. Проверить методы проверки подлинности можно с помощью командлетов Get-VirtualDirectory. Дополнительные сведения о виртуальных каталогах см. в разделах Общие сведения о виртуальных каталогах Outlook Web App и Общие сведения о виртуальных каталогах веб-служб Exchange.

Сбои службы автообнаружения

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

HTTP/1.1 400 Bad Request
Content-Type: text/html; charset=us-ascii
Server: Microsoft-HTTPAPI/2.0
Date: Tue, 09 Mar 2010 18:06:18 GMT
Connection: close
Content-Length: 346

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN""https://www.w3.org/TR/html4/strict.dtd">

<HTML><HEAD><TITLE>Bad Request</TITLE>

<META HTTP-EQUIV="Content-Type" Content="text/html; charset=us-ascii"></HEAD>

<BODY><h2>Bad Request - Request Too Long</h2>

<hr><p>HTTP Error 400. The size of the request headers is too long.</p>

</BODY></HTML>

Чтобы устранить эту ошибку, увеличьте предельное значение размера заголовка IIS. Дополнительные сведения см. в разделе Документация к IIS.

Текущее обслуживание учетных данных ASA

При необходимости периодического обновления локального пароля для общих учетных данных ASA см. инструкции по настройке запланированной задачи по выполнению регулярного обслуживания пароля в разделе Использование сценария RollAlternateserviceAccountCredential.ps1 в консоли. Отслеживайте выполнение этой запланированной задачи для проверки своевременного переключения паролей и предотвращения возможных простоев проверки подлинности.

Отключение проверки подлинности Kerberos

Чтобы отключить на массиве серверов клиентского доступа проверку подлинности Kerberos, удалите имена участников служб из общей учетной записи службы. Если имена участников служб удалены, то клиенты не будут выполнять проверку подлинности Kerberos, а клиенты, настроенные на использование проверки подлинности с согласованием, будут выполнять проверку подлинности NTLM. Клиенты, настроенные на использование только проверки подлинности Kerberos, не смогут устанавливать подключения. После удаления имен участников служб необходимо также удалить общую учетную запись службы. Можно использовать сценарий обслуживания, чтобы удалить учетные данные для всех членов массива серверов клиентского доступа с помощью параметра toEntireForest, и выбрать параметр сервера -copy, чтобы указать сервер, не имеющий учетных данных Kerberos. Кроме того, может потребоваться перезагрузить все клиентские компьютеры для очистки кэша билета Kerberos.

 © Корпорация Майкрософт (Microsoft Corporation), 2010. Все права защищены.