Необычная учетная запись службы SQL — служба не запустилась из-за ошибки входа в систему

Question

Этосумасшедший, поэтому, пожалуйста, потерпите меня. Это НЕ неправильный пароль.

У меня есть учетная запись SQL Service, которая НЕ проходит аутентификацию. Я опытный серверный парень и пробовал все основы с парой знающих коллег (даже если они ориентированы на Cisco).

Сценарий:

1. Active Directory на 3 сайтах с 2 контроллерами домена на каждом и 1 корневым контроллером домена на Server 2008 R2
2. Никаких проблем с DNS и репликация сайта на высоте. Любые изменения в аккаунте происходят в течение нескольких секунд.
3. Недавно созданный SQL 2016 R2 развернут на 2 серверах Server 2012 R2 в домене, которые находятся в организационном подразделении, где также находится SQL 2005 на Server 2008 R2.
4. ВСЕ SQL-серверы находятся в своем собственном vlan, DC в другом. Никаких проблем с брандмауэром между ними, хотя, положа руку на сердце, мы не можем видеть никаких журналов, поскольку они размещены третьей стороной на кластерах ESX с контрактами Cisco между vlan.
5. Сервер SQL 2005 без проблем проходит аутентификацию на контроллерах домена в другой VLAN.

Настройка существующей учетной записи службы AD SQL на новых серверах SQL завершается ошибкой 1069: служба не была запущена из-за ошибки входа в систему.

События в журналах событий на контроллерах домена (какой бы из них ни был аутентифицирован аккаунт) содержат следующее:

Предварительная аутентификация Kerberos не удалась. Информация об учетной записи: Идентификатор безопасности: DOMAIN\sqlsvcaccount$ Имя учетной записи: sqlsvcaccount$ (не настоящее имя учетной записи) Информация об услуге: Имя службы: krbtgt/DOMAIN (конечно, это не наше доменное имя) Информация о сети: Адрес клиента: ::ffff:10.30.xx (наш адрес IPv4) Порт клиента: 49464 Дополнительная информация: Параметры тикета: 0x40810010 Код ошибки: 0x18 Тип предварительной аутентификации: 2

Информация о сертификате: Имя издателя сертификата:
Серийный номер сертификата:
Отпечаток сертификата:

Теперь 0x18 обычно плохой пароль, но как уже упоминалось, с учетными записями все в порядке, и когда они отключаются, я снова включаю их, сбрасываю пароль и т. д. и т. д. Я могу выполнить RunAs для приложения на новом сервере SQL, и это отлично работает.

Я установил групповую политику «Компьютер», чтобы разрешить учетной записи службы права на службы и т. д., и запустил gpresult, чтобы подтвердить, что объект групповой политики применен.

Резервное копирование файлов и каталогов DOMAIN\sqlsvcaccount$ Войти как пакетное задание DOMAIN\sqlsvcaccount$ Войти как служба DOMAIN\sqlsvcaccount$

Даже имел ограниченный GPO компьютера и назначил учетную запись домена локальным администратором (что исключило бы необходимость в GPO служб).

Создал новое подразделение пользователя для учетной записи службы с заблокированным наследованием и переместил туда учетную запись службы, снова выполнил gpupdate /force и снова запустил gpresult для html, и все выглядит нормально.

Также несколько раз перезагружаюсь между делом, как обычно.

Мы запустили Wireshark, который не выявил никаких ошибок, переместили сервер SQL в ту же VLAN, что и контроллеры домена, и, как упоминалось ранее, сервер SQL 2005 в VLAN базы данных не испытывает проблем с аутентификацией.

Наконец, создал новое подразделение «Компьютер», заблокировал наследование политик и попробовал все это снова, но попытка запустить SQL Server или службу агента по-прежнему не увенчалась успехом.

Я пробовал использовать инструмент управления SQL для редактирования служб, как и положено, и даже просто Windows Services.msc.

Последнее, что мы начали рассматривать, это шифры и пытается ли Server 2012 аутентифицироваться с помощью RC4 и отключать шифры. Но пока с этим не слишком много сделано.

Таа ...

Есть ли виртуальный ящик пива для тех, кто знает ответ?

Answer 1

Управляемые учетные записи услуг(MSA) решил эту проблему. Server 2012 AD использует gMSA, поэтому это меня немного сбило с толку:

В AD (с расширенными параметрами) в Novacroft есть OU под названием Managed Service Accounts. Вы найдете созданные вами MSA там, когда-то созданные с помощью Powershell.

Итак, чтобы установить учетную запись службы:

1. Вы создаете учетную запись (без $) с помощью Powershell.
2. Затем свяжите учетную запись с сервером — снова с помощью Powershell.
3. На целевом сервере установите Powershell и модуль AD в разделе Features и AD tools. Также установите .NET 3.5
4. На целевом сервере в Powershell импортируйте учетную запись на хост.
5. Затем настройте службы (теперь вам нужно добавить $ в конце) и оставьте пароль пустым.

Легко и просто, а (если знаешь как)? Спасибо NedPyle [MSFT] Полная статьяЗДЕСЬ Я надеюсь, что это помогает кому-то :-)