Mam dwa pakiety SSIS, które są uruchamiane zaplanowane na noc (za pośrednictwem agenta SQL Server) w ramach większego wdrożenia SSIS, bez żadnych problemów. Wszystko korzysta z uwierzytelniania systemu Windows, a zaplanowane zadanie należy do sysadmin (cóż, ja) i działa jako konto usługi SQL Server Agent.
Tak więc dane zasadniczo idą z source system ~> transit db ~> staging ~> NDSdnia na dzień.
Dwa pakiety SSIS, na których mi zależy, obsługują odpowiednio transit db ~> stagingi staging ~> NDSczęści i dla określonego zestawu danych.
Użytkownik domeny (nie będący sysadminem) robi coś w tym, source systemco wpycha interesujące dane do transit db, dlatego potrzebuję sposobu, aby pobrać te zaktualizowane dane w godzinach pracy, aby zaktualizować NDS: zdecydowano, że jest to najprostszy sposób na uruchomienie tej osoby że ETL, klikając przycisk w skoroszycie programu Excel z obsługą makr, który łączy się z programem SQL Server za pośrednictwem ODBC (przy użyciu uwierzytelniania systemu Windows) i wykonuje procedurę przechowywaną.
Procedura składowana wygląda następująco:
create procedure dbo.UpdateMaterialInventory
as
begin
execute msdb.dbo.UpdateMaterialInventory;
end
Procedura składowana „siostrzana” w [msdb] wygląda następująco:
create procedure dbo.UpdateMaterialInventory
with execute as 'SqlAgentProxy'
as
begin
execute msdb.dbo.sp_start_job N'NDS-ManualMaterialInventory';
end
Ten [SqlAgentProxy] jest użytkownikiem systemu Windows, który utworzyłem w [msdb] poza loginem użytkownika domeny, któremu udzieliłem executezgody na tę UpdateMaterialInventoryprocedurę. Pozwala to uniknąć konieczności przyznania executeuprawnienia użytkownika domeny msdb.dbo.sp_start_job, co byłoby nadmierne.
Zadanie agenta SQL NDS-ManualMaterialInventoryjest własnością użytkownika domeny i ma 2 kroki, każdy typu [Pakiet usług integracji serwera SQL], skonfigurowany do działania jako SSISProxy .
SSISProxyto serwer proxy agenta SQL Server, który jest odwzorowany na podsystem [SQL Server Integration Services Package], przy użyciu nazwy referencji SSISProxyCredentials. Login użytkownika domeny został dodany do podmiotów głównych kont proxy .
SSISProxyCredentialsPowstały z Tożsamość tego samego użytkownika domeny, który jest uruchomiony cały SSIS ETL noc, a jego hasłem było poczwórną sprawdzane.
Teraz, jeśli uruchomię to:
execute as login=N'DOMAIN\thatperson'
exec NDS.dbo.UpdateMaterialInventory;
go
Otrzymuję ten wynik:
Job 'NDS-ManualMaterialInventory' started successfully.Historia pracy opowiada jednak o wiele mniej zachęcającą historię:
The job failed. The Job was invoked by User DOMAIN\thatperson.
The last step to run was step 1 (Extract).
I szczegóły kroku 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.
Zadanie kończy się niepowodzeniem i nic nie jest rejestrowane w dowolnym miejscu.
Jeśli zmienię właściciela zadania na siebie i zmienię uruchamianie kroków jako konto usługi SQL Server Agent Service, zadanie zostanie uruchomione, powiedzie się i zarejestruje 1067 wierszy w [Metadata]. [Dbo]. [Sysssislog].
Wygląda na to, że coś jest nie tak z tym, jak skonfigurowano proxy / dane uwierzytelniające. Którą część robię źle?