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プロセスに送信されるアカウンティング停止は正しいです。
• アカウンティング停止の方式IDとしてのdot1xは、認可方式がdot1xであったために正しい値です。
• Dot1x方式が成功すると、method-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段階の検出プローブは、クライアントが認証されるサーバ（2.6パッチ6、2.7パッチ2、および3.0）とは別のサーバによって応答されます。

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

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

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

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

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

各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 > Resessment configurationsで設定できます。