Запуск пакета SSIS, який належить користувачеві домену з SQL Server, який працює на локальному обліковому записі служби


10

Я хочу запустити пакет SSIS, що містить завдання передачі об’єктів SQL Server. Задіяні сервери знаходяться в одному домені, але послуги SQL Server працюють на локальних облікових записах сервісу. Отже, оточення виглядає приблизно так:

Домен

Сервер 1

  • SQL Server працює на локальному акаунті
  • У файловій системі: пакет SSIS
  • В агенті SQL Server: завдання

Сервер 2

  • SQL Server працює на локальному акаунті

Щоб мати можливість увійти на обидва сервери, я створив обліковий запис домену, який буде використовуватися як обліковий запис служби. Коли я використовую цей обліковий запис домену, щоб увійти на сервер 1, а потім виконати пакет з файлової системи, кожен крок успішний. Однак, коли я намагаюся додати завдання до SQL Server, у мене виникає одна з таких проблем:

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

Не вдалося виконати з наступною помилкою: "Каталог" LocalApplicationData "не існує."

Цю помилку можна виправити, створивши логін із правами адміністратора для користувача домену на сервері 1, але це, очевидно, не є бажаним рішенням. Додавання облікового запису до однієї з груп агентів DQL / DTS також не працює.

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

Неможливо встановити, чи має власник (Домен \ Користувач домену) Job nameдоступ до сервера (причина: Не вдалось отримати інформацію про групу / користувача Windows NT "Домен \ Користувач домену", код помилки 0x5. [SQLSTATE 42000] (Помилка 15404)) .

Я вважаю, що остання помилка полягає в тому, що SQL Server працює в локальному обліковому записі, і він не може переглянути, які облікові записи доменних прав мають.

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


ОНОВЛЕННЯ:

@JonSeigel та @ Mr.Brownstone:

Це здається правдоподібним, що це питання пов’язано з відсутністю дозволів. Однак помилка стосується відсутності "LocalApplicationData" - однієї з папок, яка генерується для кожного облікового запису. Я вже увійшов на сервер з обліковими даними, під якими працює пакет (цим чином створюючи каталог профілю) і спробував кілька комбінацій дозволів для каталогу профілю. Навіть коли вручну надають майже всі дозволи на цей конкретний каталог, я отримую згадану вище помилку.

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


Чи є причина, чому ви не використовуєте обліковий запис домену для служб SQL?
Ерік Хіггінс

Так, але я не знаю, з якої причини (я думаю, щось із циклом DTAP і домену не скрізь доступний). У будь-якому випадку, це дане середовище, яке мені не дозволяють змінювати.
vstrien

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

Чи можете ви додати вхід у систему SQL (автентифікація SQL) до віддаленого сервера SQL (сервер 2)? Якщо у вас є така опція, ви можете використовувати вхід SQL у з'єднання SSIS, яке використовується для призначення. Це означає, що вам доведеться використовувати пароль для шифрування пакету, але це вирішить вашу проблему.
Рой Гавіш

@ Юстик: Можливо, в крайньому випадку. Але завжди, коли можливі входи в домен, я вважаю за краще не використовувати SQL Authentication.
vstrien

Відповіді:


5

Моя особиста думка, що варіант №1 - це шлях. Але я не бачу необхідності надавати доступ до локального адміністратора доменного облікового запису. Мені здається, що він вимагає доступу до певних папок і файлів, і тому ви можете надати користувачу домену доступ лише до тих ресурсів, які йому потрібні для успішного запуску пакету. Це можна зробити за допомогою діалогового вікна властивостей файлів / папок та виберіть вкладку безпеки - не потрібно встановлювати його для кожного файлу та папки, оскільки ви можете встановити дозволи батьківського каталогу та встановити їх над заміною дочірніх властивостей.

Я сподіваюся, що це вам допоможе.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.