Запуск пакета служб SSIS, принадлежащего пользователю домена, с сервера SQL Server, запущенного в локальной учетной записи службы

Я хочу запустить пакет служб SSIS, содержащий задачи «Передача объектов SQL Server». Соответствующие серверы находятся в одном домене, но службы SQL Server работают на локальных учетных записях служб. Итак, среда выглядит так:

Домен

Сервер 1

SQL Server работает на локальной учетной записи
В файловой системе: пакет служб SSIS
В агенте SQL Server: работа

Сервер 2

SQL Server работает на локальной учетной записи

Чтобы иметь возможность войти на оба сервера, я создал учетную запись домена для использования в качестве учетной записи службы. Когда я использую эту учетную запись домена для входа на сервер 1, а затем запускаю пакет из файловой системы, каждый шаг завершается успешно. Однако, когда я пытаюсь добавить задание в SQL Server, я сталкиваюсь с одной из следующих проблем:

Ситуация 1. Владелец работы: локальная учетная запись; запустить шаг SSIS в качестве прокси для учетной записи домена . Когда я назначаю владельца задания локальной учетной записью, но запускаю задание в качестве прокси для учетной записи домена, само задание будет успешно выполнено, но пакет выдает такие ошибки, как

Выполнение не выполнено со следующей ошибкой: «Каталог« LocalApplicationData »не существует».

Эту ошибку можно исправить, создав учетную запись с правами администратора для пользователя домена на сервере 1, но это, очевидно, нежелательное решение. Добавление учетной записи в одну из групп агентов SQL Server / DTS также не работает.

Ситуация 2. Владелец работы: учетная запись домена; запустить шаг SSIS в качестве прокси для учетной записи домена . Когда для шага для учетной записи домена я указываю как владельца задания, так и «запускать как пользователя», задание вообще не запускается со следующей ошибкой:

Невозможно определить, имеет ли владелец (домен \ пользователь домена) задания Job nameдоступ к серверу (причина: не удалось получить информацию о группе / пользователе Windows NT «домен \ пользователь домена», код ошибки 0x5. [SQLSTATE 42000] (ошибка 15404)) ,

Я считаю, что последняя ошибка заключается в том, что SQL Server работает на локальной учетной записи и поэтому не может определить, какие учетные записи домена имеют права.

Как правильно запустить работу? Ситуация 2 кажется мне чище, но кажется невозможной, потому что SQL Server работает на локальной учетной записи. Ситуация 1 тоже бы сработала, но предоставление административных прав пользователю домена на моем SQL Server не произойдет.

ОБНОВИТЬ:

@JonSeigel и @ Mr.Brownstone:

Кажется вероятным, что это проблема из-за отсутствия разрешений. Однако ошибка связана с несуществованием «LocalApplicationData» - одной из папок, созданных для каждой учетной записи. Я уже вошел на сервер с учетными данными, под которыми запускается пакет (тем самым создав каталог профиля), и попробовал несколько комбинаций разрешений для каталога профиля. Даже если вручную предоставить почти все разрешения для этого конкретного каталога, я получаю ошибку, упомянутую выше.

Проводя дополнительные исследования, я натолкнулся на ветку форума по адресу http://www.sqlservercentral.com/Forums/Topic391332-148-1.aspx#bm391441, которая довольно похожа - хотя и без решения.

sql-server ssis

— vstrien
источник

Есть ли причина, по которой вы не используете учетную запись домена для служб SQL?

— Эрик Хиггинс

Да, но я не знаю, по какой причине (я предполагаю что-то с циклом DTAP и доменом, доступным не везде). Во всяком случае, это конкретная среда, которую я не могу изменять.

— Встриен

Ситуация № 1, кажется, ответ. Я думаю, что сообщение об ошибке вы получаете из пакета. Другими словами, пакет выполняется, но задача внутри него требует больше разрешений, чем было предоставлено учетной записи службы. Возможно, вам не придется предоставлять разрешения уровня администратора для учетной записи, чтобы сделать ее успешной (вместо этого предоставьте детальные разрешения или измените процесс, чтобы он не нуждался в разрешениях).

— Джон Зигель

Можно ли добавить логины SQL (аутентификация SQL) на удаленный SQL Server (сервер 2)? Если у вас есть эта опция, вы можете использовать SQL Login в соединении SSIS, используемом для пункта назначения. Это означает, что вам придется использовать пароль для шифрования пакета, но это решит вашу проблему.

— Рой Гавиш

@Justicator: Может быть, в крайнем случае. Но всякий раз, когда вход в домен возможен, я предпочитаю не использовать аутентификацию SQL.

— Встриен

Мое личное мнение, что вариант № 1 - это путь. Но я не вижу необходимости для вас предоставлять доступ локальному администратору учетной записи домена. Мне кажется, что для этого требуется доступ к определенным папкам и файлам, и поэтому вы можете предоставить пользователю домена доступ только к тем ресурсам, которые необходимы ему для успешного запуска пакета. Это можно сделать через диалоговое окно свойств файла / папки и выбрать вкладку безопасности - не нужно устанавливать его для каждого файла и папки, так как вы можете установить разрешения родительского каталога и настроить их на переопределение дочерних свойств.

Я надеюсь, это поможет вам.

— Mr.Brownstone
источник