次の方法で共有

フォーム認証のトラブルシューティング

適用対象: インターネット インフォメーション サービス

多くの場合、ASP.NET Web アプリケーションでフォーム認証を使用しているときに、新しい要求または進行中の要求がアプリケーションのログイン ページに断続的にリダイレクトされたときに発生する問題をトラブルシューティングする必要があります。 開発環境でデバッガーをアタッチすることで、Visual Studio IDE でこの問題をデバッグできます。 ただし、運用環境では、タスクは多くの問題になります。 このようなランダムな問題をトラブルシューティングするには、根本原因を絞り込むことができるように、問題に関連する情報をログに記録する必要があります。

この記事では、フォーム認証の概念について簡単に説明します。 また、ログイン ページにリダイレクトされるユーザーに関するさまざまなシナリオと、問題の特定に関連するデータをキャプチャする方法についても説明します。 さらに、フォーム認証情報をログに記録する IHttpModule インターフェイスを実装する方法についても説明します。

ASP.NET フォーム認証の概要

フォーム認証を使用すると、独自のコードを使用してユーザーを認証し、Cookie または URL で認証トークンを保持できます。 フォーム認証は、 FormsAuthenticationModule クラスを通じて ASP.NET ページのライフ サイクルに参加します。 FormsAuthentication クラスを使用して、フォームの認証情報と機能にアクセスできます。

フォーム認証を使用するには、ユーザーから資格情報を収集し、資格情報を認証するコードを含むログイン ページを作成します。 通常、ユーザーが認証を必要とするページなど、保護されたリソースにアクセスしようとしたときに、要求をログイン ページにリダイレクトするようにアプリケーションを構成します。 ユーザーの資格情報が有効な場合は、 FormsAuthentication クラスのメソッドを呼び出して、適切な認証チケット (Cookie) を使用して要求を元の要求されたリソースにリダイレクトできます。 リダイレクトが不要な場合は、フォーム認証 Cookie を取得するか、設定するだけです。 それ以降の要求では、ブラウザーは要求と共に認証 Cookie を渡し、ログイン ページをバイパスします。

既定では、 FormsAuthenticationModule クラスは Machine.config ファイルに追加されます。 FormsAuthenticationModule クラスは、フォーム認証プロセスを管理します。

Machine.config ファイルに次のエントリが表示されます。

<httpModule> 
  <add name="FormsAuthentication" type="System.Web.Security.FormsAuthenticationModule" />            
</httpModule>

ログイン ページの設定など、認証構成要素を使用してフォーム認証を構成できます。 構成ファイルで、認証されていない要求をログイン ページにリダイレクトする URL を指定します。

認証が成功すると、 FormsAuthenticationModule モジュールは、認証されたユーザーへの参照に User プロパティの値を設定します。 次のコード例は、フォーム認証ユーザーの ID をプログラムで読み取る方法を示しています。

String authUser2 = User.Identity.Name;

フォーム認証を使用する便利な方法は、ASP.NET メンバーシップと ASP.NET ログイン コントロールを使用することです。 ASP.NET メンバーシップを使用すると、ユーザー情報を格納および管理でき、ユーザーを認証する方法が含まれます。 ASP.NET ログイン コントロールは、ASP.NET メンバーシップと連携して動作します。 これは、ユーザーに資格情報の入力を求め、ユーザーを検証し、パスワードを回復または置換するロジックをカプセル化します。 実際には、ASP.NET メンバーシップと ASP.NET ログイン コントロールは、フォーム認証に対する抽象化レイヤーを提供します。 これらの機能は、フォーム認証を使用するために通常行う必要があるほとんどの作業またはすべての作業を置き換えます。

シナリオ

login.aspx ページにリダイレクトされる要求のシナリオを次に示します。

フォーム認証 Cookie が失われます。

シナリオ 1

Web サイトにログオンします。 ある時点で、クライアントはサーバーに要求を送信し、 FormsAuthenticationModule クラスは Cookie を受け取りません。

シナリオ 2

フォーム認証 Cookie は、クライアントの Cookie の制限を超えた場合にも失われる可能性があります。 Microsoft Internet Explorer には、20 個の Cookie の制限があります。 カウンターが 20 に達すると、前の 19 個の Cookie がクライアントのコレクションから削除されます。 ASPXAUTH Cookie が削除されると、次の要求が処理されるときにログイン ページにリダイレクトされます。

シナリオ 3

要求がクライアントから離れた後には、送信されるパケットに影響を与える可能性のあるさまざまなレイヤーがあります。 ネットワーク デバイスが Cookie を削除しているかどうかを判断するには、クライアントとサーバーでネットワーク トレースをキャプチャし、要求の本文で Cookie を探す必要があります。 クライアント要求を調べて Cookie が送信されたことを確認し、サーバーのトレースを調べて、サーバーが Cookie を受信したことを確認します。

フォーム認証チケットがタイムアウトしました

ASP.NET 2.0 以降のアプリケーションでは、既定ではフォーム認証 timeout 値が 30 分に変更されました。 つまり、非アクティブ状態が 30 分続くと、もう一度ログインするように求められます。

Note

毎回 Web サイトにアクセスすると、30 分のウィンドウ クロックがリセットされます。 アイドル状態の場合にのみ、タイムアウトがあります。

timeoutの値を長く変更する場合は、ローカル web.config ファイルのtimeout値を簡単に変更できます (timeoutの値は分単位です)。

<system.web> 
 <authentication mode="Forms">     
   <forms timeout="120"/>                 
 </authentication>
</system.web>

シナリオ 4

フォーム認証は、構成ファイルで定義されている timeout 属性の値の前に期限切れになる可能性があります。

フォーム認証チケットが手動で生成された場合、チケットの timeout プロパティは、構成ファイルに設定されている値をオーバーライドします。 そのため、その値が構成ファイルの値より小さい場合、フォーム認証チケットは、構成ファイルの属性値 timeout 前に期限切れになります。その逆も同様です。 たとえば、 FORMS タイムアウト属性が Web.config ファイルで 30 に設定され、チケットの有効期限の値が 20 分に設定されているとします。 この場合、フォーム認証チケットは 20 分後に期限切れになり、再度ログオンする必要があります。

Event code: 4005
Event message: Forms authentication failed for the request. Reason: The ticket 
supplied has expired.

シナリオ 5

フォーム認証を使用する ASP.NET 4 Web アプリケーションでは、イベント ログ メッセージに次のように表示されます。

Event code: 4005 
Event message: Forms authentication failed for the request. Reason: The ticket supplied was invalid.

データの収集とトラブルシューティング

トラブルシューティング シナリオ 1

Microsoft インターネット インフォメーション サービス (IIS) で Cookie のログ記録を有効にすると、要求に Cookie が含まれていないかどうかを確認できます。 そのためには、次の手順に従います。

  1. IIS Microsoft 管理コンソール (MMC) を開きます。
  2. Web サイトを右クリックし、 Properties を選択します。
  3. Web サイト タブを選択し、有効なログ記録を選択します。
  4. ログ形式が W3C 拡張ログ ファイル形式であることを確認します。
  5. プロパティを選択します。
  6. [Advanced] タブを選択し、[目的のプロパティを選択します。
  7. Extended プロパティで、Cookie(cs(Cookie))とReferer (cs(Referer) チェックボックスをオンにします。

この問題が発生したら、問題が発生したクライアントとそのクライアントの IP アドレスを特定します。 そのクライアントの IP アドレスで IIS ログをフィルター処理し、 <COOKIE> 列を表示します。

Note

Log Parser を使用して IIS ログを解析します。

特定のユーザーからの要求の一覧を取得したら、ログイン ページへの要求を検索します。 このページにリダイレクトされたことがわかっている場合は、リダイレクトが発生する前に要求を確認する必要があります。 次のような内容が表示された場合、クライアントが Cookie を送信しなかったか、クライアントとサーバーの間のネットワーク上で Cookie が削除されました。

Note

永続的な Cookie を作成しない限り、最初の要求にはフォーム認証 Cookie が含まれていない可能性があります。 IIS ログには、要求で受信した Cookie のみが表示されます。 ログイン試行が成功した後にフォーム認証 Cookie を取得するための最初の要求。

トラブルシューティング シナリオ 2

Microsoft Internet Explorer は、RFC 2109 が推奨する次の最小要件に準拠しています。

  • 少なくとも 300 個の Cookie。
  • Cookie あたり少なくとも 4,096 バイト (Set-Cookie ヘッダーの構文の説明で Cookie の非ターミナルを構成する文字のサイズによって測定されます)。
  • 一意のホスト名またはドメイン名ごとに少なくとも 20 個の Cookie。

フォーム認証 Cookie は、クライアントの Cookie の制限を超えた場合にも失われる可能性があります。 Microsoft Internet Explorer には、20 個の Cookie の制限があります。 カウンターが 20 に達すると、前の 19 個の Cookie がクライアントのコレクションから削除されます。 ASPXAUTH Cookie が削除されると、次の要求が処理されるときにログイン ページにリダイレクトされます。 Fiddler を使用して HTTP 要求ヘッダーまたは応答ヘッダーを表示し、クライアントから Cookie を受信しているかどうかを確認できます。 Fiddler をダウンロードします。

クライアント コンピューターで Fiddler ツールを起動し、既存の HTTP トレースを削除し、フォーム認証を実装するアプリケーションにアクセスし、アプリケーションへのログインを試み、Fiddler 上の HTTP トラフィックを観察して、クライアントとサーバーの間でフォーム認証 Cookie の交換が行われているかどうかを確認します。 トラフィックをキャプチャした後、要求をダブルクリックし、 Headers を選択して Set-Cookie ヘッダーを表示します。 成功したログインをトレースすると、成功したログインの応答に Set-Cookie ヘッダーが表示されます。

既定では、Internet Explorer はドメインごとに最大 20 個の Cookie を格納できます。 ドメイン内のサーバーが 20 個を超える Cookie をクライアント コンピューターに送信すると、クライアント コンピューター上のブラウザーは古い Cookie を自動的に破棄します。

各 Cookie は、1 つの名前と値のペアで構成されます。 このペアの後に、セミコロンで区切られた属性と値のペアが続く場合があります。 この制限は、多くの Cookie を使用する必要があるドメインでの Web アプリケーションの開発とホストを簡素化するために増やされました。 更新プログラム 937143 をインストールすると、Internet Explorer がドメインごとに格納できる Cookie の数が 20 個から 50 個に増えます。 詳細については、「 Internet Explorer と Microsoft Edge の IT 担当者向けのよく寄せられる質問 (FAQ)ɷ」を参照してください。

トラブルシューティング シナリオ 3

要求がクライアントから離れると、送信されるパケット (ファイアウォール、プロキシ、ロード バランサー) に影響を与える可能性のあるさまざまなレイヤーが存在します。 ネットワーク デバイスが Cookie を削除しているかどうかを判断するには、クライアントとサーバーでネットワーク トレースをキャプチャし、要求の本文で Cookie を検索する必要があります。 クライアント要求を調べて Cookie が送信されたことを確認し、サーバートレースを調べて、サーバーがその Cookie を受け取ったかどうかを確認することができます。

クライアント要求

これは、ユーザーが認証された後の GET 要求です。 フォーム認証チケット情報は灰色で強調表示されています。 これにより、Cookie 情報がクライアントから離れたことが確認できます。 WireShark などのネットワーク キャプチャ ツールを使用すると、実際にアダプターを通過したトラフィックが表示されます。

47 45 54 20 68 74 74 70-3a 2f 2f 6c 6f 63 61 6c   GET http://local
68 6f 73 74 2f 46 6f 72-6d 73 41 75 74 68 4c 6f   host/FormsAuthLo
67 54 65 73 74 2f 57 65-62 46 6f 72 6d 31 2e 61   gTest/WebForm1.a
73 70 78 20 48 54 54 50-2f 31 2e 31 0d 0a 41 63   spx HTTP/1.1..Ac
63 65 70 74 3a 20 69 6d-61 67 65 2f 67 69 66 2c   cept: image/gif,
…Other headers of the GET request…
63 68 65 0d 0a 43 6f 6f-6b 69 65 3a 20 2e 41 53   che..Cookie: .AS
50 58 41 55 54 48 3d 33-43 45 46 39 42 39 41 30   PXAUTH=3CEF9B9A0
43 33 37 41 44 46 36 33-45 36 42 44 33 37 42 36   C37ADF63E6BD37B6
39 43 44 41 32 35 30 30-30 46 38 30 37 32 38 46   9CDA25000F80728F
35 31 43 39 35 36 36 44-31 34 43 35 34 31 34 35   51C9566D14C54145
38 31 43 39 33 45 32 41-30 31 44 44 43 44 45 46   81C93E2A01DDCDEF
32 34 41 31 37 34 32 39-34 31 30 43 30 39 37 34   24A17429410C0974
42 33 45 43 42 30 36 34-32 32 38 45 33 35 33 39   B3ECB064228E3539
39 41 38 32 32 42 33 42-39 33 36 44 46 30 38 46   9A822B3B936DF08F
42 41 42 44 33 45 31 30-32 44 30 30 32 31 30 43   BABD3E102D00210C
32 45 31 33 39 38 30 37-39 42 32 33 35 32 39 46   2E1398079B23529F
34 46 35 44 37 34 41 3b-20 50 72 6f 66 69 6c 65   4F5D74A; Profile
3d 56 69 73 69 74 6f 72-49 64 3d 62 32 34 65 62   =VisitorId=b24eb

サーバー側の要求

サーバーに到達した要求が表示されたら、クライアントが送信したのと同じ情報をサーバーが受信したことを確認します。 サーバーが同じ情報を受信しなかった場合は、ネットワーク上の他のデバイスを調査して、Cookie が削除された場所を特定する必要があります。

Note

Cookie を削除する ISAPI フィルターのインスタンスもあります。 Web サーバーが Cookie を受信したが、Cookie が IIS ログに一覧表示されていないことを確認する場合は、ISAPI フィルターを確認します。 問題が解決されたかどうかを確認するには、フィルターを削除する必要がある場合があります。

トラブルシューティング シナリオ 5

  • シナリオに Web ファームが含まれている場合は、Web ファーム内の各サーバーの構成ファイルの検証キーと復号化キーの値が同じであることを確認します。この値はそれぞれハッシュと復号化に使用されます。 ファーム内のすべてのサーバーで整合性を維持するには、次の machineKey を使用します。

    <machineKey validationKey="<yourKey>" decryptionKey="<yourKey>" validation="SHA1" />

    マシン キーの詳細については、「 Machine Key と Plan Application Security」を参照してください。

    マシン キーを生成する方法については、「 Machine キーの設定を参照してください。

  • 両方のフォーム (認証モジュールとセッション モジュール) の timeout 値をすべての Web サーバーで比較します。

  • ファーム内のすべての Web サーバー間で、ASP.NET 4 の Framework フォルダーの下にある System.Web.dll バージョンを比較します。 要求のフォーム認証に失敗した。 理由は、指定されたチケットが無効だったということです。 これは、いずれかの Web サーバーで MS .NET Framework 4 の信頼性更新プログラム 1 が不足しているために発生します。

  • .NET Framework 4 kb2533523 の Reliability Update 1 を、不足していたサーバーにインストールし、サーバーを再起動します。 問題が修正されました。 詳細については、「 .NET Framework 4 の責任更新プログラム 1を参照してください。

詳細

サードパーティの情報に関する免責事項

この資料に記載されているサードパーティ製品は、マイクロソフトと関連のない他社の製品です。 明示的か黙示的かにかかわらず、これらの製品のパフォーマンスや信頼性についてマイクロソフトはいかなる責任も負わないものとします。