Включение протокола Kerberos в Exchange 2013


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

Технет оригинал

Если среда предприятия состоит из нескольких балансировщиков, то хорошей практикой является использование для них протокола 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. Не давайте статье на технете ввести себя в заблуждение. Никто про этот параметр блогах не писал, в чем вы легко удостоверитесь, открыв первые 5 бложиков, описывающих включение поддержки kerberos для exchnage. Я применяю их в консалтинге, и время от  времени делюсь ТЗ, когда про них вспоминаю.

Реклама

Добавить комментарий

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

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s