Включение протокола Kerberos в Exchange 2013
Спасибо Илье Сазонову за помощь при разборе полетов.
Если среда предприятия состоит из нескольких балансировщиков, то хорошей практикой является использование для них протокола Kerberos и служебной учетной записи.
Допустим, имеется 2010 или 2013 версия продукта, и несколько CAS. Все они без предварительной настройки будут использовать не самый быстрый, надежный и новый протокол. Да-да, не удивляйтесь. :) У них же нет общей учетной записи- клиент идет после autodiscover к CAS , и получив общий для балансировщиков url пробует к нему подключиться по протоколу Kerberos пробуя service/fqdn точки подключения. Разумеется, без SPN нет и Kerberos....
https://fromreallife.files.wordpress.com/2014/11/1.jpg
Давайте посмотрим, как можно исправить ситуацию.
Включение Kerberos в предыдущей версии Exchange было довольно несложным делом, а с приходом 2013 версии продукта шагов стало меньше, включать поддержку стало проще и веселее- OAB конвертировать не нужно, это уже приложение.
Для поддержки kerberos в Exchange2013 нужно провести немного простых действий, которые мы сегодня рассмотрим подробнее.
Для начала проверим, как обстоят дела на виртуальных директориях, выполним в EMS :
Get-OwaVirtualDirectory -Server EX13.mydomen.local -ADPropertiesOnly | fl *Url
https://fromreallife.files.wordpress.com/2014/11/2.jpg?w=700
Нам необходимо поменять директории на всех 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 для обоих серверов в нашем примере:
https://fromreallife.files.wordpress.com/2014/11/3.jpg?w=700
Дальше остается только создать SPN и назначить его для служебного аккаунта:
Создадим аккаунт компьютера
New-ADComputer -Name KERB -AccountPassword (Read-Host 'Enter password' -AsSecureString) -Description 'Alternate Service Account credentials for Exchange' -Enabled:$True -SamAccountName KERB
https://fromreallife.files.wordpress.com/2014/11/4.jpg
И SPN:
setspn.exe -A HTTP/owa.northwindtraders.ru mydomen\KERB$
Проверяем:
setspn.exe -l mydomen\KERB$
https://fromreallife.files.wordpress.com/2014/11/spn.jpg?w=700
Точно такой же SPN зарегистрируем и для autodiscover:
setspn.exe -A HTTP/autodiscover.northwindtraders.ru mydomen\KERB$
Все, самое страшное позади, осталось только показать наши действия Exchange:
Cd $exscripts
.\RollAlternateServiceAccountPassword.ps1 -ToArrayMembers owa.northwindtraders.ru -GenerateNewPasswordFor "mydomen\KERB$" –Verbose
https://fromreallife.files.wordpress.com/2014/11/owa3.jpg?w=700
Дожидаемся выполнения.
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, которые мы прописывали.
https://fromreallife.files.wordpress.com/2014/11/12.png
На этом настройка 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."
https://fromreallife.files.wordpress.com/2014/11/24.jpg
Здесь хочется отметить, что лучше использовать параметр 24, убирающий DES и RC4HMAC, и оставляющий только АЕS.