У меня проблема при попытке выполнить массовую вставку в SQL в следующей ситуации:
Когда я пытаюсь выполнить массовую загрузку, я получаю сообщение об ошибке
Cannot bulk load because the file <filename> could not be opened. Operating system error code 5(Access is denied.).
Теперь я знаю, что у нас здесь проблема с двойным прыжком, и нам нужно разобраться с делегированием. SPN настроены для SQL следующим образом (SQL работает на другом порту). SQL работает как пользователь домена, и SPN находятся в этой учетной записи.
command: setspn -l domain\sqluser
result:
MSSQLSvc/WIN-D04V1IOTESN
MSSQLSvc/WIN-D04V1IOTESN.domain.local
MSSQLSvc/win-d04v1iotesn.domain.local:55037
MSSQLSvc/WIN-D04V1IOTESN:55037
Я также установил делегирование от учетной записи пользователя SQL на файловый сервер для Cifs и HOST, но безрезультатно.
Я включил ведение журнала Kerberos и вижу следующее событие в средстве просмотра событий:
A Kerberos Error Message was received:
on logon session
Client Time:
Server Time: 14:44:10.0000 8/9/2011 Z
Error Code: 0xe KDC_ERR_ETYPE_NOTSUPP
Extended Error:
Client Realm:
Client Name:
Server Realm: domain.LOCAL
Server Name: krbtgt/domain.LOCAL
Target Name: krbtgt/domain.LOCAL@domain.LOCAL
Error Text:
File: 9
Line: efb
Error Data is in record data.
Итак, какие-нибудь мысли о том, что мне здесь не хватает? У меня раньше работало такое делегирование, но всегда с SQL на порте по умолчанию, может ли это повлиять?
редактировать
Я также сейчас вижу эту ошибку Kerbors вместе с первой:
A Kerberos Error Message was received:
on logon session
Client Time:
Server Time: 15:4:10.0000 8/9/2011 Z
Error Code: 0xe KDC_ERR_ETYPE_NOTSUPP
Extended Error:
Client Realm:
Client Name:
Server Realm: domain.LOCAL
Server Name: krbtgt/domain.LOCAL
Target Name: krbtgt/domain.LOCAL@domain.LOCAL
Error Text:
File: 9
Line: efb
Error Data is in record data.
Отсутствие времени клиента в вашем сообщении об ошибке вызывает у меня подозрение. Проверка подлинности Kerberos завершится ошибкой, если время на клиенте и время на сервере слишком разные. (Я никогда не был уверен, что такое «слишком разные» на самом деле. Я знаю, что это можно сделать за минуту, потому что вчера у нас была эта проблема (снова) с новым сервером.)
Когда проверка подлинности Kerberos завершается неудачно, SSMS, вероятно, все еще будет подключаться, но он молча вернется к использованию проверки подлинности NTLM.
Вы можете принудительно настроить Kerberos, настроив параметры подключения и строки, чтобы при аутентификации Kerberos соединение не получилось, но есть более простой способ узнать, подключаетесь ли вы с помощью kerberos. Чтобы убедиться, что вы подключены с помощью проверки подлинности Kerberos, подключитесь как обычно через SSMS и запустите это в окне запроса SSMS:
выберите auth_scheme из master.sys.dm_exec_connections, где session_id = @@ spid
Вы должны увидеть «КЕРБЕРОС». Если вы этого не сделаете, вы, вероятно, увидите «NTLM» и узнаете, что что-то не так.
Имя участника-службы выглядит правильно для SQL Server. Правильно ли зарегистрировано SPN для файлового сервера?
Другая вещь, которая может испортить аутентификацию Kerberos для SQL Server, - это проблемы с DNS. Я где-то читал, что клиент sql будет выполнять обратный поиск DNS по адресу сервера и использовать это имя для формирования SPN.
Я знаю, что вы уже сделали многие из этих шагов, но это должно быть все, что вам нужно сделать.
Убедитесь, что разрешение DNS работает правильно как для SQL-сервера, так и для файлового сервера.
Зарегистрируйте SPN для SQL Server. Убедитесь, что нет повторяющихся SPN. setspn в SQL 2008 может сделать эту проверку за вас.
Зарегистрируйте SPN для файлового сервера. Убедитесь, что нет дубликатов.
Включите «доверенный для делегирования» в учетной записи службы SQL Server.
Также убедитесь, что ваш аккаунт не помечен как неделагируемый. (это слово?)
Если вы не можете заставить его работать, вы можете настроить задание агента SQL для отмены массовой вставки. Затем он будет работать под учетной записью, от имени которой вы настроили задание.
Судя по комментариям, вы подключаетесь к SQL с использованием имени входа в домен, поэтому SQL пытается выдать себя за вас при подключении к общей папке. Если у вас не настроено делегирование для этой учетной записи домена, тогда это не удастся.
При запуске сохраненной процедуры, подключенной в качестве входа в систему SQL, SQL попытается использовать учетную запись службы домена, под которой он работает, для которой, как вы говорите, вы уже настроили делегирование.
Если вы подключаете окно запроса с использованием учетной записи службы домена, SQL работает так, как должен работать, поскольку это делегирование уже настроено. Настройте делегирование доверия файловому серверу для своей учетной записи домена, и он должен начать работать.