ISEポスチャの導入

はじめに

このドキュメントでは、リダイレクトベースのポスチャを使用するいくつかのユースケースに対処するいくつかのベースライン設定について説明します。

制約事項

このドキュメントの設定はCisco NADに対して機能しますが、サードパーティNADに対して機能するとは限りません。

ポスチャクライアントの動作

ポスチャクライアントは、次の場合にプローブをトリガーできます。

• 最初のログイン
• レイヤ3(L3)の変更/ネットワークインターフェイスカード(NIC)の変更（新しいIPアドレス、NICの状態変更）

使用例

使用例1：クライアントの再認証によりNADが新しいセッションIDを生成する

この使用例では、クライアントはまだ準拠していますが、再認証が原因で、NADはリダイレクト状態（リダイレクトURLおよびアクセスリスト）になっています。

デフォルトでは、Identity Services Engine(ISE)は、ネットワークに接続するたびに、具体的には新しいセッションごとにポスチャ評価を実行するように設定されています。

この設定は、Work Centers > Posture > Settings > Posture General Settingsで設定します。

再認証時にNADが新しいセッションIDを生成しないようにするには、認可プロファイルでこれらの再認証値を設定します。表示される再認証タイマーは標準的な推奨事項ではなく、接続のタイプ（無線/有線）、設計（ロードバランサの持続性ルール）などに基づいて、導入ごとの再認証タイマーを検討してください。

Policy > Policy Elements > Results > Authorization > Authorization Profiles

スイッチでは、各インターフェイスまたはテンプレートを設定して、ISEから再認証タイマーを取得する必要があります。 

authentication timer reauthenticate server

注：ロードバランサがある場合は、再認証を元のポリシーサービス(PSN)に返せるように永続性が設定されていることを確認する必要があります。

使用例2 – スイッチがMAB DOT1Xの順序（有線）とDOT1X MABの優先順位（有線）で設定されている

この場合、再認証中にMAC認証バイパス(MAB)が試行されると、802.1xセッションのアカウンティング停止を送信できるため、再認証を終了できます。

• クライアントのユーザ名が802.1Xのユーザ名からMABのユーザ名に変わるため、認証に失敗した場合にMABプロセスに送信されるアカウンティング停止は正しいです。
• アカウンティング停止のmethod-idとしてのdot1xは、認可方式がdot1xだったため、正しい値です。
• Dot1x方式が成功すると、方式IDがdot1xのアカウンティング開始が送信されます。ここでも、この動作は期待どおりです。

この問題を解決するには、エンドポイントが準拠しているときに使用されるauthZプロファイルにcisco-av-pair:termination-action-modifier=1を設定します。この属性値(AV)ペアは、設定された順序に関係なく、NADが元の認証で選択された方式を再利用することを指定します。

使用例3：ワイヤレスクライアントがローミングし、異なるAPの認証が異なるコントローラに送信される

この状況では、ローミングのために他のAPに到達可能なアクセスポイント(AP)が同じアクティブコントローラを使用するように、ワイヤレスネットワークを設計する必要があります。たとえば、ワイヤレスLANコントローラ(WLC)のステートフルスイッチオーバー(SSO)フェールオーバーがあります。WLCのハイアベイラビリティ(HA)SSOの詳細については、『ハイアベイラビリティ(SSO)導入ガイド』を参照してください。

使用例4：ロードバランサを使用した展開（2.6パッチ6より前、2.7パッチP2、および3.0）

ロードバランサを使用する導入では、前の使用例で変更を行った後、セッションが同じPSNに送信され続けることを確認することが重要です。この手順でリストされるバージョンまたはパッチよりも前では、ポスチャステータスはLight Data Distribution（以前のLight Session Directory）を介してノード間で複製されません。 このため、異なるPSNが異なるポスチャステータス結果を返す可能性があります。

持続性が正しく設定されていない場合、再認証されたセッションは、最初に使用されたものとは異なるPSNに送信される可能性があります。これが発生した場合、新しいPSNはセッションのコンプライアンスステータスを不明としてマークし、リダイレクトアクセスコントロールリスト(ACL)/URLを使用してauthZ結果を渡し、エンドポイントのアクセスを制限できます。ここでも、NAD上のこの変更はポスチャモジュールによって認識されず、プローブはトリガーされません。

ロードバランサの設定方法の詳細については、『Cisco & F5 Deployment Guide: ISE Load Balancing Using BIG-IP』を参照してください。ロードバランス環境でのISE導入のベストプラクティス設計の概要とF5固有の設定について説明します。

使用例5 – ステージ2の検出プローブが、クライアントが認証されたサーバとは異なるサーバによって応答される（Pre 2.6 Patch 6、2.7 Patch 2、および3.0）

次の図の赤いボックス内のプローブを見てください。

PSNはセッションデータを5日間保存するため、クライアントがそのノードで認証を行わなくなっても、準拠するセッションのセッションデータが元のPSNに残っている場合があります。赤いボックスに囲まれたプローブが、現在セッションを認証しているPSNとは別のPSNによって応答され、PSNが以前にこのエンドポイントを所有しており、準拠としてマークしている場合、エンドポイント上のポスチャモジュールのポスチャステータスと現在の認証PSNが一致していない可能性があります。

この不一致が発生する可能性のある一般的なシナリオを次に示します。

• ネットワークから切断されたエンドポイントのアカウンティング停止は受信されません。
• NADが1つのPSNから別のPSNにフェールオーバーしました。
• ロードバランサは、同じエンドポイントの異なるPSNに認証を転送します。

この動作から保護するために、ISEは、特定のエンドポイントからの検出プローブが、現在認証されているPSNに到達することのみを許可するように設定できます。これを実現するには、導入環境のPSNごとに異なる許可ポリシーを設定します。これらのポリシーでは、別のauthZプロファイルを参照します。このプロファイルには、authZ条件で指定されたPSNに対してのみプローブを許可するダウンロード可能アクセスコントロールリスト(DACL)が含まれています。次の例を参照してください。

各PSNには、不明なポスチャステータスのルールがあります。

個々のプロファイルは異なるDACLを参照します。

注：ワイヤレスの場合は、Airespace ACLを使用します。

各DACLでは、認証を処理するPSNへのプローブアクセスのみが許可されます。

前の例では、10.10.10.1がPSN 1のIPアドレスです。参照されるDACLは、必要に応じて追加のサービス/IPに対して変更できますが、認証を処理するPSNだけにアクセスを制限します。

2.6パッチ6、2.7パッチ2、および3.0以降の動作の変更

ポスチャステータスは、Light Data Distribution(LDD)フレームワークを介してRADIUSセッションディレクトリに追加されています。ポスチャステータスの更新がPSNで受信されるたびに、その更新は展開内のすべてのPSNに複製されます。この変更が有効になると、異なる認証で異なるPSNに到達する認証やプローブの影響が取り除かれ、どのPSNも現在認証されている場所に関係なくすべてのエンドポイントに応答できるようになります。

このドキュメントの5つの使用例では、次の動作を検討します。

使用例1：クライアントの再認証により、NADは新しいセッションIDを生成します。クライアントは引き続き準拠していますが、再認証が原因で、NADはリダイレクト状態（リダイレクトURLとアクセスリスト）になっています。

– この動作は変更されず、この設定はISEおよびNADに実装できます。

使用例2 – スイッチはMAB DOT1Xの順序（有線）とDOT1X MAB（有線）の優先順位で設定されています。

– この動作は変更されず、この設定はISEおよびNADに実装できます。

使用例3：ワイヤレスクライアントがローミングし、異なるAPの認証が異なるコントローラに送信される。

– この動作は変更されず、この設定はISEおよびNADに実装できます。

使用例4：ロードバランサを使用した導入

– ロードバランシングガイドで定義されたベストプラクティスに従うことができますが、認証がロードバランサによって異なるPSNに転送される場合は、正しいポスチャステータスをクライアントに返すことができます。

使用例5 – ステージ2の検出プローブが、クライアントの認証時とは異なるサーバによって応答される

– これは新しい動作の問題にはならず、PSNごとの認証プロファイルは不要です。

同じSessionIDを維持する場合の考慮事項

このドキュメントに記載されている方法を使用すると、ネットワークに接続されたままのユーザが、長期間準拠し続ける可能性があります。再認証されても、セッションIDは変更されないため、ISEは準拠ステータスに一致するルールに対するAuthZ結果を引き続き渡します。

この場合は、エンドポイントが定義された間隔で企業ポリシーに準拠していることを確認するためにポスチャが必要となるように、定期的な再評価を設定する必要があります。

これは、Work Centers > Posture > Settings > Reassessment configurationsで設定できます。