FreeTDSを使用してログインするユーザーが開始すると、SSISパッケージの実行が失敗する

Question

SQLエージェントからではなく、組み込みのSSISDBストアドプロシージャを使用して、ログインでSSISパッケージを開始しようとしています。

ログインはUbuntuボックスのAirflow DAGを介して接続するため、FreeTDS/pyodbcを使用して、Windowsログインとして認証できるようにしています。これは正常に機能しています。

ただし、パッケージを起動すると、次のことが起こります。

パッケージは[SSISDB].[catalog].[start_execution] @execution_idを使用して起動されます。同期と非同期の両方で実行してみました。
実行IDが生成され、[SSISDB].[catalog].[executions]のエントリとともにステータス5（ "保留中"）が生成されます。
約1分後、実行が「完了」し、実行IDがすべてのSSISDBテーブルからワイプされ、組み込みのレポートには表示されません。

Execパラメーターを create dump files に追加しても、パッケージの実行中には何も作成されません。

ボーナス問題：1分以内に、SQLエージェントから起動され、通常は正常に機能する他のパッケージが、次のエラーメッセージで失敗することがよくあります。

実行がタイムアウトしたため、操作は失敗しました。

ノート：

SQL ServerのインストールはWindows上にあり、SQL Server 2016 Entです。
このプロセスは、WindowsボックスからWindows認証ログインを使用する場合に正常に機能します。
DAGで使用されているWindowsアカウントはエージェントサービスアカウントであるため、必要なすべての権限があります。
保留中の実行の [SSISDB].[catalog].[executions] の2つのSIDフィールドは、同じサービスアカウントのSQLエージェントによって処理されている他の実行中の実行のSIDと一致します。
TDSバージョン7.2と最新のFreeTDSバージョンを使用しています。
自動コミットTrue/Falseを使用しても違いはありません
実行中にブロッキングが見られない

ログインが外部SSISプロセスを起動するために使用される場合、ログインが再認証されていると思いますが、これをまだ機能させる方法がいくつかあるのではないかと期待しています。

CLRを介した呼び出しは、複雑さが増し、セキュリティに影響するため、望ましくないオプションです。

私は現在、xp_cmdshellを介してdtexecを介してそれらを起動することもテストしています（有望そうに見えます）が、どのように/なぜ機能し、ストアドプロシージャを使用しないのかは不明です。

David Browne - Microsoft · Accepted Answer

これは、xp_cmdshellを使用してdtexecを直接実行するか、Powershellからパッケージ実行プロシージャを呼び出すのと似ていますが、より安全です。どちらの場合も、パッケージの実行にはローカルIDが使用されます。