アプリケーション プール ID を使用する IIS アプリケーションはプライマリ トークンを失いますか? 質問する

(これは漠然とした問題に関する質問です。誰かが役に立つ情報を持っていることを期待して、関連するすべてのデータを提示するように努めています。説明が長くて申し訳ありません。)

当社のウェブアプリ

IIS 7.5 で実行され、Active Directory と SQL Server データベースにアクセスする .NET 4 Web アプリケーションがあります。

このWebアプリケーションは、アプリケーションのアプリケーションプールのIDを次のように設定することで、仮想「アプリケーションプールID」の下で実行されます。アプリケーションプールID仮想アイデンティティの簡潔な説明は、StackOverflowの回答、およびそれが参照しているブログ投稿では、アプリケーションプールIDは、ネットワークサービスとして実行されているWebアプリケーションのワーカープロセスに追加される追加のグループにすぎません。ただし、1つの情報源「ネットワーク サービスと ApplicationPoolIdentity には、IIS.net サイトのドキュメントでは公開されていない違いがある」と漠然と示唆しています。したがって、仮想 ID は単なる追加グループ以上のものである可能性があります。

NetworkServiceではなくApplicationPoolIdentityを使用することにしました。これはIIS 7.5でデフォルトになったためです（例：ここ）、そしてマイクロソフトの推奨によれば、「このIDにより、管理者はアプリケーションプールが実行されているIDにのみ関係する権限を指定でき、それによってサーバーのセキュリティが強化されます。」 (applicationPools の追加のための processModel 要素 [IIS 7 設定スキーマ]) 「アプリケーション プール ID は強力な新しい分離機能であり、IIS アプリケーションの実行をさらに安全かつ信頼できるものにします。」 (IIS.net の記事「アプリケーション プール ID」）

アプリケーションは統合Windows認証を使用しますが、<identity impersonate="false"/>これにより、エンド ユーザーの ID ではなく、仮想アプリケーション プール ID を使用してコードが実行されるようになります。

このアプリケーションは、Active Directoryを照会するためにシステム.ディレクトリサービスクラス、つまり ADSI API を使用します。ほとんどの場合、追加のユーザー名/パスワードやその他の資格情報を指定せずにこれが実行されます。

このアプリケーションは、接続文字列を使用して SQL Server データベースにも接続しますIntegrated Security=true。データベースがローカルの場合は、IIS APPPOOL\OurAppPoolNameデータベースへの接続に が使用され、データベースがリモートの場合は、マシン アカウントOURDOMAIN\ourwebserver$が使用されます。

私たちの問題

正常に動作しているインストールが次のいずれかの理由で失敗し始めるという問題が定期的に発生します。

• データベースがリモート システムにある場合、データベース接続が失敗し始めます: 「ユーザー 'NT AUTHORITY\ANONYMOUS LOGON' のログインに失敗しました。理由: トークン ベースのサーバー アクセス検証がインフラストラクチャ エラーで失敗しました。以前のエラーを確認してください。」以前のエラーは「エラー: 18456、重大度: 14、状態: 11」です。したがって、現在はOURDOMAIN\ourwebserver$使用されておらず、代わりに匿名アクセスが試行されているようです。(UAC がオフになっているときにこの問題が発生し、UAC をオンにするとこの問題がなくなったという逸話的な証拠があります。ただし、UAC を変更するには再起動が必要であることに注意してください...) 同様の問題が次の場所で報告されています。IIS.net スレッド「ApplicationPoolIdentity を使用して SQL に接続する」具体的には1件の返信。

• ADSI (System.DirectoryServices) を介した Active Directory 操作が、エラー 0x8000500C (「不明なエラー」)、0x80072020 (「操作エラーが発生しました。」)、または 0x200B (「指定されたディレクトリ サービス属性または値が存在しません。」) で失敗し始めます。

• Internet Explorerからアプリケーションにサインインしようとすると、HTTP 401エラーが発生して失敗します。しかし、IISでNTLMをネゴシエートの前に配置すれば、再び機能します。(ADへ​​のアクセスはKerberosには必要ですが、NTLMには必要ありません。)同様の問題が報告されています。IIS.net スレッド「AppPool Identity でウィンドウ認証が失敗する」。

私たちの仮説と回避策

少なくとも、アプリケーションプールをApplicationPoolIdentityからNetworkServiceに切り替えると、ADとサインインの問題は常に解消されるようです。（1件のレポートこれを確認しました。

ページ「ASP ページでの認証問題のトラブルシューティング」プライマリ トークンとセカンダリ トークンに関連するいくつかの提案があり、最初の 2 つのエラーがリンクされている点が励みになります。NT AUTHORITY\ANONYMOUS LOGONアクセス、AD エラー 0x8000500C、および「指定されたディレクトリ サービス属性または値が存在しません」について言及されています。

(同じページには ADSI スキーマ キャッシュの問題についても記載されていますが、そのトピックに関して私たちが見つけたものはすべて古いものです。現時点では、これは無関係であると考えています。)

上記を踏まえて、現在の作業仮説仮想アプリケーションプールIDで実行している場合にのみ、Webアプリケーション（IIS？ワーカープロセス？）が突然プライマリトークンを失うそのため、IIS にはセカンダリ トークンのみが含まれるようになり、Active Directory および SQL Server へのすべてのアクセスが匿名で行われるようになり、上記のすべてのエラーが発生します。

今のところ、ApplicationPoolIdentity から NetworkService に切り替えるつもりです。これで上記の問題がすべて解消されることを願っています。しかし、確信はありません。可能であれば元に戻したいと思っています。

私たちの質問

上記の仮説は正しいでしょうか。正しい場合、これは IIS/Windows/.NET のバグでしょうか。どのような状況でこのプライマリ トークンの損失が発生しますか。