Спасибо Илье Сазонову за помощь при разборе полетов.

Если среда предприятия состоит из нескольких балансировщиков, то хорошей практикой является использование для них протокола Kerberos и служебной учетной записи.

Допустим, имеется 2010 или 2013 версия продукта, и несколько CAS. Все они без предварительной настройки будут использовать не самый быстрый, надежный и новый протокол. Да-да, не удивляйтесь. :) У них же нет общей учетной записи- клиент идет после  autodiscover к CAS , и получив общий для балансировщиков url пробует к нему подключиться по протоколу Kerberos пробуя service/fqdn точки подключения. Разумеется, без SPN нет и Kerberos....



1



Давайте посмотрим, как можно исправить ситуацию.

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

Для поддержки kerberos в Exchange2013 нужно  провести немного простых действий, которые мы сегодня рассмотрим подробнее.

Для начала проверим, как обстоят дела на виртуальных директориях, выполним в EMS :

Get-OwaVirtualDirectory -Server EX13.mydomen.local -ADPropertiesOnly | fl *Url

2

Нам необходимо поменять директории на всех CAS серверах, для которых мы включаем поддержку Kerberos. В терминологии 2010 мы называли так RPC Endpoint, и, соответственно, CAS Array FQDN.

•             Get-OwaVirtualDirectory -Server EX13.mydomen.local  -ADPropertiesOnly | Set-OwaVirtualdirectory -InternalUrl "https://owa.northwindtraders.ru/owa"

•             Get-EcpVirtualDirectory -Server EX13.mydomen.local  -ADPropertiesOnly | Set-EcpVirtualdirectory -InternalUrl "https://owa.northwindtraders.ru/ecp"

•             Get-WebServicesVirtualDirectory -Server EX13.mydomen.local  -ADPropertiesOnly | Set-WebServicesVirtualDirectory -InternalUrl "https://owa.northwindtraders.ru/EWS/Exchange.asmx"

•             Get-OabVirtualDirectory -Server EX13.mydomen.local  -ADPropertiesOnly | Set-OabVirtualDirectory -InternalUrl "https://owa.northwindtraders.ru/OAB"

•             Get-ActiveSyncVirtualDirectory -Server EX13.mydomen.local  -ADPropertiesOnly | Set-ActiveSyncVirtualDirectory -InternalUrl https://owa.northwindtraders.ru/Microsoft-Server-ActiveSync

Меняем на всех директориях, кроме Аutodiscover, которая не настоящая, как все помнят.

Теперь очередь OutlookAnywhere

Get-OutlookAnywhere -Server EX13.mydomen.local -ADPropertiesOnly | Set-OutlookAnywhere -InternalHostName " owa.northwindtraders.ru " -InternalClientsRequireSsl:$true

Далее создадим две записи DNS типа A для обоих серверов в нашем примере:

3

Дальше остается только создать SPN и назначить его для служебного аккаунта:

Создадим аккаунт компьютера







New-ADComputer -Name KERB -AccountPassword (Read-Host 'Enter password' -AsSecureString) -Description 'Alternate Service Account credentials for Exchange' -Enabled:$True -SamAccountName KERB

4

И SPN:

setspn.exe -A HTTP/owa.northwindtraders.ru mydomen\KERB$

Проверяем:

setspn.exe -l mydomen\KERB$

 spn

Точно такой же SPN зарегистрируем и для autodiscover:

setspn.exe -A HTTP/autodiscover.northwindtraders.ru mydomen\KERB$

Все, самое страшное позади, осталось только показать наши действия Exchange:

Cd $exscripts

.\RollAlternateServiceAccountPassword.ps1 -ToArrayMembers owa.northwindtraders.ru -GenerateNewPasswordFor "mydomen\KERB$" –Verbose

owa3

Дожидаемся выполнения.

C одного сервера на другой можно перенести данные командой

$ASA = Get-Credential -Credential "MYDOMEN\KERB$"

Set-ClientAccessServer -Identity EX13 -AlternateServiceAccountCredential $ASA

.\RollAlternateServiceAccountPassword.ps1 -CopyFrom EX13 -ToSpecificServers EX-14

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

Get-ClientAccessServer -IncludeAlternateServiceAccountCredentialstatus |Fl Name, AlternateServiceAccountConfiguration

Что дальше:

Если изменялись настройки аутенфитикации, выполним:

Get-OutlookAnywhere -Server EX13 -ADPropertiesOnly | Set-OutlookAnywhere -InternalClientAuthenticationMethod Negotiate -IISAuthenticationMethods Negotiate,Ntlm

Get-OutlookAnywhere -Server EX14 -ADPropertiesOnly | Set-OutlookAnywhere -InternalClientAuthenticationMethod Negotiate -IISAuthenticationMethods Negotiate,Ntlm

 Проверка:

Ждем события на сервере в журнале Application ID3025 Источник"MSExchange RPC Over HTTP Autoconfig"

 На клиенте, для быстрого обновления autodiscover просто войдем в свойства профиля и выберем Repair (восстановить). Этим принудительно заберем новые настройки autodiscover, которые не сразу будут отдаваться сервером для клиента.

 Проверяем билеты на клиенте, запустив Outlook и свернув его. Запустим после подключения  команду klist tickets.

Вывод должен показать нам билеты для всех SPN, которые мы прописывали.

12

На этом настройка Kerberos завершена.

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

PS. Update [ ТЗ included]

Хочется добавить 2 вещи. В схватке с Александром Станкевичем мне пришлось применить черную магию и показать, что в настройках 2-х директорий можно явно добавить поддержку только керберос, и ничего более.

Делается это так:

Get-OutlookAnywhere | Set-OutlookAnywhere –InternalClientAuthenticationMethod negoex –IISAuthenticationMethods kerberos

В справке команды можете не искать, их там нет :).

Тоже самое можно включить и для MapiVirtualDirectory.  После этого делаем стандартную очистку пула IIS и проверяем, что клиенты подключились. Это произойдет только по kerberos, поскольку ничего больше для аутентификации мы не задавали. Такая настройка не подразумевает никакого fallback до NTLM, как в первом случае, и вполне применима в среде, где последнего уже нет. Это- раз.

Два: недавно  (опять, не прошло и года :) справку опять обновили, и в нее добавился пункт

"Set-ADComputer EXCH2013ASA -add @{"msDS-SupportedEncryptionTypes"="28"}

Where EXCH2013ASA is the name of the account and the attribute to be modified is msDS-SupportedEncryptionTypes with a decimal value of 28, which enables the following ciphers: RC4-HMAC, AES128-CTS-HMAC-SHA1-96, AES256-CTS-HMAC-SHA1-96."

24

Здесь хочется отметить, что лучше использовать параметр 24, убирающий DES и RC4HMAC, и оставляющий только АЕS.