Несколько месяцев назад мы установили SQL Server 2012 в Windows 2008 R2 под виртуальной учетной записью "Служба NT \ MSSQLSERVER", все хорошо.
Несколько дней назад один из администраторов ИТ-отдела установил компонент полнотекстового поиска на SQL Server 2012 (проблема в том, что он не мог вспомнить, какие именно настройки он выбрал во время установки), и после этого возникает довольно много проблем. :
А. Мы проверили журналы Windows, в приложении мы обнаружили, что MSSQLServer имеет довольно много аномальных журналов, например:
Библиотеке сетевого интерфейса SQL Server не удалось зарегистрировать имя участника-службы (SPN) [MSSQLSvc / FooComputer.FooDomain.com: 1433] для службы SQL Server. Код возврата Windows: 0xffffffff, состояние: 63. Отказ зарегистрировать имя участника-службы может привести к тому, что встроенная проверка подлинности будет использовать NTLM вместо Kerberos. Это информационное сообщение. Дальнейшие действия требуются только в том случае, если проверка подлинности Kerberos требуется политиками проверки подлинности и если имя участника-службы не было зарегистрировано вручную.
Вроде бы причина, но не знаю, почему и как ее решить.
Б. Задания SQL с владельцами, которые являются пользователями домена, например ("MyDomain \ FooUser"), завершатся ошибкой со следующим сообщением:
Работа не удалась. Не удалось определить, есть ли у владельца (MyDomain \ FooUser) задания JOBNAME доступ к серверу (причина: не удалось получить информацию о группе / пользователе Windows NT «MyDomain \ FooUser», код ошибки 0x6e. [SQLSTATE 42000] (Ошибка 15404)).
Мы провели интенсивный поиск, и наконец заменили владельца на «sa» и решили проблему, хотя это не так уж и хорошо. Тем не менее, мы хотели бы выяснить, почему.
С. Невозможно получить доступ к сетевым ресурсам, таким как папка на других компьютерах, например, следующий sql вернет «доступ запрещен»:
DECLARE @CopyCommand nvarchar(1000)
set @CopyCommand = 'dir ' + Char(34) + '\\FooComputer\FooFolder\' + Char(34)
EXEC master..xp_cmdshell @CopyCommand
Для проблемы C, согласно MSDN (http://technet.microsoft.com/en-us/library/ms143504.aspx) мы попытались предоставить полный доступ для учетной записи MyDomain \ SQLServerComputerName $ к папке, но результат тот же.
Все эти три проблемы являются результатом того, что учетная запись, на которой запущена служба SQL, не является учетной записью домена, и все они будут исправлены путем изменения SQL для работы под учетной записью домена. В частности:
A - SPN - это функция безопасности Kerberos, для которой требуется учетная запись домена и которая не работает с локальными учетными записями.
B - для чтения из активного каталога службе требуются учетные данные учетной записи домена
C - Локальные учетные записи не распознаются удаленными компьютерами, поэтому они отклоняют попытку подключения.
Вот пошаговое руководство по изменению учетной записи службы:
Старый вопрос, но, похоже, на него нет правильного ответа. NT Service \ MSSQLSERVER, будучи локальной виртуальной учетной записью, обращается к сети как учетная запись компьютера. И пока учетная запись компьютера имеет доступ к общим ресурсам и файловым системам, вы должны иметь возможность, например, выполнять резервное копирование по UNC-путям в сети. Видеть Настройка учетных записей и разрешений служб Windows.
Когда мы столкнулись с этой проблемой, нашим решением было найти папку и добавить разрешения, необходимые для виртуальной учетной записи, которая в этом нуждается. После того, как мы добавили учетную запись, просто введя ее, мы проверили файлы журнала и обнаружили, что у нас больше нет проблемы с этой папкой / файлом.