В процессе загрузки свежее установленного экземпляра SQL Server в его логе можно обнаружить ошибку регистрации SPN, в случае если службы SQL Server запускаются от имени пользовательской доменной учетной записи.
Необходимо зарегистрировать имя участника-службы (SPN — Service Principal Name) для учетной записи службы SQL Server, чтобы в работе службы могла использоваться проверка подлинности с помощью протокола Kerberos.
Для того, чтобы получить информацию о том, что на доменной учетной записи, от имени которой производится запуск SQL Server действительно не зарегистрировано SPN связанных с SQL с помощью утилиты SetSPN выполним команду вида:
SetSPN -L <Domain SQL Service Account>
В нашем примере KOM-AD01-DB03 - это имя сервера SQL, а s-KOM-AD01-DB03-SQL01 - это имя пользовательской доменной учетной записи, из под которой запускаются службы SQL Server на этом сервере.
Как мы видим, ни на учетной записи компьютера ни на учетной записи пользователя нет SPN содержащих указатели MSSQLSvc
Помимо утилиты SetSPN мы можем воспользоваться оснасткой “AD Users and Computers” (dsa.msc) с включенным режимом отображения дополнительных компонент…
…открыв свойства соответствующей учётной записи и перейдя на вкладку редактирования атрибутов можно посмотреть и изменить значение атрибута servicePrincipalName
Особенности работы с Kerberos аутентификацией в SQL Server (и в частности управление SPN) рассмотрены в статье KB319723 - How to use Kerberos authentication in SQL Server
Для того чтобы обеспечить нужное для корректной работы Kerberos содержание атрибута servicePrincipalName можно пойти двумя путями:
1) Создать необходимую SPN запись вручную с помощью утилиты SetSPN
Синтаксис команд будет следующий:
setspn -a MSSQLSvc/SQLServerFQDN:1433 Domain\SQLAccount setspn -a MSSQLSvc/SQLServerFQDN Domain\SQLAccount
2) Разрешить учетной записи, от имени которой запускается SQL Server, динамическое обновление атрибута servicePrincipalName, выдав разрешения на чтение и запись этого атрибута.
Для того чтобы выполнить второй вариант, откроем оснастку ADSIEdit.msc, перейдём к свойствам объекта – учетной записи. На закладке “Безопасность” (Security) нажмём кнопу “Дополнительно” (Advanced)
В диалоговом окне «Дополнительные параметры безопасности» (Advanced Security Settings) нажмём кнопку «Добавить» (Add) …
… введём SELF и в открывшемся окне перейдём на закладку «Свойства» (Properties). В окне выбора области применения выберем пункт «Только этот объект» (This object only) и в списке разрешений отметим два пункта:
- Read servicePrincipalName
- Write servicePrincipalName
Сохраним внесённые изменения и затем, при запуске службы SQL Server, сможем убедиться в том, что в журнале регистрации событий появилась запись об успешном создании SPN
..а так же увидим что вывод утилиты SetSPN изменился…
Дополнительная информация:
Обратная ссылка: Useful MS SQL links « Share IT /
Подскажите, пожалуста, что за лог вьювер показан на 1м скриншоте?
Это утилита просмотра логов SQL Server встроенная в SQL Server Management Studio
Обратная ссылка: Разворачиваем SCOM 2012 – Часть 1– Подготовка « ИТ Блог Алексея Максимова /
Обратная ссылка: SCCM2012. Немного о Data Replication и SPN | slblogspot /