У меня есть два сервера A и B. B - сервер базы данных, A - (здесь) клиент для сервера базы данных. Инструмент, работающий на сервере A, подключается к SQL Server на сервере B и в конечном итоге запускает массовый импорт из общего ресурса на сервере A (\\ servera \ fileshare).
Инструмент на сервере A работает как локальная система. domain \ servera $ имеет необходимый доступ к SQL Server на сервере B.
Проблема в том, что SQL Server на сервере B не может получить доступ к \\ servera \ fileshare, несмотря на то, что учетная запись службы SQL имеет все разрешения для этого (на сервере A). Я выяснил, что это связано с тем, что SQL Server пытается делегировать подключение к учетной записи, которую утилита использует для подключения к SQL Server, и это не удается, поскольку учетная запись службы SQL Server не имеет права делегировать (и этот параметр не может быть изменен с помощью меня).
Я также обнаружил, что если я подключаюсь с использованием учетной записи SQL (т.е.не учетной записи Active Directory) с использованием проверки подлинности SQL (а не проверки подлинности Windows), SQL Server подключается к общей папке с помощью учетной записи службы SQL Server, и все работает. К счастью, инструмент поддерживает использование учетной записи SQL. К сожалению, пароль задается в виде обычного текста как параметр командной строки, а затем появляется в списке процессов среди всех других параметров. Это не хорошо.
Есть ли способ заставить SQL Server использовать свою собственную учетную запись службы при подключении к общей папке без использования учетной записи SQL для подключения к SQL Server?
Это SQL Server 2008 на Windows Server 2003.
К сожалению, поведение, свидетелем которого вы стали, является преднамеренным:
http://msdn.microsoft.com/en-us/library/ms188365.aspx [Делегирование учетной записи безопасности (выдача себя за другое лицо)] http://msdn.microsoft.com/en-us/library/ms175915.aspx [Соображения безопасности] http://msdn.microsoft.com/en-us/library/ms161965.aspx
По второй ссылке:
Способ, которым SQL Server 2005 и более поздние версии управляют доступом к файлам, решает проблему безопасности, которая присутствовала в Microsoft SQL Server 2000 и более ранних версиях. Раньше после аутентификации пользователя доступ к внешним файлам основывался на профиле безопасности процесса SQL Server. Когда у процесса SQL Server был доступ для чтения к файлу, для пользователя, который не имел доступа к файлу, но был членом фиксированной серверной роли bulkadmin, пользователь мог импортировать файл с помощью BULK INSERT и получить доступ к содержимому файл.
Единственные варианты: либо использовать учетную запись SQL Server, либо предоставить SQL Server необходимые права для выполнения делегирования.
Возможным решением может быть выполнение задания по копированию файла с ServerA на ServerB (я предполагаю, что ваша учетная запись службы имеет доступ на запись к ним обоим), а затем SQL Server на ServerB выполняет импорт со своего локального диска.
Вы можете сопоставить свои логины Windows с учетные данные имеющий доступ:
create credential [...] with identity='domain\user', secret='domainpassword';
alter login [...] with credential=[...];
Однако будьте осторожны, чтобы не дублировать AD в хранилище учетных данных SQL. И вам необходимо разработать способ синхронизации базы данных учетных данных SQL Server с AD (изменение пароля и т. Д.).
Запустите его как задание из агента sql server