Windows認証を使用したクロスドメインSQLServerログイン

質問の更新で述べたように、サービスアカウントをDomain2に変更します問題を解決しました。では、何が起こっていたのでしょうか？

問題-説明

サービスアカウントは元々Domain1だったので、私が知る限り（Microsoftの担当者の助けも借りて）ユーザーがKerberosを介して認証しているときに、接続しているユーザーがどのドメインローカルグループのメンバーであるかを判別できませんでした。これがKerberosの問題である主な原因は、NTLM認証を使用しているため、「名前付きパイプ」を使用して正常に接続したときでした。

全体的なソリューション

すべてをまとめて、Domain1からユーザーを正常に追加するにはおよびDomain3 Domain2のグループのメンバーとしてグループをWindows認証でSQLServerログインとして使用できるように、要件のリストを次に示します（または少なくとも強く推奨します）。

ドメイン間に確立された信頼関係
1. 少なくとも、Domain2になるように、一方向の信頼を設定する必要があります。 Domain1を信頼しますおよびDomain3
Domain2のグループスコープは「ドメインローカル」である必要があります
1. これは、Domain1からユーザーとグループを追加できるようにするためです。およびDomain3
2. 詳細についてはこちらをご覧ください
SQL Server Configuration Managerを使用して、管理者以外のDomain2を指定しますサービスアカウントIDとしてのユーザー
1. MSDNは、ドメインユーザーアカウントの使用が推奨される理由を文書化しています
2. 構成マネージャーはユーザーをローカルのSQLServer2005固有のグループ（つまり、SQLServer2005MSSQLUser $ MY_MACHINE $ MY_INSTANCE）に追加することになっていますが、そうでない場合がいくつかあります。したがって、ローカルグループをチェックして、Domain2で適切に更新されていることを確認してください。ユーザーアカウント。
3. SQL Serverのセットアップでは、ローカルグループに適切なアクセス許可が自動的に割り当てられるはずですが、これも当てはまらないいくつかのインスタンスに遭遇しました。これが発生した場合は、許可要件について、前述の記事と一緒にこのMSDNの記事を参照できます。
SQL Serverインスタンスホスト（エイリアスを含む）とDomain2のサービスプリンシパル名（SPN）を構成しますサービスアカウント
1. クライアントとサーバーホスト間の相互認証にはSPNが必要です
2. 詳細については、このTechNetの記事を参照してください
偽装の使用方法によっては、Domain2を有効にすることをお勧めします。委任に対して信頼されるサービスアカウント
1. 詳細については、このTechNetの記事を参照してください
SQLサービスインスタンスのリモート接続を有効にする
最後に、目的のDomain2のログインを作成しますグループと任意のDomain1 またはDomain3 メンバーはリモートで接続できる必要があります！

注

他のリモートネットワークアクティビティと同様に、ファイアウォールをチェックして、SQLServerポートがブロックされていないことを確認します。デフォルトのポートは1433ですが、ポートがクリアになっていることを確認してください。