У меня есть пара узлов Microsoft SQL Server 2016 в группе доступности всегда. Я пытаюсь выполнить BULK INSERT
(используя запрос SQL Server 2016 Management Studio) файл, расположенный в отказоустойчивом кластере файлового сервера Windows Server 2016, но получаю следующую ошибку:
Сообщение 4861, уровень 16, состояние 1
Не удается выполнить массовую загрузку, поскольку файл "\ nas2.my.domain \ Microsoft SQL Server 2016 Enterprise \ test.txt" не может быть открыт. Код ошибки операционной системы 5 (доступ запрещен.).
Это произойдет независимо от того, использую я имя активного узла ( nas2.my.domain
) или прослушиватель отказоустойчивого кластера ( nas.my.domain
).
После осмотра я обнаружил, что это связано с тем, что SQL Server не может выдать себя за учетную запись пользователя, с которой я связан из-за нюансов BULK INSERT
.
Если вы подключаетесь к SQL Server с использованием аутентификации Windows, учетная запись службы SQL Server пытается выдать себя за вашу учетную запись при подключении к файловому серверу. Если вы подключаетесь с использованием аутентификации SQL Server, он подключается к файловому серверу в качестве учетной записи службы SQL Server.
Если делегирование и олицетворение не настроены должным образом (состояние по умолчанию), служба SQL Server не сможет олицетворять вашу учетную запись пользователя и обратится к попытке подключения к файловому серверу в качестве анонимного пользователя.
В этом можно убедиться, просмотрев журнал событий безопасности на файловом сервере. Эти факты вместе с руководством по настройке неограниченного и ограниченного делегирования описаны в следующих ссылках:
Я попытался следовать инструкциям в руководстве thesqldude , но он все еще не работает.
База данных, к которой я пытаюсь обратиться, BULK INSERT
не является частью группы доступности, поэтому должен быть релевантным только узел MSSQL1. Файловый сервер был активен на узле NAS2. Проверка журнала событий на файловом сервере действительно показывает, что он все еще страдает от этой проблемы, и SQL Server пытается пройти проверку подлинности на файловом сервере как анонимный пользователь, а не выдавать себя за мою учетную запись.
Кто-нибудь знает, что идет не так? Или что-то изменилось в SQL Server 2016, чтобы сделать эти руководства устаревшими?
- Запись в журнале событий безопасности файлового сервера
- Делегирование сервисной учетной записи
- SPN учетной записи службы
- SQL Server # 1 Делегирование учетных записей компьютеров
- Файловый сервер № 2 SPNs учетной записи компьютера
- Объекты групповой политики
sys.dm_exec_connections
- Kerberos
Я могу подтвердить, что этот объект групповой политики был применен к MSSQL1 с помощью gpresult.exe /R
, а затем узлы SQL и Файловый сервер были перезагружены, чтобы обеспечить очистку любых кэшей.