Aruba ClearPass

利点

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

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

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

Aruba ClearPass with Enforcement セキュリティが必要な理由

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

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

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

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

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

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

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

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

3. ClearPassを使用した保護—強制セキュリティを備えたClearPassでは、ユーザー名または属するグループによってユーザーを識別するセキュリティポリシーを設定できるため、攻撃や侵入からユーザーを保護できます。

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

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

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

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

Aruba ClearPass with Enforcement セキュリティはどのように機能しますか?

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

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

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

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

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

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

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

ファイアウォールと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個のロールを処理できます。

  • ファイアウォールは、1 つのタイプのポスチャのみをサポートし、6 つのポスチャトークンまたは値を使用できます。個々のユーザーのID情報には、1つのポスチャトークンのみを含めることができます。

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

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

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

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

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

• 姿勢-健康(HEALTHY)

• 姿勢検査(CHECKUP)

• posture-transition(TRANSITION)

• posture-quarantine(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と連携して、攻撃と脅威のイベントログを使用して、潜在的および実際の攻撃から企業のリソースを保護します。ファイアウォールスクリーン、IDP、コンテンツセキュリティコンポーネントによって生成されるこれらのログは、企業のネットワークセキュリティを脅かす攻撃と脅威の種類を明確に特定します。

ファイアウォールは、全体的なログエントリーから脅威や攻撃イベントを報告するログをフィルタリングし、これらのログエントリーを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ユーザーまたはグループマッピングを取得します。

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

秒単位で指定された 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

関心のあるグループ

グループがセキュリティポリシーによって参照されている場合、つまりポリシーのソースIDフィールドで指定されている場合、 グループは関心のあるグループ として認定されます。ルーティングエンジン認証テーブルでは、各ユーザーエントリーには、セキュリティポリシーが存在するグループの名前を識別するポリシーリストによって参照されるグループが含まれています。ユーザーエントリに含まれるグループが現在セキュリティポリシーで使用されていない場合、このリストには含まれません。グループは、ポリシーリストで参照されているグループに出入りできます。

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

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

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

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

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

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

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

  • 送信元ID内のグループを参照している、現在設定されているセキュリティポリシーが削除されます。

  次の例を考えてみましょう。

  • 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アドレスに関連付けられたアクティブなセッションが削除されます。

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

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

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

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

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

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

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

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

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

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

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

これは、ユーザー用のClearPass認証テーブルエントリの形式であり、その後にエントリの例とそのコンポーネントの説明が続きます。

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

• IPアドレス

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

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

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

• ユーザー名

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

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

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

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

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

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

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

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

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

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

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

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

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