IISアプリケーションプールIDを使用するアプリケーションはプライマリトークンを失いますか？
（これはあいまいな問題についての質問です。誰かが有益な情報を持っていることを期待して、関連するすべてのデータを提示しようとします。長い説明の謝罪。）
私たちのウェブアプリ
Active DirectoryとSQL ServerデータベースにアクセスするIIS 7.5で実行されている.NET 4 Webアプリケーションがあります。
このWebアプリケーションは、アプリケーションのアプリケーションプールのIDを ApplicationPoolIdentity に設定することにより、仮想「アプリプールID」の下で実行されています。仮想IDの簡潔な説明は StackOverflowの回答 にあり、それが参照するブログ投稿：アプリプールIDは、Webアプリケーションのワーカープロセスに追加される単なる追加グループです「ネットワークサービス」として実行しています。ただし、 1つのソース は、「ネットワークサービスとApplicationPoolIdentityにはIIS.netサイトドキュメントが公開しない違いがある」と漠然と示唆しています。したがって、仮想IDは単なる追加のグループではありません。
NetworkServiceではなくApplicationPoolIdentityを使用することを選択しました。これは、IIS 7.5（たとえば、 here を参照）、およびMicrosoftの推奨事項によると、 IDを使用すると、管理者は、アプリケーションプールが実行されているIDのみに関連するアクセス許可を指定できるため、サーバーのセキュリティが向上します。」（ applicationPools [IIS 7 Settings Schema]のaddのprocessModel要素 ）プールIDは強力な新しい分離機能です。「実行中IISアプリケーションをさらに安全で信頼性の高いものにします。」（ IIS.netの記事「アプリケーションプールID」 から）
アプリケーションは統合Windows認証を使用しますが、 <identity impersonate="false"/> を使用するため、エンドユーザーのIDではなく仮想アプリプールIDを使用してコードを実行します。
このアプリケーションは、 System.DirectoryServices クラス、つまりADSI APIを使用してActive Directoryを照会します。ほとんどの場合、これは追加のユーザー名/パスワードまたはその他の資格情報を指定せずに行われます。
このアプリケーションは、接続文字列でIntegrated Security=trueを使用してSQL Serverデータベースにも接続します。データベースがローカルの場合、IIS APPPOOL\OurAppPoolNameがデータベースへの接続に使用されることがわかります。データベースがリモートの場合、マシンアカウントOURDOMAIN\ourwebserver$が使用されます。
私たちの問題
次のいずれかの方法で、正常に機能するインストールが失敗し始めるという問題が定期的に発生します。
データベースがリモートシステムにある場合、データベース接続が失敗し始めます：「ユーザー 'NT AUTHORITY\ANONYMOUS LOGON'のログインに失敗しました。理由：トークンベースのサーバーアクセス検証がインフラストラクチャエラーで失敗しました。以前のエラーを確認してください。」前のエラーは「エラー：18456、重大度：14、状態：11」です。そのため、現在
OURDOMAIN\ourwebserver$は使用されていないようですが、代わりに匿名アクセスが試行されています。 （この問題はUACがオフになったときに発生し、UACをオンにすると消えたという事例証拠があります。ただし、UACを変更するには再起動が必要です...）同様の問題が IIS.netスレッド「SQLに接続するにはApplicationPoolIdentityを使用」 、具体的には 1回の返信 。ADSI（System.DirectoryServices）を介したActive Directory操作は、エラー0x8000500C（「不明なエラー」）、0x80072020（「操作エラーが発生しました。」）、または0x200B（「指定されたディレクトリサービスの属性または値が存在しません」）で失敗し始めます。
Internet Explorerからアプリケーションへのサインインが失敗し始め、HTTP 401エラーが発生します。ただし、IISの場合、Negotiateの前にNTLMを配置すると、再び機能します。ADにアクセスするにはKerberosが必要ですが、NTLMは不要です。）同様の問題が IIS.netスレッド「ウィンドウプール認証がAppPool IDで失敗する」 。
私たちの仮説と回避策
アプリケーションプールを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のバグですか？このプライマリトークンの損失はどのような状況で発生しますか？
Microsoftサポートを通じて、 Microsoft Knowledge Baseの記事KB254585 で説明されている問題に遭遇したことがわかりました。これは、ApplicationPoolIdentityが使用されている場合にのみ発生します。これは非常に簡単に発生します。つまり、マシンアカウントのパスワードが変更された後（デフォルトでは30日ごとに自動的に行われます）、その後IISがiisresetを介して）再起動されます。Microsoftと私たちの観察によると、問題は再起動後に解消されることに注意してください。
Microsoftによると、Windows/IISがこの状態になっているかどうかを確認することはできません。
Microsoftには、このKB記事に修正プログラムが添付されています。修正プログラムが公式の配信にロールされる時期は示されておらず、修正プログラムは既に10か月前です。特定のケースでは、代わりにNetworkServiceに切り替えることにしました。
同じ問題/解決策に関する私のコメントについては、 https://serverfault.com/a/403534/126432 を参照してください。
リンクした修正プログラムを使用すると、ドキュメントに記載されているとおりにApplicationPoolIdentityが機能するようになりました。この修正プログラムは、ネットワークリソースにアクセスするためのソリューションをNT AUTHORITY\ANONYMOUS LOGONとして具体的に説明していませんが、コンピューターのパスワード変更に関連しています。一番下の行は、少なくともこれまでのところ、それは私のために働いたことです。
これは、Active Directory認証を使用するUmbracoにも関連しています。時々この例外が発生する場合があります。
構成エラー
指定されたディレクトリサービスの属性または値は存在しません
これは明らかにここで概説した問題が原因です。再起動すると必ず修正されます。