IIS 7.5では、Windows認証、Kerberos、SPN、および制約付き委任について学び、理解するために何時間も費やしてきました。管理者やCEOなどに対して委任を有効（つまり、デリケートなアカウントの委任を無効にしない）のままにしておくのが「危険」である理由がわかりません。誰かに簡単に説明してもらえますか？イントラネット環境に関してあなたの答えを組み立ててください。
たとえば、委任によってフロントエンドWebサーバーが他のサーバーと通信するときに、Windows認証されたユーザーに代わって動作することを許可するだけなので、これは問題にならないはずです。その人がアクセス権を持っている場合、彼らはアクセス権を持っていますが、なぜこれが問題になるのか理解できません。
私の無知を許してください。私は主に開発者ですが、私の会社は最近非常に無駄のない状態で運営されており、サーバー管理者の帽子も着用せざるを得ません...
回答:
2つの例：
制約付き委任により、ユーザーの資格情報や認証トークンがなくても偽装が可能になります。例については、この回答を参照してください。
より一般的なミートポテトの制約のない委任シナリオでは、それがWindows統合認証であるかフォーム認証であるかに関係なく、ユーザーの認証トークンへの委任アクセスは非常に強力です。つまり、トークンを使用して、そのユーザーになりすまして任意のネットワークリソースにアクセスできるということです。開発者など、そのプロセスに関与する誰もが不正な方法でそれを使用して、不正アクセスを取得する可能性があります。
どちらの例でも、「アカウントは機密で委任できない」のチェックボックスがオンになっている場合、これらはセキュリティの問題ではありません。これらの機能は存在するが、厳しく制御されているシステム/機能を設計することもできます。
Enterprises Adminsグループのメンバーなどの管理アカウントについては、このボックスをオンにする必要があります。これらのアカウントでは、偽装が必要なアプリケーションを使用する必要がほとんどないためです。また、CIO、COO、財務/財務長などの機密情報にアクセスできる上級幹部にとっても良い考えです。
つまり、マイクロソフトは非常に正当な理由でそのチェックボックスと付随する警告を提供し、特定のシナリオが望ましくないリスクにさらされていないこと、またはいくつかの補完的な制御がないことを証明できない限り、それを無視したり軽視したりしないでください。これには通常、アプリケーションまたはシステムの実際の実装または開発に関与していない有資格者による審査が含まれます。
allow/ deny認可タグを使用して特定のページのみを制限します。
私は、何千人もの顧客に委任を設定しました。アプリケーションを信頼していない（IISにデプロイしたとしましょう）場合、または他のユーザーが自由に使用できるように委任されたサービスアカウントの資格情報を提供している場合は、制約付き委任がおそらく良い考えです。ただし、誰もがアプリケーションを書き換えることができないと予想する場合は、サービスアカウントの認証情報を安全に保ち、アプリが設計されたサービスにのみ委任することを信頼すると、そこに通常は心配する必要はありません。「セキュリティを重視する」お客様の中には、このような問題に非常に重点的に取り組んでいるところを見てきましたが、実際のセキュリティの脅威への対応にリソースを費やす方がよいでしょう...