
Этосумасшедший, поэтому, пожалуйста, потерпите меня. Это НЕ неправильный пароль.
У меня есть учетная запись SQL Service, которая НЕ проходит аутентификацию. Я опытный серверный парень и пробовал все основы с парой знающих коллег (даже если они ориентированы на Cisco).
Сценарий:
- Active Directory на 3 сайтах с 2 контроллерами домена на каждом и 1 корневым контроллером домена на Server 2008 R2
- Никаких проблем с DNS и репликация сайта на высоте. Любые изменения в аккаунте происходят в течение нескольких секунд.
- Недавно созданный SQL 2016 R2 развернут на 2 серверах Server 2012 R2 в домене, которые находятся в организационном подразделении, где также находится SQL 2005 на Server 2008 R2.
- ВСЕ SQL-серверы находятся в своем собственном vlan, DC в другом. Никаких проблем с брандмауэром между ними, хотя, положа руку на сердце, мы не можем видеть никаких журналов, поскольку они размещены третьей стороной на кластерах ESX с контрактами Cisco между vlan.
- Сервер 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 и отключать шифры. Но пока с этим не слишком много сделано.
Таа ...
Есть ли виртуальный ящик пива для тех, кто знает ответ?
решение1
Управляемые учетные записи услуг(MSA) решил эту проблему. Server 2012 AD использует gMSA, поэтому это меня немного сбило с толку:
В AD (с расширенными параметрами) в Novacroft есть OU под названием Managed Service Accounts. Вы найдете созданные вами MSA там, когда-то созданные с помощью Powershell.
Итак, чтобы установить учетную запись службы:
- Вы создаете учетную запись (без $) с помощью Powershell.
- Затем свяжите учетную запись с сервером — снова с помощью Powershell.
- На целевом сервере установите Powershell и модуль AD в разделе Features и AD tools. Также установите .NET 3.5
- На целевом сервере в Powershell импортируйте учетную запись на хост.
- Затем настройте службы (теперь вам нужно добавить $ в конце) и оставьте пароль пустым.
Легко и просто, а (если знаешь как)? Спасибо NedPyle [MSFT] Полная статьяЗДЕСЬ Я надеюсь, что это помогает кому-то :-)