この記事では、ASP.NET の一般的なアクセス許可とセキュリティ関連の問題をトラブルシューティングする方法について説明します。
元の製品バージョン: ASP.NET
元の KB 番号: 910449
便利なツール
破損した問題を修正する前に、いくつかのツールを理解しておく必要があります。これは、問題を絞り込むのに役立ちます。 ここでは、FileMon、RegMon、Security Auditing などのツールに関心があります。 FileMon の詳細については、「 FileMon for Windows v7.04」を参照してください。
RegMon の詳細については、「 Windows Sysinternals」を参照してください。
詳しく調査して問題を特定する
- アプリケーションは動作したことがありますか? 「はい」の場合、アプリケーションを中断させた可能性のある変更は何ですか? ソフトウェア更新プログラムまたはセキュリティ更新プログラムがサーバーに適用されている可能性があります。 コードのロールアウトによって問題が発生した可能性もあります。
- 単純な.htmlページと.aspページは IIS から提供されますか?
- アプリケーションは別のバージョンの IIS に移行されましたか?
- サーバー上の他の ASP.NET アプリケーションが同じエラーで失敗しますか? これが失敗する唯一のアプリケーションですか?
- この問題は、すべてのユーザーまたは特定のユーザーに対してのみ発生しますか?
- この問題は、Web サーバーでローカルで参照しているときに再現できますか。それとも、少数のクライアントでのみ再現可能ですか?
- 偽装を使用している場合、偽装されたユーザーはリソースに必要なアクセス権を持っていますか?
上記の質問は、問題を診断するために役立ちます。 ASP.NET フォーラムのいずれかに問題を投稿していて、これらの質問のほとんどに対する回答が既にある場合は、問題への迅速なポインターまたは解決策が得られる可能性があります。 ASP.NET アプリケーションを実行している際に「アクセス拒否エラーが発生しています」と言うのではなく、可能であればASP.NETスタックトレースエラー全体を投稿することが重要です。 誰か助けてくれますか? スタックトレースを見て、完全なエラーメッセージがあると、誰かがそれに基づいてアドバイスをするのが簡単になります。 だから、あなたは自分自身に尋ねる必要があります...
正確なエラー メッセージは何ですか?
最初にお客様に質問する質問は、「正確なエラー メッセージは何ですか?」です。Microsoft .NET Framework によってスローされたエラー メッセージの明確な説明がある場合は、このセクションをスキップできます。 アプリケーションで実際のエラー メッセージがマスクされ、代わりにわかりやすいエラー メッセージが表示される場合は、"予期しないエラーが発生しました。 詳細については、Web サイトの管理者に問い合わせてください。"これは誰にもあまり使用されません。 実際のエラー メッセージを取得するのに役立ついくつかの手順を次に示します。
アプリケーション ディレクトリで Web.config ファイルを見つけて開き、 customErrors を mode="Off" に変更します。 ファイルを保存し、問題を再現します。
アプリケーション開発者が行ったカスタム イベント/エラー処理のため、上記の手順を実行した後も、実際のエラー メッセージを表示できない場合があります。 Global.asax ファイルで Application_Error イベントを見つけ、
Server.Transfer("Errors.aspx")
関数を使用してカスタム エラー ページに移動するコードをコメント アウトすることができます。//Global.asax void Application_Error(object sender, EventArgs e) { // Code that runs when an unhandled error occurs //Server.Transfer("Errors.aspx"); }
実際のエラー メッセージが表示されたら、それを読んで、ローカル リソースまたは ASP.NET アプリケーションがアクセスしようとしているリモート リソースに対するアクセス許可が不足しているためにエラーが発生しているかどうかを判断します。
ヒント
実際のエラー メッセージを表示する方法については、開発者に問い合わせてください。 開発者がファイルにログを記録したり、電子メール通知を受け取ったりしている可能性があります。 変更するファイルは必ずバックアップしてください。 バックアップを使用できる場合は、いつでも変更をロールバックできます。
ASP.NET アプリケーションがアクセスしようとするローカル リソースに対するアクセス許可がないために問題が発生する
カスタム エラー メッセージが原因で問題の明確な説明が得られない場合は、FileMon を実行して問題を再現します。 キャプチャを停止してFileMon.xlsとして保存し、Microsoft Excel でファイルを開きます。 [ データ ] メニューの [ フィルター] を選択し、[ オートフィルター ] を選択して Excel のフィルター機能を使用します。 次に、 F
列のドロップダウン リストを選択し、"ACCESS DENIED" エラーを探します。
FileMon の出力例を次に示します。
10381 1:01:11 PM w3wp.exe:2320 OPEN C:\winnt\microsoft.net\framework\v1.1.4322\Temporary ASP.NET Files\sessiontest\8832e585\275ec327\global.asax.xml
ACCESS DENIED NT
AUTHORITY\NETWORK SERVICE
フィルター処理された結果からわかるように、問題の原因を絞り込んでいます。 FileMon は、NT AUTHORITY\NETWORK SERVICE アカウントに、 C:\Winnt\Microsoft.net\Framework\v1.1.4322\Temporary ASP.NET Files
フォルダーの NTFS アクセス許可が不足していることを示しています。 これは直ちに修正する必要があります。
ヒント
ASP.NET プロセス アカウントを管理者アカウントに変更して、問題が解決されるかどうかを確認することをお勧めします。 IIS 6.0 以降のバージョンでは、IIS AppPool ID を "ローカル システム" に変更して、アプリケーションが動作するかどうかを確認します。
注
これは、ソリューションとしてではなく、トラブルシューティングの手順としてのみ使用する必要があります。
ほとんどのユーザーは、Microsoft .NET Framework を再インストールしたり、オペレーティング システムを再インストールしたりする傾向があります。 これは推奨されるトラブルシューティング手順ではなく、問題が再発しないことを保証するものではありません。 そのような例を 1 つ提供します。 断続的な問題は、多くの場合、分離とトラブルシューティングが困難です。 このシナリオでは、顧客のアプリケーションは数時間正常に動作し、突然、次のエラーで失敗します。 お客様は既に .NET Framework とオペレーティング システムの再インストールを試みました。 これは数日間問題を解決するように見えたが、その後再び現れた。
FileMon を実行しても ACCESS DENIED エラーは表示されませんでした。 ASPNET アカウントに必要なすべてのアクセス許可が設定されました。 問題から回復する唯一の方法は、ボックスを再起動することです。 IIS のリセットでも役に立つことはありません。 "Ah, Microsoft Software always needs a reboot to recover?" (Microsoft ソフトウェアは常に再起動して回復する必要がある) と考えています。さて、あなたは間違っています!
ここで重要なポイントは、エラー メッセージを詳しく調べてください。 このエラーは、通常の ACCESS DENIED エラーではなく、"書き込み用にファイルを開くことができません" と明確に示されているため、ファイルまたはフォルダーのロックを保持し、ASP.NET が書き込みを許可していない他のプロセスであると考えています。 再起動によって他のプロセスが強制終了され、不正なプロセスによってファイルが再度ロックされるまで、ASP.NET アプリケーションが再び動作を開始することは理にかなっています。 論理的な操作は、すべてのウイルス対策プログラム、サードパーティのスパイウェア、またはサーバー上で実行されているその他のファイル監視ソフトウェアをオフにすることです。 私は特定のサードパーティ製ソフトウェアを指摘したくありません。 しかし、一般に、ウイルス対策ソフトウェアは、IISと ASP.NET アプリケーションに多くの悲しみを引き起こすことが知られています。 ウイルス対策ソフトウェアによって引き起こされるもう 1 つの既知の問題は、Bin フォルダーまたは .config ファイルがタッチされたときに AppDomain のリサイクルが原因でセッションが失われることです。
ヒント
サードパーティのサービスをオフにする最も簡単な方法は、次のとおりです。
- [ スタート] を選択し、[ 実行] を選択し、「 msconfig」と入力します。
- サービスを選択し、すべての Microsoft サービスを非表示にします。
- [ すべて無効にする] を選択して、サード パーティのサービスを停止します。
- [スタート] を選択し、[実行] を選択し、「iisreset」と入力して CLR をワーカー プロセスに再読み込みします。
アプリケーションを監視して、問題が繰り返し発生するかどうかを確認します。 複数のウイルス対策プログラムを実行する場合は、試用版とエラーの方法を使用して、問題の原因となっている特定のプログラムを特定します。
注意
同じエラーが 100% の時間再現可能な場合は、ウイルス対策ソフトウェアが原因ではない可能性があります。 このエラーの他の原因が考えられます。 単純な ASP.NET テスト アプリケーションを作成して、Test.aspx ページで同じエラーが発生するかどうかを特定してみてください。 その場合は、必要なアクセス制御リスト (ACL) がすべて ASP.NET に配置されていることを確認します。
「必要なアクセス制御リスト (ACL) ASP.NETを参照してください。
ヒント
%SystemRoot%\Assembly
フォルダーはグローバル アセンブリ キャッシュです。 Windows エクスプローラーを使用してこのフォルダーの ACL を直接編集することはできません。
代わりに、コマンド プロンプトを使用し、次のコマンドを実行します。
cacls %windir%\assembly /e /t /p domain\useraccount:r
または、Windows エクスプローラーを使用する前に、次のコマンドを使用してShfusion.dllの登録を解除し、GUI を使用してアクセス許可を付与します。
C:\WINDOWS\Microsoft.NET\Framework\VersionNumber>regsvr32-u shfusion.dll
Windows エクスプローラーでアクセス許可を設定した後、次のコマンドを使用してShfusion.dll再登録します。
C:\WINDOWS\Microsoft.NET\Framework\VersionNumber>regsvr32 shfusion.dll
ASP.NET アプリケーションがアクセスしようとしているリモート リソースに対するアクセス許可がないために問題が発生する
ASP.NET アプリケーションが Microsoft SQL Server や汎用名前付け規則 (UNC) 共有などのリモート リソースにアクセスしている場合、多くの問題が発生する可能性があります。 また、リモート リソースに多くの設定が正しく設定されていない可能性があります。 リソースを動作させるには、これらの問題のトラブルシューティングを行う必要があります。
最初の手順では、Windows エクスプローラーを使用してリモート サーバーに接続できるかどうかを確認します。
リモート サーバーで、Test という名前のフォルダーを作成します。 テスト フォルダーの Sharing と Security タブで、ドメイン/アカウントと、ASP.NET アプリケーションで使用されるプロセス アカウントを追加し、両方にフル コントロールを付与します。
IIS サーバーで、ドメイン/アカウントでログインし、[ スタート] を選択して [実行] を選択し、リモート サーバーの UNC 共有パスを入力します:
\\RemoteServerName*\Test
。このフォルダーにアクセスできない場合は、ネットワーク管理者に連絡してこの問題を解決してください。 その場合にのみ、ASP.NET アプリケーションは共有にアクセスできます。
次のコードで CreateUNCFile.aspx という名前のファイルを作成し、アプリケーション ディレクトリにファイルを保存します。
<%@ Page Language="vb" %> <%@ Import Namespace="System.IO" %> <html> <head> <title>Writing to a Text File</title> <script runat="server"> Sub WriteToFile(ByVal sender As System.Object, ByVal e As System.EventArgs) Dim fp As StreamWriter fp = File.CreateText("\\<RemoteServerName>\Test\" & "test.txt") fp.WriteLine(txtMyFile.Text) lblStatus.Text = "The File Successfully created! Your ASP.NET process is able to access this remote share" fp.Close() End Sub </script> </head> <body style="font: 10pt verdana"> <h3 align="center">Creating a Text File in ASP.NET</h3> <form id="Form1" method="post" runat="server"> Type your text: <asp:TextBox ID="txtMyFile" TextMode="MultiLine" Rows="10" Columns="60" Runat="server" /><br> <asp:button ID="btnSubmit" Text="Create File" OnClick="WriteToFile" Runat="server" /> <asp:Label ID="lblStatus" Font-Bold="True" ForeColor="#ff0000" Runat="server" /> </form> </body> </html>
次のコード行 <RemoteServerName> を必ず変更してください
fp = File.CreateText("\\<RemoteServerName>\Test\" &"test.txt")
リモート サーバーの名前が反映されるようにします。
Windows Internet Explorer を開き、IIS サーバー以外のクライアント コンピューターから
http://**IISServerName**/**AppName**/CreateUNCFile.aspx
を参照します。Test.txt ファイルが正常に作成された場合、ASP.NET アプリケーションはリモート リソースに対して認証できます。
Internet Explorer クライアント ブラウザーからファイルの作成が失敗したが、IIS サーバー自体から同じページを参照した場合に機能する場合は、"ダブル ホップ" シナリオが発生している可能性があります。 カスタムビルド Web パーツを使用して、ユーザーの認証と承認を必要とするリモート リソースにアクセスしている場合は、"ダブルホップ" の問題が発生する可能性があります。 リモート リソースにアクセスするには、エンド ユーザーの資格情報をリソースに提供して、リソースからの出力が、エンド ユーザーがアクセス許可を持つデータに制限されるようにする必要がある場合があります。
上記の手順では、IIS で NTLM 認証が有効になっていることを前提としています。 基本認証では Kerberos は使用されません。
詳細については、「 Internet Explorer での Kerberos エラーのトラブルシューティングを参照してください。
IIS 認証方法の詳細については、「 Visual Studio 2003 Retired Technical documentationを参照してください。
ヒント
リモート UNC 共有に接続できるが、ASP.NET アプリケーションから SQL Server を実行しているリモート サーバーに接続できない場合は、SQL Server のサービス プリンシパル名 (SPN) を確認または設定する必要があります。 IIS でアプリケーションの基本認証のみを有効にして、SQL Server を実行しているリモート サーバーに接続できるかどうかを確認してください。
"サーバー アプリケーションを使用できません" というエラー メッセージには、他にも多数の原因があります。 イベント ログは、問題の原因の詳細を取得するための最善の策です。
IIS 関連のエラー
IIS ログは、IIS 認証関連のエラーが発生した場合に役立ちます。
検索する必要があるのが、この特定のエラーの状態コードとサブ状態コードです。
2006-10-12 22:47:28 W3SVC1 65.52.18.230 GET /MyAPP/login.aspx - 80
MyDomain\UserID_91 65.52.22.58 Mozilla/4.0+
(compatible;+MSIE+6.0;+Windows+NT+5.2;+SV1;+.NET+CLR+1.1.4322;+.NET+CLR+2.0.50727;+InfoPath.1) 401 3 5
サブステータス 3 の 401 が表示されます。これは、"リソースの ACL が原因で承認されていません" を示します。
これは、ファイルまたはフォルダーに NTFS アクセス許可が見つからない場合を示します。 このエラーは、アクセスしようとしているファイルのアクセス許可が正しい場合でも発生する可能性がありますが、他の SYSTEM フォルダーと IIS フォルダーに既定のアクセス許可とユーザー権限がない可能性があります。 たとえば、IUSR_ComputerName アカウントが C:\Winnt\System32\Inetsrv ディレクトリにアクセスできない場合、このエラーが表示されることがあります。
ヒント
[スタート] を選択し、[実行] を選択し、「ログ ファイル」と入力して、IIS ログを含むフォルダーを開きます。 または、IIS の Web サイトのプロパティ ページで、[ WebSiteName ] タブを選択し、[ アクティブ なログ形式] で [プロパティ ] を選択して、ログ ファイルのディレクトリと名前を表示します。
もう 1 つの関心事は、状態コード 5 です。 net helpmsg コマンドを使用して、この状態コードの詳細情報を取得できます。
C:\Documents and Settings\User> net helpmsg 5
アクセスが拒否されました。
もう 1 つの一般的な状態コード (コード 50) を試してみましょう。
C:\Documents and Settings\User> net helpmsg 50
要求はサポートされていません。
ヒント
別の一般的な悪名高い "500 内部サーバー エラー" メッセージが表示されたら、エラーの詳細な説明を受け取るように、わかりやすい HTTP エラー メッセージを無効にすることをお勧めします。 イベント ビューアーには詳細情報も含まれている可能性があるため、忘れないでください。
この考え方は、ログに記録されたすべての情報を使用して、手元の問題に関する最大の詳細を取得することです。
リソース
詳細については、以下を参照してください: