(これはあいまいな問題に関する質問です。誰かが役立つ情報を持っていることを願って、関連するすべてのデータを提示しようとしています。長い説明で申し訳ありません。)
私たちのウェブアプリ
Active Directory と SQL Server データベースにアクセスする IIS 7.5 で実行されている .NET 4 Web アプリケーションがあります。
この Web アプリケーションは、アプリケーションのアプリケーション プールの ID をApplicationPoolIdentityに設定することにより、仮想の「アプリケーション プール ID」の下で実行されます。仮想 ID の簡潔な説明は、StackOverflow の回答とそれが参照するブログ投稿にあります。アプリ プール ID は、「ネットワーク サービス」として実行されている Web アプリケーションのワーカー プロセスに追加される単なる追加のグループです。ただし、ある情報源は、「Network Service と ApplicationPoolIdentity には、IIS.net サイト ドキュメントが公開していない違いがある」と漠然と示唆しています。したがって、仮想 ID は単なる追加のグループ以上のものになる可能性があります。
NetworkService とは対照的に、ApplicationPoolIdentity を使用することを選択しました。これは、IIS 7.5 でデフォルトになったため (たとえば、ここを参照)、Microsoft の推奨に従って、「この ID により、管理者は、アプリケーションがその下にある ID にのみ関連するアクセス許可を指定できます。プールが実行されているため、サーバーのセキュリティが向上しています。」( applicationPools の add の processModel 要素 [IIS 7 設定スキーマ]より) 「アプリケーション プール ID は強力な新しい分離機能です」 )
アプリケーションは統合 Windows 認証を<identity impersonate="false"/>使用しますが、.
このアプリケーションは、 System.DirectoryServicesクラス、つまり ADSI APIを使用して Active Directory にクエリを実行します。ほとんどの場合、これは追加のユーザー名/パスワードまたはその他の資格情報を指定せずに行われます。
このアプリケーションは、接続文字列を使用して SQL Server データベースにも接続しIntegrated Security=trueます。IIS APPPOOL\OurAppPoolNameデータベースがローカルの場合、それがデータベースへの接続に使用されていることがわかります。データベースがリモートの場合、マシン アカウントOURDOMAIN\ourwebserver$が使用されます。
私たちの問題
動作中のインストールが次のいずれかの方法で失敗し始めるという問題が定期的に発生します。
データベースがリモート システム上にある場合、データベース接続が失敗し始めます。前のエラーは「エラー: 18456、重大度: 14、状態: 11」です。そのため、現在
OURDOMAIN\ourwebserver$は使用されていないようですが、代わりに匿名アクセスが試行されています。(この問題は、UAC をオフにしたときに発生し、UAC をオンにすると消えたという逸話的な証拠があります。ただし、UAC を変更するには再起動が必要であることに注意してください...) 同様の問題がIIS.net スレッドで報告されています。 SQLに接続するには」、具体的には1回の返信で。ADSI (System.DirectoryServices) による Active Directory 操作が、エラー 0x8000500C (「不明なエラー」)、0x80072020 (「操作エラーが発生しました」)、または 0x200B (「指定されたディレクトリ サービスの属性または値が存在しません」) で失敗し始めます。 .
Internet Explorer からアプリケーションにサインインすると、HTTP 401 エラーで失敗し始めます。しかし、IIS で Negotiate の前に NTLM を配置すると、再び機能します。(Kerberos には AD へのアクセスが必要ですが、NTLM には必要ないことに注意してください。) 同様の問題が、IIS.net スレッド「AppPool ID で失敗するウィンドウ認証」で報告されています。
私たちの仮説と回避策
少なくとも、アプリケーション プールを ApplicationPoolIdentity から NetworkService に切り替えると、AD とサインインの問題は常に解消されるようです。(これを確認するレポートが 1 つ見つかりました。)
ページ「ASP ページでの認証の問題のトラブルシューティング」には、プライマリ トークンとセカンダリ トークンに関連するいくつかの提案があり、私が心強いと思うのは、最初の 2 つのエラーにリンクしていることですNT AUTHORITY\ANONYMOUS LOGON。属性または値が存在しません。」
(同じページで ADSI スキーマ キャッシュの問題についても言及されていますが、そのトピックで見つけられるものはすべて古いものです。今のところ、これは無関係であると考えています。)
上記に基づいて、私たちの現在の作業仮説は、仮想アプリ プール ID の下で実行されている場合にのみ、Web アプリケーション (IIS? ワーカー プロセス?) が突然そのプライマリ トークンを失い、 IIS がセカンダリ トークンのみを持つようになるというものです。 Active Directory と SQL Server へのアクセスは匿名で行われるため、上記のすべてのエラーが発生します。
今のところ、ApplicationPoolIdentity から NetworkService に切り替える予定です。これにより、上記の問題がすべて解消されることを願っています。しかし、確かではありません。可能であれば元に戻したいと考えています。
私たちの質問
上記の仮説は正しいですか? もしそうなら、これは IIS/Windows/.NET のバグですか? このプライマリ トークンの損失はどのような状況で発生しますか?