Когда наши учетные записи gMSA автоматически меняются, мы видим сбои входа в систему в течение примерно 1-10 минут. Это особенно заметно для клиентских учетных записей gMSA, которые подключаются к серверу MS SQL, но я думаю, что это происходит и с другими учетными записями gMSA. Сервер MS SQL не работает как учетная запись gMSA, но наше приложение использует gMSA для клиентского подключения к SQL. По умолчанию ManagedPasswordIntervalInDays — каждые 30 дней, поэтому мы видим это каждый месяц в одно и то же время.
При проверке журналов контроллера домена я не вижу ошибок входа для пользователя gMSA, но сервер SQL регистрирует следующую ошибку:
SSPI handshake не удалось с кодом ошибки 0x8009030c, состояние 14 при установлении соединения с интегрированной безопасностью; соединение было закрыто. Причина: AcceptSecurityContext не удалось. Код ошибки операционной системы указывает на причину сбоя. Попытка входа в систему не удалась [КЛИЕНТ: xxxx]
Насколько я понял, эта ошибка обычно указывает на неправильную комбинацию имени пользователя и пароля.
Это происходит на нескольких клиентах, и каждый в конечном итоге снова начинает подключаться где-то через 1-10 минут. Клиенты не все начинают подключаться одновременно, но, похоже, это происходит случайным образом в пределах этого временного окна.
Сначала я думал, что это может быть связано с репликацией AD измененного пароля, поэтому мы изменили интервал репликации между сайтами по умолчанию на USE_NOTIFY для немедленной репликации. Если бы проблема была в репликации, я бы ожидал увидеть сбои входа на DC, а я не вижу сбоев входа на DC. Я также думал, что, возможно, сервер SQL кэширует токен аутентификации, но если бы это было так, я бы ожидал увидеть, что все клиенты разрешаются одновременно (т. е. когда сервер SQL обновляется). Поскольку каждый клиент начинает работать снова в разное время, это, похоже, не на стороне сервера SQL, а скорее на стороне клиента. Возможно, кэширование пароля gMSA или что-то связанное с тайм-аутом и повторными попытками.
решение1
Мы генерировали ту же ошибку из-за проблемы SPN, которая заставила gMSA пройти аутентификацию на сервере SQL через NTLM вместо Kerberos. Если вы войдете в сервер SQL и проверите сеансы через, sys.dm_exec_connectionsвы должны увидеть список сеансов с NTLM
(Вы также можете использовать его klist sessionsиз cli для просмотра сессий)
Мы смогли сопоставить наши ошибки с изменениями пароля с помощью инструментов анализа журналов, поэтому мы знали, что это было причиной. Я не знаю, как часто SCM обновляет свою копию пароля, но если служба проходит аутентификацию на сервере SQL и использует Kerberos, я считаю, что изменения пароля должны быть независимыми от продолжительности/возобновления сеанса Kerberos, поэтому сгенерированная ошибка является надежным указанием на то, что пароль отправляется на хост сервера SQL через NTLM. После того, как мы исправили нашу проблему с SPN (которая была вызвана дополнительной записью DNS A), сеансы переключились на аутентификацию Kerberos.
решение2
Я обнаружил, что это было связано с тем, как была настроена служба Windows. Служба Windows была настроена как стандартная служба, использующая обычную учетную запись пользователя, которая оказалась учетной записью gMSA, а не как служба Windows, использующая управляемую учетную запись.
Это можно проверить с помощью:
>sc.exe qmanagedaccount ServiceName
[SC] QueryServiceConfig2 SUCCESS
ACCOUNT MANAGED : FALSE
Это можно изменить, запустив
sc.exe managedaccount ServiceName TRUE
После изменения типа управляемой учетной записи службы Windows первоначальное тестирование показало, что вход в систему теперь выполняется успешно во время ротации паролей gMSA.