この製品のドキュメントセットは、偏向のない言語を使用するように配慮されています。このドキュメントセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブ ランゲージの取り組みの詳細は、こちらをご覧ください。
シスコは世界中のユーザにそれぞれの言語でサポート コンテンツを提供するために、機械と人による翻訳を組み合わせて、本ドキュメントを翻訳しています。ただし、最高度の機械翻訳であっても、専門家による翻訳のような正確性は確保されません。シスコは、これら翻訳の正確性について法的責任を負いません。原典である英語版(リンクからアクセス可能)もあわせて参照することを推奨します。
このドキュメントでは、リダイレクトなしのポスチャフローの使用と設定、およびトラブルシューティングのヒントについて説明します。
次の項目に関する知識があることが推奨されます。
後で説明する概念をより深く理解するために、次の手順を実行することをお勧めします。
以前のISEバージョンとISE 2.2のISEポスチャフローの比較
ISEセッションの管理とポスチャ
このドキュメントの情報は、次のソフトウェアとハードウェアのバージョンに基づいています。
このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されました。このドキュメントで使用するすべてのデバイスは、クリアな(デフォルト)設定で作業を開始しています。本稼働中のネットワークでは、各コマンドによって起こる可能性がある影響を十分確認してください。
ISEポスチャフローは次の手順で構成されます。
0.認証/許可。通常はポスチャフローが開始される直前に実行されますが、ポスチャ再評価(PRA)などの特定のユースケースではバイパスできます。認証自体はポスチャディスカバリをトリガーしないため、これはすべてのポスチャフローに不可欠とは見なされません。
このドキュメントでは、ISEポスチャフローの検出プロセスを中心に説明します。
ディスカバリプロセスではリダイレクションを使用することを推奨しますが、リダイレクションがサポートされていないサードパーティのネットワークデバイスの使用など、リダイレクションを実装できない特定のケースがあります。このドキュメントの目的は、このような環境でリダイレクトのないポスチャを実装およびトラブルシューティングするための一般的なガイダンスとベストプラクティスを提供することです。
リダイレクトレスフローの詳細については、「ISE 2.2での以前のISEバージョンとISEポスチャフローの比較」を参照してください。
リダイレクトを使用しないポスチャ検出プローブには、次の2つのタイプがあります。
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リストは、ポスチャプロファイルのセクションで、ポスチャに使用するPSNのリストが指定されます。connectiondata.xmlとは異なり、これはISE管理者によって作成および維持され、最適な設定のために設計フェーズが必要になる場合があります。Call HomeリストのPSNのリストは、RADIUSのネットワークデバイスまたはロードバランサに設定されている認証およびアカウンティングサーバのリストと一致している必要があります。
Call Homeリストプローブを使用すると、PSNでローカルルックアップが失敗した場合に、アクティブセッションの検索中にMnTルックアップを使用できます。同じ機能がconnectiondata.xmlプローブに拡張されるのは、それらがステージ2の検出中に使用された場合だけです。このため、すべてのステージ2プローブは、新世代プローブとも呼ばれます。
MnTルックアップフロー
リダイレクトレス検出プロセスは、多くの場合、リダイレクトフローよりも複雑なフローを伴い、PSNおよびMnT上で大量の処理を行うため、実装時に発生する可能性がある一般的な課題が2つあります。
これらの課題に対処するには、Call Homeリストを設計して、特定のエンドポイントがポスチャに使用できるPSNの数を制限することをお勧めします。中規模および大規模の導入では、複数のCall Homeリストを作成するために少数のPSNで導入を分散する必要があります。結果として、特定のネットワークデバイスのRADIUS認証に使用されるPSNのリストは、対応するCall Homeリストに一致するように制限する必要があります。
各Call Homeリスト内のPSNの最大数を決定するPSN分散戦略を作成する際には、次の点を考慮できます。
例:リダイレクトなしのポスチャのためのPSN配布
ヒント:ネットワークデバイスグループを使用して、設計に従ってネットワークデバイスを分類します。
ネットワークデバイスグループを使用すると、ネットワークデバイスを特定し、対応するRADIUSサーバリストおよびCall Homeリストと照合できます。ハイブリッド環境の場合は、それらを使用して、リダイレクトをサポートしないデバイスからのリダイレクトをサポートするデバイスを特定することもできます。
設計フェーズで作成された配布戦略がネットワークデバイスグループに依存する場合は、次の手順に従ってISE上でそれらを設定します。
このガイド全体で使用されている例では、ロケーションデバイスグループを使用してRADIUSサーバリストとCall Homeリストを識別し、カスタムポスチャデバイスグループを使用してリダイレクトなしのポスチャデバイスからのリダイレクトを識別します。
ネットワーク デバイス グループ
ネットワークデバイスの設定
クライアントに適切なソフトウェアとプロファイルをプロビジョニングして、リダイレクトのない環境でポスチャを実行するには、次の2つの方法があります。
注:必要に応じてクライアントプロビジョニングポータルポートを確認する方法については、「クライアントプロビジョニングポリシー」セクションのステップ4を参照してください。
警告:接続しようとしているヘッドエンドに、同じCisco Secure Clientファイル(Secure Firewall ASA、ISEなど)があることを確認してください。手動プロビジョニングを使用する場合でも、対応するソフトウェアバージョンでクライアントプロビジョニング用にISEを設定する必要があります。詳細な手順については、「クライアントプロビジョニングポリシーの設定」セクションを参照してください。
Cisco Secure Client導入前パッケージの内容
Cisco Secure Clientインストーラ
ヒント:トラブルシューティングに使用する診断およびレポートツールをインストールします。
ISEクライアントプロビジョニングポータルを使用して、Cisco Secure Client ISEポスチャモジュールとISEからのポスチャプロファイルをインストールできます。ISEポスチャモジュールがすでにクライアントにインストールされている場合は、ポスチャプロファイルをプッシュするためにも使用できます。
注:ポータルFQDNを使用するには、クライアントのPSN Admin証明書チェーンおよびポータル証明書チェーンが信頼ストアにインストールされている必要があります。また、管理証明書のSANフィールドにポータルFQDNが含まれている必要があります。
クライアントプロビジョニングは、エンドポイントにCisco Secure Clientをインストールするために使用するプロビジョニングのタイプ(導入前またはWeb導入)に関係なく、ISEで設定する必要があります。
Call Homeリストで使用するポートを検索するには、Work Centers > Posture > Client Provisioning > Client Provisioning Portalの順に移動し、使用中のポータルを選択してPortal Settingsを展開します。
クライアントプロビジョニングポータルポート
警告:クライアントにCisco Secure Clientが事前に導入されている場合は、ISEのバージョンがエンドポイントのバージョンと一致していることを確認してください。Web展開にASAまたはFTDを使用する場合、このデバイスのバージョンも一致する必要があります。
注:複数のCall Homeリストがある場合は、Other Conditionsフィールドを使用して、対応するクライアントに正しいプロファイルをプッシュします。この例では、デバイスロケーショングループを使用して、ポリシーにプッシュされるポスチャプロファイルを特定します。
ヒント:同じOSに対して複数のクライアントプロビジョニングポリシーが設定されている場合は、これらを相互に排他的にすることをお勧めします。つまり、特定のクライアントが一度に1つのポリシーしかヒットできないようにする必要があります。RADIUS属性をOther Conditions列で使用すると、1つのポリシーを別のポリシーと区別できます。
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を設定してください。
注:DACLを使用しない場合は、Common TasksのFilter-IDまたはAdvanced Attribute Settingsを使用して、対応するACL名をプッシュします。
展開内に古いセッションやファントムセッションがあると、リダイレクトなしのポスチャ検出で断続的かつランダムな障害が生成される可能性があります。この結果、Cisco Secure Client UIが準拠アクセスを示している間、ユーザはISE上でポスチャ不明または該当しないアクセス状態のままになります。
古いセッションは、アクティブではなくなった古いセッションです。これらは認証要求とアカウンティング開始によって作成されますが、セッションをクリアするためにPSNでアカウンティング停止が受信されません。
ファントムセッションは、特定のPSNで実際にアクティブではなかったセッションです。これらはアカウンティングの暫定アップデートによって作成されますが、セッションをクリアするためのアカウンティングの停止はPSNで受信されません。
古い/ファントムセッションの問題を特定するには、クライアントのシステムスキャンで使用されるPSNを確認し、認証を実行しているPSNと比較します。
ISE 2.6パッチ6および2.7パッチ3より上位のISEバージョンでは、リダイレクトなしのポスチャフローにおける古い/ファントムセッションシナリオのソリューションとしてRADIUSセッションディレクトリが実装されています。
注:このサービスは、PSN間のRSDに使用される通信方法を指し、ISE UIから設定できるsyslogのISEメッセージングサービス設定の状態に関係なく実行される必要があります。
注:証明書の再生成中は、Queue Link Errorアラームで原因不明のCAまたはEconnrefusedが発生することが予想されます。証明書の生成後にアラームを監視して、問題が解決されたことを確認します。
リダイレクトなしのポスチャに関連する高いCPU使用率や高い負荷平均などのパフォーマンスの問題は、PSNおよびMnTノードに影響を与える可能性があり、多くの場合、次のイベントが付随または先行します。
導入のパフォーマンスがリダイレクトなしのポスチャの影響を受ける場合、これは効果的な実装ではないことが多いことを示します。次の点を修正することをお勧めします。
影響を軽減するには、次の手順を実行します。
RADIUSアカウンティングは、ISEでのセッション管理に不可欠です。ポスチャは実行されるアクティブセッションに依存するため、アカウンティング設定の誤りまたは欠如もポスチャディスカバリとISEのパフォーマンスに影響を与える可能性があります。各セッションの1つのPSNに認証要求、アカウンティング開始、アカウンティング停止、およびアカウンティング更新を送信するように、アカウンティングがネットワークデバイスで正しく構成されていることを確認することが重要です。
ISEで受信したアカウンティングパケットを確認するには、Operations > Reports > Reports > Endpoints and Users > RADIUS Accountingの順に移動します。
改定 | 発行日 | コメント |
---|---|---|
1.0 |
24-Jul-2023 |
初版 |