概要
このドキュメントでは、リダイレクトなしのポスチャフローの使用と設定、およびトラブルシューティングのヒントについて説明します。
前提条件
要件
次の項目に関する知識があることが推奨されます。
- ISE でのポスチャ フロー
- ISE でのポスチャ コンポーネントの設定
- ISEポータルへのリダイレクト
後で説明する概念をより深く理解するために、次の手順を実行することをお勧めします。
以前のISEバージョンとISE 2.2のISEポスチャフローの比較
ISEセッションの管理とポスチャ
使用するコンポーネント
このドキュメントの情報は、次のソフトウェアとハードウェアのバージョンに基づいています。
- Cisco ISE バージョン 3.1
- Cisco Secureクライアント5.0.01242
このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されました。このドキュメントで使用するすべてのデバイスは、クリアな(デフォルト)設定で作業を開始しています。本稼働中のネットワークでは、各コマンドによって起こる可能性がある影響を十分確認してください。
背景説明
ISEポスチャフローは次の手順で構成されます。
0.認証/許可。通常はポスチャフローが開始される直前に実行されますが、ポスチャ再評価(PRA)などの特定のユースケースではバイパスできます。認証自体はポスチャディスカバリをトリガーしないため、これはすべてのポスチャフローに不可欠とは見なされません。
- ディスカバリ.Secure Client ISEポスチャモジュールによって実行されるプロセスで、現在アクティブなセッションのPSN所有者を検索します。
- クライアント プロビジョニング.対応するCisco Secure Client(以前のAnyConnect)のISEポスチャモジュールとコンプライアンスモジュールのバージョンをクライアントにプロビジョニングするためにISEによって実行されるプロセス。この手順では、特定のPSNに含まれ、そのPSNによって署名されたポスチャプロファイルのローカルコピーもクライアントにプッシュされます。
- システムスキャン。ISEで設定されたポスチャポリシーは、コンプライアンスモジュールによって評価されます。
- 修復(オプション)。準拠していないポスチャポリシーがある場合に実行されます。
- CoA.最終的な(準拠または非準拠の)ネットワークアクセスを許可するには、再認証が必要です。
このドキュメントでは、ISEポスチャフローの検出プロセスを中心に説明します。
ディスカバリプロセスではリダイレクションを使用することを推奨しますが、リダイレクションがサポートされていないサードパーティのネットワークデバイスの使用など、リダイレクションを実装できない特定のケースがあります。このドキュメントの目的は、このような環境でリダイレクトのないポスチャを実装およびトラブルシューティングするための一般的なガイダンスとベストプラクティスを提供することです。
リダイレクトレスフローの詳細については、「ISE 2.2での以前のISEバージョンとISEポスチャフローの比較」を参照してください。
リダイレクトを使用しないポスチャ検出プローブには、次の2つのタイプがあります。
- Connectiondata.xml
- Call Homeリスト
Connectiondata.xml
Connectiondata.xmlは、Cisco Secure Clientによって自動的に作成され、維持されるファイルです。これは、クライアントがポスチャ用に以前に正常に接続したPSNのリストで構成されます。したがって、これはローカルファイルのみであり、その内容はすべてのエンドポイントで永続的ではありません。
connectiondata.xmlの主な目的は、ステージ1とステージ2の両方の検出プローブのバックアップメカニズムとして機能することです。リダイレクションまたはCall HomeリストプローブがアクティブセッションのPSNを検出できない場合、Cisco Secure Clientはconnectiondata.xmlにリストされている各サーバに直接要求を送信します。
第1段階の検出プローブ
第2段階の検出プローブ
connectiondata.xmlプローブの使用によって引き起こされる一般的な問題は、エンドポイントから送信される多数のHTTPS要求によるISE導入の過負荷です。connectiondata.xmlは、リダイレクトとリダイレクトなしのポスチャメカニズムの両方で完全な停止を回避するためのバックアップメカニズムとして有効ですが、ポスチャ環境の持続可能なソリューションではないため、メインの検出プローブの障害の原因となり、検出の問題を引き起こす設計および設定の問題を診断して解決する必要があることを考慮することが重要です。
Call Homeリスト
Call Homeリストは、ポスチャプロファイルのセクションで、ポスチャに使用するPSNのリストが指定されます。connectiondata.xmlとは異なり、これはISE管理者によって作成および維持され、最適な設定のために設計フェーズが必要になる場合があります。Call HomeリストのPSNのリストは、RADIUSのネットワークデバイスまたはロードバランサに設定されている認証およびアカウンティングサーバのリストと一致している必要があります。
Call Homeリストプローブを使用すると、PSNでローカルルックアップが失敗した場合に、アクティブセッションの検索中にMnTルックアップを使用できます。同じ機能がconnectiondata.xmlプローブに拡張されるのは、それらがステージ2の検出中に使用された場合だけです。このため、すべてのステージ2プローブは、新世代プローブとも呼ばれます。
MnTルックアップフロー
設計
リダイレクトレス検出プロセスは、多くの場合、リダイレクトフローよりも複雑なフローを伴い、PSNおよびMnT上で大量の処理を行うため、実装時に発生する可能性がある一般的な課題が2つあります。
- 効果的な検出
- ISE導入のパフォーマンス
これらの課題に対処するには、Call Homeリストを設計して、特定のエンドポイントがポスチャに使用できるPSNの数を制限することをお勧めします。中規模および大規模の導入では、複数のCall Homeリストを作成するために少数のPSNで導入を分散する必要があります。結果として、特定のネットワークデバイスのRADIUS認証に使用されるPSNのリストは、対応するCall Homeリストに一致するように制限する必要があります。
各Call Homeリスト内のPSNの最大数を決定するPSN分散戦略を作成する際には、次の点を考慮できます。
- 展開内のPSNの数
- PSNおよびMnTノードのハードウェア仕様
- 展開での同時ポスチャセッションの最大数
- ネットワークデバイスの数
- ハイブリッド環境(同時リダイレクトおよびリダイレクトなしのポスチャ実装)
- エンドポイントが使用するアダプタの数
- ネットワークデバイスとPSNの場所
- ポスチャに使用されるネットワーク接続タイプ(有線、ワイヤレス、VPN)
例:リダイレクトなしのポスチャのためのPSN配布
ヒント:ネットワークデバイスグループを使用して、設計に従ってネットワークデバイスを分類します。
設定
ネットワークデバイスグループ(オプション)
ネットワークデバイスグループを使用すると、ネットワークデバイスを特定し、対応するRADIUSサーバリストおよびCall Homeリストと照合できます。ハイブリッド環境の場合は、それらを使用して、リダイレクトをサポートしないデバイスからのリダイレクトをサポートするデバイスを特定することもできます。
設計フェーズで作成された配布戦略がネットワークデバイスグループに依存する場合は、次の手順に従ってISE上でそれらを設定します。
- Administration > Network Resources Network Resource Groupsの順に移動します。
- Addをクリックして新しいグループを追加し、名前を指定して、必要に応じて親グループを選択します。
- 手順2を繰り返して、必要なグループをすべて作成します。
このガイド全体で使用されている例では、ロケーションデバイスグループを使用してRADIUSサーバリストとCall Homeリストを識別し、カスタムポスチャデバイスグループを使用してリダイレクトなしのポスチャデバイスからのリダイレクトを識別します。
ネットワーク デバイス グループ
ネットワークデバイス
- ネットワークデバイスはRADIUS認証、許可、アカウンティング用に設定する必要があります。設定手順については、各ベンダーのドキュメントを参照してください。対応するCall Homeリストに従って、RADIUSサーバリストを設定します。
- ISEで、Administration > Network Resources > Network Devicesの順に移動し、Addをクリックします。設計に従ってネットワークデバイスグループを設定し、RADIUS認証設定を有効にして共有秘密を設定します。
ネットワークデバイスの設定
クライアント プロビジョニング
クライアントに適切なソフトウェアとプロファイルをプロビジョニングして、リダイレクトのない環境でポスチャを実行するには、次の2つの方法があります。
- 手動プロビジョニング(導入前)
- クライアントプロビジョニングポータル(Web展開)
手動プロビジョニング(導入前)
- CiscoソフトウェアダウンロードからCisco Secure Client Profile Editorをダウンロードしてインストールします。プロファイルエディタパッケージ
- ISEポスチャプロファイルエディタを開きます。
- 使用中のCall Homeリストごとにステップ2を繰り返します。
- CiscoソフトウェアダウンロードからCisco Secure Client導入前パッケージをダウンロードします。
Cisco Secure Client導入前パッケージ
- プロファイルをISEPostureCFG.xmlとして保存します。
- プロファイルとインストールファイルをアーカイブファイルに配布するか、クライアントにコピーします。
警告:接続しようとしているヘッドエンドに、同じCisco Secure Clientファイル(Secure Firewall ASA、ISEなど)があることを確認してください。手動プロビジョニングを使用する場合でも、対応するソフトウェアバージョンでクライアントプロビジョニング用にISEを設定する必要があります。詳細な手順については、「クライアントプロビジョニングポリシーの設定」セクションを参照してください。
- クライアントで、でzipファイルを開き、セットアップを実行してコアおよびISEポスチャモジュールをインストールします。あるいは、個々のmsiファイルを使用して各モジュールをインストールすることもできます。この場合は、最初にcore-vpnモジュールがインストールされていることを確認する必要があります。
Cisco Secure Client導入前パッケージの内容
Cisco Secure Clientインストーラ
ヒント:トラブルシューティングに使用する診断およびレポートツールをインストールします。
- インストールが完了したら、ポスチャプロファイルxmlを次の場所にコピーします。
- Windows: %ProgramData%\Cisco\Cisco Secure Client\ISE Posture
- MacOS:/opt/cisco/secureclient/iseposture/
クライアントプロビジョニングポータル(Web展開)
ISEクライアントプロビジョニングポータルを使用して、Cisco Secure Client ISEポスチャモジュールとISEからのポスチャプロファイルをインストールできます。ISEポスチャモジュールがすでにクライアントにインストールされている場合は、ポスチャプロファイルをプッシュするためにも使用できます。
- Work Centers > Posture > Client Provisioning > Client Provisioning Portalの順に移動し、ポータル設定を開きます。Portal Settingsセクションを展開し、Authentication methodフィールドを見つけて、ポータルでの認証に使用するIdentity Source Sequenceを選択します。
- クライアントプロビジョニングポータルの使用を許可された内部および外部IDグループを設定します。
ポータル設定での認証方法と承認されたグループ
- Fully Qualified Domain Name(FQDN;完全修飾ドメイン名)フィールドで、クライアントがポータルにアクセスするために使用するURLを設定します。複数のFQDNを設定するには、値をカンマで区切って入力します。
- ポータルURLを対応するCall HomeリストのPSNに解決するようにDNSサーバを設定します。
- ISEポスチャソフトウェアをインストールするために、ポータルにアクセスするためのFQDNをエンドユーザに提供します。
注:ポータルFQDNを使用するには、クライアントのPSN Admin証明書チェーンおよびポータル証明書チェーンが信頼ストアにインストールされている必要があります。また、管理証明書のSANフィールドにポータルFQDNが含まれている必要があります。
クライアントプロビジョニングポリシー
クライアントプロビジョニングは、エンドポイントにCisco Secure Clientをインストールするために使用するプロビジョニングのタイプ(導入前またはWeb導入)に関係なく、ISEで設定する必要があります。
- シスコのソフトウェアダウンロードからCisco Secure Client webdeployパッケージをダウンロードします。Cisco Secure Client WebDeployパッケージ
- シスコソフトウェアダウンロードから最新のコンプライアンスモジュールwebdeployパッケージをダウンロードします。
ISEコンプライアンスモジュールWebDeployパッケージ
- ISEで、Work Centers > Posture > Client Provisioning > Resourcesの順に移動し、Add > Agent resources from local diskの順にクリックします。CategoryドロップダウンメニューからCisco Provided Packagesを選択し、以前にダウンロードしたCisco Secure Client webdeployパッケージをアップロードします。同じプロセスを繰り返して、コンプライアンスモジュールをアップロードします。シスコが提供するパッケージのISEへのアップロード
- Resourcesタブに戻り、Add > AnyConnect Posture Profileの順にクリックします。プロファイル:
- ISE内でプロファイルを識別するために使用できる名前を設定します。
- サーバ名ルールをカンマで区切って設定します。アスタリスク(*)を1つ使用して任意のPSNへの接続を許可するか、ワイルドカード値を使用して特定のドメイン内の任意のPSNへの接続を許可するか、PSN FQDNを使用して特定のPSNへの接続を制限します。
- PSNのカンマ区切りリストを指定するようにCall Home Listを設定します。FQDN:portまたはIP:portの形式を使用して、クライアントプロビジョニングポータルポートを追加します。ISEポスチャプロファイルの設定I
ISEポスチャプロファイルの設定II
Call Homeリストで使用するポートを検索するには、Work Centers > Posture > Client Provisioning > Client Provisioning Portalの順に移動し、使用中のポータルを選択してPortal Settingsを展開します。
クライアントプロビジョニングポータルポート
- Resourcesタブに戻り、Add > AnyConnect Configurationの順にクリックします。使用するCisco Secure Clientパッケージとコンプライアンスモジュールを選択します。
警告:クライアントにCisco Secure Clientが事前に導入されている場合は、ISEのバージョンがエンドポイントのバージョンと一致していることを確認してください。Web展開にASAまたはFTDを使用する場合、このデバイスのバージョンも一致する必要があります。
- Posture Selectionセクションまでスクロールダウンして、ステップ1で作成したプロファイルを選択します。ページの下部にあるSubmitをクリックして、設定を保存します。AnyConnectの設定
プロファイル選択
- Work Centers > Posture > Client Provisioning > Client provisioning policyの順に移動します。必要なオペレーティングシステムに使用されているポリシーを探し、Editをクリックします。Results列で+記号をクリックし、Agent Configurationセクションのステップ5でAnyConnect設定を選択します。
注:複数のCall Homeリストがある場合は、Other Conditionsフィールドを使用して、対応するクライアントに正しいプロファイルをプッシュします。この例では、デバイスロケーショングループを使用して、ポリシーにプッシュされるポスチャプロファイルを特定します。
ヒント:同じOSに対して複数のクライアントプロビジョニングポリシーが設定されている場合は、これらを相互に排他的にすることをお勧めします。つまり、特定のクライアントが一度に1つのポリシーしかヒットできないようにする必要があります。RADIUS属性をOther Conditions列で使用すると、1つのポリシーを別のポリシーと区別できます。
クライアントプロビジョニングポリシーエージェントの設定クライアントプロビジョニングポリシー
- 使用中の各Call Homeリストと対応するポスチャプロファイルについて、ステップ4 ~ 7を繰り返します。ハイブリッド環境では、同じプロファイルをリダイレクトクライアントに使用できます。
許可
許可プロファイル
- Policy > Policy Elements > Results > Authorization > Downloadable ACLsの順に移動し、Addをクリックします。
- DACLを作成して、DNS、DHCP(使用されている場合)、ISE PSNへのトラフィックを許可し、他のトラフィックをブロックします。最終的に準拠したアクセスを行う前に、アクセスに必要な他のトラフィックをすべて許可してください。
DACLの設定
permit udp any any eq domain
permit udp any any eq bootps
permit ip any host
permit ip any host
deny ip any any
注意:一部のサードパーティデバイスはDACLをサポートしていない可能性があります。このような場合は、Filter-IDまたはその他のベンダー固有属性を使用する必要があります。詳細については、ベンダーのマニュアルを参照してください。DACLを使用しない場合は、ネットワークデバイスで対応するACLを設定してください。
- Policy > Policy Elements > Results > Authorization >Authorization profilesの順に移動し、Addをクリックします。認可プロファイルに名前を付け、Common TasksからDACL名を選択します。ドロップダウンメニューから、手順2で作成したDACLを選択します。許可プロファイル
注:DACLを使用しない場合は、Common TasksのFilter-IDまたはAdvanced Attribute Settingsを使用して、対応するACL名をプッシュします。
- 使用中のCall Homeリストごとにステップ1 ~ 3を繰り返します。ハイブリッド環境では、リダイレクションに必要な認証プロファイルは1つだけです。リダイレクションの許可プロファイルの設定は、このドキュメントの範囲外です。
認可ポリシー
- Policy > Policy Setsの順に移動し、使用中のポリシーセットを開くか、または新しいポリシーセットを作成します。
- Authorization Policyセクションまでスクロールします。Session PostureStatus NOT_EQUALS Compliantを使用して認可ポリシーを作成し、前のセクションで作成した認可プロファイルを選択します。
許可ポリシー
- 対応するCall Homeリストが使用されている各認可プロファイルについて、ステップ2を繰り返します。ハイブリッド環境では、リダイレクションに必要な許可ポリシーは1つだけです。
トラブルシュート
Cisco Secure Clientで準拠し、ISEでポスチャが適用されない(保留中)
古い/ファントムセッション
展開内に古いセッションやファントムセッションがあると、リダイレクトなしのポスチャ検出で断続的かつランダムな障害が生成される可能性があります。この結果、Cisco Secure Client UIが準拠アクセスを示している間、ユーザはISE上でポスチャ不明または該当しないアクセス状態のままになります。
古いセッションは、アクティブではなくなった古いセッションです。これらは認証要求とアカウンティング開始によって作成されますが、セッションをクリアするためにPSNでアカウンティング停止が受信されません。
ファントムセッションは、特定のPSNで実際にアクティブではなかったセッションです。これらはアカウンティングの暫定アップデートによって作成されますが、セッションをクリアするためのアカウンティングの停止はPSNで受信されません。
特定
古い/ファントムセッションの問題を特定するには、クライアントのシステムスキャンで使用されるPSNを確認し、認証を実行しているPSNと比較します。
- Cisco Secure Client UIの左下隅にある歯車アイコンをクリックします。左側のメニューから、ISE Postureセクションを開き、Statisticsタブに移動します。[接続情報]にポリシーサーバを書き留めます。
Cisco Secure ClientのISEポスチャのポリシーサーバ
- ISE RADIUSのライブログには、次の点に注意してください。
- ポスチャステータスの変更
- サーバの変更
- 認可ポリシーと認可プロファイルに変更なし
- CoAライブログなし
古い/ファントムセッションのライブログ
- ライブセッションまたは最後の認証ライブログの詳細を開きます。ポリシーサーバをメモします。ステップ1で確認したサーバと異なる場合は、古い/ファントムセッションの問題を示します。
ライブログの詳細のポリシーサーバー
解決方法
ISE 2.6パッチ6および2.7パッチ3より上位のISEバージョンでは、リダイレクトなしのポスチャフローにおける古い/ファントムセッションシナリオのソリューションとしてRADIUSセッションディレクトリが実装されています。
- Administration > System > Settings > Light Data Distributionの順に移動し、Enable RADIUS Session Directoryチェックボックスがオンになっていることを確認します。
RADIUSセッションディレクトリの有効化
- ISE CLIから、次のコマンドを実行して、ISEメッセージングサービスがすべてのPSNで実行されていることを確認します アプリケーションステータスiseの表示
ISEメッセージングサービス実行中(自動)
注:このサービスは、PSN間のRSDに使用される通信方法を指し、ISE UIから設定できるsyslogのISEメッセージングサービス設定の状態に関係なく実行される必要があります。
- ISE Dashboardに移動し、Alarmsダッシュレットを見つけます。Queue Link Errorアラームがあるかどうかを確認します。アラームの名前をクリックすると、詳細が表示されます。
キューリンクエラーアラーム
- ポスチャに使用されるPSN間でアラームが生成されているかどうかを確認します。
キューリンクエラーアラームの詳細
- アラームの説明にカーソルを合わせると、詳細が表示され、原因フィールドが書き留められます。キューリンクエラーの最も一般的な原因は次の2つです。
- タイムアウト:ノードからポート8671の別のノードに送信された要求がしきい値内で応答されないことを示します。修復するには、ノード間でTCPポート8671が許可されていることを確認します。
- Unknown CA:ISEメッセージング証明書を署名している証明書チェーンが無効または不完全であることを示します。このエラーを修復するには、次の手順を実行します。
- Administration > System > Certificates > Certificate signing requestsの順に移動します。
- Generate Certificate Signing Requests (CSR)をクリックします。
- ドロップダウンメニューからISE Root CAを選択し、Replace ISE Root CA Certificate chainをクリックします。
ISEルートCAが使用できない場合は、Certificate Authority > Internal CA settingsの順に移動し、Enable Certificate Authorityをクリックしてから、CSRに戻ってルートCAを再生成します。
- 新しいCSRを生成し、ドロップダウンメニューからISE Messaging Serviceを選択します。
- 展開からすべてのノードを選択し、証明書を再生成します。
注:証明書の再生成中は、Queue Link Errorアラームで原因不明のCAまたはEconnrefusedが発生することが予想されます。証明書の生成後にアラームを監視して、問題が解決されたことを確認します。
パフォーマンス
特定
リダイレクトなしのポスチャに関連する高いCPU使用率や高い負荷平均などのパフォーマンスの問題は、PSNおよびMnTノードに影響を与える可能性があり、多くの場合、次のイベントが付随または先行します。
- ランダムまたは断続的なNo policy server detectedエラー(Cisco Secure Client)
- ポータルサービススレッドプールがしきい値に達したイベントの最大リソース制限に達したレポート。Operations > Reports > Reports > Audit > Operations Auditの順に移動して、レポートを表示します。
- MNTルックアップへのポスチャクエリは高アラームです。これらのアラームは、ISE 3.1以降のバージョンでのみ生成されます。
解決方法
導入のパフォーマンスがリダイレクトなしのポスチャの影響を受ける場合、これは効果的な実装ではないことが多いことを示します。次の点を修正することをお勧めします。
- Call Homeリストごとに使用されるPSNの数設計に従って、エンドポイントまたはネットワークデバイスごとのポスチャに使用できるPSNの数を減らすことを検討してください。
- Call Homeリストのクライアントプロビジョニングポータルポート。各ノードのIPまたはFQDNの後にポータルポート番号が含まれていることを確認します。
影響を軽減するには、次の手順を実行します。
- Cisco Secure Clientフォルダからファイルを削除してエンドポイントからconnectiondata.xmlをクリアし、ISE PostureサービスまたはCisco Secure Clientを再起動します。サービスを再起動しないと、古いファイルが再生成され、変更は有効になりません。このアクションは、Call Homeリストを修正した後にも実行する必要があります。
- DACLまたは他のACLを使用して、ISE PSNへのトラフィックをブロックし、関連性のないネットワーク接続を実現します。
- 認可ポリシーでポスチャが適用されていないが、Cisco Secure Client ISEポスチャモジュールがインストールされているエンドポイントに適用される接続の場合、TCPポート8905およびクライアントプロビジョニングポータルポートのすべてのISE PSNに対するクライアントからのトラフィックをブロックします。このアクションは、リダイレクト実装を使用するポスチャにも推奨されます。
- ポスチャが許可ポリシーに適用される接続では、クライアントから認証側PSNへのトラフィックを許可し、展開内の他のPSNへのトラフィックをブロックします。このアクションは、設計の改訂中に一時的に実行できます。
単一のPSNに対するDACLを使用した認証プロファイル
PSNごとの許可ポリシー
アカウンティング
RADIUSアカウンティングは、ISEでのセッション管理に不可欠です。ポスチャは実行されるアクティブセッションに依存するため、アカウンティング設定の誤りまたは欠如もポスチャディスカバリとISEのパフォーマンスに影響を与える可能性があります。各セッションの1つのPSNに認証要求、アカウンティング開始、アカウンティング停止、およびアカウンティング更新を送信するように、アカウンティングがネットワークデバイスで正しく構成されていることを確認することが重要です。
ISEで受信したアカウンティングパケットを確認するには、Operations > Reports > Reports > Endpoints and Users > RADIUS Accountingの順に移動します。
関連情報