Cisco Identity Service Engine のアップグレードの概要
このマニュアルでは、Cisco ISE アプライアンスおよび仮想マシンで Cisco Identity Services Engine(ISE)ソフトウェアをリリース 2.4 にアップグレードする方法について説明します。
Cisco ISE 展開環境のアップグレードは複数段階のプロセスであり、このマニュアルで指定されている順序で実行する必要があります。このマニュアルで示されている推定所要時間を使用して、最小限のダウンタイムでのアップグレードを計画してください。展開環境に含まれる複数のポリシー サービス ノード(PSN)が 1 つの PSN グループに属している場合、ダウンタイムは発生しません。アップグレード対象の PSN で認証されるエンドポイントが存在する場合、要求はノード グループ内の別の PSN で処理されます。エンドポイントは、認証の成功後に再認証されて、ネットワーク アクセス権が付与されます。
(注) |
スタンドアロン展開環境または単一の PSN のみの展開環境の場合は、その PSN がアップグレードされている間、すべての認証にダウンタイムが発生する可能性があります。 |
次のリリースはすべて、リリース 2.4 に直接アップグレードできます。
-
Cisco ISE、リリース 2.0
-
Cisco ISE、リリース 2.0.1
-
Cisco ISE、リリース 2.1
-
Cisco ISE、リリース 2.2
-
Cisco ISE、リリース 2.3
(注) |
Cisco ISE リリース 2.3 以降では、すべての既存のネットワーク アクセス ポリシーとポリシー セットを置き換える、新しい拡張された [ポリシーセット(Policy Sets)] ページが用意されています。以前のリリースからリリース 2.3 以降にアップグレードすると、すべてのネットワーク アクセス ポリシーの設定(認証および認可の条件、ルール、ポリシー、プロファイル、および例外を含む)が Cisco ISE GUI の新しい [ポリシーセット(Policy Sets)] ウィンドウに移行されます。変更の詳細については、新規ポリシー モデル を参照してください。 |
Cisco ISE リリース 2.0 より前のバージョンの場合は、はじめに上記のリリースのいずれかにアップグレードしてから、リリース 2.4 にアップグレードする必要があります。
アップグレード バンドルは Cisco.com からダウンロードすることができます。リリース 2.4 では、次のアップグレード バンドルを使用できます。
ise-upgradebundle-2.x-to-2.4.0.xxx.SPA.x86_64.tar.gz:リリース 2.0、2.0.1、2.1、2.2 または 2.3 から 2.4 にアップグレードするには、このバンドルを使用します
Cisco ISE のこのリリースでは、GUI ベースおよび CLI ベース両方のアップグレードに対応しています。
(注) |
管理者用ポータルからの GUI ベースのアップグレードは、現在リリース 2.0 以降で、2.4 にアップグレードする場合にのみサポートされます。詳細については、GUI からの Cisco ISE 展開のアップグレードを参照してください。 |
Cisco ISE の CLI からは、リリース 2.0、2.0.1、2.1、または 2.2 からリリース 2.4 に直接アップグレードできます。詳細については、CLI からの Cisco ISE 展開のアップグレードを参照してください。
GUI または CLI を使用してアップグレードするかどうかに関係なく、最小のダウンタイムで、最大の復元力とロールバックの機能を提供しながら、展開環境をアップグレードするには、次の順序でアップグレードを実行することをお勧めします。
-
すべての設定およびモニタリングデータ。必要に応じて、手動で簡単にロールバックできるように、アップグレードを開始する前にこのタスクを実行する必要があります。
-
セカンダリ管理ノード
(注)
この時点では、プライマリ管理ノードは以前のバージョンのままで、アップグレードに失敗した場合はロールバックに使用できます。
-
プライマリ モニタリング ノード
-
ポリシー サービス ノード
ポリシー サービス ノードのセットをアップグレードした後、アップグレードが成功したかどうかを確認し(アップグレード プロセスの確認を参照)、ネットワーク テストを実行して新しい展開環境が期待どおりに機能していることを確認します。アップグレードが成功した場合は、ポリシー サービス ノードの次のセットをアップグレードできます。
-
セカンダリ モニタリング ノード
-
プライマリ管理ノード
(注)
プライマリ管理ノードをアップグレードした後、アップグレードの検証テストとネットワーク テストを再実行します。
アップグレード後、セカンダリ管理ノードはプライマリ管理ノードになり、元のプライマリ管理ノードはセカンダリ管理ノードになります。必要に応じて、[ノードの編集(Edit Node)] ウィンドウで [プライマリに昇格(Promote to Primary)] をクリックして、セカンダリ管理ノードを昇格してプライマリ管理ノードにします(古い展開環境と一致させます)。
アップグレード プロセスの種類
アップグレードの技術上の専門知識とアップグレードに割くことのできる時間に応じて、以下のアップグレード プロセスから選択できます。
- GUI からの Cisco ISE 展開環境のアップグレード
- バックアップと復元の手順を使用した Cisco ISE のアップグレード(推奨)
- CLI からの Cisco ISE 展開環境のアップグレード
一般に、Cisco ISE のアップグレードに RHEL(Red Hat Enterprise Linux)OS(Red Hat の後継バージョン)のアップグレードが含まれている場合は、ISE インスタンスあたりのアップグレード所要時間が長くなります。さらに、ISE の Oracle データベース バージョンに変更がある場合は、OS のアップグレード時に新しい Oracle パッケージがインストールされます。このためアップグレードに時間がかかる場合があります。アップグレードの時間を最小限にするには、ISE のアップグレード中に基盤となる OS がアップグレードされるかどうかを確認する必要があります。
次の表に、Cisco ISE のアップグレード時に OS のアップグレードが発生するかどうかを示します。表中の○は、ISE のアップグレード中に基盤となる OS のアップグレードが発生することを、×は ISE のアップグレード中に OS のアップグレードが発生しないことを示します。ISE アップグレードに OS アップグレードが伴うかどうかは、 シスコの ISE ソフトウェア ダウンロード センターのアップグレード バンドルのサイズから簡単にわかります。
アップグレード元 |
ISE 1.3 へのアップグレード |
ISE 1.4 へのアップグレード |
ISE 2.0 へのアップグレード |
ISE 2.0.1 へのアップグレード |
ISE 2.1 へのアップグレード |
ISE 2.2 へのアップグレード |
ISE 2.3 へのアップグレード |
ISE 2.4 へのアップグレード |
リリース 2.6 へのアップグレード |
---|---|---|---|---|---|---|---|---|---|
ISE 1.3 |
該当なし |
なし |
なし |
あり |
あり |
該当なし |
該当なし |
該当なし |
該当なし |
ISE 1.4 |
該当なし |
該当なし |
なし |
あり |
あり |
あり |
あり |
該当なし |
該当なし |
ISE 2.0 |
該当なし |
該当なし |
該当なし |
該当なし |
あり |
あり |
あり |
あり |
あり |
ISE 2.0.1 |
該当なし |
該当なし |
該当なし |
該当なし |
あり |
あり |
あり |
あり |
あり |
ISE 2.0 |
該当なし |
該当なし |
該当なし |
該当なし |
該当なし |
なし |
あり |
あり |
あり |
ISE 2.1 |
該当なし |
該当なし |
該当なし |
該当なし |
該当なし |
該当なし |
該当なし |
あり |
あり |
ISE 2.2 |
該当なし |
該当なし |
該当なし |
該当なし |
該当なし |
該当なし |
該当なし |
あり |
あり |
ISE 2.3 |
該当なし |
該当なし |
該当なし |
該当なし |
該当なし |
該当なし |
該当なし |
あり |
あり |
ISE 2.4 |
該当なし |
該当なし |
該当なし |
該当なし |
該当なし |
該当なし |
該当なし |
あり |
あり |
ライセンスの変更
デバイス管理ライセンス
Cisco ISE 2.3 以前のバージョンでは、展開でのデバイス管理ノードの数にかかわらず、展開ごとに Device Administration 永久ライセンスが必要です。Cisco ISE 2.4 以降、デバイス管理ライセンスの数は、展開環境のデバイス管理ノード(デバイス管理サービス用に設定された PSN)の数と同じである必要があります。
現在、デバイス管理ライセンスを使用していてリリース 2.4 以降へのアップグレードを計画している場合、TACACS+ 機能はリリース 2.4 以降で 50 デバイス管理ノードに対しサポートされます。
新しい PID から生成された PAK をインストールすると、PAK ファイルで利用可能な数量に応じて Device Administration ライセンス数が表示されます。必要なデバイス管理ノード数に基づいて、展開に複数のデバイス管理ライセンスを追加できます。評価ライセンスでは、1 つのデバイス管理ノードをサポートします。
VM ノードのライセンス
Cisco ISE は、仮想アプライアンスとしても販売されています。リリース 2.4 以降では、展開に VM ノードの適切な VM ライセンスをインストールすることをお勧めします。VM ノードの数と CPU やメモリなどの各 VM ノードのリソースに基づいて、VM ライセンスをインストールする必要があります。そうでない場合、リリース 2.4 以降で VM ライセンス キーを調達してインストールする警告と通知が表示されますが、サービスは中断されません。
VM ライセンスは、小、中、大の 3 つのカテゴリで提供されます。たとえば、8 コアと 64 GB RAM を搭載した 3595 相当の VM ノードを使用している場合に、その VM で同じ機能をレプリケートするには、中カテゴリの VM ライセンスが必要になります。展開の要件に応じて、VM とそのリソースの数に基づいて、複数の VM ライセンスをインストールできます。
VM ライセンスは、インフラストラクチャ ライセンスなので、展開で使用可能なエンドポイント ライセンスに関係なく VM ライセンスをインストールできます。展開に評価、Base、Plus、Apex ライセンスのどれもインストールされていない場合でも、VM ライセンスをインストールできます。ただし、Base、Plus、または Apex ライセンスによって有効になる機能を使用するには、適切なライセンスをインストールする必要があります。
リリース 2.4 以降のインストールまたはアップグレードの後、展開済みの VM ノードの数とインストール済みの VM ライセンスの数の間に不一致がある場合、アラームが 14 日ごとに [アラーム(Alarms)] ダッシュレットに表示されます。アラームは、VM ノードのリソースに変化がある場合や、VM ノードが登録または登録解除されるたびにも表示されます。
VM ライセンスは永続ライセンスです。VM ライセンスの変更は、Cisco ISE GUI にログインするたびに表示され、通知ポップアップで [このメッセージを再度表示しない(Do not show this message again)] チェックボックスをオンにすると表示されなくなります。
以前に ISE VM ライセンスのいずれも購入していない場合は、『ISE Ordering Guide』を参照して購入する適切な VM ライセンスを選択します。製品認証キー(PAK)が関連付けられていない ISE VM ライセンスを購入済みの場合、licensing@cisco.com で ISE VM 購入を反映する販売注文番号を使用して VM PAK を要求することができます。この要求は、過去に購入した ISE VM ごとに 1 つの中規模 VM ライセンス キーを提供するように処理されます。
次の表は、VM 最小リソースをカテゴリ別に示しています。
VM カテゴリ |
RAM の範囲 |
CPU の数 |
---|---|---|
小 |
16 GB |
12 個の CPU |
中 |
64 GB |
16 個の CPU |
大 |
256 GB |
16 個の CPU |
ライセンスの詳細については、『Cisco Identity Services Engine Administrator Guide』の「Cisco ISE Licenses」の章を参照してください。
新規ポリシー モデル
認証、認可、例外を含め、すべてのネットワーク アクセス ポリシーおよびポリシー セットは、Cisco ISE 2.3 以降では [ポリシーセット(Policy Sets)] ウィンドウの下に統合されます。各ポリシー セットは、ポリシー階層の最上位レベルで定義されたコンテナであり、その下にそのセットのすべての関連する認証および認可ポリシーおよびポリシー例外ルールが設定されます。
条件に基づいて、認証と認可の両方に複数のルールを定義できます。また、条件とその他の関連設定に簡単にアクセスして、新しいポリシー セット インターフェイスから直接再利用できるようになりました。ポリシー セットの照合順序は、新しい [ポリシーセット(Policy Set)] インタフェイスに表示される順序によって決まります。チェックは、ポリシーセット テーブルの最初の行から開始され、一致が見つかるまで続きます。一致するものが見つからない場合は、システムのデフォルト ポリシー セットが使用されます。同じ論理を使用して正しい認証ルールの照合と選択が行われ、次に正しい認可ルールの照合と選択が行われます。各ポリシーセット テーブルの先頭からチェックが開始され、一致が見つかるまで各ルールがチェックされます。一致する他のルールがない場合は、デフォルト ルールが使用されます。
新しいポリシー モデルは、古いユーザ インターフェイスを使用して以前のバージョンで追加された可能性のあるすべてのポリシーを表しますが、ネットワーク アクセスを論理的に管理できる大幅に簡素化された改良済みのインターフェイスが提供されます。
スタンドアロンの認証および許可ポリシーの変更
スタンドアロンの認証ルールを使用する場合、ISE 2.2 以前のバージョンのルールは新しいポリシー モデルに変換されます。認証ルールに割り当てられている許可されたプロトコルに基づいて、2 つの個別のシナリオがあります。
-
システム内のすべての「外部パート」に、デフォルト パートを含む同じ許可されたプロトコルが割り当てられている場合、すべての元の認証ルールは次のように変換されます。
すべての「外部パート」は、新しいポリシー モデルの単一のポリシー セットに変換されます。新しいポリシー セットはデフォルトと呼ばれ、ポリシー セット レベルでは条件が定義されず、統一された許可プロトコルが割り当てられます。すべての内部パートは、新しいデフォルト ポリシー セット内の認証ポリシーの一部としてルールに変換されます。
次の表に、同じ許可プロトコルを使用する古いスタンドアロン認証ルールのセットの変換を示します(シナリオ 1)。この表では、各行の形式は次のとおりです。
名前(条件/結果)
たとえば認証外部パート 1(外部条件/許可されるプロトコル A)の場合:
-
名前:認証外部パート 1
-
条件:外部条件
-
結果:許可されるプロトコル A
表 2. 同じ許可されたプロトコルを使用したスタンドアロン認証ポリシー Cisco ISE 2.3 より前:デフォルト認証
Cisco ISE 2.3 以降へのアップグレード後:ポリシー セット
-
認証外部パート 1(外部条件 1/許可されるプロトコル A)
-
認証内部パート 1.1(内部条件 1.1/ID ストア A)
-
認証内部パート 1.2(内部条件 1.2/ID ストア A)
-
認証内部パート 1.3(内部条件 1.3/ID ストア A)
-
認証内部 1 デフォルト(条件なし/ID ストア B)
-
-
認証外部パート 2(外部条件 2/許可されるプロトコル A)
-
認証内部パート 2.1(内部条件 2.1/ID ストア A)
-
認証内部パート 2.2(内部条件 2.2/ID ストア A)
-
認証内部パート 2.3(内部条件 2.3/ID ストア A)
-
認証内部 2 デフォルト(条件なし/ID ストア B)
-
-
認証外部パート 3(外部条件 3/許可されるプロトコル A)
-
認証内部 3 デフォルト(条件なし/ID ストア B)
-
-
デフォルト認証外部パート(条件なし/許可されるプロトコル A/デフォルト ID ストア)
-
例外 1
-
許可ルール 1
-
許可ルール 2
-
デフォルト(条件なし/許可されるプロトコル A)
-
認証ポリシー(コンテナ)
-
認証外部パート 1:認証内部パート 1.1(外部条件 1 + 内部条件 1.1/ID ストア A)
-
認証外部パート 1:認証内部パート 1.2(外部条件 1 + 内部条件 1.2/ID ストア A)
-
認証外部パート 1:認証内部パート 1.3(外部条件 1 + 内部条件 1.3/ID ストア A)
-
認証外部パート 1:認証内部 1 デフォルト(外部条件 1/ID ストア B)
-
認証外部パート 2:認証内部パート 2.1(外部条件 2 + 内部条件 2.1/ID ストア A)
-
認証外部パート 2:認証内部パート 2.2(外部条件 2 + 内部条件 2.2/ID ストア A)
-
認証外部パート 2:認証内部パート 2.3(外部条件 2 + 内部条件 2.3/ID ストア A)
-
認証外部パート 2:認証内部 2 デフォルト(外部条件 2/ID ストア B)
-
認証外部パート 3:認証内部 3 デフォルト(外部条件 3/ID ストア B)
-
デフォルト認証外部パート(条件なし/デフォルト ID ストア)
-
-
例外 1
-
許可ポリシー(コンテナ)
-
許可ルール 1
-
許可ルール 2
-
-
-
-
システム内の「外部パート」の少なくとも 1 つに、デフォルト パートなどの他の部分とは異なる許可されたプロトコルが割り当てられている場合、すべての元の認証ルールは次のように変換されます。
各「外部パート」は、新しいポリシー モデルの個別のポリシー セットに変換されます。新しいポリシー セットは、その特定の新しいセットの元の外部パートの名前に基づいて名前が付けられます。各ポリシー セットのポリシー セット レベルでは、元の外部パートの条件と許可プロトコルが割り当てられます。各外部パートのすべての内部パートは、新しいポリシー セット内の認証ポリシーの一部として 1 対 1 で認証ルールに変換されます。
次の表に、異なる許可プロトコルを使用する古いスタンドアロン認証ルールのセットの変換を示します(シナリオ 2)。この表では、各行の形式は次のとおりです。
名前(条件/結果)
たとえば認証外部パート 1(外部条件/許可されるプロトコル A)の場合:
-
名前:認証外部パート 1
-
条件:外部条件
-
結果:許可されるプロトコル A
表 3. 異なる許可されたプロトコルを使用したスタンドアロン認証ポリシー Cisco ISE 2.3 より前:デフォルト認証
Cisco ISE 2.3 以降へのアップグレード後:ポリシー セット
-
認証外部パート 1(外部条件 1/許可されるプロトコル A)
-
認証内部パート 1.1(内部条件 1.1/ID ストア A)
-
認証内部パート 1.2(内部条件 1.2/ID ストア A)
-
認証内部パート 1.3(内部条件 1.3/ID ストア A)
-
認証内部 1 デフォルト(条件なし/ID ストア B)
-
-
認証外部パート 2(外部条件 2/許可されるプロトコル B)
-
認証内部パート 2.1(内部条件 2.1/ID ストア A)
-
認証内部パート 2.2(内部条件 2.2/ID ストア A)
-
認証内部パート 2.3(内部条件 2.3/ID ストア A)
-
認証内部 2 デフォルト(条件なし/ID ストア B)
-
-
認証外部パート 3(外部条件 3/許可されるプロトコル C)
-
認証内部 3 デフォルト(条件なし/ID ストア B)
-
-
デフォルト認証外部パート(条件なし/許可されるプロトコル A/ID ストア C)
-
例外 1
-
許可ルール 1
-
許可ルール 2
-
デフォルト認証外部パート 1(外部条件 1/許可されるプロトコル A)
-
認証ポリシー(コンテナ)
-
認証内部パート 1.1(内部条件 1.1/ID ストア A)
-
認証内部パート 1.2(内部条件 1.2/ID ストア A)
-
認証内部パート 1.3(内部条件 1.3/ID ストア A)
-
認証内部 1 デフォルト(条件なし/ID ストア B)
-
-
例外 1
-
許可ポリシー(コンテナ)
-
許可ルール 1
-
許可ルール 2
-
-
-
デフォルト認証外部パート 2(外部条件 2/許可されるプロトコル B)
-
認証ポリシー(コンテナ)
-
認証内部パート 2.1(内部条件 2.1/ID ストア A)
-
認証内部パート 2.2(内部条件 2.2/ID ストア A)
-
認証内部パート 2.3(内部条件 2.3/ID ストア A)
-
認証内部 2 デフォルト(条件なし/ID ストア B)
-
-
例外 1
-
許可ポリシー(コンテナ)
-
許可ルール 1
-
許可ルール 2
-
-
-
デフォルト認証外部パート 3(外部条件 3/許可されるプロトコル C)
-
認証ポリシー(コンテナ)
-
認証内部 3 デフォルト(条件なし/ID ストア B)
-
-
例外 1
-
許可ポリシー(コンテナ)
-
許可ルール 1
-
許可ルール 2
-
-
-
デフォルト(条件なし/許可されるプロトコル A)
-
認証ポリシー(コンテナ)
-
デフォルト認証ルール(条件なし/ID ストア C)
-
-
例外 1
-
許可ポリシー(コンテナ)
-
許可ルール 1
-
許可ルール 2
-
-
-
ポリシー セットの変更
以前のバージョンから ISE 2.3 以降にアップグレードする場合、表示される新しいポリシー セットはここで説明する古い ISE バージョンの場合とは異なりますが、動作は同じままです。
次の図は、Cisco ISE 2.3 以降へのアップグレード後のポリシー セットの変更を示しています。
ISE 2.2 以前のバージョンのポリシーは、新しいポリシー モデルに変換されます。認証ルールに割り当てられている許可されたプロトコルに基づいて、2 つの個別のシナリオがあります。
-
単一のポリシー セット内のすべての「外部パート」に同じ許可されたプロトコルが割り当てられている場合、元のポリシー セットはすべて次のように変換されます。
-
すべての「外部パート」は、新しいポリシー モデルの単一のポリシー セットに変換されます。新しいポリシー セットは、元のポリシー セットと同じ名前になります。たとえば、古いモデルでポリシー セットの名前が「全従業員」になっている場合、新しいモデルでも「全従業員」と呼ばれます。
次の表に、同じ許可プロトコルを使用する認証ルールを含む古いポリシー セットの変換を示します(シナリオ 1)。この表では、各行の形式は次のとおりです。
名前(条件/結果)
たとえば認証外部パート 1(外部条件/許可されるプロトコル A)の場合:
-
名前:認証外部パート 1
-
条件:外部条件
-
結果:許可されるプロトコル A
表 4. 同じ許可されたプロトコルを使用したポリシー セットの変換 Cisco ISE 2.2 以前からの古いポリシー セット
Cisco ISE 2.3 以降へのアップグレード後の新しいポリシー セット
-
ポリシー セット A(条件 A/結果なし)
-
認証外部パート 1(外部条件 1/許可されるプロトコル A)
-
認証内部パート 1.1(内部条件 1.1/ID ストア A)
-
認証内部パート 1.2(内部条件 1.2/ID ストア A)
-
認証内部パート 1.3(内部条件 1.3/ID ストア A)
-
認証内部 1 デフォルト(条件なし/ID ストア B)
-
-
認証外部パート 2(外部条件 2/許可されるプロトコル A)
-
認証内部パート 2.1(内部条件 2.1/ID ストア A)
-
認証内部パート 2.2(内部条件 2.2/ID ストア A)
-
認証内部パート 2.3(内部条件 2.3/ID ストア A)
-
認証内部 2 デフォルト(条件なし/ID ストア B)
-
-
認証外部パート 3(外部条件 3/許可されるプロトコル A)
-
認証内部 3 デフォルト(条件なし/ID ストア B)
-
-
デフォルト認証外部パート(条件なし/許可されるプロトコル A/ID ストア C)
-
例外 1
-
許可ルール 1
-
許可ルール 2
-
-
ポリシー セット A(条件 A/許可されるプロトコル A)
-
認証ポリシー(コンテナ)
-
認証外部パート 1:認証内部パート 1.1(外部条件 1 + 内部条件 1.1/ID ストア A)
-
認証外部パート 1:認証内部パート 1.2(外部条件 1 + 内部条件 1.2/ID ストア A)
-
認証外部パート 1:認証内部パート 1.3(外部条件 1 + 内部条件 1.3/ID ストア A)
-
認証外部パート 1:認証内部 1 デフォルト(外部条件 1/ID ストア B)
-
認証外部パート 2:認証内部パート 2.1(外部条件 2 + 内部条件 2.1/ID ストア A)
-
認証外部パート 2:認証内部パート 2.2(外部条件 2 + 内部条件 2.2/ID ストア A)
-
認証外部パート 2:認証内部パート 2.3(外部条件 2 + 内部条件 2.3/ID ストア A)
-
認証外部パート 2:認証内部 2 デフォルト(外部条件 2/ID ストア B)
-
認証外部パート 3:認証内部 3 デフォルト(外部条件 3/ID ストア B)
-
デフォルト認証外部パート(条件なし/ID ストア C)
-
-
例外 1
-
許可ポリシー(コンテナ)
-
許可ルール 1
-
許可ルール 2
-
-
-
-
新しくアップグレードされたポリシー セットには、元のポリシー セットからの外部条件と内部条件を組み合わせて変換される認証ルールのリストが含まれています。変換中に作成されるそれぞれの新しい認証ルールは、内部パートの名前を含むサフィックス付きの古い外部パートの名前に基づいて名前が付けられます。たとえば、上記の表のように、古いポリシー セットが「ポリシー セット A」と呼ばれ、その認証の「外部パート」の 1 つが外部パート 1 と呼ばれ、認証の「内部パート」の 1 つが内部パート 1 と呼ばれている場合、新しく作成された認証ルールは、ポリシー セット A 内で「外部パート 1:内部パート 1」と呼ばれます。同様に、古いポリシー セットが「全従業員」ポリシー セットと呼ばれ、その認証の「外部パート」の 1 つがロンドンと呼ばれ、認証の「内部パート」の 1 つが「有線 MAB」と呼ばれている場合、新しく作成された認証ルールは「全従業員」ポリシー セット内で「ロンドン:有線 MAB」と呼ばれます。認証ポリシーのデフォルトの外部パートは、デフォルトの認証ルールとして変換されます。システムのデフォルト ポリシー ルールは、作成または変換された他のルールに関係なく、認証テーブル全体の最後のルールとして表示され、このルールは移動または削除できません。
-
外部パートに定義された条件(それに基づいて認証ルールが照合されます)は、内部パートの条件(認証に使用される ID ストアを示す)と組み合わされます。新しい結合条件は、新しいモデルのポリシー セット内の単一の認証ルールで設定されます。ポリシー セット内の新しい個別ルールは、古いポリシー セットの個別の外部パートごとに作成されます。
-
-
ポリシー セット内の「外部パート」に対して 2 つ以上の許可プロトコルが選択されている場合、元のポリシー セットはすべて次のように変換されます。
-
古いポリシー セット内の各認証ルールの各「外部パート」は、新しいモデルで新しい個別のポリシー セットに変換されます。この新しいポリシー セットは、新しいポリシー モデルの [認証ポリシー(Authentication Policy)] セクションの下にある同じ元の「外部パート」から「条件」を配置します。
次の表に、ISE 2.2 以前のバージョンから ISE 2.3 以降への古いポリシー セットの変換を示します(シナリオ 2)。
表 5. 異なる許可されたプロトコルを使用したポリシー セットの変換 Cisco ISE 2.2 以前からの古いポリシー セット
Cisco ISE 2.3 以降へのアップグレード後の新しいポリシー セット
-
ポリシー セット A(条件 A/結果なし)
-
認証外部パート 1(外部条件 1/許可されるプロトコル A)
-
認証内部パート 1.1(内部条件 1.1/ID ストア A)
-
認証内部パート 1.2(内部条件 1.2/ID ストア A)
-
認証内部パート 1.3(内部条件 1.3/ID ストア A)
-
認証内部 1 デフォルト(条件なし/ID ストア B)
-
-
認証外部パート 2(外部条件 2/許可されるプロトコル B)
-
認証内部パート 2.1(内部条件 2.1/ID ストア A)
-
認証内部パート 2.2(内部条件 2.2/ID ストア A)
-
認証内部パート 2.3(内部条件 2.3/ID ストア A)
-
認証内部 2 デフォルト(条件なし/ID ストア B)
-
-
認証外部パート 3(外部条件 3/許可されるプロトコル C)
-
認証内部 3 デフォルト(条件なし/ID ストア B)
-
-
デフォルト認証外部パート(条件なし/許可されるプロトコル A/ID ストア C)
-
例外 1
-
許可ルール 1
-
許可ルール 2
-
-
ポリシー セット A:認証外部パート 1(条件 A + 外部条件 1/許可されるプロトコル A)
-
認証ポリシー(コンテナ)
-
認証内部パート 1.1(内部条件 1.1/ID ストア A)
-
認証内部パート 1.2(内部条件 1.2/ID ストア A)
-
認証内部パート 1.3(内部条件 1.3/ID ストア A)
-
認証内部 1 デフォルト(条件なし/ID ストア B)
-
-
例外 1
-
許可ポリシー(コンテナ)
-
許可ルール 1
-
許可ルール 2
-
-
-
ポリシー セット A:認証外部パート 2(条件 A + 外部条件 2/許可されるプロトコル B)
-
認証ポリシー(コンテナ)
-
認証内部パート 2.1(内部条件 2.1/ID ストア A)
-
認証内部パート 2.2(内部条件 2.2/ID ストア A)
-
認証内部パート 2.3(内部条件 2.3/ID ストア A)
-
認証内部 2 デフォルト(条件なし/ID ストア B)
-
-
例外 1
-
許可ポリシー(コンテナ)
-
許可ルール 1
-
許可ルール 2
-
-
-
ポリシー セット A:デフォルト認証外部パート 3(条件 A + 外部条件 3/許可されるプロトコル C)
-
認証ポリシー(コンテナ)
-
認証内部 3 デフォルト(条件なし/ID ストア B)
-
-
例外 1
-
許可ポリシー(コンテナ)
-
許可ルール 1
-
許可ルール 2
-
-
-
ポリシー セット A:デフォルト(条件 A/許可されるプロトコル A)
-
認証ポリシー(コンテナ)
-
デフォルト認証ルール(条件なし/ID ストア C)
-
-
例外 1
-
許可ポリシー(コンテナ)
-
許可ルール 1
-
許可ルール 2
-
-
-
-
変換時に作成される新しいポリシー セットは、外部パート名を含むサフィックスを使用して抽出された古いポリシー セットの名前に基づいて名前が付けられます。たとえば、上記の表のように、古いポリシー セットが「ポリシー セット A」と呼ばれ、その認証の「外部パート」の 1 つが外部パート 1 と呼ばれている場合、新しく作成されたポリシー セットは「ポリシー セット A:外部パート 1」と呼ばれます。同じように、古いポリシー セットが「ロンドン」と呼ばれ、その認証の「外部パート」の 1 つが有線 MAB と呼ばれている場合、新しく作成されたポリシー セットは「ロンドン:有線 MAB」と呼ばれます。
古い各ポリシー セットのデフォルトの外部パートも、「ロンドン:デフォルト」などのように、他のすべての外部パートと同様に新しいポリシー セットに変換されます。システム デフォルト ポリシー セットは、作成または変換された他のポリシー セットに関係なく、テーブル全体の最後のポリシー セットとして表示され、移動または削除できません。
-
古いポリシー セットの最上位レベルで定義された条件は、許可された正しいプロトコルを選択するように設計された外部認証パート条件と組み合わされます。新しい結合条件は、新しいモデルの新しいポリシー セットごとに最上位レベルのルールで構成されます。古い各ポリシー セットの各外部パートごとに新しい個別のポリシー セットが作成されます。
-
許可ルール/例外の変更
グローバル例外とローカル例外に加えて、認可ルールもポリシー セット内から管理できるようになりました。古いポリシー セット内のすべての認可ルールおよび例外は、認証ポリシー ルールの変換の結果として生じるすべての新しいポリシー セットにも適用されます。許可ポリシーの変更は、外部パートに設定されている許可されたプロトコルに関係なく、アップグレードされるすべてのポリシー セットに適用されます。
ポリシー セットの評価
新しいインターフェイスでポリシー セットは、[ポリシーセット(Policy Set)] テーブルに表示される順序に従って一致の有無がチェックされます。たとえば、古い「ロンドン」ポリシー セットに、変換前にステータスが異なる 3 つの外部パートがあり、古い「ニューヨーク」セットにデフォルトの外部パートのみが含まれている場合、新しいポリシー セット インターフェイスのテーブルには新しいポリシー セットとシステムのデフォルト ポリシー セットが次の順序で表示されます。
ポリシー セット名 |
---|
ロンドン:有線 MAB |
ロンドン:ワイヤレス MAB |
ロンドン:デフォルト |
ニューヨーク:デフォルト |
デフォルト |
最初の 2 つのセットが一致しない場合、システムは「ロンドン:デフォルト」をチェックします。「ロンドン:デフォルト」が一致しない場合、システムは次に「ニューヨーク:デフォルト」をチェックします。「ニューヨーク:デフォルト」も一致しない場合、システムはポリシーとして「デフォルト」のみを使用します。
同じ論理を使用して正しい認証ルールの照合と選択が行われ、次に正しい許可ルールの照合と選択が行われます。各テーブルの先頭から開始し一致が見つかるまで各ルールがチェックされます。一致する他のルールがない場合は、デフォルト ルールが使用されます。
新しく変換されたポリシー セットのステータス
認証ルールに異なる許可されたプロトコルを使用するポリシー セットを変換する際に、新しく変換されたポリシー セットのステータスは、古いポリシー セットのステータスと古いポリシー セットの「外部パート」のステータスに基づいて次のように決定されます。
古いポリシー セットのステータス |
古いポリシー セットの「外部パート」のステータス |
新しいポリシー セットのステータス |
---|---|---|
無効 |
無効 |
無効 |
無効 |
モニタ |
無効 |
無効 |
有効 |
無効 |
モニタ |
無効 |
無効 |
モニタ |
モニタ |
モニタ |
モニタ |
有効 |
モニタ |
有効 |
無効 |
無効 |
有効 |
モニタ |
モニタ |
有効 |
有効 |
有効 |
新しく変換された認証ルールのステータス
認証ルールに同じ許可されたプロトコルを使用するポリシー セットを変換する際に、新しく変換された認証ルールのステータスは、古い認証ルールの「外部パート」のステータスと対応する古い認証ルールの「内部パート」のステータスに基づいて次のように決定されます。
古い認証ルールの「外部パート」のステータス |
対応する古い認証ルールの「内部パート」のステータス |
変換された認証ルールのステータス |
---|---|---|
無効 |
無効 |
無効 |
無効 |
モニタ |
無効 |
無効 |
有効 |
無効 |
モニタ |
無効 |
無効 |
モニタ |
モニタ |
モニタ |
モニタ |
有効 |
モニタ |
有効 |
無効 |
無効 |
有効 |
モニタ |
モニタ |
有効 |
有効 |
有効 |