概要
この技術情報は組織的に Firepower システムのデータパスを解決する方法を Firepower のコンポーネントはトラフィックに影響を及ぼすかもしれないかどうか判別するために説明する一連の技術情報の一部です。 他のデータパス トラブルシューティング技術情報への Firepower プラットフォームおよびリンクのアーキテクチャについての情報に関しては概要技術情報を参照して下さい。
この技術情報は Firepower データパス トラブルシューティングの第 6 ステージを、アクティブな認証機能カバーします。

前提条件
- この技術情報は現在サポートされた Firepower プラットフォームすべてに関係します
- Firepower デバイスは経路選択済み モードで動作したにちがいありません
アクティブな認証フェーズのトラブルシューティング
確認することを試みるとき問題が識別によって引き起こされていたかどうか、どんなトラフィックに影響を与えるこの機能がことができるか理解することは重要です。 トラフィック interuptions を引き起こす場合がある識別の唯一の機能自体はアクティブな認証に関する物です。 受動認証はトラフィックを予想に反して廃棄します場合がありません。 HTTPトラフィックだけアクティブな認証によって影響を与えられることを理解しておくことは重要です。 識別がはたらいていないので他のトラフィックが影響を与えられればこれは予想外事柄が発生する場合があるがデバイスアクセス 制御 ポリシーおよび識別ポリシーによって決まる識別機能 ユーザを識別できないので割り当てるべきポリシー使用ユーザ/グループ/ブロック トラフィックが、従ってときより本当らしいです。 このセクションのトラブルシューティングはアクティブな認証だけに関する問題によって歩きます。
リダイレクト 方式を確認して下さい
アクティブ 認証機能は HTTPサーバを実行する Firepower デバイスを含みます。 トラフィックがアクティブな認証操作が含まれている識別ポリシー ルールと一致するとき、Firepower はセッションに捕虜ポータル サーバーにクライアントをリダイレクトするために 307 (一時リダイレクト)パケットを、送信 します。
現在アクティブな認証には 5 つの異なる型があります。 2 つのリダイレクト レルムに結ばれるへのセンサーのホスト名および Active Directory プライマリ ドメインで構成されているホスト名および捕虜門脈リダイレクトを行っている Firepower デバイスのインターフェイスの IP アドレスへの 3 つのリダイレクト。
何かがリダイレクト プロセスでうまくいかない場合、セッションはサイトが利用できないので壊れることができます。 こういうわけでリダイレクションが実行コンフィギュレーションでオペレーティングどのようにであるか理解することは重要です。 この設定側面を理解するヘルプの下の図。

アクティブな認証がホスト名にリダイレクトする場合、ciscoasa.my-ad.domain にクライアントをリダイレクトしていました: <port_used_for_captive_portal>
生成する パケットキャプチャ
パケットキャプチャを集めることはトラブルシューティング アクティブな認証問題のほとんどの重要な部分です。 パケットキャプチャは 2 つのインターフェイスで起こります:
- 識別/認証が実行された場合のトラフィックが ingressing Firepower デバイスのインターフェイス
- 下記の例では、内部インターフェイスは使用されます
- Firepower が HTTPS サーバにリダイレクションのために- tun1 使用する内部 トンネルインターフェイス
- このインターフェイスが捕虜ポータルにトラフィックをリダイレクトするのに使用されています
- トラフィックの IP アドレスは出力にオリジナルに戻ります

2 人のキャプチャは Firepower デバイスを通って、関連 トラフィック動作します始められます、そしてキャプチャは停止します。
内部インターフェイス パケットキャプチャ ファイルが、「ins_ntlm」、/mnt/disk0 ディレクトリにコピーされることに注意して下さい。 それはデバイス(すべての FTD プラットフォームの /ngfw/var/common)の /var/common ディレクトリにダウンロードされるためそれからことができますコピーする:
> expert
# copy /mnt/disk0/<pcap_file> /var/common/
パケットキャプチャ ファイルはこの技術情報の方向を使用して > プロンプトから Firepower デバイスのそれからコピーすることができます。
また、Firepower バージョン 6.2.0 および それ 以上の Firepower Management Center (FMC)に n オプションがあります。 FMC のこのユーティリティに、ナビゲート デバイス > デバイス管理にアクセスするため。 それから、疑わしいデバイス
の隣でアイコンを高度なトラブルシューティング > File Download によって続かれてクリックして下さい。 そして疑わしいファイルの名前を入力し、『Download』 をクリック することができます。

パケットキャプチャ(PCAP)ファイル 分析
Wireshark の PCAP 分析はアクティブな認証 オペレーション内の問題の識別を助けるために実行されたことができます。 標準外ポートが捕虜門脈設定(885 デフォルトで)で使用されるので、Wireshark は SSL のようなトラフィックをデコードするために設定される必要があります。

内部インターフェイス キャプチャおよびトンネルインターフェイス キャプチャは比較する必要があります。 両方の PCAP ファイルで疑わしいセッションを識別する最もよい方法は IP アドレスが異なっているのでユニークな送信元ポートを見つけることです。

上述の例では、サーバHello パケットが内部インターフェイス キャプチャから抜けていることに注意して下さい。 これはクライアントに戻って決してそれを作らなかったことを意味します。 パケットが snort によって廃棄された、または問題かミスコンフィギュレーションが可能性のある原因ですことは可能性のある。
注: Snort は HTTP エクスプロイトを防ぐために自身の捕虜門脈トラフィックを検査します。
暗号化されたストリームの復号化
問題が SSL スタックにない場合、HTTP ストリームを見るために PCAP ファイルのデータを復号化することは有利かもしれません。 これが堪能行う場合もある 2 つのメソッドがあります。
- Windows の環境変数を設定 して下さい(-推奨されるセキュア)
- この方式は premaster シークレット ファイルを作成することを含みます。 これは次のコマンド(ウィンドウ コマンドの入力ターミナルからの実行)で実行することができます: setx SSLKEYlOGFILE 「%HOMEPATH% \デスクトップ\ premaster.txt」
- 私用 セッションは疑わしい SSL を使用するサイトに参照できる Firefox でそれから開くことができます。
- 対称鍵は上記のステップ 1 からのコマンドで規定 される ファイルにそれから記録 されます。
- Wireshark は対称鍵を使用して復号化するのにファイルを使用できます(下記の図を参照して下さい)。
- 検定証およびユーザを使用する RSA プライベートキーを使用して下さい(より少なく保護して下さい、)
- 使用されるべきプライベートキーは捕虜門脈証明書に使用するものです
- これは非 RSA (楕円曲線のように)またははかない何でものためにはたらきません(デフィーヘルマン、たとえば)
注意: 方式 2 が使用される場合、Cisco Technical Assistance Center (TAC)をプライベートキー提供しないで下さい。 しかし一時検定証およびキーは使用することができます。 テスト ユーザもテストで使用する必要があります。

復号化された PCAP ファイルの表示
下記の例では、PCAP ファイルは復号化されました。 NTLM がアクティブな認証方式として使用されていることを示します。

NTLM 許可が起こった後、クライアントはオリジナル セッションに戻って http://www.cisco.com である意図されたデスティネーションに到達できるように、リダイレクトされます。
軽減ステップ
受動認証だけに切り替えて下さい
識別ポリシーで使用されたとき、何かがリダイレクト プロセスでうまくいかなければ、アクティブな認証に割り当てられて廃棄する機能が(HTTPトラフィックだけ)あります。 速い軽減ステップはアクティブな認証の操作を用いる識別ポリシー内のルールを無効に することです。
また受動認証がオプションがユーザ」識別できない場合操作にチェックされる「使用アクティブな認証ないので、ことをのあらゆるルール「受動認証」確かめて下さい。

TAC に提供するべきデータ
次のステップ
アクティブな認証 コンポーネントは問題の原因ではないことが判別されたら、次のステップは不正侵入 ポリシー機能を解決することです。
次の技術情報に進むためにここをクリックして下さい。