短縮版：
Windows 認証を使用する IIS 7.5 Web アプリケーションの場合、エンド ユーザーはファイルの読み取りアクセス権を持っている必要がありますか?
長いバージョン:
Windows 認証を使用するイントラネット ASP.NET Web アプリがあります。数十の異なる企業にインストールされており、通常、認証は正常に機能します。ユーザーはサイトに移動します。たとえばhttp://appserver/MyApp、アプリはログインしているユーザーを認識し、それに応じてページを表示します。新しいクライアントにインストールしたところ、問題が発生しました。
たとえばに接続するときhttp://appserver/MyAppに、Windows 資格情報の入力を求められますが、それらを入力した後、繰り返し求められます。資格情報を何度か再入力すると、「401 - 権限がありません: 資格情報が無効なため、アクセスが拒否されました。」という 401 エラー ページが表示されます。そのため、ID を通過しないだけでなく、ユーザー名とパスワードを入力してもアクセスが拒否されます。
アプリのエンド ユーザーに読み取りと実行のアクセス許可を与えることでこの問題は解決しますが、これはまったく必要ないと思います。
Windows のアプリケーション イベント ログには、スレッド アカウント名: NT AUTHORITY\NETWORK SERVICE およびユーザー: [正しいワークステーション ユーザーのドメイン アカウント]と共に、「要求のファイル認証に失敗しました」というメッセージがあります。これは、ネットワーク サービスの AppPool ID ではなく、ユーザーの ID を使用してファイル アクセスが実行されていることを示しています。案の定、エンド ユーザーにアプリケーションのディレクトリへの読み取りと実行のアクセス許可 (読み取り専用は試していません) を付与すると、すべてが正しく機能します。ユーザーがサイトを参照すると、プロンプトは表示されず、自動的に認証され、Web サイト自分の正体を正しく認識！したがって、私の回避策は、アプリケーションディレクトリの全員に読み取りと実行のアクセス許可を与えることです...
これは非常に奇妙に思えます。私が思い出す限り、IIS 7.5 でこれを行う必要はありませんでした。また、IIS 6 または IIS 7 でこれを行う必要はまったくありませんでした。ドキュメントによると、偽装はデフォルトでオフになっています。念のために web.config に要素を追加し、ネットワーク サービス以外のファイル アクセス許可を削除しましたが、問題は残りました。
何かご意見は？IIS 7.5 の Windows 認証済みサイトで、エンド ユーザーが Web サーバー ファイルに対するファイル アクセス許可を必要とするのは正常ですか?
関連する詳細:
- Network Service には、アプリ フォルダーに対するフル コントロールのファイル アクセス許可があります。
- サーバー自体から接続するときに資格情報の入力を求められましたが、それらを入力すると認証され、Windowsログインの表示やデータベースへの接続とデータの取得など、アプリケーションが正しく動作します。
http://localhost後で、信頼済みサイトにあり、イントラネット ゾーンとして認識されず、ID が渡されなかったため、資格情報の入力を求められていると判断しました。また、ファイル権限を持つ管理者ユーザーであるため、このユーザー ID として機能していると判断しました。 - Web サーバーは Windows Server 2008 R2 / IIS 7.5 を実行しています。インストールするまでIISはありませんでした。デフォルトの機能と、Windows 認証、ASP.NET、および場合によっては他のいくつかの機能をインストールしました。IIS、匿名認証、および .net 2.0 を使用する、私がインストールした別の WCF アプリは、その Web サーバーで正常に動作しています。
- アプリのインストール プロセスは、ファイルの手動コピー、IIS アプリ プールと Web アプリの作成、接続文字列の更新などです。
- IE のセキュリティ設定を確認しました。サーバーがイントラネット ゾーンにあると認識し、[イントラネット ゾーンでのみ自動ログオン] オプションが選択されていました。また、詳細設定では、[統合 Windows 認証を有効にする] オプションがオンになっています。
- IIS をインストールした後
aspnet_regiis -i、.net 2.0 とaspnet_regiis -iru.net 4.0 を実行しました。 - アプリの匿名認証が無効になっており、Windows 認証が有効になっています。
- アプリは ASP.NET v4 で実行されていますが、ASP.NET v2 で同じ問題が発生している別のアプリをインストールしました。
- アプリは Identity = Network Service で 32 ビット モードで実行されています。
Trusted Connection=Trueデータベース接続文字列に[domain]\[server]$はDGM\MyServer$.- IIS > 認証 > Windows 認証 > プロバイダーでは、リストは最初にネゴシエート、次に NTLM でした。NTLMが最初になるように並べ替えてみました。
- Windows セキュリティ イベント ログには、一連の Microsoft Windows セキュリティ監査イベント (ログオンおよびログオフ) がありました。彼らは、ログオンが成功し、ワークステーション ユーザーのユーザー ID を表示していることを示しました。これは、別のワークステーションから接続していて、何度か試行した後に 401 Unauthorized を受け取ったときのものです。
誰かがこの問題をここで報告しているようですが、解決策はありません。最初にASPに投稿し、次にIISフォーラムに投稿しましたが、今のところ回答がありません。
更新: この msdn の記事は言う
Windows 認証が有効で、偽装が無効になっている場合、ASP.NET は、ブラウザーから送信された資格情報を使用して、ファイル承認モジュールでファイル アクセス チェックを実行します(私の強調)。 . 偽装を有効にする必要はありません。FileAuthorizationModule モジュールは、リクエストを実行する前に、リクエスト動詞 (GET や POST など) に応じて、リクエストしているユーザーにリソースへの読み取りアクセスまたは書き込みアクセスを許可することを保証するためです。この動作は、マネージ コードに入るすべての要求に適用されます。以前のバージョンの ASP.NET では、"Default.aspx" などの URI に基づいてファイルにアクセスすると、アクセス チェックがトリガーされました。通常、拡張子のない URL を使用してリソースへのアクセスが実行される ASP.NET MVC アプリケーションでは、チェックする物理ファイルがないため、このチェックは通常適用されません。その場合、FileAuthorizationModule クラスはフォールバックしてフォルダーのアクセス制御リスト (ACL) をチェックします。
これは、エンド ユーザーがファイル (.aspx の場合) またはフォルダー (MVC の場合) へのアクセス許可を必要としていることを示唆しています。アプリケーション プールに関するこの記事では、アプリケーション プールはリソースを保護するための ID として使用されていると述べていますが、これはエンド ユーザーに特権を付与する必要があるという考えと矛盾しています。App Pool と NETWORK SERVICE のルールが異なる場合を除き、これは事実である可能性がありますが、驚くべきことです。
