Команда,
Среда Exchange - это все 2016, без всякой смеси. Родительский и дочерний домены существуют, но функциональный уровень каждого домена и леса - 2012R2. До недавнего времени все контроллеры домена были 2012R2. Команда AD (отличная от меня) представила контроллеры домена Server 2016, и я думаю, что это вызвало проблему. Вот симптомы:
Почта застревает на серверах в родительском домене с местом назначения в дочернем домене. Ошибка в очереди: «454 4.7.0 Temporary Authentication error», а соответствующие события в журнале событий - это событие с идентификатором 2017, источник: MSExchangeTransport, сообщение:
«Исходящая аутентификация не удалась с ошибкой KdcUnknownEncryptionType для соединителя отправки Внутриорганизационный соединитель отправки SMTP. Механизм аутентификации - ExchangeAuth. Целевой объект - SMTPSVC / server fqdn».
Почта будет без проблем перетекать из дочернего домена в родительский. Как я уже сказал ранее, я считаю, что наиболее существенное изменение, которое произошло, - это просто введение контроллеров домена Server 2016. Чтобы исправить это временно, я могу перезагрузить сервер, на котором застряли сообщения, и он будет работать некоторое время. Это действительно похоже на проблему с Kerberos.
РЕДАКТИРОВАТЬ: У нас также настроен ASA, но поддерживаемые типы шифрования между всеми моими серверами обмена, контроллерами домена и этим ASA - «28».
Поиск в Google предполагает проблемы с синхронизацией времени, но я проверил как серверы Exchange, так и контроллеры домена, и все, похоже, точно синхронизируется. Я также проверил работоспособность репликации, и, похоже, с этим нет никаких проблем. Я также проверил наличие повторяющихся или искаженных имен SPN и ничего не нашел. Есть ли что-то еще, что я могу узнать о SPN? Например, какое шифрование они запрашивают / используют или что-то в этом роде? Я мало что знаю о Kerberos.
РЕДАКТИРОВАТЬ: В качестве еще одного примечания, используя GPO, я удалил RC4-HMAC с целевого сервера. В результате klist tickets команда показывала правильный "AES ...", но затем мой PowerShell был сломан ... "Возможные причины" были:
Затем предлагается попробовать добавить целевой компьютер в список WinRM TrustedHosts.
Я думаю, вы можете сначала проверить SPN, вы можете запустить «SetSPN -L <ExchangeServerName>», Чтобы проверить конфигурацию SPN. Он должен содержать:
SMTP/<ExchangeServerName>
SMTP/<ExchangeServerName>.example.com
SMTPSVC/<ExchangeServerName>
SMTPSVC/<ExchangeServerName>.example.com
Если кто-то пропустит, ты можешь бежать "setspn -a <data>" добавить.
А затем, на стороне клиента, запустите «klist Tickets» в CMD, чтобы проверить тип билета. Обычно это должно быть «AES-256-CTS-xxx».
Вот связанный блог о типах билетов: https://blogs.msdn.microsoft.com/openspecification/2011/05/30/windows-configurations-for-kerberos-supported-encryption-type/
Кроме того, согласно моим исследованиям, начиная с Windows Server 2016, KDC могут поддерживать расширение свежести PKInit. Может быть, вы могли бы также проверить этот момент.
Похоже, что RC4 был разрешенным типом шифрования Kerberos на контроллерах домена 2012 года, а ваша группа AD представила контроллеры домена 2016 года с отключенным RC4. Я говорю это с некоторой уверенностью, потому что это рекомендуемый параметр безопасности для Server 2016. Цель состоит в том, чтобы удалить RC4 из среды, но не без предварительного обновления ваших критически важных приложений для поддержки AES. Я предлагаю убедиться, что разрешенные типы шифрования Kerberos настроены одинаково на всех контроллерах домена, а затем включить аудит успешности билета службы Kerberos на всех контроллерах домена, чтобы увидеть, какие приложения все еще пытаются использовать RC4. Он будет отображаться в EventId 4769 с типом шифрования 0x17. Если вы видите это, значит используется RC4. Вам необходимо убедиться, что все задействованные учетные записи пользователей, учетные записи компьютеров и политика Kerberos на каждом сервере (включая контроллеры домена) правильно настроены для работы AES.