ISEポスチャリダイレクトフローとISEポスチャリダイレクトレスフローの比較
はじめに
このドキュメントでは、（ISE v2.2以降の）ポスチャリダイレクトレスフローと、以前のバージョンのISEでサポートされているポスチャリダイレクトフローについて説明します。
前提条件
要件
次の項目に関する知識があることが推奨されます。
- ISE でのポスチャ フロー
- ISE でのポスチャ コンポーネントの設定
- バーチャル プライベート ネットワーク（VPN）を介したポスチャに対する適応型セキュリティ アプライアンス（ASA）の設定
使用するコンポーネント
このドキュメントの情報は、次のソフトウェアとハードウェアのバージョンに基づいています。
- Cisco ISE バージョン 2.2
- ソフトウェア9.6(2)が稼働するCisco ASAv
このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されました。このドキュメントで使用するすべてのデバイスは、クリアな（デフォルト）設定で作業を開始しています。本稼働中のネットワークでは、各コマンドによって起こる可能性がある影響を十分確認してください。
背景説明
このドキュメントでは、Identity Service Engine(ISE)2.2で導入された新機能について説明します。この機能により、ISEはネットワークアクセスデバイス(NAD)またはISEでどのようなリダイレクションのサポートも行わずにポスチャフローをサポートできます。
ポスチャは Cisco ISE のコア コンポーネントです。コンポーネントとしてのポスチャは、次の 3 つの主要な要素で表現できます。
- ポリシー設定ディストリビューションおよび意思決定ポイントとしての ISE。
ISEの管理者の観点からは、ポスチャポリシー（デバイスを企業準拠としてマークするために満たす必要がある正確な条件）、クライアントプロビジョニングポリシー（どの種類のデバイスにどのエージェントソフトウェアをインストールする必要があるか）、および許可ポリシー（どの種類の権限を割り当てる必要があるか、ポスチャステータスによって異なる）を設定します。 - ポリシー適用ポイントとしてのネットワークアクセスデバイス。
NAD側では、実際の許可制限はユーザ認証時に適用されます。ポリシー ポイントとしての ISE は、ダウンロードされた ACL（dACL）、VLAN、リダイレクト URL、リダイレクト アクセス コントロール リスト（ACL）などの認証パラメータを提供します。従来、ポスチャを実行するには、エンドポイントのポスチャステータスが決定された後にユーザを再認証するために、NADはリダイレクション（ユーザまたはエージェントソフトウェアに対してISEノードへの接続を必要とする指示）と認可変更(CoA)をサポートする必要がありました。 - データ収集およびエンドユーザとの対話のポイントとしてのエージェントソフトウェア。
Cisco ISEは、AnyConnect ISEポスチャモジュール、NAC Agent、Web Agentの3種類のエージェントソフトウェアを使用します。エージェントは、ISEからポスチャ要件に関する情報を受信し、要件のステータスに関するレポートをISEに提供します。
ISE 2.2より前のフローポスチャでは、NADはユーザの認証とアクセスの制限に使用されるだけでなく、接続する必要がある特定のISEノードに関する情報をエージェントソフトウェアに提供するためにも使用されます。リダイレクトプロセスの一部として、ISEノードに関する情報がエージェントソフトウェアに返されます。
従来、リダイレクションのサポート（NAD側またはISE側）は、ポスチャ実装に不可欠な要件でした。ISE 2.2では、リダイレクションをサポートする要件は、初期クライアントプロビジョニングとポスチャプロセスの両方で削除されました。
リダイレクトなしのクライアントプロビジョニング：ISE 2.2では、ポータルの完全修飾ドメイン名(FQDN)を使用してクライアントプロビジョニングポータル(CPP)に直接アクセスできます。これは、スポンサー ポータルまたは MyDevice ポータルへのアクセス方法に似ています。
リダイレクトなしのポスチャプロセス：CPPポータルからのエージェントインストール中に、ISEサーバに関する情報がクライアント側に保存されるため、直接通信が可能になります。
ISE 2.2 より前のポスチャ フロー
次の図は、ISE 2.2より前のAnyconnect ISEポスチャモジュールフローの段階的な説明を示しています。
図1-1
ステップ 1：認証はフローの最初のステップであり、dot1x、MAB、またはVPNにすることができます。
ステップ 2： ISEはユーザの認証および認可ポリシーを選択する必要があります。ポスチャシナリオでは、選択された認可ポリシーには、最初は不明であるかまたは該当しない、ポスチャステータスへの参照が含まれている必要があります。これらの両方のケースをカバーするために、ポスチャステータスが不等に準拠している条件を使用できます。
選択した認可プロファイルには、リダイレクトに関する情報が含まれている必要があります。
- Webリダイレクション：ポスチャの場合、Webリダイレクションのタイプはクライアントプロビジョニング（ポスチャ）として指定する必要があります。
- ACL：このセクションには、NAD側で設定されているACL名を含める必要があります。このACLは、どのトラフィックがリダイレクションをバイパスする必要があり、どのトラフィックが実際にリダイレクトされる必要があるかをNADに指示するために使用されます。
- DACL：これはリダイレクトアクセスリストと一緒に使用できますが、異なるプラットフォームではDACLとリダイレクトACLが異なる順序で処理されることを考慮してください。
たとえば、ASAは常にDACLを処理してからACLをリダイレクトします。同時に、一部のスイッチプラットフォームではASAと同じ方法でトラフィックを処理し、他のスイッチプラットフォームでは最初にリダイレクトACLを処理してから、トラフィックをドロップまたは許可する必要がある場合はDACL/インターフェイスACLを確認します。
ステップ 3： ISEは認可属性とともにアクセス承認を返します。認可属性のリダイレクト URL は、ISE によって自動的に生成されます。次に、この構成要素を示します。
- 認証が実行された ISE ノードの FQDN。場合によっては、Webリダイレクトセクションで許可プロファイル設定（スタティックIP/ホスト名/FQDN）によってダイナミックFQDNを上書きすることができます。
静的な値を使用する場合、この値は認証が処理された同じISEノードを指す必要があります。
ロードバランサ(LB)の場合、このFQDNはLB VIPを指すことができますが、これはLBがRadius接続とSSL接続を結び付けるように設定されている場合に限られます。
- Port：ポート値は、ターゲットのポータル設定から取得します。
- Session ID：この値は、ISEによって、アクセス要求に示されるCisco AVペア監査セッションIDから取得されます。値自体はNADによって動的に生成されます。
- ポータルID:ISE側のターゲットポータルのID。
ステップ 4：NADは、セッションに認可ポリシーを適用します。また、DACLが設定されている場合、認可ポリシーが適用される前にそのコンテンツが要求されます。
重要な考慮事項：
- All NADs：デバイスには、redirect-aclとしてAccess-Acceptで受信したACLと同じ名前の、ローカルに設定されたACLが必要です。
- Switches：クライアントのIPアドレスは
show authentication session interface detailsコマンドの出力に表示され、リダイレクトとACLを正常に適用する必要があります。クライアントのIPアドレスは、IPデバイストラッキング機能(IPDT)によって学習されます。
ステップ 5：クライアントは、Webブラウザに入力されたFQDNに対するDNS要求を送信します。この段階で、DNSトラフィックはリダイレクトをバイパスし、正しいIPアドレスがDNSサーバから返される必要があります。
手順 6：クライアントは、DNS応答で受信したIPアドレスにTCP SYNを送信します。パケット内の送信元IPアドレスはクライアントIPであり、宛先IPアドレスは要求されたリソースのIPです。クライアントのWebブラウザで直接HTTPプロキシが設定されている場合を除き、宛先ポートは80です。
ステップ7:NADはクライアント要求を代行受信し、要求されたリソースIPと等しい送信元IP、クライアントIPと等しい宛先IP、および80と等しい送信元ポートを持つSYN-ACKパケットを準備します。
重要な考慮事項：
- NADには、クライアントが要求を送信するポートで実行されているHTTPサーバが必要です。デフォルトでは、ポート80です。
- クライアントが直接HTTPプロキシWebサーバを使用する場合、HTTPサーバはNASのプロキシポートで実行する必要があります。このシナリオは、このドキュメントの対象範囲外です。
- NADがクライアントにローカルIPアドレスを持っていない場合、サブネットSYN-ACKはNADルーティングテーブルとともに（通常は管理インターフェイス経由で）送信されます。
このシナリオでは、パケットはL3インフラストラクチャ経由でルーティングされ、L3アップストリームデバイスによってクライアントに戻されます。
L3デバイスがステートフルファイアウォールである場合、このような非対称ルーティングに対して追加の例外を指定する必要があります。
ステップ 8： クライアントはACKによってTCP 3ウェイハンドシェイクを終了します。
ステップ 9： ターゲットリソースに対するHTTP GETがクライアントによって送信されます。
ステップ 10： NADはリダイレクトURLをHTTPコード302（ページ移動）でクライアントに返します。一部のNADのリダイレクトは、ロケーションヘッダーのHTTP 200 OKメッセージ内で返すことができます。
図1-2
ステップ 11クライアントは、リダイレクトURLからFQDNへのDNS要求を送信します。FQDNはDNSサーバ側で解決できる必要があります。
ステップ 12 リダイレクト URL で受け取られたポート経由の SSL 接続が確立されます（デフォルト 8443）。この接続は、ISE側からのポータル証明書によって保護されます。 クライアント プロビジョニング ポータル（CPP）がユーザに表示されます。
ステップ13：クライアントにダウンロードオプションを提供する前に、ISEはターゲットクライアントプロビジョニング(CP)ポリシーを選択する必要があります。ブラウザユーザエージェントから検出されたクライアントのオペレーティングシステム(OS)と、CPPポリシー選択に必要なその他の情報は、認証セッション（AD/LDAPグループなど）から取得されます。ISEは、リダイレクトURLに示されたセッションIDからターゲットセッションを認識します。
ステップ 14： Network Setup Assistant(NSA)ダウンロードリンクがクライアントに返されます。クライアントがアプリケーションをダウンロードします。
ステップ15：ユーザがNSAアプリケーションを実行します。
ステップ 16： NSAが最初のディスカバリプローブ（デフォルトゲートウェイへのHTTP /auth/discovery）を送信します。NSA は結果としてリダイレクト URL を予期します。
ステップ17:NSAは、最初のプローブが失敗した場合に2番目のプローブを送信します。2番目のプローブは、enroll.cisco.comに対するHTTP GET /auth/discoveryです。 このFQDNは、DNSサーバによって正常に解決できる必要があります。スプリットトンネルを使用したVPNのシナリオでは、enroll.cisco.comへのトラフィックがトンネル経由でルーティングされる必要があります。
ステップ 18： いずれかのプローブが成功すると、NSAはリダイレクトURLから取得した情報を使用して、ポート8905でのSSL接続を確立します。この接続は、ISE管理証明書によって保護されています。 この接続内で、NSAはAnyconnectをダウンロードします。
重要な考慮事項：
- ISE 2.2リリース以前は、ポート8905を介したSSL通信はポスチャの要件でした。
- 証明書の警告を回避するには、ポータル証明書と管理証明書の両方がクライアント側で信頼されている必要があります。
- マルチインターフェイスISE導入では、G0以外のインターフェイスをシステムFQDNとは異なるFQDNにバインドできます(
ip host CLIコマンドを使用)。 これにより、サブジェクト名(SN)/サブジェクトの別名(SAN)の検証で問題が発生する可能性があります。たとえば、クライアントがインターフェイスG1からFQDNにリダイレクトされる場合、システムFQDNは8905通信証明書のリダイレクトURLのFQDNと異なる場合があります。 このシナリオの解決策として、管理証明書のSANフィールドに追加インターフェイスのFQDNを追加するか、管理証明書にワイルドカードを使用できます。
図1-3
ステップ19:Anyconnect ISEポスチャプロセスが起動します。
Anyconnect ISEポスチャモジュールは、次のいずれかの状況で起動します。
- インストール後
- デフォルトゲートウェイ値の変更後
- システムユーザログインイベントの後
- システムの電源イベントの後
ステップ 20： この段階で、Anyconnect ISEポスチャモジュールはポリシーサーバの検出を開始します。これは、Anyconnect ISEポスチャモジュールによって同時に送信される一連のプローブによって達成されます。
- プローブ1：デフォルトゲートウェイIPへのHTTP get /auth/discovery。MAC OSデバイスのVPNアダプタにデフォルトゲートウェイがないことに注意してください。プローブの期待される結果は、リダイレクトURLです。
- プローブ2:HTTP GET /auth/discovery to
enroll.cisco.com。 このFQDNは、DNSサーバによって正常に解決できる必要があります。スプリットトンネルを使用したVPNのシナリオでは、enroll.cisco.comへのトラフィックがトンネル経由でルーティングされる必要があります。プローブの期待される結果は、リダイレクトURLです。 - プローブ 3：検出ホストへの HTTP get /auth/discovery。ディスカバリホスト値は、ACポスチャプロファイルのインストール中にISEから返されます。プローブの期待される結果は、リダイレクトURLです。
- プローブ 4：前に接続されていた PSN に対して、ポート 8905 上で HTTP GET /auth/status が SSL 経由で実行されます。この要求には、クライアントIPに関する情報と、ISE側のセッションルックアップ用のMACリストが含まれます。この問題は、最初のポスチャ試行時には発生しません。接続はISE管理証明書によって保護されています。 このプローブの結果として、プローブが取得されたノードがユーザが認証されているのと同じノードである場合、ISEはセッションIDをクライアントに返すことができます。
次のステップでは、プローブの1つの結果としてリダイレクトURL（フローに文字aでマーク）を受信した場合のポスチャプロセスについて説明します。
ステップ 21： Anyconnect ISEポスチャモジュールは、検出フェーズで取得されたURLを使用して、クライアントプロビジョニングポータルへの接続を確立します。この段階で、ISEは認証済みセッションからの情報を使用して、クライアントプロビジョニングポリシーの検証を再度行います。
ステップ 22：クライアント プロビジョニング ポリシーが検出された場合、ISE はリダイレクトをポート 8905 に返します。
ステップ 23： エージェントがポート8905経由でISEへの接続を確立します。この接続中に、ISEはポスチャプロファイル、コンプライアンスモジュール、およびAnyConnectアップデートのURLを返します。
図1-4
ステップ24:AC ISEポスチャモジュール設定をISEからダウンロードします。
ステップ 25：必要な場合はダウンロードとインストールを更新します。
ステップ 26：AC ISEポスチャモジュールは、システムに関する初期情報（OSバージョン、インストールされたセキュリティ製品、およびそれらの定義バージョンなど）を収集します。この段階で、AC ISEポスチャモジュールは、セキュリティ製品に関する情報を収集するOPSWAT APIを含みます。収集されたデータはISEに送信されます。 この要求に対する応答として、ISEはポスチャ要件リストを提供します。要件リストは、ポスチャポリシー処理の結果として選択されます。正しいポリシーに一致させるため、ISEはデバイスのOSバージョン（要求内に存在）とセッションID値を使用して、他の必要な属性（AD/LDAPグループ）を選択します。セッションIDの値は、クライアントからも送信されます。
ステップ 27：このステップでは、クライアントはOPSWATコールおよびその他のメカニズムを使用して、ポスチャ要件を確認します。要件リストを含む最終レポートとそのステータスがISEに送信されます。ISEは、エンドポイントのコンプライアンスステータスに関する最終決定を行う必要があります。 このステップでエンドポイントが非準拠としてマークされると、一連の修復アクションが返されます。 準拠しているエンドポイントについては、ISEはコンプライアンスステータスをセッションに書き込み、ポスチャリースが設定されている場合は、最後のポスチャタイムスタンプをエンドポイント属性に追加します。ポスチャの結果がエンドポイントに送信されます。ポスチャ再評価(PRA)の場合、PRAの時間もISEによってこのパケットに入力されます。
非準拠シナリオでは、次の点を考慮に入れます。
- 一部の修復アクション（テキストメッセージの表示、リンクの修復、ファイルの修復など）は、ポスチャエージェント自体によって実行されます。
- 他の修復タイプ（AV.AS、WSUS、およびSCCMなど)では、ポスチャエージェントとターゲット製品の間のOPSWAT API通信が必要です。このシナリオでは、ポスチャエージェントは単に修復要求を製品に送信するだけです。修復自体は、セキュリティ製品によって直接行われます。
ステップ28:ISEがCOA要求をNADに送信します。これにより、ユーザに対する新しい認証がトリガーされる必要があります。 NADはこの要求をCOA ACKで確認する必要があります。VPNの場合は、COAプッシュが使用されるため、新しい認証要求は送信されないことに注意してください。代わりに、ASAは以前の認証パラメータ（リダイレクトURL、リダイレクトACL、およびDACL）をセッションから削除し、COA要求から新しいパラメータを適用します。
ステップ29：ユーザに対する新しい認証要求。
重要な考慮事項：
- 通常、Cisco NAD COAの場合、再認証はISEによって使用され、これがNADに前のセッションIDを使用して新しい認証要求を開始するように指示します。
- ISE側では、同じセッションID値は、以前に収集されたセッション属性を再使用する必要があること（この場合は準拠ステータス）、およびこれらの属性に基づく新しい認可プロファイルを割り当てる必要があることを示します。
- セッションIDが変更された場合、この接続は新規として扱われ、完全なポスチャプロセスが再起動されます。
- セッションIDの変更のたびに再ポスチャを回避するために、ポスチャリースを使用できます。このシナリオでは、ポスチャステータスに関する情報は、セッションIDが変更されてもISE上に残るエンドポイント属性に保存されます。
ステップ 30：新しい認可ポリシーは、ポスチャステータスに基づいてISE側で選択されます。
ステップ 31： 新しい承認属性が指定されたアクセス承認が NAD に送信されます。
次のフローは、リダイレクトURLがポスチャプローブによって取得されず（文字bでマークされている）、以前に接続されていたPSNが最後のプローブによって照会されたシナリオを説明しています。ここで示すすべてのステップは、プローブ 4 の結果として PSN により返されるリプレイを除き、リダイレクト URL での場合とまったく同じです。このプローブが現在の認証セッションの所有者と同じPSNに到達した場合、リプレイにはセッションIDの値が含まれます。この値は、後でプロセスを完了するためにポスチャエージェントによって使用されます。以前に接続されたヘッドエンドが現在のセッションオーナーと同じでない場合、セッションルックアップは失敗し、空の応答がAC ISEポスチャモジュールに返されます。この最終結果として、No Policy Server Detectedのメッセージがエンドユーザに返されます。
図1-5
ISE 2.2後のポスチャフロー
ISE 2.2後のポスチャフローISE 2.2以降のバージョンでは、リダイレクトとリダイレクトなしのフローの両方を同時にサポートします。 次に、リダイレクトレスポスチャフローの詳細な説明を示します。
図2-1
ステップ1:認証はフローの最初のステップです。dot1x、MAB、またはVPNを使用できます。
ステップ2:ISEはユーザの認証および認可ポリシーを選択する必要があります。ポスチャでは、シナリオで選択された認可ポリシーには、最初は不明であるかまたは該当しない、ポスチャステータスへの参照が含まれている必要があります。これらの両方のケースをカバーするために、ポスチャステータスが不等に準拠している条件を使用できます。 リダイレクトなしのポスチャの場合、認可プロファイルでWebリダイレクト設定を使用する必要はありません。ポスチャステータスが利用できない段階でユーザアクセスを制限するために、DACLまたはAirspace ACLの使用を引き続き検討できます。
ステップ 3：ISE は認可属性があるアクセス承認を返します。
ステップ 4： DACL名がアクセス承認で返された場合、NADはDACLコンテンツのダウンロードを開始し、認可プロファイルを取得後にセッションに適用します。
ステップ 5：新しいアプローチでは、リダイレクトが不可能であることを前提としているため、ユーザはクライアントプロビジョニングポータルFQDNを手動で入力する必要があります。CPPポータルのFQDNは、ISE側のポータル設定で定義する必要があります。DNSサーバの観点からは、AレコードはPSNロールが有効になっているISEサーバを指す必要があります。
手順 6：クライアントはHTTPを送信してクライアントプロビジョニングポータルFQDNに到達します。この要求はISE側で解析され、完全なポータルURLがクライアントに返されます。
図2-2
ステップ 7：リダイレクト URL で受け取られたポート経由の SSL 接続が確立されます（デフォルト 8443）。この接続は、ISE側からのポータル証明書によって保護されます。クライアントプロビジョニングポータル(CPP)がユーザに表示されます。
ステップ 8： このステップでは、ISEで2つのイベントが発生します。
- シングルサインオン(SSO):ISEは以前の正常な認証の検索を試行します。ISEは、ライブRADIUSセッションの検索フィルタとして、パケットの送信元IPアドレスを使用します。
- クライアントプロビジョニングポリシーのルックアップ：SSOが成功した場合、ISEは認証済みセッションからのデータとクライアントブラウザからのユーザエージェントを使用できます。SSOに失敗した場合、ユーザはクレデンシャルを提供する必要があります。ユーザ認証情報は、内部および外部IDストア（AD/LDAP/内部グループ）から取得した後で、クライアントプロビジョニングポリシーチェックに使用できます。
ステップ 9： クライアントプロビジョニングポリシーの選択後、ISEはエージェントのダウンロードURLをユーザに表示します。NSAのダウンロードをクリックすると、アプリケーションがユーザにプッシュされます。NSAファイル名には、CPPポータルのFQDNが含まれます。
ステップ10：このステップでは、NSAはプローブを実行してISEへの接続を確立します。2つのプローブは従来のプローブであり、3つ目のプローブはURLリダイレクションを使用しない環境でのISE検出を可能にする設計になっています。
- NSAが最初のディスカバリプローブ（デフォルトゲートウェイへのHTTP /auth/discovery）を送信します。NSA は結果としてリダイレクト URL を予期します。
- NSAは、最初のプローブが失敗した場合に2番目のプローブを送信します。2番目のプローブは、
enroll.cisco.comに対するHTTP GET /auth/discoveryです。 このFQDNは、DNSサーバによって正常に解決できる必要があります。スプリットトンネルを使用したVPNのシナリオでは、enroll.cisco.comへのトラフィックがトンネル経由でルーティングされる必要があります。 - NSAは、3番目のプローブをCPPポータルポート経由でクライアントプロビジョニングポータルFQDNに送信します。 この要求には、ISEが提供する必要があるリソースを特定できるポータルセッションIDに関する情報が含まれています。
ステップ 11 NSAはAnyConnectや特定のモジュールをダウンロードします。ダウンロードプロセスは、クライアントプロビジョニングポータルポートを介して実行されます。
図2-3
ステップ 12ISE 2.2では、ポスチャプロセスは2つの段階に分かれています。第1段階には、従来のポスチャ検出プローブのセットが含まれ、URLリダイレクトに依存する導入との下位互換性をサポートします。
ステップ13：第1段階には、従来のポスチャディスカバリプローブがすべて含まれています。プローブの詳細については、ISE 2.2より前のポスチャフローのステップ20を確認してください。
ステップ14：第2段階には、AC ISEポスチャモジュールが、リダイレクトがサポートされていない環境でセッションが認証されるPSNへの接続を確立できるようにする2つのディスカバリプローブが含まれています。第2段階では、すべてのプローブは連続しています。
- プローブ1：最初のプローブ時に、AC ISEポスチャモジュールは「Call Homeリスト」からのIP/FQDNとの確立を試行します。プローブのターゲットのリストは、ISE側のACポスチャプロファイルで設定する必要があります。IP/FQDNをカンマで区切って定義できます。コロンを使用して、各Call Home宛先のポート番号を定義できます。このポートは、クライアントプロビジョニングポータルが実行されるポートと同じである必要があります。 Call Homeサーバに関するクライアント側の情報は
ISEPostureCFG.xmlにあります。このファイルはフォルダC:\ProgramData\Cisco\Cisco AnyConnect Secure Mobility Client\ISE Posture\にあります。
Call Homeターゲットがセッションを所有していない場合は、この段階で所有者を検索する必要があります。AC ISEポスチャモジュールは、特別なターゲットURL(/auth/ng-discovery要求)を使用して所有者検索を開始するようにISEに指示します。また、クライアントIPとMACのリストも含まれています。このメッセージがPSNセッションで受信されると、最初にローカルでルックアップが行われます（このルックアップでは、AC ISEポスチャモジュールによって送信された要求のIPとMACの両方が使用されます）。セッションが見つからない場合、PSNはMNTノードクエリを開始します。この要求にはMACリストのみが含まれているため、所有者のFQDNはMNTから取得する必要があります。その後、PSNは所有者のFQDNをクライアントに返します。クライアントからの次の要求は、セッションオーナーのFQDNに送信され、URLとIPおよびMACのリストにauth/statusが含まれます。
- プローブ2：この段階で、AC ISEポスチャモジュールは
ConnectionData.xmlにあるPSN FQDNを試行します。このファイルはC:\Users\<current user>\AppData\Local\Cisco\Cisco AnyConnect Secure Mobility Client\にあります。AC ISEポスチャモジュールは、最初のポスチャ試行後にこのファイルを作成します。このファイルには、ISE PSNのFQDNのリストが含まれています。リストの内容は、次の接続試行時に動的に更新できます。このプローブの最終目標は、現在のセッションオーナーのFQDNを取得することです。実装はプローブ1と同じですが、プローブの宛先の選択が異なります。
デバイスが複数のユーザによって使用される場合、ファイル自体は現在のユーザのフォルダにあります。別のユーザはこのファイルの情報を使用できません。これにより、Call Homeのターゲットが指定されていない場合、リダイレクトのない環境でチキンとエッグの問題が発生する可能性があります。
ステップ 15： セッションオーナーに関する情報を取得した後、後続のすべての手順はISE 2.2より前のフローと同じです。
設定
設定このドキュメントでは、ASAv はネットワーク アクセス デバイスとして使用されます。すべてのテストは、VPN 経由でポスチャを使用して実施されます。VPN経由のポスチャのサポートに関するASAの設定は、このドキュメントの対象範囲外です。詳細については、『ASAバージョン9.2.1 VPNポスチャとISEの設定例』を参照してください。
ネットワーク図
ネットワーク図
図3-1
このトポロジはテストで使用されます。ASAでは、NAT機能により、クライアントプロビジョニングポータルのSSOメカニズムがPSN側で失敗するシナリオを簡単にシミュレートできます。VPNを介した通常のポスチャフローの場合、SSOは正常に機能する必要があります。これは、ユーザが企業ネットワークに入ると、NATは通常VPN IPには適用されないためです。
コンフィギュレーション
コンフィギュレーションクライアント プロビジョニングの設定
クライアント プロビジョニングの設定Anyconnectの設定を準備する手順を次に示します。
ステップ 1：Anyconnectパッケージのダウンロード。Anyconnect パッケージ自体は ISE からの直接ダウンロードには使用できないので、開始する前に AC が PC 上で使用可能であることを確認してください。次のリンクは、ACダウンロードに使用できます：https://www.cisco.com/site/us/en/products/security/secure-client/index.htmlこのドキュメントでは、anyconnect-win-4.4.00243-webdeploy-k9.pkg packageを使用しています。
ステップ 2：ACパッケージをISEにアップロードするには、Policy > Policy Elements > Results > Client Provisioning > Resourcesに移動して、Addをクリックします。ローカルディスクからAgent resourcesを選択します。新しいウィンドウでCisco Provided Packagesを選択し、をクリックしてbrowse、PC上のACパッケージを選択します。
図3-2
Submitをクリックしてインポートを終了します。
ステップ 3：コンプライアンスモジュールをISEにアップロードする必要があります。同じページでAddをクリックし、Agent resources from Cisco siteを選択します。 リソースリストで、コンプライアンスモジュールを確認する必要があります。このドキュメントでは、AnyConnectComplianceModuleWindows 4.2.508.0 complianceモジュールを使用します。
ステップ 4： ここで、ACポスチャプロファイルを作成する必要があります。Addをクリックし、NAC agent or Anyconnect posture profileを選択します。
図3-3
- プロファイルのタイプを選択します。このシナリオではAnyConnectを使用する必要があります。
- プロファイル名を指定します。プロファイルの
Posture Protocolセクションに移動します。
図3-4
Server Name Rulesを指定します。このフィールドを空にすることはできません。このフィールドには、AC ISEポスチャモジュールの接続を適切な名前空間からPSNに制限するFQDNをワイルドカードで含めることができます。いずれかのFQDNを許可する必要がある場合は、アスタリスク(*)を付けます。- ここで指定された名前と IP は、ポスチャ ディスカバリの第 2 段階で使用されます。名前はカンマで区切ることができます。また、コロンを使用してFQDN/IPの後にポート番号を追加できます。GPOまたはその他のソフトウェアプロビジョニングシステム(PSN)を使用して（ISEクライアントプロビジョニングポータルからではなく）アウトオブバンドで導入されたACの場合、これはISE PSNに正常に到達できる1つのプローブのみであるため、Call Homeアドレスの存在が不可欠になります。つまり、アウトオブバンドACプロビジョニングの場合、管理者はACプロファイルエディタを使用してAC ISEポスチャプロファイルを作成し、ACインストールとともにこのファイルをプロビジョニングする必要があります。
ステップ 5：AC 設定を作成します。 Policy > Policy Elements > Results > Client Provisioning > Resourcesに移動してAddをクリックし、AnyConnect Configurationを選択します。
図3-5
- ACパッケージを選択します。
- AC 設定名を入力します。
- コンプライアンスモジュールのバージョンを選択します。
- ドロップダウンリストからACポスチャ設定プロファイルを選択します。
手順 6： クライアントプロビジョニングポリシーを設定します。Policy > Client Provisioningに移動します。 初期設定の場合、デフォルトで表示されるポリシーに空の値を入力できます。 既存のポスチャ設定にポリシーを追加する必要がある場合、再利用できるポリシーに移動し、Duplicate AboveまたはDuplicate Below を選択します。まったく新しいポリシーを作成することもできます。
このドキュメントで使用されているポリシーの例を次に示します。
図3-6
結果セクションでAC設定を選択します。SSO が失敗した場合には、ISE はポータルへのログインの属性しか持つことができません。これらの属性は、内部および外部IDストアからユーザに関して取得できる情報に限定されます。このドキュメントでは、ADグループはクライアントプロビジョニングポリシーの条件として使用されます。
ポスチャ ポリシーおよび条件
ポスチャ ポリシーおよび条件簡単なポスチャチェックが使用されます。ISEは、エンドデバイス側でWindow Defenderサービスのステータスを確認するように設定されています。実際のシナリオははるかに複雑になる可能性がありますが、一般的な設定手順は同じです。
ステップ 1： ポスチャ条件を作成します。ポスチャ条件は、Policy > Policy Elements > Conditions > Postureにあります。ポスチャ条件のタイプを選択します。 Windows Defenderサービスが実行されているかどうかを確認する必要があるサービス条件の例を次に示します。
図3-7
ステップ 2：ポスチャ要件の設定。Policy > Policy Elements > Results > Posture > Requirementsに移動します。次に、Window Defenderチェックの例を示します。
図3-8
新しい要件でポスチャ条件を選択し、修復アクションを指定します。
ステップ 3： ポスチャポリシーの設定Policy > Postureに移動します。このドキュメントで使用するポリシーの例を次に示します。ポリシーには必須として割り当てられたWindows Defenderの要件があり、条件として外部ADグループ名のみが含まれています。
図3-9
クライアントプロビジョニングポータルの設定
クライアントプロビジョニングポータルの設定リダイレクトなしのポスチャの場合、クライアントプロビジョニングポータルの設定を編集する必要があります。Administration > Device Portal Management > Client Provisioningに移動します。デフォルトポータルを使用するか、独自のポータルを作成できます。リダイレクトの有無にかかわらず、同じポータルを両方の姿勢で使用できます。
図3-10
リダイレクト以外のシナリオでは、ポータル設定で次の設定を編集する必要があります。
- [認証]で、SSOがユーザーのセッションを見つけられない場合に使用する必要があるIDソース・シーケンスを指定します。
- 選択したIDソースシーケンスに従って、使用可能なグループのリストが読み込まれます。この時点で、ポータルログインを許可されたグループを選択する必要があります。
- クライアントプロビジョニングポータルからACを展開する必要があるシナリオでは、クライアントプロビジョニングポータルのFQDNを指定する必要があります。このFQDNは、ISE PSN IPに解決できる必要があります。 ユーザは、最初の接続試行時にWebブラウザでFQDNを指定するように指示される必要があります。
認可プロファイルおよびポリシーの設定
認可プロファイルおよびポリシーの設定ポスチャステータスが利用できない場合のクライアントの初期アクセスは制限する必要があります。これは、次の複数の方法で実現できます。
- DACL割り当て：制限されたアクセスフェーズでは、DACLをユーザに割り当ててアクセスを制限できます。このアプローチは、シスコ ネットワーク アクセス デバイスに使用できます。
- VLAN割り当て：ポスチャが正常に実行される前に、ユーザを制限付きVLANに配置できます。このアプローチは、ほぼすべてのNADベンダーで適切に機能する必要があります。
- Radius フィルタ ID：この属性により、NAD でローカルに定義した ACL を、ポスチャ ステータスが不明なユーザに割り当てることができます。これは標準のRFC属性であるため、このアプローチはすべてのNADベンダーに適している必要があります。
ステップ 1：DACLを設定します。この例は ASA に基づいているため、NAD DACL を使用できます。実際のシナリオでは、可能なオプションとしてVLANまたはFilter-IDを考慮する必要があります。
DACLを作成するには、Policy > Policy Elements > Results > Authorization > Downloadable ACLsに移動してAddをクリックします。
不明なポスチャ状態の間は、少なくとも次の権限を提供する必要があります。
- DNS トラフィック
- DHCP トラフィック
- ISE PSN(ポート80および443。ポータルの友好的なFQDNを開くことができます。CPポータルが実行されているポートは、デフォルトでは8443で、下位互換性を確保するためにポートは8905です)。
- 必要な場合、修復サーバへのトラフィック
これは修復サーバなしの DACL の例です。
図3-11
ステップ 2： 許可プロファイルを設定します。
通常どおり、ポスチャには 2 つの認可プロファイルが必要です。最初のプロファイルには、あらゆる種類のネットワークアクセス制限（この例ではDACLを使用するプロファイル）が含まれている必要があります。このプロファイルは、ポスチャ ステータスが準拠に等しくない認証に適用できます。2番目の認可プロファイルにはjust permit accessを含めることができ、準拠に等しいポスチャステータスのセッションに適用できます。
許可プロファイルを作成するには、Policy > Policy Elements > Results > Authorization > Authorization Profilesに移動します。
制限付きアクセスプロファイルの例：
図3-12
この例では、デフォルトのISEプロファイルPermitAccessが、ポスチャステータスチェックが成功した後のセッションに使用されます。
ステップ 3：許可ポリシーを設定します。この手順では、2つの認可ポリシーを作成する必要があります。1つは不明なポスチャステータスと初期認証要求を照合する方法で、もう1つは正常なポスチャプロセスの後にフルアクセスを割り当てる方法です。
次に、この場合の単純な認可ポリシーの例を示します。
図3-13
認証ポリシーの設定はこのドキュメントの一部ではありませんが、認可ポリシーの処理の前に、認証が成功する必要があることに注意してください。
確認
確認フローの基本的な検証は、次の3つの主要な手順で構成できます。
ステップ 1：認証フローの検証。
図4-1
- 初期認証。この手順では、認可プロファイルが適用された検証を確認できます。予期しない認可プロファイルが適用された場合は、詳細な認証レポートを調査します。このレポートは、[詳細]列の虫眼鏡アイコンをクリックすると開きます。詳細な認証レポートの属性を、照合する予定の認可ポリシーの条件と比較できます。
- DACL ダウンロード イベント。この文字列は、初期認証用に選択された認可プロファイルにDACL名が含まれている場合にのみ表示されます。
- ポータル認証：フローのこの手順は、SSOメカニズムがユーザセッションを見つけられなかったことを示します。複数の原因が考えられます。
- NADがアカウンティングメッセージを送信するように設定されていないか、フレーム化されたIPアドレスがメッセージ内に存在しません
- CPPポータルFQDNは、初期認証が処理されたノードとは異なるISEノードのIPに解決されています
- クライアントはNATの背後にあります
- セッションデータの変更。この例では、セッションの状態が不明から準拠に変更されています。
- ネットワークアクセスデバイスへのCOA。このCOAは、NAD側からの新しい認証とISE側での新しい認可ポリシー割り当てのプッシュに成功する必要があります。 COAが失敗した場合は、詳細レポートを開いて原因を調査できます。COAの最も一般的な問題は次のとおりです。
- COAタイムアウト：この場合、要求を送信したPSNがNAD側のCOAクライアントとして設定されていないか、COA要求が途中でドロップされています。
- COA 否定 ACK：COA は NAD に受け取られましたが、何らかの理由で COA 操作を確認できなかったことを示します。このシナリオでは、詳細レポートに、より詳細な説明が含まれている必要があります。
この例ではASAがNADとして使用されているため、ユーザに対するその後の認証要求を確認できません。これは、VPNサービスの中断を回避するASAのCOAプッシュをISEが使用するために発生します。このようなシナリオでは、COA自体に新しい認可パラメータが含まれるため、再認証は必要ありません。
ステップ2：クライアントプロビジョニングポリシーの選択の検証：このために、ユーザに適用されたクライアントプロビジョニングポリシーを理解するのに役立つレポートをISEで実行できます。
Operations > Reports Endpoint and Users > Client Provisioningに移動し、必要な日付のレポートを実行します。
図4-2
このレポートでは、選択されたクライアントプロビジョニングポリシーを確認できます。また、障害の場合は、Failure Reasonの列に理由を示す必要があります。
ステップ3：ポスチャレポートの検証：Operations > Reports Endpoint and Users > Posture Assessment by Endpointに移動します。
図4-3
ここから、特定の各イベントの詳細レポートを開くことができます。たとえば、このレポートが属するセッションID、エンドポイントに対してISEが選択した正確なポスチャ要件、および各要件のステータスなどを確認できます。
トラブルシュート
トラブルシュート一般情報
一般情報ポスチャプロセスのトラブルシューティングを行うには、ポスチャプロセスを実行できるISEノードでデバッグするために、次のISEコンポーネントを有効にする必要があります。
client-webapp – エージェントプロビジョニングを担当するコンポーネント。ターゲットログファイルguest.log、およびise-psc.log。guestacess – クライアントプロビジョニングポータルコンポーネントとセッションオーナーのルックアップを担当するコンポーネント（要求が誤ったPSNに到達した場合）。ターゲットログファイル：guest.log。provisioning – クライアントプロビジョニングポリシー処理を担当するコンポーネント。 ターゲットログファイル：guest.log。posture – すべてのポスチャ関連イベント。 ターゲットログファイル：ise-psc.log。
クライアント側のトラブルシューティングでは、次のコマンドを使用できます。
acisensa.log – クライアント側でクライアントプロビジョニングの失敗が発生した場合、このファイルはNSAがダウンロードされたフォルダ（通常はWindows用のディレクトリをダウンロード）に作成されます。AnyConnect_ISEPosture.txt – このファイルは、Cisco AnyConnect ISE Posture ModuleディレクトリのDARTバンドル内にあります。ISE PSNディスカバリとポスチャフローの一般的な手順に関するすべての情報がこのファイルに記録されます。
一般的な問題のトラブルシューティング
一般的な問題のトラブルシューティングSSO 関連の問題
SSO 関連の問題SSOが成功した場合、これらのメッセージはise-psc.logに表示されます。この一連のメッセージは、セッションルックアップが正常に終了し、ポータルでの認証をスキップできることを示します。
2016-11-09 15:07:35,951 DEBUG [http-bio-10.48.30.40-8443-exec-12][] cisco.cpm.posture.runtime.PostureRuntimeFactory -::::- looking for Radius session with input values : sessionId: null, MacAddr: null, ipAddr: 10.62.145.121
2016-11-09 15:07:35,989 DEBUG [http-bio-10.48.30.40-8443-exec-12][] cisco.cpm.posture.runtime.PostureRuntimeFactory -::::- looking for session using session ID: null, IP addrs: [10.62.145.121], mac Addrs [null]
2016-11-09 15:07:35,989 DEBUG [http-bio-10.48.30.40-8443-exec-12][] cisco.cpm.posture.runtime.PostureRuntimeFactory -::::- looking for session using IP 10.62.145.121
2016-11-09 15:07:35,989 DEBUG [http-bio-10.48.30.40-8443-exec-12][] cisco.cpm.posture.runtime.PostureRuntimeFactory -::::- nasPortType = 5
2016-11-09 15:07:35,989 DEBUG [http-bio-10.48.30.40-8443-exec-12][] cisco.cpm.posture.runtime.PostureRuntimeFactory -::::- nasPortType equal to 5 ( 5 is virtual NAS_PORT_TYPE for VPN ). Found a VPN session null using ip address 10.62.145.121
2016-11-09 15:07:35,989 DEBUG [http-bio-10.48.30.40-8443-exec-12][] cisco.cpm.posture.runtime.PostureRuntimeFactory -::::- Found session c0a801010002600058232bb8 using ipAddr 10.62.145.121テキストウィンドウ5-1
エンドポイントIPアドレスを検索キーとして使用して、この情報を見つけることができます。
ゲストログの少し後に、認証がスキップされたことを確認する必要があります。
2016-11-09 15:07:35,989 DEBUG [http-bio-10.48.30.40-8443-exec-12][] guestaccess.flowmanager.step.cp.CPInitStepExecutor -::- SessionInfo is not null and session AUTH_STATUS = 1
2016-11-09 15:07:35,989 DEBUG [http-bio-10.48.30.40-8443-exec-12][] com.cisco.ise.portalSessionManager.PortalSession -::- Putting data in PortalSession with key and value: Radius.Session c0a801010002600058232bb8
2016-11-09 15:07:35,989 DEBUG [http-bio-10.48.30.40-8443-exec-12][] com.cisco.ise.portalSessionManager.PortalSession -::- Putting data in PortalSession with key : Radius.Session
2016-11-09 15:07:35,989 DEBUG [http-bio-10.48.30.40-8443-exec-12][] guestaccess.flowmanager.step.cp.CPInitStepExecutor -::- Login step will be skipped, as the session =c0a801010002600058232bb8 already established for mac address null , clientIPAddress 10.62.145.121
2016-11-09 15:07:36,066 DEBUG [http-bio-10.48.30.40-8443-exec-12][] cpm.guestaccess.flowmanager.processor.PortalFlowProcessor -::- After executeStepAction(INIT), returned Enum: SKIP_LOGIN_PROCEED
テキストウィンドウ5-2
SSOが機能しない場合、ise-psc logファイルにはセッションルックアップの失敗に関する情報が含まれます。
2017-02-23 17:59:00,779 DEBUG [http-bio-10.48.17.249-8443-exec-2][] cisco.cpm.posture.runtime.PostureRuntimeFactory -::::- looking for Radius session with input values : sessionId: null, MacAddr: null, ipAddr: 10.62.145.44
2017-02-23 17:59:00,779 DEBUG [http-bio-10.48.17.249-8443-exec-2][] cisco.cpm.posture.runtime.PostureRuntimeFactory -::::- looking for session using session ID: null, IP addrs: [10.62.145.44], mac Addrs [null]
2017-02-23 17:59:00,779 DEBUG [http-bio-10.48.17.249-8443-exec-2][] cisco.cpm.posture.runtime.PostureRuntimeFactory -::::- looking for session using IP 10.62.145.44
2017-02-23 17:59:00,779 DEBUG [http-bio-10.48.17.249-8443-exec-2][] cisco.cpm.posture.runtime.PostureRuntimeFactory -::::- nasPortType = null
2017-02-23 17:59:00,779 DEBUG [http-bio-10.48.17.249-8443-exec-2][] cisco.cpm.posture.runtime.PostureRuntimeFactory -::::- nasPortType == null or is not a virtual NAS_PORT_TYPE ( 5 ).
2017-02-23 17:59:00,779 DEBUG [http-bio-10.48.17.249-8443-exec-2][] cisco.cpm.posture.runtime.PostureRuntimeFactory -::::- No Radius session found
テキストウィンドウ5-3
このような場合にguest.logを使用すると、ポータルで完全なユーザ認証を確認できます。
2017-02-23 17:59:00,779 DEBUG [http-bio-10.48.17.249-8443-exec-2][] cpm.guestaccess.flowmanager.step.StepExecutor -::- Find Next Step=LOGIN
2017-02-23 17:59:00,779 DEBUG [http-bio-10.48.17.249-8443-exec-2][] cpm.guestaccess.flowmanager.step.StepExecutor -::- Step : LOGIN will be visible!
2017-02-23 17:59:00,779 DEBUG [http-bio-10.48.17.249-8443-exec-2][] cpm.guestaccess.flowmanager.step.StepExecutor -::- Returning next step =LOGIN
2017-02-23 17:59:00,780 INFO [http-bio-10.48.17.249-8443-exec-2][] cpm.guestaccess.flowmanager.step.StepExecutor -::- Radius Session ID is not set, assuming in dry-run mode
テキストウィンドウ5-4
ポータルで認証に失敗した場合は、ポータル設定の検証に集中する必要があります。どのIDストアが使用されていますか。どのグループがログインを許可されますか。
クライアント プロビジョニング ポリシーの選択のトラブルシューティング
クライアントプロビジョニングポリシーの失敗や誤ったポリシー処理が発生した場合は、guest.logファイルで詳細を確認できます。
2017-02-23 17:59:07,080 DEBUG [http-bio-10.48.17.249-8443-exec-2][] guestaccess.flowmanager.step.guest.ClientProvStepExecutor -:user1:- In Client Prov : userAgent =Mozilla/5.0 (Windows NT 6.1; WOW64; rv:51.0) Gecko/20100101 Firefox/51.0, radiusSessionID=null, idGroupName=S-1-5-21-70538695-790656579-4293929702-513, userName=user1, isInUnitTestMode=false
2017-02-23 17:59:07,080 DEBUG [http-bio-10.48.17.249-8443-exec-2][] cpm.guestaccess.common.utils.OSMapper -:user1:- UserAgent : Mozilla/5.0 (Windows NT 6.1; WOW64; rv:51.0) Gecko/20100101 Firefox/51.0
2017-02-23 17:59:07,080 DEBUG [http-bio-10.48.17.249-8443-exec-2][] cpm.guestaccess.common.utils.OSMapper -:user1:- Client OS: Windows 7 (All)
2017-02-23 17:59:07,080 DEBUG [http-bio-10.48.17.249-8443-exec-2][] guestaccess.flowmanager.step.guest.ClientProvStepExecutor -:user1:- Retrieved OS=Windows 7 (All)
2017-02-23 17:59:07,080 DEBUG [http-bio-10.48.17.249-8443-exec-2][] guestaccess.flowmanager.step.guest.ClientProvStepExecutor -:user1:- Updating the idGroupName to NAC Group:NAC:IdentityGroups:S-1-5-21-70538695-790656579-4293929702-513
2017-02-23 17:59:07,080 DEBUG [http-bio-10.48.17.249-8443-exec-2][] guestaccess.flowmanager.step.guest.ClientProvStepExecutor -:user1:- User Agent/Radius Session is empty or in UnitTestMode
2017-02-23 17:59:07,080 DEBUG [http-bio-10.48.17.249-8443-exec-2][] guestaccess.flowmanager.step.guest.ClientProvStepExecutor -:user1:- Calling getMatchedPolicyWithNoRedirection for user=user1
2017-02-23 17:59:07,505 DEBUG [http-bio-10.48.17.249-8443-exec-2][] guestaccess.flowmanager.step.guest.ClientProvStepExecutor -:user1:- CP Policy Status =SUCCESS, needToDoVlan=false, CoaAction=NO_COA
テキストウィンドウ5-5
最初の文字列では、セッションに関する情報がポリシー選択エンジンにどのように注入されるかを確認できます。ポリシーの一致がない場合、またはポリシーの一致が正しくない場合は、ここにある属性をクライアントプロビジョニングポリシー設定と比較できます。最後の文字列は、ポリシー選択のステータスを示します。
ポスチャ プロセスのトラブルシューティング
クライアント側では、プローブとその結果の調査に関心を持つ必要があります。 これは、成功したステージ1プローブの例です。
******************************************
Date : 02/23/2017
Time : 17:59:57
Type : Unknown
Source : acise
Description : Function: Target::Probe
Thread Id: 0x4F8
File: SwiftHttpRunner.cpp
Line: 1415
Level: debug
PSN probe skuchere-ise22-cpp.example.com with path /auth/status, status is -1..
******************************************
テキストウィンドウ5-6
この段階で、PSNはセッションオーナーに関するAC情報に戻ります。これらのメッセージは後で確認できます。
******************************************
Date : 02/23/2017
Time : 17:59:58
Type : Unknown
Source : acise
Description : Function: Target::probeRecentConnectedHeadEnd
Thread Id: 0xBE4
File: SwiftHttpRunner.cpp
Line: 1674
Level: debug
Target skuchere-ise22-2.example.com, posture status is Unknown..
******************************************
テキストウィンドウ5-7
セッションの所有者は、必要なすべての情報をエージェントに返します。
******************************************
Date : 02/23/2017
Time : 17:59:58
Type : Unknown
Source : acise
Description : Function: SwiftHttpRunner::invokePosture
Thread Id: 0xFCC
File: SwiftHttpRunner.cpp
Line: 1339
Level: debug
MSG_NS_SWISS_NEW_SESSION, <?xml version="1.0" ?>
<root>
<IP></IP>
<FQDN>skuchere-ise22-2.example.com</FQDN>
<PostureDomain>posture_domain</PostureDomain>
<sessionId>c0a801010009e00058af0f7b</sessionId>
<configUri>/auth/anyconnect?uuid=106a93c0-9f71-471c-ac6c-a2f935d51a36</configUri>
<AcPackUri>/auth/provisioning/download/81d12d4b-ff58-41a3-84db-5d7c73d08304</AcPackUri>
<AcPackPort>8443</AcPackPort>
<AcPackVer>4.4.243.0</AcPackVer>
<PostureStatus>Unknown</PostureStatus>
<PosturePort>8443</PosturePort>
<PosturePath>/auth/perfigo_validate.jsp</PosturePath>
<PRAConfig>0</PRAConfig>
<StatusPath>/auth/status</StatusPath>
<BackupServers>skuchere-ise22-1.example.com,skuchere-ise22-3.example.com</BackupServers>
</root>
.
******************************************
テキストウィンドウ5-8
PSN側からは、ノードに送信される最初の要求がセッションを所有していないと予想される場合に、guest.logの次のメッセージに焦点を合わせることができます。
2017-02-23 17:59:56,345 DEBUG [http-bio-10.48.17.249-8443-exec-10][] cisco.cpm.client.posture.NextGenDiscoveryServlet -::- Got http request from 10.62.145.44 user agent is: Mozilla/4.0 (compatible; WINDOWS; 1.2.1.6.1.48; AnyConnect Posture Agent v.4.4.00243)
2017-02-23 17:59:56,345 DEBUG [http-bio-10.48.17.249-8443-exec-10][] cisco.cpm.client.posture.NextGenDiscoveryServlet -::- mac_list from http request ==> 00:0B:7F:D0:F8:F4,00:0B:7F:D0:F8:F4
2017-02-23 17:59:56,345 DEBUG [http-bio-10.48.17.249-8443-exec-10][] cisco.cpm.client.posture.NextGenDiscoveryServlet -::- iplist from http request ==> 172.16.31.12,10.62.145.95
2017-02-23 17:59:56,345 DEBUG [http-bio-10.48.17.249-8443-exec-10][] cisco.cpm.client.posture.NextGenDiscoveryServlet -::- Session id from http request - req.getParameter(sessionId) ==> null
2017-02-23 17:59:56,345 DEBUG [http-bio-10.48.17.249-8443-exec-10][] cpm.client.provisioning.utils.ProvisioningUtil -::- the input ipAddress from the list currently being processed in the for loop ==> 172.16.31.12
2017-02-23 17:59:56,345 DEBUG [http-bio-10.48.17.249-8443-exec-10][] cpm.client.provisioning.utils.ProvisioningUtil -::- the input ipAddress from the list currently being processed in the for loop ==> 10.62.145.95
2017-02-23 17:59:56,368 DEBUG [http-bio-10.48.17.249-8443-exec-10][] cisco.cpm.client.posture.NextGenDiscoveryServlet -::- Found Client IP null and corresponding mac address null
2017-02-23 17:59:56,369 ERROR [http-bio-10.48.17.249-8443-exec-10][] cpm.client.provisioning.utils.ProvisioningUtil -::- Session Info is null
2017-02-23 17:59:56,369 DEBUG [http-bio-10.48.17.249-8443-exec-10][] cisco.cpm.client.posture.NextGenDiscoveryServlet -::- Not able to find a session for input values - sessionId : null, Mac addresses : [00:0B:7F:D0:F8:F4, 00:0B:7F:D0:F8:F4], client Ip : [172.16.31.12, 10.62.145.95]
2017-02-23 17:59:56,369 DEBUG [http-bio-10.48.17.249-8443-exec-10][] cisco.cpm.client.posture.NextGenDiscoveryServlet -::- clientMac is null/ empty, will go over the mac list to query MNT for active session
2017-02-23 17:59:56,369 DEBUG [http-bio-10.48.17.249-8443-exec-10][] cisco.cpm.client.posture.NextGenDiscoveryServlet -::- Performing MNT look up for macAddress ==> 00-0B-7F-D0-F8-F4
2017-02-23 17:59:56,539 DEBUG [http-bio-10.48.17.249-8443-exec-10][] cisco.cpm.client.posture.NextGenDiscoveryServlet -::- Performed MNT lookup, found session 0 with session id c0a801010009e00058af0f7b
2017-02-23 17:59:56,539 DEBUG [http-bio-10.48.17.249-8443-exec-10][] cpm.client.provisioning.utils.ProvisioningUtil -::- getting NIC name for skuchere-ise22-cpp.example.com
2017-02-23 17:59:56,541 DEBUG [http-bio-10.48.17.249-8443-exec-10][] cpm.client.provisioning.utils.ProvisioningUtil -::- local interface 0 addr 10.48.17.249 name eth0
2017-02-23 17:59:56,541 DEBUG [http-bio-10.48.17.249-8443-exec-10][] cpm.client.provisioning.utils.ProvisioningUtil -::- Nic name for local host: skuchere-ise22-cpp.example.com is: eth0
2017-02-23 17:59:56,541 DEBUG [http-bio-10.48.17.249-8443-exec-10][] cpm.client.provisioning.utils.ProvisioningUtil -::- getting host FQDN or IP for host skuchere-ise22-2 NIC name eth0
2017-02-23 17:59:56,545 DEBUG [http-bio-10.48.17.249-8443-exec-10][] cpm.client.provisioning.utils.ProvisioningUtil -::- hostFQDNOrIP for host skuchere-ise22-2 nic eth0 is skuchere-ise22-2.example.com
2017-02-23 17:59:56,545 DEBUG [http-bio-10.48.17.249-8443-exec-10][] cisco.cpm.client.posture.NextGenDiscoveryServlet -::- PDP with session of 00-0B-7F-D0-F8-F4 is skuchere-ise22-2, FQDN/IP is: skuchere-ise22-2.example.com
2017-02-23 17:59:56,545 DEBUG [http-bio-10.48.17.249-8443-exec-10][] cisco.cpm.client.posture.NextGenDiscoveryServlet -::- Redirecting the request to new URL: https://skuchere-ise22-2.example.com:8443/auth/status
2017-02-23 17:59:56,545 DEBUG [http-bio-10.48.17.249-8443-exec-10][] cisco.cpm.client.posture.NextGenDiscoveryServlet -::- Session info is null. Sent an http response to 10.62.145.44.
2017-02-23 17:59:56,545 DEBUG [http-bio-10.48.17.249-8443-exec-10][] cpm.client.provisioning.utils.ProvisioningUtil -::- header X-ISE-PDP-WITH-SESSION value is skuchere-ise22-2.example.com
2017-02-23 17:59:56,545 DEBUG [http-bio-10.48.17.249-8443-exec-10][] cpm.client.provisioning.utils.ProvisioningUtil -::- header Location value is https://skuchere-ise22-2.example.com:8443/auth/status
テキストウィンドウ5-9
ここでは、PSNが最初にローカルでセッションを見つけようとし、障害が発生した後にIPとMACのリストを使用してセッションオーナーを見つけるためのMNTへの要求を開始することがわかります。
少し後に、正しいPSNでクライアントからの要求が表示されます。
2017-02-23 17:59:56,790 DEBUG [http-bio-10.48.30.41-8443-exec-8][] cisco.cpm.posture.runtime.PostureRuntimeFactory -::::- looking for session using session ID: null, IP addrs: [172.16.31.12, 10.62.145.95], mac Addrs [00:0B:7F:D0:F8:F4, 00:0B:7F:D0:F8:F4]
2017-02-23 17:59:56,790 DEBUG [http-bio-10.48.30.41-8443-exec-8][] cisco.cpm.posture.runtime.PostureRuntimeFactory -::::- looking for session using IP 172.16.31.12
2017-02-23 17:59:56,791 DEBUG [http-bio-10.48.30.41-8443-exec-8][] cisco.cpm.posture.runtime.PostureRuntimeFactory -::::- nasPortType = 5
2017-02-23 17:59:56,792 DEBUG [http-bio-10.48.30.41-8443-exec-8][] cisco.cpm.posture.runtime.PostureRuntimeFactory -::::- nasPortType equal to 5 ( 5 is virtual NAS_PORT_TYPE for VPN ). Found a VPN session null using ip address 172.16.31.12
2017-02-23 17:59:56,792 DEBUG [http-bio-10.48.30.41-8443-exec-8][] cisco.cpm.posture.runtime.PostureRuntimeFactory -::::- Found session c0a801010009e00058af0f7b using ipAddr 172.16.31.12
テキストウィンドウ5-10
次の手順として、PSNはこのセッションのクライアントプロビジョニングポリシー検索を実行します。
2017-02-23 17:59:56,793 DEBUG [http-bio-10.48.30.41-8443-exec-8][] com.cisco.cpm.swiss.SwissServer -::::- null or empty value for hostport obtained from SwissServer : getHostNameBySession()
2017-02-23 17:59:56,793 DEBUG [http-bio-10.48.30.41-8443-exec-8][] cisco.cpm.posture.runtime.PostureRuntimeFactory -::::- looking for Radius session with input values : sessionId: c0a801010009e00058af0f7b, MacAddr: 00-0b-7f-d0-f8-f4, ipAddr: 172.16.31.12
2017-02-23 17:59:56,793 DEBUG [http-bio-10.48.30.41-8443-exec-8][] cisco.cpm.posture.runtime.PostureRuntimeFactory -::::- looking for session using session ID: c0a801010009e00058af0f7b, IP addrs: [172.16.31.12], mac Addrs [00-0b-7f-d0-f8-f4]
2017-02-23 17:59:56,793 DEBUG [http-bio-10.48.30.41-8443-exec-8][] cisco.cpm.posture.runtime.PostureRuntimeFactory -::::- Found session using sessionId c0a801010009e00058af0f7b
2017-02-23 17:59:56,795 DEBUG [http-bio-10.48.30.41-8443-exec-8][] cisco.cpm.posture.runtime.PosturePolicyUtil -::::- User user1 belongs to groups NAC Group:NAC:IdentityGroups:Endpoint Identity Groups:Profiled:Workstation,NAC Group:NAC:IdentityGroups:Any
2017-02-23 17:59:58,203 DEBUG [http-bio-10.48.30.41-8443-exec-8][] com.cisco.cpm.swiss.SwissServer -::::- null or empty value for hostport obtained from SwissServer : getHPortNumberBySession()
2017-02-23 17:59:58,907 DEBUG [http-bio-10.48.30.41-8443-exec-10][] cisco.cpm.posture.util.AgentUtil -::::- Increase MnT counter at CP:ClientProvisioning.ProvisionedResource.AC-44-Posture
テキストウィンドウ5-11
次の手順では、ポスチャ要件の選択プロセスを確認できます。ステップの最後に、要件のリストが作成され、エージェントに返されます。
2017-02-23 18:00:00,372 DEBUG [http-bio-10.48.30.41-8443-exec-8][] cisco.cpm.posture.runtime.PostureHandlerImpl -:user1:::- About to query posture policy for user user1 with endpoint mac 00-0b-7f-d0-f8-f4
2017-02-23 18:00:00,423 DEBUG [http-bio-10.48.30.41-8443-exec-8][] cisco.cpm.posture.runtime.PostureManager -:user1:::- agentCMVersion=4.2.508.0, agentType=AnyConnect Posture Agent, groupName=OESIS_V4_Agents -> found agent group with displayName=4.x or later
2017-02-23 18:00:00,423 DEBUG [http-bio-10.48.30.41-8443-exec-8][] cisco.cpm.posture.runtime.PosturePolicyUtil -:user1:::- User user1 belongs to groups NAC Group:NAC:IdentityGroups:Endpoint Identity Groups:Profiled:Workstation,NAC Group:NAC:IdentityGroups:Any
2017-02-23 18:00:00,423 DEBUG [http-bio-10.48.30.41-8443-exec-8][] cisco.cpm.posture.runtime.PosturePolicyUtil -:user1:::- About to retrieve posture policy resources for os 7 Professional, agent group 4.x or later and identity groups [NAC Group:NAC:IdentityGroups:Endpoint Identity Groups:Profiled:Workstation, NAC Group:NAC:IdentityGroups:Any]
2017-02-23 18:00:00,432 DEBUG [http-bio-10.48.30.41-8443-exec-8][] cisco.cpm.posture.runtime.PosturePolicyUtil -:user1:::- Evaluate resourceId NAC Group:NAC:Posture:PosturePolicies:WinDefend by agent group with FQN NAC Group:NAC:AgentGroupRoot:ALL:OESIS_V4_Agents
2017-02-23 18:00:00,433 DEBUG [http-bio-10.48.30.41-8443-exec-8][] cisco.cpm.posture.runtime.PosturePolicyUtil -:user1:::- The evaluation result by agent group for resourceId NAC Group:NAC:Posture:PosturePolicies:WinDefend is Permit
2017-02-23 18:00:00,433 DEBUG [http-bio-10.48.30.41-8443-exec-8][] cisco.cpm.posture.runtime.PosturePolicyUtil -:user1:::- Evaluate resourceId NAC Group:NAC:Posture:PosturePolicies:WinDefend by OS group with FQN NAC Group:NAC:OsGroupRoot:ALL:WINDOWS_ALL:WINDOWS_7_ALL:WINDOWS_7_PROFESSIONAL_ALL
2017-02-23 18:00:00,438 DEBUG [http-bio-10.48.30.41-8443-exec-8][] cisco.cpm.posture.runtime.PosturePolicyUtil -:user1:::- stealth mode is 0
2017-02-23 18:00:00,438 DEBUG [http-bio-10.48.30.41-8443-exec-8][] cisco.cpm.posture.runtime.PosturePolicyUtil -:user1:::- The evaluation result by os group for resourceId NAC Group:NAC:Posture:PosturePolicies:WinDefend is Permit
2017-02-23 18:00:00,438 DEBUG [http-bio-10.48.30.41-8443-exec-8][] cisco.cpm.posture.runtime.PosturePolicyUtil -:user1:::- Evaluate resourceId NAC Group:NAC:Posture:PosturePolicies:WinDefend by Stealth mode NSF group with FQN NAC Group:NAC:StealthModeStandard
2017-02-23 18:00:00,439 DEBUG [http-bio-10.48.30.41-8443-exec-8][] cisco.cpm.posture.runtime.PosturePolicyUtil -:user1:::- Procesing obligation with posture policy resource with id NAC Group:NAC:Posture:PosturePolicies:WinDefend
2017-02-23 18:00:00,439 DEBUG [http-bio-10.48.30.41-8443-exec-8][] cisco.cpm.posture.runtime.PosturePolicyUtil -:user1:::- Found obligation id urn:cisco:cepm:3.3:xacml:response-qualifier for posture policy resource with id NAC Group:NAC:Posture:PosturePolicies:WinDefend
2017-02-23 18:00:00,439 DEBUG [http-bio-10.48.30.41-8443-exec-8][] cisco.cpm.posture.runtime.PosturePolicyUtil -:user1:::- Found obligation id PostureReqs for posture policy resource with id NAC Group:NAC:Posture:PosturePolicies:WinDefend
2017-02-23 18:00:00,439 DEBUG [http-bio-10.48.30.41-8443-exec-8][] cisco.cpm.posture.runtime.PosturePolicyUtil -:user1:::- Posture policy resource id WinDefend has following associated requirements []
2017-02-23 18:00:03,884 DEBUG [http-bio-10.48.30.41-8443-exec-8][] cpm.posture.runtime.agent.AgentXmlGenerator -:user1:::- policy enforcemnt is 0
2017-02-23 18:00:03,904 DEBUG [http-bio-10.48.30.41-8443-exec-8][] cpm.posture.runtime.agent.AgentXmlGenerator -:user1:::- simple condition: [Name=WinDefend, Descriptionnull, Service Name=WinDefend, Service Operator=Running, Operating Systems=[Windows All], Service Type=Daemon, Exit code=0]
2017-02-23 18:00:03,904 DEBUG [http-bio-10.48.30.41-8443-exec-8][] cpm.posture.runtime.agent.AgentXmlGenerator -:user1:::- check type is Service
2017-02-23 18:00:04,069 DEBUG [http-bio-10.48.30.41-8443-exec-8][] cisco.cpm.posture.runtime.PostureHandlerImpl -:user1:::- NAC agent xml <?xml version="1.0" encoding="UTF-8"?><cleanmachines>
<version>ISE: 2.2.0.470</version>
<encryption>0</encryption>
<package>
<id>10</id>
<name>WinDefend</name>
<description>Enable WinDefend</description>
<version/>
<type>3</type>
<optional>0</optional>
<action>3</action>
<check>
<id>WinDefend</id>
<category>3</category>
<type>301</type>
<param>WinDefend</param>
<operation>running</operation>
</check>
<criteria>(WinDefend)</criteria>
</package>
</cleanmachines>
テキストウィンドウ5-12
後で、ポスチャレポートがPSNによって受信されたことを確認できます。
2017-02-23 18:00:04,231 DEBUG [http-bio-10.48.30.41-8443-exec-8][] cisco.cpm.posture.runtime.PostureHandlerImpl -::::- UDID is 8afb76ad11e60531de1d3e7d2345dbba5f11a96d for end point 00-0b-7f-d0-f8-f4
2017-02-23 18:00:04,231 DEBUG [http-bio-10.48.30.41-8443-exec-8][] cisco.cpm.posture.runtime.PostureHandlerImpl -::::- Received posture request [parameters: reqtype=report, userip=10.62.145.44, clientmac=00-0b-7f-d0-f8-f4, os=WINDOWS, osVerison=1.2.1.6.1.48, architecture=9, provider=Device Filter, state=, userAgent=Mozilla/4.0 (compatible; WINDOWS; 1.2.1.6.1.48; AnyConnect Posture Agent v.4.4.00243), session_id=c0a801010009e00058af0f7b
テキストウィンドウ5-13
フローの最後で、ISEはエンドポイントを準拠としてマークし、COAを開始します。
2017-02-23 18:00:04,272 INFO [http-bio-10.48.30.41-8443-exec-8][] cisco.cpm.posture.runtime.PostureManager -:user1:::- Posture state is compliant for endpoint with mac 00-0b-7f-d0-f8-f4
2017-02-23 18:00:04,272 DEBUG [http-bio-10.48.30.41-8443-exec-8][] cisco.cpm.posture.runtime.PostureCoA -:user1:::- entering triggerPostureCoA for session c0a801010009e00058af0f7b
2017-02-23 18:00:04,272 DEBUG [http-bio-10.48.30.41-8443-exec-8][] cisco.cpm.posture.runtime.PostureCoA -:user1:::- Posture CoA is scheduled for session id [c0a801010009e00058af0f7b]
2017-02-23 18:00:04,272 DEBUG [http-bio-10.48.30.41-8443-exec-8][] cisco.cpm.posture.runtime.PostureCoA -:user1:::- Posture status for session id c0a801010009e00058af0f7b is Compliant
2017-02-23 18:00:04,273 DEBUG [http-bio-10.48.30.41-8443-exec-8][] cisco.cpm.posture.runtime.PostureCoA -:user1:::- Issue CoA on active session with sessionID c0a801010009e00058af0f7b
2017-02-23 18:00:04,273 DEBUG [http-bio-10.48.30.41-8443-exec-8][] cisco.cpm.posture.runtime.PostureCoA -:user1:::- Posture CoA is scheduled for session id [c0a801010009e00058af0f7b]
テキストウィンドウ5-14
更新履歴
| 改定 | 発行日 | コメント |
|---|---|---|
1.0 |
24-Aug-2021 |
初版 |
フィードバック