SQL Serverエージェント - 信頼されていないドメインメッセージ

Question

SQL Server 2016を実行しています。現在、1つのドメインでホストされているソリューションがあります。データを自動化する必要があります。

エンドポイント情報とクレデンシャルのセットを収集するクレデンシャルマネージャを使用してWindowsクレデンシャルを追加しました。

• インターネットまたはネットワークアドレス：mydatabase.remotedomain.com
• ユーザー名：remotedomain \ユーザー名
• パスワード：パスワード

このソリューションは、多くのツールやExcel、SSMS直接問い合わせ、Visual Studioに動作します。ユーザーはエンドポイント（サーバーURLまたはIP /ポート）に入り、Windows統合セキュリティーを使用します。接続が確立され、資格証明ストアがトリックを行い、ユーザーが認証されます。

SSMS例

• サーバー名：mydatabase.remotedomain.com
• 認証：Windows認証

は私の挑戦は、SSISとSQLエージェントです。 SSISパッケージはVS2015で動作します。パッケージをIntegration Servicesカタログに展開し、パッケージを強調表示して実行し、実行します。

.....

ログインをSQL Serverエージェントジョブを作成し、ジョブを実行し、私はこの贈り物を受け取る失敗しました：ログインは信頼できないドメインからのものであり、Windows認証で使用することはできません

私はSQL資格情報を作成し、プロキシ（SSISパッケージの実行）を作成し、資格情報と共に実行するが同じ結果で終了するジョブを作成しました。資格情報は私のローカルドメインになければなりません。または、ジョブは実行されません。もちろん、localdomain \ usernameはリモートデータ接続に対して認証されません。だからプロキシは状況を助けません。

私は何を期待していたことは、Windowsの資格情報マネージャはジョブを手動で実行されたときにそれがないと資格情報を交換、またはExcelや他のいくつかの方法を通じてだろうということです...

Answer 1

あなたの窓の資格アカウントがなければなりませんグローバルまたはユニバーサルのいずれかのスコープを持つグループに属するADユーザーアカウントであること。ユニバーサルグループは、複数のドメインを持つ場合に便利です。

プロセスは、呼び出されたあらゆるコンテキスト（つまり、あなた、SQLエージェント、またはプロキシアカウント）で実行されます。あなたが実際にそれを作っていない限り、実行可能なコンテキストを変更するわけではありません。途中で楽しいAD設定のヒントを学びました。

Understanding User and Group Accounts状態次の：

グループは、ビルトイン、ローカルのグローバル、ユニバーサル、地元異なるスコープドメインを持つことができます。つまり、グループは有効な領域が異なります。

グローバルグループ：ドメインツリーまたはフォレスト内の任意のドメイン内のオブジェクトへのアクセス権を付与するために使用されている

グループ。グローバルグループのメンバーには、定義されているドメインのアカウントとグループのみを含めることができます。

ユニバーサルグループ：ドメインツリーまたはフォレスト全体で広くスケール上の権限を付与するために使用されている

グループ。グローバルグループのメンバーには、ドメインツリーまたはフォレスト内の任意のドメインのアカウントとグループが含まれます。

EDIT

、それは別のドメインからだけのデータプルだ場合は、データが最初に信頼されていないドメインでCSVにエクスポートすることができ、その後、TLは（トランスフォームどこ環境にSFTP'dとETL（Extract-Transform-Load）プロセスの負荷（負荷）が発生する可能性がありますか？

SSISはこれに適したツールですが、C＃とPowershellも使用できます。

Answer 2

申し訳ありませんが、ローカルADアカウントのグループをグローバルまたはユニバーサルに変更しても効果はありません。私は、SQL Agentを使用しているローカルアカウントを変更することによって、どのような違いが生まれるのか、少し分かりません。このソリューションは、Credential Managerのリモートアカウント設定を使用して、ローカルのアカウント置き換えによってすべてのツールで機能します。もし私がそれを見落とし、この変更を行う必要があるなら、可能であればセットアップの例を提供してください。

このプロセスは、SQL Serverエージェントが他の場所では動作しますが、エージェントによって実行されるジョブでは動作しないため、このプロセスはSQL Serverエージェントによって実行されていません。

もう一度私の希望は誰かが前にこのような何かを見て、解決策を持っています。

私の最終目標は、信頼性のないリモートSQLサーバーからデータを取得するだけです。私は、プロキシソリューションがうまくいくことを期待していましたが、リモートドメイン\ユーザー名に資格情報を設定すると、ジョブは実行されません。

リモートドメイン\ユーザー名\ pwdに資格情報を明示的に設定するために、SSISパッケージで接続をセットアップする方法はありますか。私はそれを刺して、それを飛ぶこともできなかった。そうであれば、私にとって貴重な一例です。私はゴールラインを取得する方法を気にいけない

は、ちょうどすべてのヘルプ

Answer 3

ためのおかげで、私はMicrosoftとチケットを開いて、この上の先輩資源の一つで働いていた...する必要があります。

これはSQL Agentのバグのようです。 SQL AgentがWindows資格情報ストアからリモート資格情報を取得することを妨げる既知の理由または問題はありませんが、そうではありません。

代わりに、コマンドラインユーティリティDTEXECを使用する方法がありました。すべての接続マネージャがプロジェクトではなくパッケージレベルにあることを確認するためにSSISプロジェクトを少し修正しました（参照問題を作成しました）。

このソリューションは理想的ではありませんが、DTEXECはSSISがストア内で必要な資格情報を取得して問題なく実行できるようにしました。

Microsoftが調査を完了し、私に戻ったらフォローアップしますが、チケットはまだ開いています。