ドメインユーザーの委任の信頼を設定する
複数のマシン上のSQLServer 2005の多数のインスタンスのログオンアカウントとして設定されているドメインユーザーアカウント（mydomain.comなど）があります。主にリンクサーバーを介してSQLサーバー間で2ホップ認証を行うために、このドメインアカウント（マシンアカウントではない）を委任に対して信頼できるようにしたい。リンクサーバーのセキュリティは、既存の接続のコンテキストを使用するように構成され、すべてのSQLServerインスタンスは上記のドメインアカウントのコンテキストで実行されます。
議論のために、これはSQLインスタンスのインスタンス名になります。svra（デフォルトのSQLインスタンス）svra\inst2（名前付きのSQLインスタンス）svrb（デフォルトのSQLインスタンス）
したがって、Active Directoryに登録したいSPNは、MSSQLSvc/svra.mydomain.com：1433 MSSQLSvc/svrb.mydomain.com：1433になると思います。
Svraの名前付きインスタンスに3番目は必要ありませんか？
誰かがそれがSPNの正しいフォーマットであることを確認できますか？また、同じドメインアカウントでIISを実行すると、SQLインスタンスに対して2ホップ認証を実行できますか？
通常、FQDN SPNとNetBIOS名SPNの両方を登録する必要があります：MSSQLSvc/svra.mydomain.com：1433およびMSSQLSvc/svra：1433
セカンダリインスタンス（inst2）の場合、そのインスタンスのTCPポートMSSQLSvc/svra：1500（例））のSPNが必要です。
また、SQL Serverサービスプロセスがドメインアカウントで実行されている場合は、それも指定する必要があります。
MSSQLSvc/svra.mydomain.com：1433
SQL ServerサービスプロセスをLOCALSYSTEMとして実行すると、これらのSPNが自動的に作成されることに注意してください。
最後に、ドメイン内のIISサーバーのコンピューターアカウントで、[委任に対して信頼済み]フラグを設定する必要があります。
インスタンスごとにSPNが必要であり、SPNの最後にあるポートは、マルチインスタンスマシン上のインスタンスを指定します。一部の環境では、NetBIOSとFQDNの両方にSPNが必要になる場合があります。 SPNは、他のアカウントではなく、現在のサービスアカウントに属している必要があります。 KB811889を参照してください。「SSPIコンテキストを生成できません」というエラーメッセージのトラブルシューティング方法
また、同じアカウントを複数のサービスに使用することは、セキュリティのベストプラクティスに反します。
これは委任の部分については説明していませんが、認証の設定とSPNの適切な取得については説明しています。