セキュリティ : Cisco Identity Services Engine

AnyConnect バージョン 4.0 および NAC ポスチャは ISE でエージェント解決しますガイドをポップアップしません

2015 年 11 月 26 日 - 機械翻訳について
その他のバージョン: PDFpdf | 英語版 (2015 年 8 月 22 日) | フィードバック

概要

Identity Services Engine (ISE)はネットワーク アドミッション コントロール(NAC) エージェント(による Microsoft Windows、マッキントッシュのために、または webagent)または AnyConnect バージョン 4.0 の使用を必要とするポーズをとる機能を提供します。 従って AnyConnect バージョン 4.0 ISE ポスチャ モジュールは NAC エージェントとそっくりにはたらき、ようにこの資料の NAC エージェント参照されます。 クライアントのためのポスチャ失敗のもっとも一般的な現象は機能シナリオが NAC エージェント ウィンドウをポップアップし、PC を分析するために常に引き起こすので NAC エージェントがポップアップしないことです。 この資料はポスチャを失敗するために導くことができる多くの原因を狭くするのを助けます NAC エージェントはポップアップしないことを意味する。 NAC エージェント ログが Cisco Technical Assistance Center (TAC)によってしかデコードすることができ、可能性のある 根本的な原因が多数であるので徹底的であることを意味しません; ただしそれはより「エージェント ポスチャ 分析と」が単にポップアップしないし、もっとも一般的な原因を解決するヘルプをおそらく状況を明白にし、問題を更に正確に示すことを向けます。

Contributed by Nicolas Darchis, Cisco TAC Engineer.

前提条件

要件

初期セットアップが既に完了していた後あなたが問題を解決することができるようにこの資料にリストされているシナリオ、現象およびステップは書かれています。 初期設定に関しては、Cisco.com の Cisco ISE コンフィギュレーション ガイドのポスチャ サービスを参照して下さい。

使用するコンポーネント

このドキュメントの情報は、次のソフトウェアとハードウェアのバージョンに基づくものです。

  • ISE Version1.2.x
  • ISE バージョン 4.9.x のための NAC エージェント
  • AnyConnect バージョン 4.0

: 情報はまたリリース ノートが主要な行動変更を表示しなければ ISE の他のリリースに適当であるはずです。

このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されたものです。 このドキュメントで使用するすべてのデバイスは、クリアな(デフォルト)設定で作業を開始しています。 ネットワークが稼働中の場合は、コマンドが及ぼす潜在的な影響を十分に理解しておく必要があります。

トラブルシューティング方法

何がエージェントをポップアップさせますか。

エージェントは ISE ノードを検出するときポップアップします。 完全なネットワーク アクセスを持たないし、ポスチャ リダイレクション シナリオにあることをエージェントが検知すれば、絶えず ISE ノードを探します。

そこに私達 Cisco.com 資料 エージェント ディスカバリ プロセスの詳細を説明する: Identity Services Engine のためのネットワーク アドミッション コントロール(NAC) エージェント ディスカバリ プロセス。 コンテンツ重複を避けるために、この資料はキーポイントだけを説明します。

クライアントが接続するとき、それは、ISE がネットワークデバイス(スイッチ、適応性があるセキュリティ アプライアンス モデル(ASA)、またはワイヤレス コントローラ経ます)にリダイレクション Access Control List (ACL)およびそれが IP アドレスおよび Domain Name Server (DNS)解決を得るためにだけクライアント トラフィックを制限するためにリダイレクション URL を戻す端で RADIUS認証を(MAC フィルタリングか 802.1X)。 すべての HTTPトラフィックはクライアントから来る CPP で終了する ISE ポータル自体に向かうトラフィックを除く ISE のユニークな URL に(クライアント ポスチャおよびプロビジョニング)、リダイレクトされます。 NAC エージェントはデフォルト ゲートウェイに常連 HTTP GET パケットを送信 します。 エージェントが返事または他のどの CPP リダイレクションより返事受け取らない場合、それ自身がフル接続があると考慮し、ポーズをとることを続行しません。 仕様 ISE ノードの終わりに CPP URL へリダイレクションである HTTP応答を受け取れば、ポスチャ プロセスおよび連絡先をその ISE ノード続けます。 それはその ISE ノードからポスチャ 詳細の受け取りに成功するときだけポップアップし、分析を開始します。

NAC エージェントはまた設定されたディスカバリ ホスト IP アドレス(複数設定されると期待しません)に手を差し伸べます。 セッションID のリダイレクション URL を得ることを同様にそこにリダイレクトすると期待します。 ディスカバリ IP アドレスが ISE ノードである場合、右のセッションID を得ることをリダイレクトするために待っているので追求しません。 従ってディスカバリ ホストは通常リダイレクションを引き起こすためにのであらゆる IP アドレス リダイレクト ACL の範囲で設定 されたとき必要で、しかし役立ちます(VPN シナリオでのように、たとえば)。

考えられる原因

リダイレクションは起こりません

これは圧倒的にもっとも一般的な原因です。 検証するか、または無効になることは、URL をタイプするときエージェントがポップアップしないし、Download ページ ポスチャ エージェントにリダイレクトされる場合見る PC のブラウザを開きます。 また可能性のある DNS 問題(IP アドレスがリダイレクトすればが、Webサイト名前が、DNS を検知できます)を避けるために http://1.2.3.4 のようなランダム IP アドレスを入力できます。

リダイレクトされる場合、エージェント ログおよび ISE サポート バンドルを(モードをデバッグするポスチャおよびスイス モジュールと)集め、Cisco TAC に連絡する必要があります。 これはエージェントが ISE ノードを検出するが、何かがプロセスの間にポスチャ データを得ないことを示します。

リダイレクションが起こらない場合、まだ根本的な原因のより詳しい調査を必要とする最初 の 原因があります。 よい開始するはネットワーク アクセス デバイス(ワイヤレス LAN コントローラ(WLC)またはスイッチ)の設定をチェックし、この資料の次の項目へ移動することです。

属性はネットワークデバイスでインストールされていません

この問題はリダイレクションの subcase シナリオ起こりませんです。 リダイレクションが起こらない場合、最初の事柄はクライアントはスイッチかワイヤレスアクセス 層によって右のステータスに正しく置かれること(問題がある特定のクライアントで)発生するので確認することです。

クライアントが接続されるスイッチで奪取 される show authentication セッション int <interface number> コマンド(いくつかのプラットフォームの端に詳細を追加しなければならないかもしれません)の出力例はここにあります。 URL リダイレクト ACL が意図されていたリダイレクト ACL を正しく指し示すこと、そして URL リダイレクトが URL の終わりで CPP の期待された ISE ノードを指すことことステータスが「Authz 成功」である確認して下さい。 ACS ACL フィールドは ISE の許可 プロファイルのダウンロード可能 アクセス リストを設定したかどうかその時だけ示すので必須ではないです。 しかしそれを検知 し、リダイレクト ACL の競合がないことを確認することは重要です(疑いの場合にはポスチャ 設定についての文書を参照して下さい)。

01-SW3750-access#show auth sess int gi1/0/12
Interface: GigabitEthernet1/0/12
MAC Address:  000f.b049.5c4b
           IP Address:  192.168.33.201
            User-Name:  00-0F-B0-49-5C-4B
               Status:  Authz Success
               Domain:  DATA
      Security Policy:  Should Secure
      Security Status:  Unsecure
       Oper host mode:  single-host
     Oper control dir:  both
        Authorized By:  Authentication Server
          Vlan Policy:  N/A
              ACS ACL:  xACSACLx-IP-myDACL-51519b43
     URL Redirect ACL:  redirect
         URL Redirect:  https://ISE2.wlaaan.com:8443/guestportal/gateway?
sessionId=C0A82102000002D8489E0E84&action=cpp
      Session timeout:  N/A
         Idle timeout:  N/A
    Common Session ID:  C0A82102000002D8489E0E84
      Acct Session ID:  0x000002FA
               Handle:  0xF60002D9

Runnable methods list:

       Method   State
       mab      Authc Success

AireOS を実行する WLC を解決するために、示し、無線クライアント 詳細 < MAC アドレス > を入ります Cisco IOS XE を実行する WLC を解決するために示します無線クライアント MAC アドレス < MAC アドレス > 詳細を入力して下さい。 クライアントが「POSTURE_REQD」状態にまたは類似した(あれば同じようなデータ 表示およびソフトウェア バージョンによってそれ変わりますリダイレクト URL および ACL を確認し、)。

属性がない場合、リダイレクション属性が送信 されたことを(オペレーション > 認証へのナビゲート)開き、結果セクションで解決していたクライアントの ISE の認証 詳細を確認して下さい。 それらが送信 されなかった場合、属性がこの特定のクライアントのためになぜ戻らなかったか理解するために承認ポリシーを検討する必要があります。 おそらく、条件の 1 つは一致する、従ってそれらを一つずつ解決することが得策です。

、リダイレクト ACL に関して、ことを割り当て文の Cisco IOS ® リダイレクト(そう ISE および DNS IP アドレスは否定される必要があります)間、Deny ステートメント(そう ISE および DNS のために許可されます)の WLC リダイレクトの AireOS 覚えています。

属性はきちんと整っていますが、ネットワークデバイスはリダイレクトしません

主要な原因はこの場合設定 に関する 問題です。 Cisco.com のコンフィギュレーション ガイドおよび設定例に対してネットワークデバイスの設定を検討する必要があります。 これが事実、一般的にすべてのポート全体存在 する問題またはネットワークデバイスのアクセス ポイント(AP)なら。 そうでなかったら、問題はいくつかのスイッチポートかいくつかの AP で発生するだけかもしれません。 これが事実である場合、問題がポスチャがうまく働くポートか AP と比較されて発生するところでそれらの設定を比較する必要があります。

それらはそれぞれ固有の設定がある場合があり、いくつかの AP の ACL または VLAN の間違えやすく、他ではないので FlexConnect AP は敏感です。

もう一つのよくある問題はクライアント VLAN に SVI がないことです。 これはスイッチにだけ適用し、Catalyst 3750 シリーズ スイッチの ISE トラフィック リダイレクションで詳しく説明されています。 すべては属性観点からよく検知 するかもしれません。

干渉ダウンロード可能 Access-list (DACL)

、リダイレクション属性がスイッチに戻って、DACL (かワイヤレス コントローラ用の Airespace ACL を)押すと同時に、リダイレクションをブロックする可能性があります。 DACL は最初に適用され、完全に廃棄され、ものが処理されるべきを続くものが判別します。 それからリダイレクト ACL は適用し、リダイレクトされるものが判別します。

これが具体的に意味するものはほとんどの場合それです、割り当て DACL のすべての HTTP および HTTPS トラフィックがにほしいと思います。 それをブロックする場合、それ前に廃棄されるのでリダイレクトされません。 それはそのトラフィックがリダイレクト ACL で大抵の後でリダイレクトされる、従ってネットワークで実際に許可されませんので、セキュリティ上の問題ではないです; ただしリダイレクト ACL をの直後に見つける可能性を持つ、それらのために割り当てを DACL のそれら二つのトラフィック の 種類必要とします。

悪い NAC エージェント バージョン

特定の NAC エージェント バージョンが ISE の特定のバージョンに対して検証されることを忘れていることは容易です。 多くの管理者は ISE クラスタをアップグレードし、クライアント プロビジョニング結果データベースの関連 NAC エージェント バージョンをアップロードすることを忘れています。

ISE コードのために旧式 NAC エージェント バージョンを使用する場合、はたらくかもしれませんが、またかもしれなかったことに注意して下さい。 従ってそれは何人かのクライアントがはたらき、他がという驚きではないです。 確認する 1 つの方法は ISE バージョンの Cisco.com ダウンロード セクションへ行き、どの NAC エージェント バージョンがそこにあるかチェックすることです。 一般的に各 ISE バージョンのためにサポートされる複数があります。 この Webページはすべての行列を収集します: Cisco ISE 互換性に関する情報

HTTP Web プロキシはクライアントによって使用中です

HTTP Web プロキシの概念はクライアントが Webサイト DNS IP アドレス自身を解決しなかったり Webサイトに直接連絡しないことです; むしろ、それらはそれ処理するプロキシサーバに要求を単に送信 します。 通常 の 設定における典型的な問題はクライアントが直接 gets が ISE ポータルに代行受信し、合法的にリダイレクトしたプロキシへそれのための HTTP GET を送信 することによって Webサイトを(www.cisco.com のような)解決することです。 ただし、それから ISE 門脈 IP アドレスへ次の HTTP GET を送信 するかわりに、クライアントはプロキシにその要求を送信 し続けます。

プロキシに向かう HTTPトラフィックをリダイレクトしないことにすればユーザに全 インターネットに認証を受けるか、またはポーズをとらないでダイレクトアクセスが(すべてのトラフィックがプロキシを通過するので)あります。 ソリューションは実際にクライアントのブラウザ設定を修正し、プロキシ 設定の ISE IP アドレスのための例外を追加することです。 クライアントが ISE に達しなければならないときこうすれば、それは ISE とないプロキシに要求を直接送信 します。 これはクライアントが絶えずログイン ページをリダイレクトされないが、決して見ない無限ループを回避します。

NAC エージェントがシステムで入力されるプロキシ 設定から影響を受けないし、普通機能し続けることに注目して下さい。 これは(そのプロキシ ポートを使用し、典型的なスイッチがマルチポートでリダイレクトできないので)参照するときそれらがポスチャ ページにリダイレクトされれば(ポートを 80)使用し、ユーザ自己インストールがエージェントあるので Web プロキシを使用すれば、両方 NAC エージェント ディスカバリ作業があることができないことを意味します。

ディスカバリ ホストは NAC エージェントで設定されます

し、しないことを専門知識をの持っていなければ特にの後で ISE バージョン 1.2、ディスカバリ ホストをの NAC エージェント設定しないことを推奨します。 NAC エージェントは HTTP ディスカバリによってクライアントデバイスを認証した ISE ノードを検出するはずです。 ディスカバリ ホストに頼る場合、NAC エージェントをデバイスを認証したはたらかないし、ものとは別の ISE ノードに接触してもらうかもしれません。 ISE バージョン 1.2 は NAC エージェントにリダイレクト URL からセッションID を得てほしい従ってこの方式が落胆するのでディスカバリ ホスト プロセスによってノードを検出するエージェントを拒否します。

場合によっては、ディスカバリ ホストを設定したいと思うかもしれません。 それからそれはリダイレクト ACL によってリダイレクトされる、およびクライアントとして同じ サブネットに理想的にあるはずではないですあらゆる IP アドレスで(非実在)設定する必要があります(他ではクライアントはそれのために ARP 決して HTTP ディスカバリ パケットを送信 するため不明確に、)。

NAC エージェントは時々ポップアップしません

問題はより断続的な、/ケーブルを再接続するのような操作プラグを抜くこと/wifi 接続はそれをはたらかせるときより微妙な問題です。 それはセッションID が ISE で RADIUS 説明かによって削除される RADIUS セッションID における問題である可能性があります(何かを変更するかどうか)見るために説明するディセーブル。

ISE Version1.2 を使用する場合、もう一つの可能性はどれもブラウザか NAC エージェントから来ないようにクライアントが多くの HTTP パケットを送信することです。 ISE バージョン 1.2 は NAC エージェントかブラウザから来るが、他の多くのアプリケーションはユーザ エージェント フィールドの HTTPトラフィックを送信 し、オペレーティング システムか有益な情報を述べませんかどうか見るために HTTP パケットのユーザ エージェント フィールドをスキャンします。 ISE バージョン 1.2 はそれからクライアントを切る許可の変更を送信 します。 ISE バージョン 1.3 は別の方法ではたらかせるこの問題 beause から影響を受けません。 ソリューションはバージョン 1.3 へアップグレードするか、または ISE の方にリダイレクトされないようにリダイレクト ACL のすべての検出するアプリケーションを割り当てることです。

逆問題: エージェントは繰り返しポップアップします

反対問題はエージェントがどこにポップアップし、ポスチャ 分析をし、クライアントを検証し、次にネットワーク接続を許可し、無声にかとどまるかわりに間もなくして再度ポップアップするか起こることができます。 これは、正常なポスチャの後でさえも、HTTPトラフィックがまだ ISE の CPP ポータルにリダイレクトされるので起こります。 そして ISE 承認ポリシーを通過し、対応クライアントおよびない CPP リダイレクションをもう一度見るとき割り当てアクセス 送信 するルールがあることを確認することが得策です(または可能性のある ACL および VLAN の同じようなルールを)。

関連情報


関連するシスコ サポート コミュニティ ディスカッション

シスコ サポート コミュニティは、どなたでも投稿や回答ができる情報交換スペースです。


Document ID: 118724