短縮版:
IIS 7.5 Windows認証を使用するWebアプリケーションは、エンドユーザーにファイルの読み取りアクセス権が必要ですか?
ロングバージョン:
Windows認証を使用するイントラネットASP.NET Webアプリがあります。数十の異なる企業にインストールされており、通常、認証は正常に機能します。ユーザーはサイトに移動します。 http://appserver/MyApp
、アプリはログインしているユーザーを認識し、それに応じてページを表示します。新しいクライアントにインストールしたところ、問題が発生しました。
接続するときなどto http://appserver/MyApp
Windows資格情報の入力を求められますが、入力後、繰り返し求められます。資格情報を何度か再入力した後、「401-権限がありません:資格情報が無効なため、アクセスが拒否されました」という401エラーページが表示されます。だから、それは私の身元を通過しないだけでなく、ユーザー名とパスワードを入力してもアクセスを拒否しています。
アプリのエンドユーザーに読み取りと実行の許可を与えると、この問題は解決しますが、これはまったく必要ないと思います。
Windowsのアプリケーションイベントログには、「要求のファイル認証に失敗しました」というメッセージがスレッドアカウント名とともに表示されます。NTAUTHORITY\NETWORK SERVICEおよびユーザー:[正しいワークステーションユーザーのドメインアカウント]。これは、ネットワークサービスのAppPool IDではなく、ユーザーのIDでファイルアクセスが実行されていることを示しています。エンドユーザーにアプリケーションのディレクトリへの読み取りと実行のアクセス許可(読み取りのみを試行しなかった)を許可すれば、すべてが正常に機能します。ユーザーがサイトを参照すると、自動的に認証され、プロンプトは表示されず、Webサイト彼らの身元を正しく認識します!したがって、私の回避策は、アプリケーションディレクトリの全員に読み取りと実行の許可を与えることですが、これは理想的な解決策ではありません。
これは非常に奇妙に思えます。私はこれまでにIIS 7.5でこれを行う必要はありませんでしたが、私が思い出す限り、絶対にIIS 6またはIIS 7.これは新しいIIS7.5のものですか?ドキュメントでは、偽装はデフォルトでオフになっています。web.configに要素を追加して、ネットワークサービス以外のファイル許可を削除しましたが、問題は残った。
何かご意見は? IIS 7.5上のWindows認証サイトは、エンドユーザーがWebサーバーファイルのファイルアクセス許可を必要とするのは正常ですか?
関連する詳細:
http://localhost
が信頼済みサイトにあり、したがってイントラネットゾーンとして認識されず、IDが渡されないため、資格情報の入力を求めていると後で判断しました。また、ファイルアクセス許可を持つ管理ユーザーであるため、このユーザーIDとして機能していると判断しました。aspnet_regiis -i
、. NET 4.0ではaspnet_regiis -iru
を実行しました。Trusted Connection=True
が含まれ、Webサーバーアカウント[domain]\[server]$
にデータベース権限が付与されます。 DGM\MyServer$
。誰かがこの問題を抱えているようです ここに報告 しかし、解決策はありません。もともと私は [〜#〜] asp [〜#〜] に投稿し、それから [〜#〜] iis [〜#〜] フォーラムにこれまでに答えがなかった。
更新: このmsdnの記事 は
Windows認証が有効になっているが、偽装が無効になっている場合、ASP.NETは、ブラウザーから送信された資格情報を使用して、 ファイル認証 モジュールでファイルアクセスチェックを実行します(私の強調)。 FileAuthorizationModuleモジュールは、リクエストを実行する前に、リクエスト動詞(GETやPOSTなど)に応じて、リクエストしているユーザーがリソースへの読み取りアクセスまたは書き込みアクセスを許可されるようにするため、偽装を有効にする必要はありません。この動作は、マネージコードを入力するすべての要求に適用されます。 ASP.NETの以前のバージョンでは、「Default.aspx」などのURIに基づいてファイルにアクセスすると、アクセスチェックがトリガーされました。通常、リソースへのアクセスが拡張子のないURLを使用して実行されるASP.NET MVCアプリケーションでは、チェックする物理ファイルがないため、このチェックは通常適用されません。その場合、FileAuthorizationModuleクラスは、フォルダーのアクセス制御リスト(ACL)のチェックにフォールバックします。
これは、エンドユーザーがファイル(.aspxの場合)またはフォルダー(MVCの場合)へのアクセス許可を必要としていることを示唆しています...それでも、これは少し隠れており、明確ではありません。 この記事 App Poolsについては、リソースを保護するためのIDとして使用されると述べており、エンドユーザーに特権を付与する必要があるという考えと矛盾しています。 App PoolsとNETWORK SERVICEのルールが異なる場合を除き、そうなる可能性がありますが、驚くべきことです。
短い答えはNOです。 IIS 7.0およびIIS 7.5。でWindows認証を使用する場合、ファイルアクセス許可を付与する必要はありません。
サーバー管理者が、ユーザーおよびグループにファイルレベルのアクセスを許可するルートをとることから生じるセキュリティと管理の問題を嗅ぎつけたため、これを発見することができました。
この問題に対処する場合、または新しいIIS7/IIS7.5サーバーをセットアップする場合、および/またはIIS 6から移行する場合は、Windows認証オプションのすべてを提供する記事また、個人またはグループにファイルレベルのアクセスを許可しないように変更する必要がある構成。
この記事で使用されているメソッドの有効な批評については、POSTの最後にある2つのコメントをお読みください。
記事の情報に加えて、IIS 7.5はsystem.webのWeb構成タグを使用していないことに注意してください(少なくとも私のMVC 4アプリケーションでは)。
認可設定用のsystem.webserverタグを探しています(アプリケーションにアクセスするためにユーザーが必要とするWindowsドメイン\グループをリストする必要があります)。
-DSB
認証されたユーザーはアプリフォルダーに許可されていますか?
また、この問題と戦い、ユーザーにファイルレベルのアクセス許可を付与できるようにセキュリティグループの設定を開始しました。その後、サーバー管理者の1人が、設定された資格情報の下でアプリがファイルシステムを認証できるようにするいくつかの新しいプロパティを見つけ、ユーザーがアクセスする必要性を解決しました。ここに彼が思いついたものがあります…
これを制御する2つのIIS設定があります。
物理パス資格情報物理パス資格情報ログオンタイプ
デフォルトでは、Physical Path CredentialsはApplication User(パススルー認証)に設定されています。つまり、IISはWindows認証要求を処理するときに偽装を行いません。ただし、これは特定のユーザーに設定できます(ただし、残念ながら、アプリケーションプールIDは、理想)物理パス資格情報ログオンタイプはデフォルトでクリアテキストに設定されています。テストでは、これをインタラクティブに設定します(これは正しい値ではないかもしれません)。可能な値はクリアテキスト、バッチ、インタラクティブ、およびネットワークです。
これを設定するために、次のことを行いました。
- ローカルアカウント(IIS-AccessUser)を作成しました
- サイトの/ homeディレクトリへの読み取りおよび実行アクセス権をIIS-AccessUserに付与しました。
- IIS-AccessUserをIIS_IUSRSグループに追加しました(.NET一時ファイルへのアクセスに必要)
- IIS-AccessUserを物理パスの資格情報として設定します
- 物理パス資格情報のログオンタイプをインタラクティブに設定します
上記の操作を行うと、認証済みユーザーを許可することなく、アプリケーションに直接ログインできます。または、/ homeフォルダー内のグループのメンバーである必要があります。また、.NET承認ロールも保持されているため、許可されていないサイトの一部にアクセスできませんでした。