アイデンティティ制御ポリシーの設定

アイデンティティ制御ポリシーの設定

アイデンティティ制御ポリシーでは、指定された条件と加入者イベントに応じて Cisco Identity Based Networking Services（IBNS）で実行されるアクションを定義します。さまざまなシステムアクション、条件、およびイベントを一貫したポリシー言語を使用して組み合わせられます。このモジュールでは、Cisco IBNS のアイデンティティ制御ポリシーの設定方法について説明します。

アイデンティティ制御ポリシーに関する情報

Cisco Identity Based Networking Services の設定

関連するすべての認証コマンドを各コマンドのクラスベースポリシー言語（CPL）と同等のコマンドに変換するには、authentication convert-to new-style コマンドを使用します。このコマンドは、スイッチのレガシー設定を ID ベースのネットワーキング サービスに完全に変換します。


（注）  

この設定は元に戻せません。変換コマンド authentication display [legacy | new-style] を無効にします。

現在のコンフィギュレーション モードを表示するには、EXEC モードで authentication display config-mode コマンドを使用します。レガシーモードの場合は [Legacy]、Identity Based Networking Services コンフィギュレーション モードの場合は new-style 。 

(Device)# authentication display config-mode 
Current configuration mode is legacy

Device)# authentication display config-mode 
Current configuration mode is new-style

同時認証方式

Cisco IBNS では、IEEE 802.1x（dot1x）、MAC 認証バイパス（MAB）、および Web 認証方式を同時に実行できるため、1 つの加入者セッションに対して複数の認証方式を同時に呼び出すことができます。そのため、シリアル化に伴う遅延は発生しないため、クライアントがサポートするメソッドを可能な限り早く完了できます。

通常、ホストの承認に使用するアクセス制御方式はエンドポイントに委ねられます。たとえば、802.1x サプリカントのないプリンタは MAB のみで承認され、従業員のデスクトップは 802.1x のみで承認され、ゲストは Web 認証のみで承認されます。デフォルトの優先順位は、802.1x、MAB、Web 認証の順です。方式の優先順位が同じ場合は、セッションの認証に最初に成功した方式が優先されます。

セッションの有効期間中に複数の認証方式が成功する例としては、802.1x の認証成功が保留中の間、MAB を使用して一時的なアクセスを提供する場合があります。認証の失敗後に 802.1x が成功するように、ログイン情報の更新を許可するために、ホストに Web サーバーへの中間アクセスを許可することもできます。

設定表示モード

Identity Based Networking Services には、以前サポートされていた多くの認証コマンドやポリシーコマンドに代わる新しい Cisco IOS コマンドが導入されています。これらのコマンドは、Identity-Based Networking Services をサポートする Cisco Common Classification Policy Language （C3PL）表示モードを有効にした後でだけ使用できます。IPv6 での同時認証や Web 認証などの Identity Based Networking Services 機能は、レガシーモードではサポートされていません。

次のいずれかを実行するまで、デバイスはデフォルトのレガシー コンフィギュレーション モードになります。

  • authentication display new-style コマンドの入力：このコマンドを実行すると、C3PL 表示モードに切り替わり、レガシーのコンフィギュレーションが一時的に Identity Based Networking Services コンフィギュレーションに変換されるため、永続的に変換する前に動作を確認できます。authentication display legacy コマンドを使用して、レガシーモードに戻すことができます。「Cisco Identity Based Networking Services の表示モードの有効化」の項を参照してください。

  • Identity Based Networking Services コンフィギュレーション コマンドの入力：最初の明示的な Identity Based Networking Services コマンドを入力すると、コンフィギュレーションは永続的に C3PL 表示モードに変換され、レガシーコマンドは抑制されます。authentication display コマンドは無効になり、レガシー コンフィギュレーション モードには戻れなくなります。

Cisco Identity Based Networking Services の制御ポリシー

制御ポリシーでは、さまざまな加入者のライフサイクルイベントの処理を定義します。セッションの開始やセッションの失敗などのさまざまなイベントに対して、制御ポリシーでアクションを指定できます。各アクションは、さまざまな一致基準に基づき、さまざまな加入者に対して条件付きで実行できます。制御ポリシーはインターフェイスでアクティブ化され、一般に加入者アイデンティティの認証およびセッションでのサービスのアクティブ化を制御します。たとえば、特定の加入者を認証してから、特定のサービスへのアクセスをその加入者に提供するように制御ポリシーを設定できます。

制御ポリシーは、1 つ以上の制御ポリシールールと、ポリシールールの評価方法を制御する決定戦略で構成されます。制御ポリシールールは、制御クラス（Flexible Condition 句）、条件が評価されるイベント、および 1 つ以上のアクションで構成されます。アクションは、authenticate や activate などの一般的なシステム機能です。イベントでトリガーされる特定のアクションを定義します。一部のイベントにはデフォルトのアクションがあります。

以下の図は、加入者のライフサイクルに適用可能だと見なされるイベントのリストが各制御ポリシーにどのように含まれているかを示しています。各イベントタイプ内には、加入者アイデンティティの一致基準が異なる制御クラスのリストがあり、各クラスの下に実行されるアクションのリストがあります。

図 1. 制御ポリシーの構造
制御ポリシーの構造

制御ポリシーの設定の概要

制御ポリシーは、イベント、条件、およびアクションの観点からシステムの機能を表します。制御ポリシーの定義には以下の 3 つの手順があります。

  1. 1 つまたは複数の制御クラスの作成：制御クラスでは、制御ポリシーをアクティブ化するために満たす必要がある条件を指定します。制御クラスには複数の条件を含めることができ、各条件は true または false の評価を行います。一致ディレクティブでは、クラスが true と評価されるために、個々の条件のすべてまたはいずれかが true と評価される必要があるか、あるいはいずれも評価される必要がないかを指定します。または、条件を含まず、常に true と評価されるデフォルトの制御クラスを指定できます。

  2. 制御ポリシーを作成します。制御ポリシーには 1 つ以上の制御ポリシールールが含まれます。制御ポリシールールは、制御クラス、クラスを評価することになるイベント、および 1 つ以上のアクションで構成されます。アクションに番号が付けられ、順に実行されます。

  3. 制御ポリシーの適用：制御ポリシーは、インターフェイスに適用することでアクティブになります。

Cisco Identity Based Networking Services のパラメータマップ

パラメータマップを使用すると、制御ポリシーで指定されたアクションの動作を制御するパラメータを指定できます。Cisco IBNS の場合、authenticate using webauth コマンドで指定されたアクションに使用されるパラメータを認証パラメータマップで定義します。次のタイプのパラメータマップを設定できます。

  • 認証バイパス（非応答ホスト（NRH）認証とも呼ばれます）。

  • 同意

  • Web 認証

  • 同意付きの Web 認証

パラメータマップの設定は任意です。名前付きパラメータマップを設定しない場合、グローバルパラメータマップで指定されているデフォルトのパラメータがソフトウェアで使用されます。

複数の方式に対応するユーザーごとの非アクティブ状態の処理

一般的な非アクティブエージング機能により、RADIUS 属性 28（Idle-Timeout）および属性 29（Termination-Action）のサポートが Web 認証セッションにも拡張されるため、802.1x、MAC 認証バイパス（MAB）、および Web 認証を含むすべての認証方式で一貫した非アクティブ状態の処理が可能となります。AAA サーバーは、ユーザー認可の一環としてこれらの属性を送信します。セッションが属性 28 で指定された時間だけアイドル状態になっているか、属性 29 で設定されたタイムアウトに達した場合、そのセッションは終了します。

また、ローカルに定義されたサービステンプレートを介して、非アクティブタイムアウトと絶対タイムアウトをセッションに適用できます。非アクティブタイムアウトを有効にする場合、セッションが終了する前に送信される Address Resolution Protocol（ARP）プローブも有効にできます。

アイデンティティ制御ポリシーの設定方法

Cisco Identity Based Networking Services の表示モードの有効化

Cisco IBNS 機能は、Cisco Common Classification Policy Language（C3PL）表示モードで設定します。レガシーの認証マネージャモードはデフォルトで有効になっています。次の手順を実行して、C3PL 表示モードに切り替え、レガシーのコンフィギュレーション コマンドを C3PL の同等のコマンドに一時的に変換できます。一時的に変換することで、変換を永続的にする前に、レガシーの設定を Identity Based Networking Services の設定としてプレビューできます。明示的な Cisco IBNS コマンドを入力すると、変換は永続的になり、レガシーモードには戻せなくなります。

手順

  コマンドまたはアクション 目的

ステップ 1

enable

例:

Device> enable

特権 EXEC モードを有効にします。

  • パスワードを入力します（要求された場合）。

ステップ 2

authentication display {legacy | new-style}

例:

Device# authentication display new-style

認証およびポリシー設定の表示モードを設定します。

  • デフォルトの表示モードはレガシーです。

  • このコマンドを使用すると、最初の明示的な Identity Based Networking Services コマンドを実行するまで、レガシー表示モードと C3PL 表示モードを切り替えることができます。最初の明示的な Identity Based Networking Services コマンドの入力後（たとえば、制御クラスまたは制御ポリシーを設定する場合）、このコマンドは無効になり、レガシーモードに戻せないため、続行の有無を確認するプロンプトが表示されます。

（注）  

 

新スタイルモードが有効になっている間に設定を保存してからリロードすると、表示モードは永続的に新スタイルに設定されます。authentication display コマンドは無効になっているため、レガシーモードには戻せません。

スタックデバイスとスタンドアロンデバイスをレガシーモードに戻すには、新スタイルの設定をフラッシュに保存し、デバイスを write erase して、reload を実行します。

制御クラスの設定

制御クラスは、制御ポリシーのアクションを実行する条件を定義します。制御ポリシーのアクションを実行するためには、条件のすべてが true と評価される、いずれかが true と評価される、あるいはいずれも true と評価されない、のいずれかを定義します。制御クラスは、制御ポリシーで指定されたイベントに基づいて評価されます。


（注）  

この手順では、制御クラスで設定できるすべての一致条件を示します。制御クラスを有効にするには、制御クラスで少なくとも 1 つの条件を指定する必要があります。他のすべての条件と、それに対応する手順はオプションです（以下のステップ 4 ～ 18）。

手順

  コマンドまたはアクション 目的

ステップ 1

enable

例:

Device> enable

特権 EXEC モードを有効にします。

  • パスワードを入力します（要求された場合）。

ステップ 2

configure terminal

例:

Device# configure terminal

グローバル コンフィギュレーション モードを開始します。

ステップ 3

class-map type control subscriber {match-all | match-any | match-none} control-class-name

例:

Device(config)# class-map type control subscriber match-all DOT1X_NO_AGENT

制御クラスを作成し、制御クラスマップ フィルタ モードを開始します。

  • match-all ：制御クラスのすべての条件が true と評価される必要があります。

  • match-any ：制御クラスの少なくとも 1 つの条件が true と評価される必要があります。

  • match-none ：制御クラスのすべての条件が false と評価される必要があります。

ステップ 4

{match | no-match} activated-service-template template-name

例:

Device(config-filter-control-classmap)# match activated-service-template SVC_1

（任意）セッションでアクティブ化されているサービステンプレートに基づいて true と評価される条件を作成します。

ステップ 5

{match | no-match} authorization-status {authorized | unauthorized}

例:

Device(config-filter-control-classmap)# match authorization-status authorized

（任意）セッションの承認ステータスに基づいて true と評価される条件を作成します。

ステップ 6

{match | no-match} authorizing-method-priority {eq | gt | lt} priority-value

例:

Device(config-filter-control-classmap)# match authorizing-method-priority eq 10

（任意）承認方式の優先順位に基づいて true と評価される条件を作成します。

  • eq ：現在の優先順位は priority-value と同じです。

  • gt ：現在の優先順位は priority-value より大きいです。

  • lt ：現在の優先順位は priority-value より小さいです。

  • priority-value ：照合する優先順位値。範囲は 1 ～ 254 で、1 が最も高い優先順位、254 が最も低い優先順位です。

ステップ 7

{match | no-match} client-type {data | switch | video | voice}

例:

Device(config-filter-control-classmap)# match client-type data

（任意）イベントのデバイスタイプに基づいて true と評価される条件を作成します。

ステップ 8

{match | no-match} current-method-priority {eq | gt | lt} priority-value

例:

Device(config-filter-control-classmap)# match current-method-priority eq 10

（任意）現在の認証方式の優先順位に基づいて true と評価される条件を作成します。

ステップ 9

{match | no-match} ip-address ip-address

例:

Device(config-filter-control-classmap)# match ip-address 10.10.10.1

（任意）イベントの送信元 IPv4 アドレスに基づいて true と評価される条件を作成します。

ステップ 10

{match | no-match} ipv6-address ipv6-address

例:

Device(config-filter-control-classmap)# match ipv6-address FE80::1

（任意）イベントの送信元 IPv6 アドレスに基づいて true と評価される条件を作成します。

ステップ 11

{match | no-match} mac-address mac-address

例:

Device(config-filter-control-classmap)# match mac-address aabb.cc00.6500

（任意）イベントの MAC アドレスに基づいて true と評価される条件を作成します。

ステップ 12

{match | no-match} method {dot1x | mab | webauth}

例:

Device(config-filter-control-classmap)# match method dot1x

（任意）イベントの認証方式に基づいて true と評価される条件を作成します。

ステップ 13

{match | no-match} port-type {l2-port | l3-port | dot11-port}

例:

Device(config-filter-control-classmap)# match port-type l2-port

（任意）イベントのインターフェイスタイプに基づいて true と評価される条件を作成します。

ステップ 14

{match | no-match} result-type [method {dot1x | mab | webauth}] result-type

例:

Device(config-filter-control-classmap)# match result-type agent-not-found

（任意）指定した認証結果に基づいて true と評価される条件を作成します。

  • 使用可能な結果タイプを表示するには、疑問符（?）のオンラインヘルプ機能を使用します。

ステップ 15

{match | no-match} service-template template-name

例:

Device(config-filter-control-classmap)# match service-template svc_1

（任意）イベントのサービステンプレートに基づいて true と評価される条件を作成します。

ステップ 16

{match | no-match} tag tag-name

例:

Device(config-filter-control-classmap)# match tag tag_1

（任意）イベントに関連付けられたタグに基づいて true と評価される条件を作成します。

ステップ 17

{match | no-match} timer timer-name

例:

Device(config-filter-control-classmap)# match timer restart

（任意）イベントのタイマーに基づいて true と評価される条件を作成します。

ステップ 18

{match | no-match} username username

例:

Device(config-filter-control-classmap)# match username josmiths

（任意）イベントのユーザー名に基づいて true と評価される条件を作成します。

ステップ 19

end

例:

Device(config-filter-control-classmap)# end

（任意）制御クラスマップ フィルタ コンフィギュレーション モードを終了し、特権 EXEC モードに戻ります。

ステップ 20

show class-map type control subscriber {all | name control-class-name}

例:

Device# show class-map type control subscriber all

（任意）ID ベースのネットワーキングサービスの制御クラスに関する情報を表示します。

例：制御クラス

次に、2 つの一致条件が設定された制御クラスの例を示します。 

class-map type control subscriber match-all DOT1X_NO_AGENT
 match method dot1x
 match result-type agent-not-found

制御ポリシーの設定

制御ポリシーは、指定されたイベントと条件に対応してシステムが実行するアクションを決定します。制御ポリシーには、制御クラスを 1 つ以上のアクションに関連付ける 1 つ以上の制御ポリシールールが含まれます。ポリシー ルールで設定できるアクションは、指定するイベントのタイプに応じて異なります。


（注）  

この作業には、イベントに関係なく、制御ポリシーで設定できるすべてのアクションが含まれています。これらのアクションと対応する手順は、すべてオプションです（以下のステップ 6 ～ 21）。特定のイベントでサポートされているアクションを表示するには、疑問符（[?]）のオンラインヘルプ機能を使用します。

手順

  コマンドまたはアクション 目的

ステップ 1

enable

例:

Device> enable

特権 EXEC モードを有効にします。

  • パスワードを入力します（要求された場合）。

ステップ 2

configure terminal

例:

Device# configure terminal

グローバル コンフィギュレーション モードを開始します。

ステップ 3

policy-map type control subscriber control-policy-name

例:

Device(config)# policy-map type control subscriber POLICY_1

加入者セッションに対する制御ポリシーを定義します。

ステップ 4

event event-name [match-all | match-first]

例:

Device(config-event-control-policymap)# event session-started

条件が満たされた場合に制御ポリシーのアクションをトリガーするイベントのタイプを指定します。

  • match-all デフォルトの動作です。

  • 使用可能なイベント タイプを表示するには、（?）のオンライン ヘルプ機能を使用します。イベントタイプの完全な説明については、event コマンドについて参照してください。

ステップ 5

priority-number class {control-class-name | always} [do-all | do-until-failure | do-until-success]

例:

Device(config-class-control-policymap)# 10 class always

制御ポリシーを制御クラスの 1 つ以上のアクションに関連付けます。

  • 名前付き制御クラスを最初に設定してから、このクラスを control-class-name 引数を使用して指定する必要があります。

  • do-until-failure デフォルトの動作です。

ステップ 6

action-number activate {policy type control subscriber control-policy-name [child [no-propagation | concurrent] | service-template template-name [aaa-list list-name] [precedence number] [replace-all]}

例:

Device(config-action-control-policymap)# 10 activate service-template FALLBACK

（任意）加入者セッションの制御ポリシーまたはサービステンプレートをアクティブ化します。

ステップ 7

action-number authenticate using {dot1x | mab | webauth} [aaa {authc-list authc-list-name | authz-list authz-list-name]} [merge] [parameter-map map-name] [priority priority-number] [replace | replace-all] [retries number {retry-time seconds}]

例:

Device(config-action-control-policymap)# 10 authenticate using dot1x priority 10

（任意）指定されたメソッドを使用して加入者セッションの認証を開始します。

ステップ 8

action-number authentication-restart seconds

例:

Device(config-action-control-policymap)# 20 authentication-restart 60

（任意）認証または承認の失敗後に認証プロセスを再開するタイマーを設定します。

ステップ 9

action-number authorize

例:

Device(config-action-control-policymap)# 10 authorize

（任意）加入者セッションの承認を開始します。

ステップ 10

action-number clear-authenticated-data-hosts-on-port

例:

Device(config-action-control-policymap)# 20 clear-authenticated-data-hosts-on-port

（任意）認証が失敗した後、ポート上の認証済みデータホストをクリアします。

ステップ 11

action-number clear-session

例:

Device(config-action-control-policymap)# 30 clear-session

（任意）アクティブな加入者セッションをクリアします。

ステップ 12

action-number deactivate {policy type control subscriber control-policy-name | service-template template-name}

例:

Device(config-action-control-policymap)# 20 deactivate service-template interface_template

（任意）加入者セッションの制御ポリシーまたはサービステンプレートを非アクティブ化します。

ステップ 13

action-number err-disable

例:

Device(config-action-control-policymap)# 10 err-disable

（任意）セッション違反イベント後、ポートを一時的に無効にします。

ステップ 14

action-number pause reauthentication

例:

Device(config-action-control-policymap)# 20 pause reauthentication

（任意）認証失敗後、再認証を一時停止します。

ステップ 15

action-number protect

例:

Device(config-action-control-policymap)# 10 protect

（任意）セッション違反イベント後、違反パケットをサイレントにドロップします。

ステップ 16

action-number replace

例:

Device(config-action-control-policymap)# 10 replace

（任意）違反イベント後、既存のセッションをクリアして新しいセッションを作成します。

ステップ 17

action-number restrict

例:

Device(config-action-control-policymap)# 10 restrict

（任意）セッション違反イベント後、違反パケットをドロップして syslog エントリを生成します。

ステップ 18

action-number resume reauthentication

例:

Device(config-action-control-policymap)# 20 resume reauthentication

（任意）認証失敗後、再認証プロセスを再開します。

ステップ 19

action-number set-timer timer-name seconds

例:

Device(config-action-control-policymap)# 20 set-timer RESTART 60

（任意）指定されたポリシータイマーを開始します。

ステップ 20

action-number terminate {dot1x | mab | webauth}

例:

Device(config-action-control-policymap)# 20 terminate webauth

（任意）加入者セッションの認証方式を終了します。

ステップ 21

action-number unauthorize

例:

Device(config-action-control-policymap)# 20 unauthorize

（任意）加入者セッションからすべての承認データを削除します。

ステップ 22

end

例:

Device(config-action-control-policymap)# end

（任意）制御ポリシー マップ アクション コンフィギュレーション モードを終了し、特権 EXEC モードに戻ります。

ステップ 23

show policy-map type control subscriber {all | name control-policy-name}

例:

Device# show policy-map type control subscriber POLICY_1

（任意）アイデンティティ制御ポリシーに関する情報を表示します。

例：制御ポリシー

次に、認証を開始するために必要な最小限の設定を使用した、単純な制御ポリシーの例を示します。 

policy-map type control subscriber POLICY_1
 event session-started match-all
  10 class always do-until-failure
   10 authenticate using dot1x

同時認証および連続認証の制御ポリシーの詳細な例については、Cisco Identity-Based の制御ポリシーの設定例 セクションを参照してください。

インターフェイスへの制御ポリシーの適用

制御ポリシーは、一般に加入者アイデンティティの認証およびセッションでのサービスのアクティブ化を制御します。インターフェイスに制御ポリシーを適用するには、次の手順を実行します。

手順

  コマンドまたはアクション 目的

ステップ 1

enable

例:

Device> enable

特権 EXEC モードを有効にします。

  • パスワードを入力します（要求された場合）。

ステップ 2

configure terminal

例:

Device# configure terminal

グローバル コンフィギュレーション モードを開始します。

ステップ 3

interface type number

例:

Device(config)# interface GigabitEthernet 1/0/1

インターフェイスを指定し、インターフェイス コンフィギュレーション モードを開始します。

ステップ 4

service-policy type control subscriber control-policy-name

例:

Device(config-if)# service-policy type control subscriber POLICY_1

以前に設定された制御ポリシーを適用します。

  • 設定済みのすべての制御ポリシーのリストを表示するには、疑問符（?）のオンラインヘルプ機能を使用します。

ステップ 5

subscriber aging {inactivity-timer seconds [probe] | probe}

例:

Device(config-if)# subscriber aging inactivity-timer 60 probe

加入者セッションに対する非アクティブタイマーを有効にします。

Cisco IOS XE Everest 16.6.1 以降、このコマンドを設定する場合、プローブが期待どおりに機能するためには、グローバル コンフィギュレーション モードで device-tracking binding reachable-lifetime コマンドも設定する必要があります。非アクティブタイマープローブと同じ値で到達可能な有効期間を設定します。これにより、到達可能な有効期間が切れると、エントリの状態はホストの到達可能性に基づいて変化します。詳細については、対応するリリースのコマンドリファレンスにある device-tracking binding コマンドを参照してください。

例：インターフェイスへの制御ポリシーの適用

interface GigabitEthernet 1/0/2
 subscriber aging inactivity-timer 60 probe
 device-tracking binding reachable-lifetime 60
 service-policy type control subscriber POLICY_1

ポートでの認証機能の設定

ポートの認可状態、ホストアクセスモード、事前認証アクセス、および認証方向を含めて、ポートへのアクセスを制御するには、次の手順を実行します。

手順

  コマンドまたはアクション 目的

ステップ 1

enable

例:

Device> enable

特権 EXEC モードを有効にします。

  • パスワードを入力します（要求された場合）。

ステップ 2

configure terminal

例:

Device# configure terminal

グローバル コンフィギュレーション モードを開始します。

ステップ 3

interface type number

例:

Device(config)# interface gigabitethernet 1/0/2

選択したインターフェイスのインターフェイス コンフィギュレーション モードを開始します。

ステップ 4

access-session port-control {auto | force-authorized | force-unauthorized}

例:

Device(config-if)# access-session port-control auto

ポートの認可状態を設定します。

  • デフォルト値は force-authorized です。

ステップ 5

access-session host-mode {multi-auth | multi-domain | multi-host | single-host}

例:

Device(config-if)# access-session host-mode single-host

ホストの制御ポートへのアクセスを許可します。

  • このコマンドを使用するには、まず access-session port-control auto コマンドを有効にする必要があります。

  • デフォルト値は multi-auth です。

ステップ 6

access-session closed

例:

Device(config-if)# access-session closed

ポートへの事前認証アクセスを防止します。

  • ポートはデフォルトでオープンアクセスに設定されています。

ステップ 7

access-session control-direction {both | in}

例:

Device(config-if)# access-session control-direction in

ポートの認証制御の方向を設定します。

  • デフォルト値は both です。

ステップ 8

end

例:

Device(config-if)# end

インターフェイス コンフィギュレーション モードを終了し、特権 EXEC モードに戻ります。

ステップ 9

show access-session interface interface-type interface-number [details]

例:

Device# show access-session interface gigabitethernet 1/0/2 details

指定されたクライアント インターフェイスに一致するサブスクライバセッションに関する情報を表示します。

例：ポート認証

interface GigabitEthernet 1/0/2
 access-session host-mode single-host
 access-session closed
 access-session port-control auto
 access-session control-direction in

Web ベース認証のパラメータマップの設定

パラメータマップを使用すると、制御ポリシーで設定されたアクションの動作を制御するパラメータを変更できます。Web 認証のパラメータマップにより、認証時に加入者セッションに適用できるパラメータが設定されます。パラメータマップを作成しない場合、ポリシーではデフォルトのパラメータが使用されます。

Web ベース認証のグローバルパラメータマップまたは名前付きパラメータマップを定義するには、次の手順を実行します。


（注）  

グローバルパラメータマップで使用できるコンフィギュレーション コマンドは、名前付きパラメータマップで使用できるコマンドとは異なります。

手順

  コマンドまたはアクション 目的

ステップ 1

enable

例:

Device> enable

特権 EXEC モードを有効にします。

  • パスワードを入力します（要求された場合）。

ステップ 2

configure terminal

例:

Device# configure terminal

グローバル コンフィギュレーション モードを開始します。

ステップ 3

parameter-map type webauth {parameter-map-name | global}

例:

Device(config)# parameter-map type webauth MAP_2

パラメータ マップを作成し、parameter-map webauth コンフィギュレーション モードを開始します。

  • global キーワードで定義されたグローバルパラメータマップでサポートされる特定のコンフィギュレーション コマンドは、parameter-map-name 引数を指定して定義された名前付きパラメータマップでサポートされるコマンドとは異なります。

ステップ 4

banner {file location:filename | text banner-text}

例:

Device(config-params-parameter-map)# banner file flash:webauth_banner.html

（任意）Web 認証ログイン Web ページにバナーを表示します。

ステップ 5

consent

例:

Device(config-params-parameter-map)# type consent

（任意）Web ベースの認証パラメータマップでサポートされる方式を定義します。

  • このコマンドは、名前付きパラメータ マップでのみサポートされます。

ステップ 6

consent email

例:

Device(config-params-parameter-map)# consent email

（任意）Web 認証ログイン Web ページでユーザーの電子メールアドレスを要求します。

  • このコマンドは、名前付きパラメータ マップでのみサポートされます。

ステップ 7

custom-page {failure | login [expired] | success} device location:filename

例:

Device(config-params-parameter-map)# custom-page login device flash:webauth_login.html
Device(config-params-parameter-map)# custom-page login expired device flash:webauth_expire.html
Device(config-params-parameter-map)# custom-page success device flash:webauth_success.html
Device(config-params-parameter-map)# custom-page failure device flash:webauth_fail.html

（任意）Web ベース認証中にカスタム認証プロキシ Web ページを表示します。

  • 4 つのカスタム HTML ファイルをすべて設定する必要があります。設定したファイルの数が 4 個未満の場合、内部デフォルト HTML ページが使用されます。

ステップ 8

max-http-conns number

例:

Device(config-params-parameter-map)# max-http-conns 5

（任意）各 Web 認証クライアントの HTTP 接続数を制限します。

ステップ 9

redirect {{for-login | on-failure | on-success} url | portal {ipv4 ipv4-address | ipv6 ipv6-address}}

例:

Device(config-params-parameter-map)# redirect portal ipv6 FE80::1
Device(config-params-parameter-map)# redirect on-failure http://10.10.3.34/~sample/failure.html

（任意）Web ベースの認証中にユーザーを特定の URL にリダイレクトします。

ステップ 10

timeout init-state sec seconds

例:

Device(config-params-parameter-map)# timeout init-state sec 60

（任意）Web ベース認証セッションの Init 状態のタイムアウトを設定します。

  • seconds の範囲は（60 ～ 3,932,100）です。

ステップ 11

type {authbypass | consent | webauth | webconsent}

例:

Device(config-params-parameter-map)# type consent

（任意）Web ベースの認証パラメータマップでサポートされる方式を定義します。

  • このコマンドは、名前付きパラメータ マップでのみサポートされます。

ステップ 12

virtual-ip {ipv4 ipv4-address | ipv6 ipv6-address}

例:

Device(config-params-parameter-map)# virtual-ip ipv6 FE80::1

（任意）Web ベース認証クライアントの仮想 IP アドレスを指定します。

  • このコマンドは、グローバル パラメータ マップでのみサポートされます。

ステップ 13

watch-list {add-item {ipv4 ipv4-address | ipv6 ipv6-address} | dynamic-expiry-timeout minutes | enabled}

例:

Device(config-params-parameter-map)# watch-list enabled
Device(config-params-parameter-map)# watch-list dynamic-expiry-timeout 20
Device(config-params-parameter-map)# watch-list add-item ipv6 FE80::1

（任意）Web ベース認証クライアントのウォッチリストを有効にします。

  • このコマンドは、グローバル パラメータ マップでのみサポートされます。

ステップ 14

end

例:

Device(config-params-parameter-map)# end

（任意）パラメータ マップ コンフィギュレーション モードを終了し、特権 EXEC モードに戻ります。

ステップ 15

show ip admission status [banners | custom-pages | parameter-map [parameter-map]]

例:

Device# show ip admission status custom-pages

（任意）設定されたバナーおよびカスタムページについて説明します。

例：Web ベース認証のパラメータマップ

parameter-map type webauth PMAP_2
 type webconsent
 timeout init-state sec 60
 max-http-conns 5
 type consent
 consent email
 custom-page login device flash:webauth_login.html
 custom-page success device flash:webauth_success.html
 custom-page failure device flash:webauth_fail.html
 custom-page login expired device flash:webauth_expire.html

次のタスク

制御ポリシーの設定時に authenticate using コマンドで指定することで、パラメータマップをセッションに適用します。制御ポリシーの設定を参照してください。

Cisco Identity-Based の制御ポリシーの設定例

例：同時認証方式の制御ポリシーの設定

以下の例は、同時認証方式を許可するように設定されている制御ポリシーを示しています。3 つの方式（dot1x、MAB、および Web 認証）は、セッションが開始されると同時に実行されます。dot1x 方式が最も高い優先順位に設定され、Web 認証が最も低い優先順位になります。つまり、複数の方式が成功した場合、最も高い優先順位の方式が採用されます。

認証が失敗した場合、セッションマネージャはすべての方式が失敗したのか確認し、失敗していた場合は再起動タイマーを 60 秒に設定して、3 つの方式すべての再起動を試みます。認証が成功すると、セッションマネージャは優先順位が低いすべての方式を終了します。 dot1x の場合は MAB と Web 認証、MAB の場合は Web 認証が終了します。最後に、セッションマネージャは dot1x クライアント（agent-found）を検出すると、dot1x のみをトリガーして実行します。

ALL-FAILED という名前のクラスマップでは、3 つの方式すべてが完了するまで実行され（完了するまで結果タイプは none）、すべて失敗したことが確認されます。つまり、3 つの方式すべてが完了し、失敗していることになります。


（注）  

同時認証の制御ポリシーを設定する場合は、より優先順位が高い別の方式が成功した後に、1 つの方式を明示的に終了するポリシールールを含める必要があります。

 

class-map type control subscriber match-all ALL_FAILED
 no-match result-type method dot1x none
 no-match result-type method dot1x success
 no-match result-type method mab none
 no-match result-type method mab success
 no-match result-type method webauth none
 no-match result-type method webauth success
!
class-map type control subscriber match-all DOT1X
 match method dot1x
!
class-map type control subscriber match-all MAB
 match method mab
!
policy-map type control subscriber CONCURRENT_DOT1X_MAB_WEBAUTH
	event session-started match-all
	 10 class always do-until-failure
	  10 authenticate using mab priority 20
	  20 authenticate using dot1x priority 10
	  30 authenticate using webauth parameter-map WEBAUTH_DEFAULT priority 30
	event authentication-failure match-first
	 10 class ALL_FAILED
   10 authentication-restart 60
 event authentication-success match-all
  10 class DOT1X
   10 terminate MAB
   20 terminate webauth
  20 class MAB
   10 terminate webauth
 event agent-found match-all
  10 class always do-until-failure
   10 authenticate using dot1x priority 10

例：連続認証方式の制御ポリシーの設定

次の例は、802.1X（dot1x）、MAB、および Web 認証を使用する連続認証方式を許可するように設定されている制御ポリシーを示しています。 

parameter-map type webauth WEBAUTH_FALLBACK
	type webauth
!
class-map type control subscriber match-all DOT1X_NO_RESP
 match method dot1x
 match result-type method dot1x agent-not-found
!
class-map type control subscriber match-all MAB_FAILED
 match method mab
 match result-type method mab authoritative
!
policy-map type control subscriber POLICY_Gi3/0/10
	event session-started match-all
	 10 class always do-until-failure
	  10 authenticate using dot1x priority 10
	event authentication-failure match-first
	 10 class DOT1X_NO_RESP do-until-failure
	  10 terminate dot1x
	  20 authenticate using mab priority 20
	 20 class MAB_FAILED do-until-failure
	  10 terminate mab
	  20 authenticate using webauth parameter-map WEBAUTH_FALLBACK priority 30
	 30 class always do-until-failure
	  10 terminate dot1x
	  20 terminate mab
	  30 terminate webauth
	  40 authentication-restart 60
	event agent-found match-all
	 10 class always do-until-failure
	  10 terminate mab
	  20 terminate webauth
	  30 authenticate using dot1x priority 10

次の例は、802.1X および MAB を使用する連続認証方式を許可するように設定されている制御ポリシーを示しています。認証が失敗すると、VLAN のサービステンプレートがアクティブになります。 

service-template VLAN210
	vlan 210
!
class-map type control subscriber match-all DOT1X_FAILED
 match method dot1x
 match result-type method dot1x authoritative
!
class-map type control subscriber match-all DOT1X_NO_RESP
 match method dot1x
 match result-type method dot1x agent-not-found
!
class-map type control subscriber match-all MAB_FAILED
 match method mab
 match result-type method mab authoritative
!
policy-map type control subscriber POLICY_Gi3/0/14
	event session-started match-all
	 10 class always do-until-failure
	  10 authenticate using dot1x retries 2 retry-time 0 priority 10
	event authentication-failure match-first
	 10 class DOT1X_NO_RESP do-until-failure
	  10 terminate dot1x
	  20 authenticate using mab priority 20
	 20 class MAB_FAILED do-until-failure
	  10 terminate mab
	  20 activate service-template VLAN210
	  30 authorize
	 30 class DOT1X_FAILED do-until-failure
	  10 terminate dot1x
	  20 authenticate using mab priority 20
	 40 class always do-until-failure
	  10 terminate dot1x
	  20 terminate mab
	  30 authentication-restart 60
	event agent-found match-all
	 10 class always do-until-failure
	  10 terminate mab
	  20 authenticate using dot1x retries 2 retry-time 0 priority 10

例：パラメータマップの設定

グローバル パラメータ マップ

以下に、グローバルパラメータマップの設定例を示します。 

parameter-map type webauth global
 timeout init-state sec 15
 watch-list enabled
 virtual-ip ipv6 FE80::1
 redirect on-failure http://10.10.3.34/~sample/failure.html
 max-http-conns 100
 watch-list dynamic-expiry-timeout 5000
 banner file flash:webauth_banner.html
Web 認証および認証バイパス（非応答ホスト（NRH））の名前付きパラメータマップ

次に、2 つの名前付きパラメータマップの設定例を示します。1 つは Web 認証用、もう 1 つは認証バイパス用です。対応する制御ポリシーの設定例も示します。 

parameter-map type webauth WEBAUTH_BANNER
 type webauth
 banner		
!
parameter-map type webauth WEBAUTH_NRH
 type authbypass
!
class-map type control subscriber match-all NRH_FAIL
 match method webauth
 match current-method-priority eq 254
!
policy-map type control subscriber WEBAUTH_NRH
 event session-started match-all
  10 class always do-until-failure
   10 authenticate using webauth parameter-map WEBAUTH_NRH priority 254
 event authentication-failure match-all
  10 class NRH_FAIL do-until-failure
   10 terminate webauth
   20 authenticate using webauth parameter-map WEBAUTH_BANNER priority 30
カスタムページを使用した Web 認証の名前付きパラメータマップ

次の例は、ログインプロセスのカスタムページを定義する Web 認証の名前付きパラメータマップと、そのパラメータマップを使用する制御ポリシーの設定を示しています。 

parameter-map type webauth CUSTOM_WEBAUTH
 type webauth
 custom-page login device flash:login_page.htm
 custom-page success device flash:success_page.htm
 custom-page failure device flash:fail_page.htm
 custom-page login expired device flash:expire_page.htm
!
policy-map type control subscriber CUSTOM_WEBAUTH
 event session-started match-all
  10 class always do-until-failure
   10 authenticate using webauth parameter-map CUSTOM_WEB retries 2 retry-time 0
同意用の名前付きパラメータマップ

次の例は、同意用の名前付きパラメータマップの設定と、そのパラメータマップを使用する対応する制御ポリシーを示しています。 

parameter-map type webauth CONSENT
 type consent
!
ip access-list extended GUEST_ACL
 permit ip any 172.30.30.0 0.0.0.255
 permit ip any host 172.20.249.252
!
service-template GUEST_POLICY
 access-group GUEST_ACL
!
policy-map type control subscriber CONSENT
 event session-started match-all
  10 class always do-until-failure
   10 authenticate using webauth parameter-map CONSENT
 event authentication-success match-all
  10 class always do-until-failure
   10 activate service-template GUEST_POLICY
同意付きの Web 認証用の名前付きパラメータマップ

次の例は、同意付きの Web 認証用の名前付きパラメータマップの設定と、そのパラメータマップを使用する対応する制御ポリシーを示しています。 

parameter-map type webauth WEBAUTH_CONSENT
 type webconsent
!
ip access-list extended GUEST_ACL
 permit ip any 172.30.30.0 0.0.0.255
 permit ip any host 172.20.249.252
!
service-template GUEST_POLICY
 access-group GUEST_ACL
!
policy-map type control subscriber WEBAUTH_CONSENT
 event session-started match-all
  10 class always do-until-failure
   10 authenticate using webauth parameter-map CONSENT
 event authentication-success match-all
  10 class always do-until-failure
   10 activate service-template GUEST_POLICY

アイデンティティ制御ポリシーの機能履歴

次の表に、このモジュールで説明する機能のリリースおよび関連情報を示します。

これらの機能は、特に明記されていない限り、導入されたリリース以降のすべてのリリースで使用できます。

表 1. アイデンティティ制御ポリシーの機能履歴
リリース

機能名

機能情報

Cisco IOS XE Everest 16.6.1

Cisco Common Classification Policy Language ベースのアイデンティティ設定

アイデンティティ制御ポリシーでは、指定されたイベントと条件に応じて実行されるアクションを定義します。

Cisco IOS XE Cupertino 17.7.1

Cisco Common Classification Policy Language ベースのアイデンティティ設定

この機能は、スーパーバイザモジュール C9400X-SUP-2 および C9400X-SUP-2XL に導入されました。

Cisco Feature Navigator を使用すると、プラットフォームおよびソフトウェアイメージのサポート情報を検索できます。Cisco Feature Navigator にアクセスするには、https://cfnng.cisco.com に進みます。