Aruba ClearPass

利点

• ネットワーク、クライアント、デバイスの管理と保守に役立つデータにすばやく簡単にアクセスできます。

• 継続的な監視と高度な分析により、ネットワークをリアルタイムで可視化します。

ファイアウォールとClearPass間の通信はどのように行われますか?

Enforcement SecurityにAruba ClearPassが必要な理由

1. リスクと課題:会社のスマートフォンの使用は、企業にとって最大のITセキュリティリスクの1つです。

   • 今日のネットワーク環境は、多かれ少なかれ 、いつでも、あらゆるデバイス へのアクセスをサポートし、ユーザーが複数のネットワークに接続されたデバイスを同時に使用できるため、さまざまな種類の攻撃にさらされています。

   • 攻撃者は、近くの会社所有のモバイルデバイスにアクセスし、マルウェアをインストールして、いつでもデータをキャプチャすることができます。

   • 攻撃者は、情報収集ベンチャーを立ち上げ、ビジネス活動を停止し、企業の機密データを盗む可能性があります。

2. ビジネスのニーズ:モバイルデバイスやクラウドサービスの急増とそれらのセキュリティ保護は、企業のサイバーセキュリティの基本的な戦略的部分となっています。

   • モバイルデバイスをサポートする作業環境では、ユーザーの身元を知ることが重要です。

   • ユーザー ID により、IT 管理者は、攻撃元を特定し、同じ戦略に従う将来の潜在的な攻撃を防止する上で有利になります。

   • 強制セキュリティを備えたClearPassは、モバイルデバイスおよび同時に接続された複数のデバイスの使用によって生じる悪意のある侵入から保護します。

3. ClearPassを使用した保護—セキュリティを適用したClearPassは、ユーザー名またはユーザーが属するグループでユーザーを識別するセキュリティポリシーを構成できるようにすることで、攻撃や侵入からユーザーを保護できます。

   • ClearPassは、ネットワーク環境に対して行われた脅威と攻撃を特定し、この情報をCPPMに提供します。

   • CPPMの管理者は、セキュリティの適用をより適切に調整して、同じ種類の将来の攻撃から保護できます。

   • ユーザーが複数のデバイスでネットワークにログインしている場合、デバイスだけでなく、ID に基づいてアクティビティを追跡できます。

   • 意図したかどうかにかかわらず、ネットワークアクセスや悪質なアクティビティを簡単に制御できます。

Aruba ClearPassとEnforcement Securityの仕組み

ポリシー適用セキュリティを備えたAruba ClearPassは、SCREENS、IDP、およびコンテンツセキュリティ機能の保護を提供し、さまざまな攻撃戦略からネットワークを保護します。デバイスは、企業のネットワークリソースを保護するだけでなく、攻撃や攻撃の脅威に対応して、これらの保護セキュリティ機能によって生成されたCPPMログレコードで利用できるようにすることができます。すでに発生している脅威や具体的な攻撃を把握していれば、IT部門はコンプライアンス違反のシステムやネットワークの露出エリアを特定するのに役立ちます。この情報をもとに、デバイスコンプライアンスを徹底し、リソースの保護を強化することで、セキュリティを強化できます。

適用セキュリティを備えたClearPassでは、ユーザーレベルでのきめ細かな制御が可能です。

• デバイスの管理者は、 アイデンティティ認識型セキュリティ ポリシーの ID ソース パラメータで、CPPM がデバイスに送信するユーザ名またはロール(グループ)名を指定できるようになりました。ユーザーを識別する手段として、デバイスのIPアドレスのみに依存することはもうありません。デバイスだけでなく、デバイスのユーザーに焦点を合わせることで、セキュリティ適用の制御を強化できます。

• CPPMは、認証されたユーザー情報をファイアウォールに提供するだけでなく、デバイスタイプをロールにマッピングし、ユーザーをそのロールに割り当てることができます。その後、そのロールマッピングをファイアウォールに送信できます。この機能により、ユーザーが 特定のタイプのデバイスを使用しているときに、セキュリティ ポリシーを使用してリソースへのアクセスを制御できます。

たとえば、CPPM の管理者が marketing-company-device というロールを設定し、会社のデバイスとマーケティング部門のメンバーの両方をそのロールにマッピングしたとします。デバイスの管理者は、セキュリティポリシーでそのロールをグループであるかのように指定できます。その後、セキュリティ ポリシーはロールにマッピングされたすべてのユーザーに適用され、そのタイプのデバイス タイプを使用する場合のネットワーク アクティビティを本質的に制御します。

ファイアウォールのセキュリティポリシーは、企業のリソースを保護し、CPPMからデバイスに送信されるユーザー認証とID情報を利用して、きめ細かなレベルでアクセス制御を実施します。CPPMは認証ソースとして機能します。独自の内部RADIUSサーバーを使用してユーザーを認証します。また、外部RADIUSサーバーやActive Directoryなどの外部認証ソースに依存して認証を実行することもできます。

CPPM認証は、スイッチやアクセスコントローラなどのNASデバイスからの要求によってトリガーされます。CPPMは、デバイスが公開するRESTful WebサービスのXML部分を使用して、POSTリクエストメッセージをデバイスの認証済みユーザーID、およびデバイスのポスチャ情報に送信します。

ファイアウォールとAruba ClearPassは、企業のリソースを保護し、モバイルデバイスのインターネット・アクセス・ポリシーを適用するために必要な、複雑で複雑なセキュリティ・タスクを簡素化します。このセキュリティは、モバイルエクスペリエンスをサポートし、ユーザーが独自のシステム、スマートフォン、タブレットなど、さまざまなデバイスを使用する自由度を与えるネットワーク環境に不可欠です。

ClearPassからファイアウォールに送信されるデータの整合性

次の要件により、CPPMから送信されるデータが危険にさらされることはありません。

• Web API の実装は、HTTP/HTTPS POST 要求の処理のみに制限されています。その他の種類の要求を受信すると、エラー メッセージが生成されます。

• Web API デーモンは、次の専用 URL からの HTTP/HTTPS 要求のみを分析および処理します。

• CPPMがデバイスに送信するHTTP/HTTPSコンテンツは、一貫して正しくフォーマットされている必要があります。正しい XML形式は、妥協がないことを示し、ユーザー ID 情報が失われないようにします。

データ サイズの制限とその他の制約

CPPMには、次のデータサイズの制限と制限が適用されます。

• CPPMは、投稿するデータのサイズを制御する必要があります。そうしないと、Web API デーモンはそれを処理できません。現在、Web API は最大 2 メガバイトのデータを処理できます。

• ロールおよびデバイスポスチャ情報の XML データには、次の制限が適用されます。Web API デーモンは、これらの量を超える送信された XML データ (つまり、オーバーフロー データ) を破棄します。

  • ファイアウォールは、最大 209 個のロールを処理できます。

  • ファイアウォールは、6 つの可能なポスチャ トークンまたは値を持つ 1 種類のポスチャのみをサポートします。個々のユーザーの ID 情報には、ポスチャ トークンを 1 つだけ含めることができます。

  • CPPMはファイアウォールの正常性と態勢をチェックし、その情報を投稿するユーザー情報の一部としてファイアウォールに送信できます。

  • ファイアウォールでポスチャを定義することはできません。また、ファイアウォールは受信したポスチャ情報をチェックしません。

ポスチャ状態とポスチャ グループ

ユーザ、ロール、およびポスチャトークンフィールドは、CPPMのコンテキストで区別されます。ユーザー ID 情報の各セットには、ユーザーおよびロール(グループ)ID とポスチャ トークンが含まれています。ファイアウォールまたはNFXシリーズ デバイスは user フィールドとロール(グループ)フィールドのみをサポートするため、ポスチャ トークン値はプレフィックス posture–を追加することでロールにマッピングされます。その後、セキュリティ ポリシーでそのロールをグループとして使用でき、そのポリシーはポリシーに一致するすべてのトラフィックに適用されます。

事前定義されたポスチャ ID の状態は次のとおりです。

• posture-healthy(HEALTHY)

• posture-checkup(CHECKUP)

• ポスチャトランジション(TRANSITION)

• ポスチャ検疫(QUARANTINE)

• posture-infected(感染)

• posture-unknown(不明)

ClearPassが脅威と攻撃を検出してCPPMに通知する方法

ファイアウォールが脅威イベントと攻撃イベントを検出すると、そのイベントがファイアウォール イベント ログに記録されます。ファイアウォールは syslog を使用してログを CPPM に転送します。CPPMはログを評価し、一致する条件に基づいてアクションを実行できます。ClearPassの管理者は、ファイアウォールからの情報を使用し、CPPMで適切なアクションを定義してセキュリティを強化できます。

ファイアウォール上の Junos OS は、10 以上のモジュールによって発行された 100 種類以上のログ エントリーを生成します。脅威ログと攻撃ログを生成するファイアウォールには、SCREENS、IDP、およびコンテンツセキュリティがあります。ファイアウォールとログサーバーの過負荷を回避するために、ClearPassでは、SCREENS、IDP、およびコンテンツセキュリティ機能によって検出されたアクティビティに応じてイベントログに書き込まれた攻撃および脅威ログエントリのみをCPPMに送信するようにファイアウォールを設定できます。

ログ送信を制御するために、以下の条件を設定できます。

• 脅威と攻撃のログのみを送信するためのログ ストリーム フィルター。

• 送信ボリュームを制御するレートリミッター。デバイスログの送信は、設定したレート制限条件を超えることはありません。

CPPMが送信するログ情報を分析するためには、コンテンツを標準的で構造化された方法でフォーマットする必要があります。ファイアウォールログの送信は、ベンダー固有の拡張を構造化された方法で提供できるメッセージ形式を持つsyslogプロトコルに従います。

脅威と攻撃のログをAruba ClearPassに送信

ファイアウォールとポリシー適用機能は、Aruba ClearPassと連携し、攻撃と脅威のイベント・ログを使用して、潜在的および実際の攻撃から企業のリソースを保護します。SRXシリーズ SCREENS、IDP、Content Securityコンポーネントによって生成されるこれらのログは、企業のネットワークセキュリティを脅かす攻撃や脅威のタイプを明確に特定します。

ファイアウォールは、ログエントリ全体から脅威と攻撃イベントを報告するログをフィルタリングし、これらのログエントリをClearPass Policy Manager(CPPM)に転送して、企業のセキュリティポリシーの評価と実施に使用します。ファイアウォールは、設定したレート制限条件によって決定されるボリュームでログを送信します。

ClearPassとJIMSの関係

ユーザーがCPPMによって認証されると、CPPMはWeb APIを使用してユーザーまたはデバイス情報をファイアウォールにプッシュします。ファイアウォールは、ユーザーの認証エントリーまたはデバイス情報を構築し、ユーザートラフィックはセキュリティポリシーに基づいてファイアウォールを通過できます。Windows Active Directory クライアントがドメインにログオンすると、ファイアウォールはバッチ クエリを介して JIMS からクライアントのユーザーまたはデバイス情報を取得します。認証テーブルは、JIMS によって提供されるエントリで更新されます。ユーザートラフィックは、セキュリティポリシーに基づいてデバイスを通過できます。

JIMS IP クエリと ClearPass ユーザー クエリの両方が有効になっている場合、ファイアウォールは常に最初に ClearPass にクエリを実行します。CPPMがIPユーザー・マッピング情報とともに戻った場合、その情報はその後認証テーブルに追加されます。CPPMがIPユーザーマッピング情報を返さない場合、またはファイアウォールがIPユーザーマッピングなしでCPPMから応答を受信した場合、ファイアウォールはJIMSにクエリーを実行してIPユーザーまたはグループのマッピングを取得します。

IP ユーザーまたはグループ マッピングが JIMS と CPPM の両方から受信されると、ファイアウォールは最新の認証エントリを考慮し、既存の認証エントリを上書きします。

秒単位で指定された delay-query-time パラメーターを設定して、デバイスがクエリを送信する前に一定時間待機できるようにすることができます。遅延時間は、ClearPassとJIMSで同じ値にする必要があります。そうでない場合は、エラーメッセージが表示され、コミットチェックは失敗します。

JIMS と CPPM の両方から IP ユーザーまたはグループ マッピングを受信すると、デバイスは最新の認証エントリーを考慮し、既存の認証エントリーを上書きします。

ClearPassとJIMSの連携に関するさまざまなシナリオ

JIMSを使用したClearPassがどのように機能するかについて、シナリオを含む詳細な説明は次のとおりです。

ドメイン グループ

デバイスは、ドメイン名前空間のユーザー名の処理方法に関して、通常のコースに従います。名前空間を使用して、 admin など、同じであるが、異なるソースからのものであり、異なるドメインにある名前を区別します。これらは異なるドメインに属しているため、名前は競合しません。

IP ユーザー マッピングの一部であるグループは、そのドメインが特定のドメインであるか GLOBAL ドメインであるかに関係なく、常にドメインに属します。ドメイン名がIPユーザー・マッピングで指定されていない場合は、GLOBALドメインが想定されます。

IP, , user1, group-list

IP, domain1, user1, group-list

関心のあるグループ

グループは、セキュリティ ポリシーによって参照されている場合(つまり、ポリシーの source-identity フィールドで指定されている場合)に 、対象グループ として認定されます。ルーティングエンジンの認証テーブルでは、各ユーザーエントリーに、セキュリティポリシーが存在するグループの名前を識別するポリシーリストが参照するグループが含まれます。ユーザー・エントリーに含まれるグループが現在セキュリティー・ポリシーで使用されていない場合、そのグループはこのリストに含まれません。グループは、ポリシーリストによって参照されるグループ内およびグループ外に移動できます。

• 関心のあるグループリスト

  関心のあるグループリスト、またはポリシーによって参照されるグループのリストは、グループ全体のサブセットです。これは、ユーザー認証項目のグループ・リストと、セキュリティー・ポリシーの送信元 ID リストの共通部分です。つまり、ClearPass認証テーブルのユーザーエントリーに含まれるすべてのグループが、対象グループとして認定されます。ルーティングエンジンは、セキュリティポリシーによって参照されるグループのみを、パケット転送エンジンのClearPass認証テーブルのユーザーエントリーに同期します。

  その仕組みは次のとおりです。

  • UserID デーモンは、CPPM から完全な IP ユーザーロール (グループ) マッピングを取得します。

  • ユーザー・ID デーモンは、グループごとに、そのグループを参照するセキュリティー・ポリシーがあるかどうかを判別することによって、そのグループがインタレスト・グループであるかどうかを識別します。条件を満たすグループは、ルーティングエンジン上のポリシーリストが参照するグループに含まれます。UserIDデーモンは、残りのユーザー認証およびID情報とともに、パケット転送エンジン対象グループのClearPass認証テーブル内のユーザーエントリーと同期します。

  ルーティングエンジンでのユーザーエントリーの対象グループリストは、以下のイベントに基づいて変化する可能性があります:

  • ルーティングエンジンのユーザーエントリーに含まれるが、エントリーの参照グループリストにはまだ含まれていないグループを参照する新しいセキュリティポリシーが設定されます。

  • 現在設定されているセキュリティポリシーのうち、source-identity でグループを参照しているものは削除されます。

  次の例について考えてみます。

  • CPPMが2人のユーザーに関する次の情報をファイアウォールに投稿したとします。

  • デバイスがポスチャをマッピングし、グループとして定義すると、デバイス ルーティングエンジン認証テーブル内の 2 つのユーザー エントリーは以下のようになります。

  • 複数のセキュリティ ポリシーに、group1、group3、posture-healthy のいずれかを参照する source-identity フィールドが含まれているとします。

    上記のセット(元のグループリストとグループを参照するセキュリティポリシーのリスト)の共通部分は、次の関心のあるグループリストになります。

    • ユーザ john の場合、ポリシー リストによって参照されるグループには group1 と posture-healthy が含まれます。

    • ユーザ abe の場合、ポリシー リストによって参照されるグループには、group1、group3、および posture-healthy が含まれます。

  ここで、source-identity フィールドに group1 が指定されたセキュリティ ポリシーが削除されたとします。2 人のユーザー (john と abe) のユーザー認証エントリーのポリシーリストによって参照されるグループは変更され、以下の結果になります。

  • ユーザ john の場合、リストには posture-healthy のみが含まれます。

  • ユーザ abe の場合、リストには group3 と posture-healthy が含まれます。

表6 は、グループがセキュリティポリシーによって参照 されておらず 、したがって関心のあるグループではない場合の、ClearPass認証テーブルへの影響を示しています。

203.0.113.9, ,user1, g1, g2, g3, g4

203.0.113.9 , ,user1 

192.0.2.1, domain1, user2, g1, g2, g3, g4

192.0.2.1, domain1, user2, g2, g4

ユーザーが別のソースによってすでに認証されている場合

例えば、デバイスルーティングエンジン認証テーブルとパケット転送エンジン上の個々のMicrosoft Active Directory認証テーブルに、Active Directoryによって認証されたユーザーのエントリーが含まれている場合があります。通常どおり、CPPM はユーザの IP ユーザ マッピングをデバイスに送信します。ルーティングエンジン認証テーブルは Active Directory と ClearPass の両方に共通であるため、デバイスで問題を解決する必要があります。

デバイスが状況を処理する方法は次のとおりです。

• ルーティングエンジン認証テーブル上:

  • デバイスは、共通ルーティングエンジン認証テーブル内のユーザーの Active Directory 認証エントリーを、CPPM からのユーザーの IP ユーザー マッピングから新しく生成されたエントリーで上書きします。

    これで、IPアドレスまたはユーザー名の競合は発生しなくなりました。

• パケット転送エンジン上:

  • デバイスは、ユーザーの既存の Active Directory 認証エントリーを Active Directory 認証テーブルから削除します。

    これにより、IPアドレスに関連付けられているアクティブなセッションが削除されます。

  • デバイスは、パケット転送エンジンのClearPass認証テーブルに、CPPM認証されたユーザー向けの新しいエントリーを生成します。

    IPユーザー マッピング エントリに関連付けられたトラフィックは、ClearPass認証テーブル内のユーザー認証に基づいて新しいセッションを開始します。

ファイアウォールはClearPass認証テーブルをどのように管理しますか?

ファイアウォールは、CPPMから認証されたユーザーID情報を取得し、ClearPass認証テーブルにエントリーを生成して、セキュリティポリシーとユーザーイベントに関連してこれらのエントリーを管理します。ClearPassは、ファイアウォールの認証ソースとして機能します。CPPMは、認証したユーザーに関するファイアウォールID情報をファイアウォールに送信します。ファイアウォールの UserID デーモン プロセスは、この情報を受信して処理し、この目的のために生成される独立した ClearPass 認証テーブルのパケット転送エンジン側に同期します。

デバイスの管理者は、セキュリティー・ポリシーで認証されたユーザー・アイデンティティー情報を使用して、保護されたリソースおよびインターネットへのアクセスを制御できます。

デバイスがCPPMから取得し、個々のClearPass認証テーブルに同期されるグローバルルーティングエンジン認証テーブルにエントリーを作成するために使用するユーザー識別情報のコレクションは、ユーザー名と関連するグループリストがユーザーのデバイスのIPアドレスにマッピングされるため、マッピング、またはより一般的にはIPユーザーマッピングと呼ばれます。

グループリストでは、ClearPass認証テーブル内のユーザー認証エントリーごとに、ユーザーが属するグループと、正常かどうかなどのデバイスの状態を示すポスチャトークンなどの情報が表示されます。

ClearPass認証テーブル内のユーザー認証エントリー

ファイアウォールのIPアドレスは、ClearPass認証テーブルエントリ内のユーザー名とそのグループに関連付けられているため、セキュリティポリシーでユーザー名またはグループ名を使用してユーザーを識別し、使用するデバイスのIPアドレスに直接依存しないようにすることができます。グループリストでは、ClearPass認証テーブル内のユーザー認証エントリーごとに、ユーザーが属するグループと、正常かどうかなどのデバイスの状態を示すポスチャトークンなどの情報が表示されます。ClearPass認証は、認証テーブルにユーザーIDと認証エントリがあるユーザーごとに最大2048セッションを管理します。

ユーザー・エントリーごとに、エントリー内のグループまたはロールの数は 200 を超えることはできません。容量に達すると、追加のロールは破棄され、次の syslog メッセージが送信されます。

CPPMは、次の形式でユーザーにユーザー情報を投稿します。デバイスはこれらの情報のすべてを使用するわけではありません。

以下は、ユーザーのClearPass認証テーブルエントリの形式と、それに続くエントリ例とそのコンポーネントの説明です。

次の例では、ユーザは human-resources-grp グループと posture-healthy グループの 2 つのグループに属しています。ファイアウォールは、ポスチャ情報を CPPM からグループ名に変換します。デバイスが posture-healthy グループ(ロール)に属している場合、すべてのユーザーにマーケティング サーバーへのアクセスを許可するセキュリティ ポリシーを設定できます。

• IP アドレス

  これは、使用するデバイスのIPアドレスです。

• ユーザーが属するドメインの名前。

  この例では、ドメイン名は「my-company-domain」です。ドメイン名が指定されていない場合は、デフォルトのドメイン名GLOBALが使用されます。

• ユーザー名

  ユーザー名は、ネットワークへの接続に使用されるユーザーのログイン名で、この例では linです。

  この名前は、使用するデバイスに関係なく一定です。

  source-identity タプルが、使用されるデバイスの IP アドレスではなく、ユーザ名またはグループ名でトラフィックの送信元を識別するセキュリティ ポリシーを設定すると、セキュリティ ポリシーがデバイスに依存していないかのようになります。これは、使用するデバイスに関係なく、ユーザーのアクティビティに適用されます。

• ユーザーが属する 1 つ以上のグループ

  ここで、 利害関係 グループの概念とセキュリティポリシーとの関係が関係してきます。対象グループは、セキュリティ ポリシーで参照されるグループです。関心のあるグループの概念については、このトピックの後半で説明します。

ユーザーが複数のデバイスを使用してネットワークに接続している場合、そのユーザーに対して複数の IP ユーザー マッピングが存在する可能性があることに注意してください。各マッピングには、ユーザー名と IP アドレスとともに、独自の値のセット(ドメイン名とグループリスト)があります。

例えば、3 つの別々のデバイスを使用してネットワークに接続しているユーザー abe には、以下の 3 つの IP アドレスからユーザー名へのマッピングが存在する可能性があります。

ファイアウォールが 110.208.132.23, abe のログアウト メッセージを受信したとします。以下の部分的なユーザー認証エントリーは、ユーザー abe が 2 つのデバイスのみを使用してネットワークにログインしていることを示しています。

2048 を超えるセッションが ClearPass 認証テーブル内の 1 つの認証エントリに関連付けられている場合、ClearPass の Active Directory はオーバーフローの原因となったセッションを管理しません。その結果、これらのセッションのセッション終了ログに報告されるセッションのユーザー識別情報はありません。

Aruba ClearPassのタイムアウト設定とは何ですか?

Aruba ClearPass認証テーブルの認証エントリーには、エントリーの有効期限が切れるまでのタイムアウト値が含まれています。無効なエントリーに固有のタイムアウト設定を構成することで、認証テーブル内の無効なユーザー認証エントリーが、ユーザーを検証する前に期限切れになるのを防ぐことができます。無効な認証エントリのタイムアウト設定は、有効なエントリに適用される一般的な認証エントリのタイムアウト設定とは別のものです。

ClearPass機能では、認証されていないユーザーがネットワークに参加しようとして、ユーザーのデバイスのIPアドレスが見つからない(つまり、パケット転送エンジンにない場合)は、デバイスはAruba ClearPassにユーザーの情報を照会します。クエリが失敗した場合、システムはユーザーに対して無効な認証エントリを生成します。無効なタイムアウト設定の値を構成すると、そのタイムアウトがエントリに適用されます。無効なエントリのタイムアウトを設定しない場合、デフォルトのタイムアウトである30分が新しいエントリに適用されます。無効なエントリのタイムアウトは、状態が valid または pending から INVALID に変更されたエントリにも適用されます。

Aruba ClearPassのタイムアウト設定の仕組み

次のコマンドを使用して、ClearPass認証テーブルのエントリに無効な認証エントリのタイムアウトを設定します。ここでは、ClearPass認証テーブル内の無効な認証エントリは、作成されてから22分後に有効期限が切れます。

• ClearPass の無効な認証エントリのタイムアウト値を最初に設定すると、設定 後に 生成された無効な認証エントリに適用されます。ただし、既存の無効な認証エントリーはすべて、デフォルトのタイムアウトである 30 分を保持します。

• 無効な認証エントリーのタイムアウト設定を構成しない場合、デフォルトのタイムアウトである 30 分がすべての無効な認証エントリーに適用されます。

  無効な認証エントリのタイムアウト設定を行い、後で削除した場合、削除後に生成される新しい無効な認証エントリにデフォルト値が適用されます。ただし、設定された値が以前に適用された既存の無効な認証エントリーは、その値を保持します。

• 無効な認証エントリーのタイムアウト値の設定を変更すると、値の変更 後に 作成されたすべての無効な認証エントリーに新しい値が適用されます。ただし、既存の無効な認証エントリーはすべて、以前の無効な認証エントリーのタイムアウト設定が適用されたままになります。デフォルト値の 30 分が以前に適用されていたエントリは、その設定を保持します。

• エントリの保留中または有効な状態が無効に変更されると、無効な認証エントリのタイムアウト設定が適用されます。

  無効な認証エントリの状態が保留中または有効に変更されると、無効な認証エントリのタイムアウト設定は適用されなくなります。共通認証エントリーのタイムアウトに設定されたタイムアウト値が適用されます。

  表 7: ClearPass認証テーブル内の無効なエントリに対する無効な認証タイムアウト

  無効な入力タイムアウト設定	初期無効な入力タイムアウト設定	経過時間	新しい無効な入力タイムアウトの構成設定	既存の無効な入力の最終タイムアウト設定
  新しい無効な認証エントリ			50	50
  既存の無効なエントリのタイムアウト	20	5	50	15
  既存の無効なエントリのタイムアウト	0	40	20	0
  既存の無効なエントリのタイムアウト	40	20	0	20