Запуск пакета SSIS від завдання SQL Agent, що належить користувачеві домену, який не належить sysadmin

У мене є два пакети SSIS, які запускаються заплановано протягом ночі (через агент SQL Server) як частина більшого розгортання SSIS без будь-яких проблем. Все використовує автентифікацію Windows, а заплановане завдання належить sysadmin (ну, я) і працює як обліковий запис сервера агента SQL Server.

Отже, дані по суті йдуть за source system ~> transit db ~> staging ~> NDSніч.

Дві пакети SSIS, які мені важливі, обробляють transit db ~> stagingі staging ~> NDS, відповідно, частини для конкретного набору даних.

Користувач домену (не-sysadmin) робить щось у тому, source systemщо підштовхує цікаві дані до transit db, тому мені потрібен спосіб отримати ці оновлені дані в робочі години для оновлення NDS: було вирішено, що найпростіший спосіб запустити цю особу що ETL, було натисненням кнопки в робочій книжці Excel з підтримкою макросу, яка підключається до SQL Server через ODBC (використовуючи автентифікацію Windows) та виконує збережену процедуру.

Збережена процедура виглядає приблизно так:

create procedure dbo.UpdateMaterialInventory
as
begin
    execute msdb.dbo.UpdateMaterialInventory;
end

Збережена процедура "сестри" в [msdb] виглядає так:

create procedure dbo.UpdateMaterialInventory
with execute as 'SqlAgentProxy'
as
begin
    execute msdb.dbo.sp_start_job N'NDS-ManualMaterialInventory';
end

Цей користувач [SqlAgentProxy] - це користувач Windows, який я створив у [msdb] за межами входу користувача домену, якому я надав executeдозвіл на цю UpdateMaterialInventoryпроцедуру. Це дозволяє уникнути необхідності надання executeдозволу користувачеві домену msdb.dbo.sp_start_job, що було б надмірно.

Завдання агента SQL NDS-ManualMaterialInventoryналежить користувачеві домену і має 2 етапи, кожен із типів [Пакет послуг інтеграції SQL Server], налаштований на Запуск як SSISProxy .

SSISProxyце проксі-сервер агента SQL Server, який відображається в підсистемі [Пакет послуг інтеграції SQL Server] з використанням імені облікових даних SSISProxyCredentials. Вхід користувача домену додано до принципів облікового запису проксі .

Вони SSISProxyCredentialsбули створені з ідентичністю того самого користувача домену, який працює протягом усього SSIS ETL протягом ночі, і його пароль перевірявся чотириразово.

Тепер, якщо я запускаю це:

execute as login=N'DOMAIN\thatperson'
exec NDS.dbo.UpdateMaterialInventory;
go

Я отримую цей вихід:

Job 'NDS-ManualMaterialInventory' started successfully.

Однак історія роботи розповідає набагато менш обнадійливу історію:

The job failed.  The Job was invoked by User DOMAIN\thatperson.
The last step to run was step 1 (Extract).

І деталі кроку 1:

Executed as user: {domain user that runs SSIS ETL overnight}.
Microsoft (R) SQL Server Execute Package Utility  Version 12.0.4100.1 for 64-bit
Copyright (C) Microsoft Corporation. All rights reserved.
Started:  2:18:50 PM  Failed to execute IS server package because of error 0x80131904.
Server: {server name}, Package path: \SSISDB\Foo\Bar\foobar.dtsx, Environment reference Id: NULL.
Description: Login failed for user '{domain user that runs SSIS ETL overnight}'.
Source: .Net SqlClient Data Provider 
Started:  2:18:50 PM  Finished: 2:18:51 PM  Elapsed:  0.094 seconds.
The package execution failed.
The step failed.

Робота не вдається, і ніде нічого не записується.

Якщо я зміню власника завдання, щоб бути самим собою, і змінити виконання кроків як облікового запису служби агента SQL Server, завдання запускається, вдається та записує 1,067 рядків у [Метадані]. [Dbo]. [Sysssislog].

Схоже, щось не вірно в налаштуванні проксі / облікових даних. Яка частина я роблю неправильно?

Проблема виглядає складніше, ніж є. Оскільки ви використовуєте SQL 2014, вас, ймовірно, кусають нові функції безпеки, запроваджені в 2012 році.

Єдине, що насправді має значення:

Server: {server name}, Package path: \SSISDB\Foo\Bar\foobar.dtsx, Environment reference Id: NULL.   
Description: Login failed for user '{domain user that runs SSIS ETL overnight}'.

Швидше за все, ваш логін користувача не має доступу до каталогу SSISDB (навіть якщо він може мати доступ до SQL Server).
Потрібно зіставити логін для користувача SSISDB та налаштувати доступ до папок / проектів SSISDB в службах інтеграції.

Будь ласка, подивіться на це MSDN блозі після SSIS Доступ до каталогу Органи управління організацій і SQL 2012 SSIS Каталог дозволів

Після завантаження пакета ви можете зіткнутися з іншими проблемами контексту безпеки, але вам слід краще ввійти в систему від самих служб інтеграції.