信頼されていないドメインのSQLServerに対するセキュリティが統合されたIIS8アプリケーションプールID？
これが私たちが経験しているシナリオと私たちがこれを解決しようとしている理由です：
私たちは、多くのクライアントのために特定のサードパーティソフトウェアアプリケーションをサポートするコンサルティング会社です。アプリケーションはASP.NETで記述され、IISおよびSQLServerで実行されます。この例では、組織「ABC」がドメイン内のサーバーでアプリケーションをホストしています。このアプリケーションは大幅に拡張可能でカスタマイズ可能です。そのため、各クライアントには多くの場合、カスタマイズのリポジトリがあり、これらのカスタマイズをサポートする1つ以上のベンダーが存在する場合があります。
組織が既存のカスタマイズを変更するように当社または別のベンダーに依頼した場合、通常、開発をより効率的にするために（特にデバッグ）、マシン上にアプリケーションのローカルインスタンスをセットアップする必要があります。ただし、通常はデータベースのローカルコピーをホストしないようにします。代わりに、ローカルマシンから組織のVPNに接続して、ローカルIISインスタンスが開発SQLサーバーに接続できるようにします。次に、通常の統合セキュリティを使用する代わりに、接続文字列のSQL資格情報のセットを設定します。
問題は、開発中のSQLサーバーであっても、認証に使用されるSQL資格情報に慣れていない組織があることです。このシナリオをサポートする必要がある場合、開発SQLサーバーでSQL credを許可する強力なケースがあることを認識していますが、私が見つけようとしているのは、他のオプションがあるかどうかです。組織のエンジニアは、ローカルIISアプリケーションプールIDを構成して、統合セキュリティを使用してSQLサーバーにアクセスするためのドメイン資格情報を使用できます。ただし、外部ベンダー（当社など）はドメインに参加していません。また、ドメインが信頼されていないため、組織ABCが提供するドメイン資格情報をアプリケーションプールIDとして使用できません。
ドメイン「XYZ」のマシンでIISアプリケーションを実行する方法を知っている人はいますか？統合セキュリティを使用して、ドメイン「ABC」で実行されているSQLサーバーを認証します。ドメインを信頼するか、Kerberos委任を設定しますか？
さまざまな組み込みアカウントをアプリケーションプールIDとして使用し、SQLサーバーへのアクセスを許可することを検討しましたが、DOMAIN\MachineName $のすべての可能な組み合わせに対してSQLサーバーへのアクセスを許可したくありません。それはすべての異なるベンダーからそれに接続している可能性があります。おそらく、アプリケーションプール名で命名規則に従い、ApplicationPoolIdentityを使用した場合、SQLサーバーへのアクセスを1つの「仮想」アカウントにのみ許可できるでしょうか。 （私はこれを試したことがなく、時間が許せばそうする予定です）。
これは、ドメインのメンバーであるか、少なくとも信頼がなければ不可能です。
サーバーは他のドメインが何であるかを理解しておらず、そのドメインへの認証（または検出）を可能にする資格情報を持っていません。 Windowsは通常、信頼できない権限（ドメイン）からのユーザーとしてプロセスを実行することを許可しません。したがって、ワーカープロセスはそのユーザーとして実行しようとするため、アプリプールIDを設定することはできません。