ユーザ アクセス、認証およびアカウンティング

この章で説明する内容は、次のとおりです。

アクセス権のワークフローの依存関係

  Cisco Application Centric Infrastructure （ACI) RBAC のルールによって、ファブリック全体へのアクセスを有効にするか、一部へのアクセスに制限します。たとえば、ベアメタルサーバー アクセス用のリーフ スイッチを設定するには、ログインしている管理者が infra ドメインに対する権限を持っている必要があります。デフォルトでは、テナント管理者は infra ドメインに対する権限を持っていません。この場合、リーフ スイッチに接続されているベア メタル サーバの使用を計画しているテナント管理者は、そのために必要なすべての手順を実行することはできません。テナント管理者は、 infra ドメインに対する権限を持っているファブリック管理者と連携する必要があります。ファブリック管理者は、テナント管理者が ACI リーフ スイッチに接続されたベア メタル サーバーを使用するアプリケーション ポリシーを導入するために使用するスイッチ設定ポリシーをセットアップします。

ユーザー アクセス、認可およびアカウンティング

Application Policy Infrastructure Controller （APIC）ポリシーは、（ Cisco Application Centric Infrastructure （ACI）ファブリックの認証、認可、およびアカウンティング（AAA）機能を管理します。ユーザー権限、ロール、およびドメインとアクセス権限の継承を組み合わせることにより、管理者は細分化された方法で管理対象オブジェクト レベルで AAA 機能を設定することができます。これらの設定は、REST API、CLI、または GUI を使用して実行できます。


（注）  

ログイン ドメイン名を 32 文字より長くすることはできないという既知の制限があります。また、ログイン ドメイン名とユーザー名を合わせた文字数は 64 文字を超えることはできません。

マルチテナントのサポート

コア Application Policy Infrastructure Controller （APIC）の内部データ アクセス コントロール システムにより、マルチテナント分離が提供され、テナント間での個人情報の漏洩が防止されます。読み取り/書き込みの制約により、テナントによる他のテナントの設定、統計情報、障害、またはイベント データの参照が防止されます。管理者によって読み取り権限が割り当てられない限り、テナントはファブリックの設定、ポリシー、統計情報、障害、またはイベントの読み取りが制限されます。

ユーザー アクセス：ロール、権限、セキュリティ ドメイン

  APIC では、ロールベース アクセス コントロール (RBAC) を介してユーザーのロールに従ってアクセスが提供されます。  Cisco Application Centric Infrastructure （ACI）ファブリック ユーザーは以下に関連付けられています。

  • 事前定義またはカスタム ロール。ユーザーに割り当てられた 1 つ以上の権限のセットです。

  • 権限のセット。ユーザーがアクセスできる管理対象オブジェクト（MO）を決定します。

  • ロールごとの権限タイプ：アクセスなし、読み取り専用、または読み取り/書き込み

  • ユーザーがアクセスできる管理情報ツリー (MIT) の一部を識別する 1 つ以上のセキュリティ ドメイン タグ

ロールと権限

権限はシステム内の特定の機能に対するアクセス権を制御します。  ACI ファブリックは、管理対象オブジェクト（MO）レベルでアクセス権限を管理します。すべてのオブジェクトは、読み取り可能な権限のリストと、書き込み可能な権限のリストを保持しています。特定の機能に対応するすべてのオブジェクトには、その機能の読み取りまたは書き込みリストの権限が付与されます。オブジェクトは追加の機能に対応する場合があるため、そのリストには複数の権限が含まれている場合があります。権限を含むロールがユーザーに割り当てられると、そのユーザーには、読み取りリストが読み取りアクセスを指定する関連オブジェクトへの読み取りアクセス権が付与され、書き込みリストが書き込みアクセスを指定するオブジェクトへの書き込みアクセス権が付与されます。

たとえば、「fabric-equipment」は、物理ファブリック内の機器に対応するすべてのオブジェクトへのアクセスを制御する権限です。物理ファブリック内の機器に対応するオブジェクト（「eqptBoard」など）では、特権リストに「fabric-equipment」が含まれます。「eqptBoard」オブジェクトは、「fabric-equipment」権限の読み取り専用アクセスを許可します。「fabric-admin」などの権限「fabric-equipment」が割り当てられているユーザーには、「eqptBoard」オブジェクトへの読み取り専用アクセスなど、これらの機器オブジェクトへのアクセス権が付与されます。


（注）  

一部のロールには他のロールが含まれています。たとえば、tenant-admin、fabric-admin、access-admin などの「-admin」ロールは、同じベース名を持つロールのグループです。たとえば、「access-admin」は「access-connectivity」、「access-equipment」、「access-protocol」、および「access-qos」のグループです。同様に、tenant-adminは「テナント」ベースのロールのグループで、fabric-adminは「ファブリック」ベースのロールのグループです。

「admin」ロールにはすべての権限が含まれます。管理ユーザーを APIC から削除することはできません

ロールと権限の詳細については、 APIC のロールと権限のマトリクスを参照してください。

セキュリティ ドメイン

セキュリティ ドメインは、 MIT オブジェクト階層の特定のサブツリーに関連付けられたタグです。 ACI MIT オブジェクト階層たとえば、デフォルトのテナント「common」にはドメイン タグ commonが付いています。同様に、特別なドメイン タグ all には、MIT オブジェクト ツリー全体が含まれます。管理者は、MIT オブジェクト階層にカスタム ドメイン タグを割り当てることができます。たとえば、管理者は「solar」という名前のテナントにドメイン タグ「solar」を割り当てることができます。MIT 内では、特定のオブジェクトだけがセキュリティ ドメインとしてタグ付けできます。たとえば、テナントにはセキュリティ ドメインとしてタグ付けすることができますが、テナント内のオブジェクトにはできません。


（注）  

（R6.1.2 まで）パスワード強度のパラメータは、 カスタム条件 を作成するか、用意されている 任意の 3 つの条件 を選択することによって、設定できます。


（注）  

（R6.1.3 以降）パスワード強度のパラメータは、 カスタム条件 を作成するか、小文字、数字、特殊文字を含めるという デフォルトの 3 条件 を選択することによって、設定できます。

ユーザーを作成してロールを割り当てても、アクセス権は有効になりません。1 つ以上のセキュリティ ドメインにそのユーザーを割り当てることも必要です。デフォルトでは、 ACI ファブリックには事前作成された次の特殊なドメインが含まれています。

  • All：MIT 全体へのアクセスを許可

  • Common：ファブリックの共通オブジェクト/サブツリーへのアクセスを許可

  • Mgmt：ファブリックの管理オブジェクト/サブツリーへのアクセスを許可


（注）  

ユーザーのクレデンシャルが許可しない管理対象オブジェクトの読み取り操作の場合、「DN/Class Unauthorized to read」ではなく「DN/Class Not Found」というエラーが返されます。ユーザーのクレデンシャルが許可しない管理対象オブジェクトへの書き込み操作の場合、「HTTP 401 Unauthorized」というエラーが返されます。GUI では、ユーザーのクレデンシャルが許可しないアクションの場合、表示されないか、またはグレー表示されます。

事前に定義された一連の管理対象オブジェクト クラスをドメインに関連付けることができます。これらのクラスがオーバーラップすることはできません。ドメインの関連付けをサポートするクラスの例：

  • レイヤ 2 およびレイヤ 3 のネットワークで管理されたオブジェクト

  • ネットワーク プロファイル (物理、レイヤ 2、レイヤ 3、管理など)

  • Quality of Service（QoS）ポリシー

ドメインに関連付けることができるオブジェクトが作成されると、ユーザーは、ユーザーのアクセス権の範囲内でオブジェクトにドメインを割り当てる必要があります。ドメインの割り当てはいつでも変更できます。

仮想マシン管理 (VMM) ドメインがセキュリティ ドメインとしてタグ付けされている場合、セキュリティ ドメイン内のユーザーは、対応するタグ付き VMM ドメインにアクセスできます。たとえば、solar という名前のテナントに sun というセキュリティ ドメインのタグが付いており、VMM ドメインにも sun というセキュリティ ドメインのタグが付いている場合、solar テナント内のユーザーは各自のアクセス権限に従って VMM ドメインにアクセスできます。

ログイン ドメイン

ログイン ドメインは、ユーザーの認証ドメインを定義します。ログイン ドメインは、ローカル、LDAP、RADIUS、TACACS+、DUO、SAML、RSA、または OAuth 2 認証メカニズムを設定できます。REST、 CLI、または GUI からシステムにアクセスする場合は、 APIC により、ユーザーは正しい認証ドメインを選択できます。

たとえば、REST シナリオでは、完全なログイン ユーザー名が次のように表示されるようにユーザー名の頭に文字列が付きます。 

apic:<domain>\<username>

GUIからシステムにアクセスする場合、 APIC により選択するユーザーのドメインのドロップダウン リストが提供されます。  apic: domain が指定されない場合は、デフォルトの認証ドメイン サーバーがユーザー名の検索に使用されます。

ACI バージョン 1.0(2x) 以降、 APIC のログイン ドメイン フォールバックのデフォルトはローカルになっています。デフォルト認証とコンソール認証方法がどちらも非ローカルの方法に設定されており、両方の非ローカル方法がローカル認証に自動的にフォールバックしない場合でも、 APIC にはローカル認証を使用してアクセスすることができます。

  APIC フォールバック ローカル認証にアクセスするには、次の文字列を使用します：

  • APIC とスイッチの両方の REST API、GUI、および CLI で apic#fallback\\username 文字列を使用します。

  •   apic:fallback\\username 文字列は、REST API と GUI にのみ使用し、CLI インターフェイスには使用しません。


（注）  

フォールバック ログイン ドメインは変更しないでください。変更すると、システムからロックアウトされる可能性があります。

GUI を使用してローカル ドメインを作成する

SAML および OAuth 2 の外部サーバーによる認証は、標準の CiscoAVPair ベースの認証に加え、ユーザーグループのマップ ルール情報に基づいて行われるようになりました。

始める前に

  •   Cisco Application Centric Infrastructure （ACI）ファブリックがインストールされていて、 Application Policy Infrastructure Controller（APIC）がオンラインであり、そして APIC クラスターが形成され、正常に動作していること。

  • ログイン ドメイン名、レルム、リモート サーバー プロバイダーは、ユーザーに対して認証ドメインを定義できます。

手順

ステップ 1

メニュー バーで、 [管理（Admin）] > [AAA]を選択します。

ステップ 2

[ナビゲーション（Navigation）] ペインで [認証（Authentication）]を選択します。

ステップ 3

[作業（Work）] ペインで、 [ログイン ドメイン（Login Domain）] タブを選択します。

ステップ 4

  [アクション（Actions）] ボタン > [ログイン ドメインの作成（Create Login Domain）]をクリックします。

ステップ 5

  [ログイン ドメインの作成（Create Login Domain）] 画面の [全般（General）] ペインで、次を指定します：

  • ユーザーが設定したドメイン名。

  • ログイン ドメインの説明。

  • ファブリック デバイスにアクセスするエンティティ（個人またはデバイス）の ID を確認するためのレルム。 [レルム（Realm）] ドロップダウン リストで使用できるオプションについては、以下で説明します。

    1. 認証用 RADIUS プロトコルをサポートするリモート サーバーのグループに対する RADIUS プロバイダー グループ。

    2. 認証用 TACACS+ プロトコルをサポートするリモート サーバーのグループに対する TACACS+ プロバイダー グループ。

    3. 認証用 LDAP プロトコルをサポートするリモート サーバーのグループに対する LDAP プロバイダー グループ。

    4. 認証用 RSA プロトコルをサポートするリモート サーバーのグループに対する RSA プロバイダー グループ。

    5. 認証用の SAML プロトコルをサポートする SAML プロバイダーのリモートサーバー。

    6. 認証用 OAuth 2 プロトコルをサポートする OAuth 2 プロバイダーのリモートサーバー

（注）  

 

LDAP、RADIUS、TACACS+ がデフォルトのセキュリティメソッドとして指定されており、このダイアログで指定された関連するプロバイダー グループがユーザ ログイン中に使用できない場合、特にそうするように構成されていない限り、 Cisco APIC サーバーではフォールバック ローカル認証は実行されません。

  Cisco APIC が ID プロバイダーに到達するためにプロキシサーバーを必要とする場合は、対応するプロキシ アドレスを構成します。プロキシ設定の構成は、 [システム（System）] > [システム設定（System Settings）] > [プロキシ ポリシー（Proxy Policy）]にあります。  [プロキシポリシー（Proxy Policy）] ペインで、必要なURLを [HTTP URL] または [HTTPS URL] フィールドに入力します。

ステップ 6

表示されたオプションの詳細を入力します。表示されるオプションは動的で、選択した [レルム（Realm）]に応じて変化します。

選択した [レルム（Realm）] が RADIUS または LDAP の場合、次のオプションが表示されます：

  •   [デフォルト（Default）] または [デュオ（Duo）] を [レルム サブタイプ（Realm Subtype）]として選択します。

  •   [設定（Settings）] ペインで、 [RADIUS（または LDAP）プロバイダーの追加（Add RADIUS（or LDAP）Provider）] をクリックして（上記の [デフォルト（Default）] を選択していた場合）プロバイダーを選択するか、作成します。  [デュオ（Duo）] オプションを選択した場合 [RADIUS（または LDAP）Duo プロバイダーの追加（Add RADIUS（or LDAP）Duo Provider）] をクリックして、プロバイダーを選択または作成します。

選択した [レルム（Realm）] が TACACS+ または RSA の場合、次のオプションが表示されます：

  •   [設定（Settings）] ペインで、 [RSA（または TACACS+）プロバイダーの追加（Add RSA（or TACACS+）Provider）] をクリックして、プロバイダーを選択または作成します。

選択した[レルム（Realm）] SAML または OAuth 2 の場合、次のオプションが表示されます：

  •   [設定（Settings）] ペインで、 [SAML（または OAuth 2）プロバイダーの選択（Select SAML（or OAuth 2）Provider）] をクリックして、プロバイダーを選択または作成します。

  •   [SAML（または OAuth 2）認証の選択（SAML (or OAuth 2) Authorization Choice）]については、 [CiscoAVPair] または [GroupMap]のいずれかを選択します。

    •   [CiscoAVPair] を選択した場合、外部認証サーバーで設定された CiscoAVpair の値/文字列に基づいて承認されます。外部 IDP から CiscoAVPair 値を受信すると、 Cisco APIC は、これに従って、リモート ユーザーに権限を割り当てます。

    •   [GroupMap] を選択した場合、外部認証サーバーで構成されたグループ情報に基づいて承認されます。外部 IDP からユーザーグループ情報を受信すると、 Cisco APIC は、 Cisco APIC で設定されているユーザー グループ名との照合を行い、それに応じてリモートユーザーに権限を割り当てます。

      GroupMapを使用した 承認には、2 つの追加パラメータが必要です。それらは次のとおりです：

    •   グループ属性（Group Attribute）を入力します。ここで入力するグループ属性は、外部認証サーバーのグループ属性と一致している必要があります。SAML の場合、グループ属性は、SAML IdP サーバーによって送信される応答のグループ アサーションの名前と一致する必要があります。OAuth2 の場合、グループ属性は、OAuth2 サーバーによって送信される JWT（JSON Web トークン）のグループ要求と一致する必要があります。 

      Example: memberOf (used in Active directory), Groups or groups (used in ping ID/Okta)

      また、OAuth2 の場合、IDP からグループ情報を適切に受信するには、対応するスコープが OAuth2 プロバイダー構成で構成されていることを確認してください。例： 例：openid プロファイル グループ。。

    •   ユーザー グループ マップ ルールを[ユーザー グループ マップ ルールの追加（Add User Group Map Rule）]をクリックして追加します。

        [ユーザー グループ マップ ルールの追加（Add User Group Map Rule）] ウィンドウで、次の詳細を入力します：

      1.   [名前（Name）] フィールドにユーザー グループ マップルールの名前を入力します。

      2.   [説明（Description）] フィールドに、説明を入力します。

      3.   [ユーザーグループ（User Group）] フィールドに、ユーザーが属するユーザーグループの名前を入力します。

        ここで入力したユーザーグループが、外部サーバーのユーザーグループと一致していることを確認してください。これは、外部サーバーから受信した認証情報を検証するために Cisco APIC によって使用されます。権限は、ユーザーが属するユーザーグループに基づいて設定されます。

      4.   [ユーザー権限（User Privileges）]を設定するには、 [ユーザー権限の追加（Add User Privileges）]をクリックします。

      5. セキュリティドメインを追加するには、 [セキュリティドメインの選択（Select Security Domain）] をクリックし、表示されたリストからセキュリティ ドメインを選択します。

      6.   [ロールの追加（Add Role）] をクリックしてロールを選択し、権限タイプ（読み取りまたは書き込み）を関連付け、チェックマークをクリックして、権限をロールに関連付けます。

        さらにロールを追加するには、 [ロールの追加（Add Role）]をクリックし、権限を関連付けます。

      7.   追加（Add） をクリックします（ [ユーザー権限の追加（Add User Privileges）] ウィンドウ）。

      8.   [適用（Apply）] をクリックします（ [ユーザー グループ マップ ルールの追加（Add User Group Map Rule）] ウィンドウ）。

ステップ 7

  [保存（Save）] をクリックします（[ログイン ドメインの作成（Create Login Domain）] 画面） 。

プロバイダーを作成する

この手順に従って、認証/承認プロトコルのプロバイダーを作成します。

始める前に

認証/承認プロトコルのプロバイダーを作成する前の関連する前提条件については、関連するプロトコルのセクションで説明します。

手順

ステップ 1

メニュー バーで、 [管理（Admin）] > [AAA]を選択します。

ステップ 2

[ナビゲーション（Navigation）] ペインで [認証（Authentication）]を選択します。

ステップ 3

[作業（Work）] ペインで、 プロバイダー（Providers）を選択します。

ステップ 4

  [アクション（Actions）] > [プロバイダの作成（Create Provider）]をクリックします。

ステップ 5

表示された [プロバイダの作成（Create Provider）] 画面で、 ホスト名/IP アドレス（Hostname/IP Address）、 [説明（Description）]を入力し、ドロップダウン リストから [レルム（Realm）] 選択します。  [レルム（Realm）] で選択可能なオプションは、以下のとおりです：

  • RADIUS

  • TACACS+

  • LDAP

  • SAML

  • RSA

  • OAuth 2

プロバイダーを構成するためのオプションは動的であり、選択した [レルム（Realm）]に応じて変化します。それぞれの [レルム（Realm）] で使用可能なオプションは、以降の手順で詳しく説明します。

ステップ 6

（任意） RADIUS にのみ適用可能： [レルム サブタイプ（Realm Subtype）]を選択します。オプションは [デフォルト（Default）] または [デュオ（Duo）]です。以下を指定します。

  • RADIUS サーバーのパスワード：確認のためにもう一度パスワードを入力してください。

  •   [到達可能性 EPG の選択（Select Reachability EPG）] をクリックして、エンドポイント グループを選択します。

  • RADIUS のサービス ポート番号。指定できる範囲は 1 ～ 65535 です。デフォルト値は 1812 です。

  • 認証プロトコルのオプションは、 PAP、 CHAP、 MS-CHAPです。このオプションは、 [デフォルト（Default）] を [レルム サブタイプ（Realm Subtype）]として選択した場合にのみ、表示されます。

  • RADIUS サーバーとの通信タイムアウト。有効な範囲は 0 ～ 60 秒です。デフォルトは 5 秒（レルム サブタイプ：デフォルトの場合）、または 30 秒（レルム サブタイプ：Duo）です。

  • RADIUS エンドポイントに接続する際の再試行回数。

  • 定期的なサーバー監視を有効にするには、 [有効（Enabled）] チェック ボックスをオンにして、同じユーザー名とパスワードを入力します。

この手順は、RADIUS プロバイダー設定用です。手順 12 に進むことができます。

ステップ 7

（オプションの手順で TACACS+ にのみ適用）次を指定します。

  • TACACS+ サーバーのパスワード：確認のためにもう一度パスワードを入力してください。

  •   [到達可能性 EPG の選択（Select Reachability EPG）] ドロップダウンリストで、エンドポイントグループを選択します。

  • [ポート（Port）] フィールドに、 TACACS+ のサービス ポート番号を入力します。

    指定できる範囲は 1 ～ 65535 です。非TLS経由の TACACS+ のデフォルト値は 49 です。

  • 認証プロトコルのオプションは、PAP、CHAP、MS-CHAP です。

  • TACACS+ サーバーとの通信タイムアウト。有効な範囲は 0 ～ 60 秒です。デフォルトは 5 秒です。

  • TACACS+ エンドポイントに接続する際の再試行回数。

  • 定期的なサーバー監視を有効にするには、 有効（Enabled） チェック ボックスをオンにして、同じユーザー名とパスワードを入力します。

    TACACS+ over TLSを設定するには、次の手順を実行します。

  •   [TACACS over TLSの有効化（Enable TACACS+ over TLS）] チェックボックスをオンにして、 TACACS+ over TLS接続を有効にします。

    TACACS+ over TLS が有効になっている場合、 共有秘密（Shared Secret）を使用して TACACS+ プロバイダーを構成しないでください。

  •   [SSL証明書の検証レベル（SSL Certificate Validation Level）]で、 [厳格（Strict）] または [許容（Permissive）] オプションを選択します。

  •   [キー リング（Key Ring）] ドロップダウンリストで、 TACACS+ プロバイダーのキー リング証明書を選択します。

  •   [認証局（Certificate Authority）] ドロップダウンリストで、 TACACS+ プロバイダーの CA 証明書を選択します。

  • [ポート（Port）] フィールドに、 TACACS+ のサービス ポート番号を入力します。

    指定できる範囲は 1 ～ 65535 です。TACACS+ over TLS のデフォルト値は 6049 です。

（注）  

 

AAA 権限を持つユーザーは、TACACS+ プロバイダー設定で TLS モードを非 TLS モードに変更したり、その逆に変更したりできます。

この手順は、TACACS+ プロバイダーの設定用です。手順 12 に進むことができます。

ステップ 8

（オプションの手順で LDAP にのみ適用）レルム サブタイプを選択します。オプションは、 [デフォルト（Default）] または [デュオ（Duo）]です。以下を指定します。

  • LDAP ディレクトリのルート識別名（DN）。

  • LDAP ベース DN：APIC がリモートユーザーアカウントを検索する LDAP サーバー内のコンテナ名とパスです。これはパスワードが検証される場所です。フィルタを使用して、APIC が [Cisco AVPair]Cisco AVPair に使用するために要求している属性を見つけます。

  • LDAP サーバーのパスワード。確認のためにもう一度パスワードを入力してください。

  • LDAP のサービスポート番号。指定できる範囲は 1 ～ 65535 です。デフォルト値は 389 です。

  •   [到達可能性 EPG の選択（Select Reachability EPG）] をクリックして、エンドポイント グループを選択します。

  • LDAP サーバーとの通信タイムアウト。有効な範囲は 0 ～ 60 秒です。デフォルトは 30 秒です。

  • LDAP エンドポイントに接続する際の再試行回数。

  •   [有効化（Enable）] チェックボックスを選択して、SSL を有効にします。

  • SSL 証明書の検証レベル。次のオプションがあります。

    • 許容（Permissive）：DUO LDAP SSL 証明書の問題の診断に役立つデバッグ ノブ。

    • 厳格（Strict）：実稼働環境で使用するレベル。

  • LDAP 属性。

  • 認証方式。次のオプションがあります：

    • LDAPバインド

    • パスワード比較

  • フィルタ タイプ。フィルタは、検索要求のエントリの識別に使用される条件を定義する、主要なエレメントです。例：（cn=*）。これは、1 つ以上の cn 値を含むエントリを意味します。次のオプションがあります：

    • デフォルト

    • Microsoft Active Directory

    • カスタム

  • LDAP フィルタ。このフィールドは、選択したフィルタ タイプに基づいて自動入力されます（カスタム オプション [フィルタ タイプ（Filter Type）] を選択した場合を除く）。デフォルトを選択した場合、フィルタは cn=Suseridになります。Microsoft Active Directory を選択した場合、フィルタは sAMAccountName=Suseridになります。

  • 定期的なサーバー監視を有効にするには、 [有効（Enabled）] チェックボックスをオンにして、同じユーザー名とパスワードを入力します。

この手順は、LDAP プロバイダー構成用です。手順 12 に進むことができます。

ステップ 9

（オプションの手順で RSA にのみ適用）次を指定します：

  • RSA サーバーのパスワード：確認のためにもう一度パスワードを入力してください。

  •   [到達可能性 EPG の選択（Select Reachability EPG）] をクリックして、エンドポイント グループを選択します。

  • RSA のサービスポート番号。指定できる範囲は 1 ～ 65535 です。デフォルト値は 1812 です。

  • RSA サーバーとの通信タイムアウト。有効な範囲は 0 ～ 60 秒です。デフォルトは 5 秒です。

  • RSA エンドポイントに接続する際の再試行回数。

  • 定期的なサーバー監視を有効にするには、 [有効（Enabled）] チェックボックスをオンにして、同じものに対するユーザー名とパスワードを入力します。

この手順は、RSA プロバイダー構成用です。手順 12 に進むことができます。

ステップ 10

（オプションの手順で SAML にのみ適用）以下を指定します：

  • [アイデンティティ プロバイダー（Identity Provider）] （IdP）。オプションは、ADFS、OKTA、PING IDENTITY です。

  • [IDP が提供するメタデータURL（Metadata URL provided by IDP）]。

    ADFS の場合、 [IDP が提供するメタデータURL（Metadata URL provided by IDP）] は https://<FQDN of ADFS>/FederationMetadata/2007-06/FederationMetadata.xmlの形式です。

    Ping ID については、Ping ID サーバーの構成セクション（SAML アプリケーションの下）メタデータ URL リンクをコピーします。

  • SAML ベースのサービスの [IdP エンティティ ID（IdP Entity ID）] を入力します。

  •   [SP エンティティ ID（SP Entity ID）]を入力します。これはサービス プロバイダ エンティティ ID です。ID はサービス プロバイダから取得できます。形式は次のとおりです： 

    https://apic-id/api/aaaLoginSSO.json?name=domain-name

  • IdP がプライベート CA によって署名されている場合は、 [認証局の選択（Select Certificate Authority）] を選択します。

  • GUI リダイレクトバナー。URL またはメッセージを指定できます。この情報は、認証のためにユーザーが ID プロバイダーのログイン ページにリダイレクトされる前に表示されます。

  • SAML サーバーとの通信タイムアウト。有効な範囲は 0 ～ 60 秒です。デフォルトは 5 秒です。

  • ドロップダウンリストから [署名アルゴリズム（Signature Algorithm）] を選択します。

  •   [有効（Enabled）] チェックボックスをオンにして、暗号化された SAML アサーション、SAML 応答の署名アサーション、SAML 署名要求、SAML 応答メッセージの署名のすべてまたは一部を有効にできます。

この手順は、SAML プロバイダー構成用です。手順 12 に進むことができます。

ステップ 11

（オプションの手順で OAuth 2 にのみ適用）以下を指定します。

  • クライアント ID：IdP 上の APIC アプリケーションのクライアント識別子。

  • APIC アプリケーションのクライアント シークレット。確認のため、もう一度クライアント シークレットを入力します。

  • ユーザー名要求。トークンのユーザー名属性。例：メール、サブ。

  • 範囲。OAuth 2 範囲のリスト。例：「openid プロファイル」。ユーザー グループ情報を受信するには、IdP プロバイダーで構成された対応するスコープを追加します。例：「openid プロファイル グループ」。

  • OIDC プロトコルの [有効化（Enable）] または [無効化（Disable）] を選択します。

  •   [有効（Enabled）] チェック ボックスをオンにして、トークンの署名を検証します。

  • JWKS エンドポイント。トークンを検証するための JSON Web キーセット（JWKS）。このフィールドは、トークン署名の検証を有効にしている場合にのみ表示されます。

  • 認証エンドポイント。IdP エンドポイント認証 URL。IdP サーバーから認可エンドポイントを取得します。このフィールドは、OIDC プロトコルが無効な場合にのみ表示されます。

  • トークン エンドポイント。IdP エンドポイント トークンの URL。IdP サーバーからトークン エンドポイントを取得します。このフィールドは、OIDC プロトコルが無効な場合にのみ表示されます。

  • 発行元 URL IdP サーバーから発行者の URL を取得します。このフィールドは、OIDC プロトコルが有効な場合にのみ表示されます。

  • IdP がプライベート CA によって署名されている場合は、 [認証局の選択（Select Certificate Authority）] を選択します。

  •   [到達可能性 EPG の選択（Select Reachability EPG）] をクリックして、エンドポイント グループを選択します。

  • OAuth 2 サーバーとの通信タイムアウト。有効な範囲は 0 ～ 60 秒です。デフォルトは 5 秒です。

  • GUI リダイレクト バナー。これは URL またはメッセージが可能です。この情報は、認証のためにユーザーが ID プロバイダーのログインページにリダイレクトされる前に表示されます。

この手順は、OAuth 2 プロバイダー構成用です。手順 12 に進むことができます。

ステップ 12

  [保存（Save）]。

ローカル ユーザーの設定

初期の設定スクリプトで、管理者アカウントが設定され、管理者はシステム起動時の唯一のユーザーとなります。  APIC は、きめ細かなロールベースのアクセス コントロール システムをサポートしており、そのシステムでは、権限が少ない管理者以外のユーザーを含め、ユーザー アカウントをさまざまなロールで作成することができます。

GUI を使用したローカル ユーザーの設定

始める前に

  • ACI ファブリックがインストールされていて、 APIC コントローラがオンラインで、 APIC クラスターが形成され、正常に動作していること。

  • 必要に応じて、ユーザーがアクセスするセキュリティ ドメインが定義されていること。たとえば、新しいユーザー アカウントがテナントへのアクセスに制限される場合、テナント ドメインはそれに応じてタグ付けされます。

  • 以下を行うことができる APIC ユーザーアカウントを使用できること：

    • TACACS+ プロバイダーの作成。

    • ターゲット セキュリティ ドメインでのローカル ユーザ アカウントの作成。ターゲット ドメインが [すべて（all）]である場合、新しいローカル ユーザーの作成に使用するログイン アカウントは、 [すべて（all）]にアクセスできるファブリック全体の管理者である必要があります。ターゲット ドメインがテナントである場合、新しいローカル ユーザーの作成に使用するログイン アカウントは、ターゲット テナント ドメインに対する完全な読み取り/書き込みアクセス権を持つテナント管理者である必要があります。

手順

ステップ 1

メニュー バーで、 [管理（Admin）] > [AAA]を選択します。

ステップ 2

次に [ナビゲーション（Navigation）] ペインで、 [ユーザー（Users）]をクリックします。

次に [作業（Work）] ペインで、 [ローカルユーザー（Local Users）] タブを選択します。

ステップ 3

この [作業（Work）] ペインで、タスク アイコンのドロップダウン リストをクリックし、 [ローカル ユーザーの作成（Create Local User）]を選択します。

ステップ 4

次に [ステップ 1 > ユーザー アイデンティティ（STEP 1 > User Identity）] ダイアログボックスで、次の操作を実行します：

  1. この [ログイン ID（Login ID）] フィールドに、ID を追加します。

    ログイン ID は、次のガイドラインを満たしている必要があります：

    • これは APIC内で一意である必要があります。

    • 先頭は英字にする必要があります。

    • 1 〜 32 文字を使用できます。

    • 英数字、アンダースコア、ハイフン、およびドットを使用してください。

    ユーザー アカウントの作成後は、ログイン ID を変更できません。そのユーザー アカウントを削除し、新しいユーザー アカウントを作成する必要があります。

  2. 次に パスワード（Password） フィールドにパスワードを入力します。

    ユーザーがパスワードを設定する時点で、 Cisco APIC は、次の基準に基づいて検証します。

    • パスワードの最小長は 8 文字です。

    • パスワードの最大長は 64 文字です。

    • 連続して繰り返される文字は 3 文字未満にします。

    • （R6.1.1 まで）パスワードには、小文字、大文字、数字、記号のうち、3 つ以上の文字タイプが含まれる必要があります。

    • （R6.1.2 以降）パスワード強度チェックの条件に応じて、次の要件を満たす必要があります。

      • デフォルト条件が有効の場合：

        • パスワードには、小文字、大文字、数字、記号のうち、3 つ以上の文字タイプが含まれる必要があります。R6.1.3 から、パスワードには小文字、数字、記号の 3 つすべての文字タイプが含まれる必要があります。

      • カスタム条件が有効の場合は、次の条件から 3 つ以上を選択します。

        • パスワードには少なくとも 1 つの大文字を含める必要があります。

        • パスワードには少なくとも 1 つの小文字を含める必要があります。

        • パスワードには少なくとも 1 つの数字を含める必要があります。

        • パスワードには、少なくとも 1 つの記号を含める必要があります。

        • パスワードには同一の文字を 3 回以上連続して含めることはできません。

        • パスワードには、QWERTY キーボード レイアウトから 3 文字以上連続する文字を含めることはできません。これは、小文字、大文字、数字にのみ適用されます。

    • 簡単に推測できるパスワードは使用しません。

    • ユーザー名やユーザー名を逆にしたものは使用できません。

    • cisco、isco、またはこれらの文字列の並べ替えを変化させたものや、それらの文字を大文字化して得られる変形語であってはなりません。

  3. それから パスワードの確認（Confirm Password） フィールドで、パスワードを確認します。

  4. （任意） 証明書ベースの認証の場合 [ユーザー証明書属性（User Certificate Attribute）] フィールドに、認証証明書からのユーザー アイデンティティを入力します。

  5. それから [次へ（Next）]をクリックします。

ステップ 5

ユーザー アカウントは、 [アカウント ステータス（Account Status）] コントロールでアクティブ化または非アクティブ化すること、さらに [アカウントの期限（Account Expires）] コントロールで有効期限を設定することができます。

ステップ 6

次に [ステップ 2 > セキュリティ（STEP 2 > Security）] ダイアログ ボックスの、 セキュリティ ドメイン（Security Domain）で、ユーザーに必要なセキュリティ ドメインを選択し、 [次へ（Next）]をクリックします。

ステップ 7

次に [ステップ 3 > ロール（Step 3 > Roles）] ダイアログボックスで、次の操作を実行します。

  1. まず [+] をクリックして、ユーザーをドメインに関連付けます。

  2. ドロップダウン リストから [ロール名（Role Name）] および [役割の特権タイプ（Role Privilege Type）] をユーザー用に選択します。

  3. 次に [更新（Update）] をクリックします。

読み取り専用または読み取り/書き込み権限を提供できます。

ステップ 8

最後に [終了（Finish）] をクリックします。

GUI を使用した SSH 公開キー認証の設定

始める前に

  • ターゲット セキュリティ ドメインでローカル ユーザー アカウントを作成します。ターゲット ドメインが allである場合、新しいローカル ユーザーの作成に使用するログイン アカウントは、 allにアクセスできるファブリック全体の管理者である必要があります。。ターゲット ドメインがテナントである場合、新しいローカル ユーザーの作成に使用するログイン アカウントは、ターゲット テナント ドメインに対する完全な読み取り/書き込みアクセス権を持つテナント管理者である必要があります。

  • UNIX コマンド ssh-keygenを使用して公開キーを生成します。

    デフォルトのログイン ドメインは [ローカル（local）] に設定する必要があります。

手順

ステップ 1

メニュー バーで、 [管理（Admin）] > [ユーザー（Users）] を選択し、 ローカル（Local） タブを選択していることを確認します。

ステップ 2

  [作業（Work）] ペインで、先ほど作成したユーザーの名前をクリックします。

ユーザーに関する情報を含むウィンドウが右側に表示されます。

ステップ 3

  [詳細（Details）] アイコンをクリックすると、 、ユーザーの詳細が、新しい画面に表示されます。

下方向にスクロールして SSH 認証の詳細を確認します。

ステップ 4

  [編集（Edit）] アイコンをクリックすると, 、 [ローカル ユーザーの編集（Edit Local User）] 画面が表示されます。必要に応じて、SSH の詳細を変更できます。

（注）  

 

リモート ロケーションにダウンロードするための SSH 秘密キー ファイルを作成するには、メニューバーで、 [ファームウェア（Firmware）] > [ダウンロード タスク（Download Tasks）]を展開します。

ステップ 5

  [保存（Save）]をクリックします。

リモート ユーザーの設定

ローカルユーザーを設定する代わりに、一元化された企業クレデンシャル データセンターで、 APIC をポイントすることができます。  APIC は、Lightweight Directory Access Protocol（LDAP）、Active Directory、RADIUS、および TACACS+ をサポートしています。


（注）  

APIC がマイノリティである（クラスターから切断されている）場合、ACI は分散システムであり、ユーザー情報が APICS に分散されるため、リモート ログインは失敗する可能性があります。ただし、ローカル ログインは APIC に対してローカルであるため、この場合も機能します。

3.1(1) リリース以降、 サーバー モニタリング は RADIUS、TACACS +、LDAP、および RSA を介して設定され、個別の AAA サーバーがアクティブかを判断できます。サーバー モニタリング機能は、サーバーがアクティブかどうか確認するためそれぞれのプロトコルのログインを使用します。たとえば、LDAP サーバーは ldap lログインを使用し、Radius サーバーはサーバーがアクティブか判断するサーバー モニタリング機能を持つ radius のログインを使用します。

外部認証プロバイダーを通じて認証されたリモート ユーザーを設定するには、次の前提条件を満たす必要があります。

  • DNS 設定は、RADIUS サーバーのホスト名ですでに名前解決されている必要があります。

  • 管理サブネットを設定する必要があります。

外部認証サーバーの AV ペア

Cisco APIC では、管理者が外部認証サーバーで Cisco AV ペアを設定する必要があります。Cisco AV ペアは、ユーザーが必要とする APIC RBAC ロールと権限を指定します。Cisco AV ペアの形式は、RADIUS、LDAP、または TACACS+ のものと同じです。

外部認証サーバーで Cisco AV ペアを設定するには、管理者が既存のユーザー レコードに Cisco AV ペアを追加します。Cisco AV ペアの形式は次のとおりです： 

shell:domains = 
domainA/writeRole1|writeRole2|writeRole3/readRole1|readRole2,
domainB/writeRole1|writeRole2|writeRole3/readRole1|readRole2
shell:domains = 
domainA/writeRole1|writeRole2|writeRole3/readRole1|readRole2,
domainB/writeRole1|writeRole2|writeRole3/readRole1|readRole2(16003)

Cisco APIC リリース 2.1 より、AV ペアで UNIX ID が指定されていない場合は、APIC が一意の UNIX ユーザー ID を内部的に割り当てます。


（注）  

APIC の Cisco AV ペアの形式は互換性があり、他の Cisco AV ペアの形式と共存できます。APIC はすべての AV ペアから、最初に一致した AV ペアを選択します。

リリース 3.1(x) 以降、AV ペアの shell:domains=all//admin を使用すると、ユーザーに読み取り専用権限を割り当てて、スイッチにアクセスしてコマンドを実行することができます。

  APIC は、次の正規表現をサポートしています。 

shell:domains\\s*[=:]\\s*((\\S+?/\\S*?/\\S*?)(,\\S+?/\\S*?/\\S*?){0,31})(\\(\\d+\\))$
shell:domains\\s*[=:]\\s*((\\S+?/\\S*?/\\S*?)(,\\S+?/\\S*?/\\S*?){0,31})$

例：

  • 例 1：writeRoles のみを持つ単一のセキュリティ ドメインを含む Cisco AV ペア：
    

shell:domains=domainA/writeRole1|writeRole2/
  • 例 2：readRoles のみを持つ単一のセキュリティ ドメインを含む Cisco AV ペア：
    

shell:domains=domainA//readRole1|readRole2

（注）  

「/」文字は、セキュリティ ドメインごとの writeRoles と readRoles の間の区切り文字であり、1 つのタイプのロールのみを使用する場合でも必要です。

Cisco AV ペアの文字列では、大文字と小文字が区別されます。使用する大文字と小文字がドメイン名またはロールに一致していない場合は、エラーが表示されなくても、予期しない権限が付与されることがあります。

オープン RADIUS サーバー（/etc/raddb/users）の設定例は次のとおりです： 

aaa-network-admin Cleartext-Password := "<password>"
Cisco-avpair = "shell:domains = all/aaa/read-all(16001)"

外部認証サーバの AV ペアの設定

属性/値（AV）のペア文字列のカッコ内の数字は、セキュア シェル（SSH）または telnet を使用してログインしたユーザーの UNIX ユーザー ID として使用されます。


（注）  

6.0(2) リリース以降、telnet はサポートされていません。
手順

外部認証サーバの AV ペアを設定します。

Cisco AV ペアの定義は次のとおりです（シスコは、UNIX ユーザ ID が指定されているかどうかにかかわらず AV ペアをサポートします）
例:

shell:domains = domainA/writeRole1|writeRole2|writeRole3/readRole1|readRole2,domainB/writeRole1|writeRole2|writeRole3/readRole1|readRole2
shell:domains = domainA/writeRole1|writeRole2|writeRole3/readRole1|readRole2,domainB/writeRole1|writeRole2|writeRole3/readRole1|readRole2(8101)

These are the boost regexes supported by APIC:
uid_regex("shell:domains\\s*[=:]\\s*((\\S+?/\\S*?/\\S*?)(,\\S+?/\\S*?/\\S*?){0,31})(\\(\\d+\\))$");
regex("shell:domains\\s*[=:]\\s*((\\S+?/\\S*?/\\S*?)(,\\S+?/\\S*?/\\S*?){0,31})$");

次に、例を示します。

shell:domains = coke/tenant-admin/read-all,pepsi//read-all(16001)

TACACS+ アクセス用の APIC の設定

始める前に

  •   Cisco Application Centric Infrastructure （ACI）ファブリックがインストールされていて、 Application Policy Infrastructure Controller（APIC）がオンラインであり、そして APIC クラスターが形成され、正常に動作していること。

  • TACACS+ サーバーのホスト名または IP アドレス、ポート、およびキーを使用できること。

  •   APIC 管理エンドポイント グループを使用できること。

手順

ステップ 1

  APICで、TACACS+ プロバイダーを作成します。

TACACS+ プロバイダーの設定については、 プロバイダーを作成するを参照してください。

APIC GUI のインバンドまたはアウトオブバンド管理をトグルするには：

[ナビゲーション（Navigation）] ペインで システム（System） > [システム設定（System Settings）] > [APIC 接続の環境設定（APIC Connectivity Preferences）]を選択します。[作業（Work）] ペインで、 [インバンド（inband）] または [アウトオブバンド（ooband）]のいずれかを選択します。

ステップ 2

TACACS+ の ログイン ドメイン（Login Domain） を作成します。

詳細な手順については、 GUI を使用してローカル ドメインを作成するを参照してください。

次のタスク

これで、 APIC TACACS+ 構成手順は完了です。次に、RAIDUS サーバーも使用する場合は、 APIC RADIUS 用の設定も行います。TACACS+ サーバーのみを使用する場合は、次の ACS サーバー設定に関するトピックに進みます。

RADIUS アクセス用の APIC の設定

始める前に

  • ACI ファブリックがインストールされていて、 Application Policy Infrastructure Controller（APIC）がオンラインであり、そして APIC クラスターが形成され、正常に動作していること。

  • RADIUS サーバーのホスト名または IP アドレス、ポート、認証プロトコル、およびキーを使用できること。

  •   APIC 管理エンドポイント グループを使用できること。

手順

ステップ 1

  APICで、RADIUS プロバイダーを作成します。

RADIUS プロバイダーの設定については、 プロバイダーを作成するを参照してください。

APIC GUI のインバンドまたはアウトオブバンド管理のトグル：

[ナビゲーション（Navigation）] ペインで [システム（System）] > [システム設定（System Settings）] > [APIC 接続の設定（APIC Connectivity Preferences）]を選択します。作業ペインで、 [インバンド（inband）] または [アウトオブバンド（ooband）]のいずれかを選択します。

ステップ 2

RADIUS の場合。 ログイン ドメイン（Login Domain） を作成します。

詳細な手順については、 GUI を使用してローカル ドメインを作成するを参照してください。

次のタスク

これで、 APIC RADIUS 設定手順は完了です。次に、RADIUS サーバーを設定します。

Cisco Secure Access Control Server の設定 、RADIUS および TACACS+ からのアクセス： APIC

始める前に

  • Cisco Secure Access Control Server (ACS) バージョン 5.5 がインストールされ、オンラインになっていること。


    （注）  

    ここでは手順の説明に ACS v5.5 が使用されています。ACS の他のバージョンでもこのタスクを実行できる可能性がありますが、GUI の手順はバージョンによって異なる場合があります。

  •   Cisco Application Policy Infrastructure Controller （Cisco APIC）の RADIUS キーまたは TACACS+ キーを使用できること（両方を設定する場合は両方のキー）。

  • APIC が設置されオンラインになっており、APIC クラスタが形成されて正常に動作していること。

  • RADIUS または TACACS+ のポート、認証プロトコル、およびキーを使用できること。

手順

ステップ 1

APIC をクライアントとして設定するには、ACS サーバーにログインします。

  1.   [ネットワーク リソース（Network Resources）] > [ネットワーク デバイス グループ（Network Devices Groups）] > [ネットワーク デバイスと AAA クライアント（Network Devices and AAA Clients）]に移動します。

  2. クライアント名、APIC インバンド IP アドレスを指定し、TACACS + または RADIUS（または両方）の認証オプションを選択します。

    （注）  

     

    RADIUS または TACACS+ のみの認証が必要な場合は、必要なオプションのみを選択します。

  3. 共有秘密（キー）や認証オプションに適したポートなど、認証の詳細を指定します。

    （注）  

     

      共有秘密は、APIC の プロバイダー キーと一致する必要があります。

ステップ 2

アイデンティティ グループを作成します。

  1.   [ユーザーおよびアイデンティティ ストア（Users and Identity Stores）] > [内部グループ（Internal Groups）] オプションに移動します。

  2.   [名前（Name）]、および 親グループ（Parent Group） を適切に指定します。

ステップ 3

ユーザーをアイデンティティ グループにマッピングします。

  1. リスト [ナビゲーション（Navigation）] ペインで、 [ユーザーとアイデンティティ ストア（Users and Identity Stores）] > [内部アイデンティティ ストア（Internal Identity Stores）] > [ユーザー（Users）] オプションをクリックします。

  2. ユーザーの [名前（Name）]、および [アイデンティティ グループ（Identity Group）] を適切に指定します。

ステップ 4

ポリシー要素を作成します。

  1.   [ポリシー要素（Policy Elements）] オプションに移動します。

  2. RADIUS の場合、[承認と許可（Authorization and Permissions）] > [ネットワーク アクセス（Network Access）] > [承認プロファイル（Authorization Profiles）] の [名前（Name）]を指定します。TACACS+ の場合、[承認と許可（Authorization and Permissions）] > [デバイス管理（Device Administration）] > [シェル プロファイル（Shell Profile）] の [名前（Name）] を適切に指定します。

  3. RADIUS の場合、 [属性（Attribute）] を [cisco-av-pair]として、 [タイプ（Type）] を 文字列として、および [値（Value）] を shell:domains = <domain>/<role>/,<domain>// role として適切に指定します。TACACS+の場合は、 [属性（Attribute）] を [cisco-av-pair]として、 [要件（Requirement）] を [必須（Mandatory）]として、および [値（Value）] を shell:domains = <domain>/<role>/,<domain>// role として適切に指定します。

      [値（Value）] フィールドのシンタックスは、書き込み権限を付与するかどうかを以下のように決定します：

    • 読み取り専用権限の場合、シンタックスは shell:domains = <domain>/<role>/です。

    • 読み取り専用権限の場合、 シンタックスは shell:domains = <domain>// <role>です。

    たとえば、 cisco-av-pair の値が shell:domains = solar/admin/,common// read-allの場合、 solar はセキュリティ ドメイン、 admin は、 solarというセキュリティドメインのこのユーザーに書き込み権限を付与するロールで、 common はテナントcommon であり、 read-all は、読み取り権限を持つロールで、このユーザーにテナント common すべてに対する読み取り権限を付与します。

ステップ 5

サービス選択ルールを作成します。

  1. RADIUS の場合、 [アクセス ポリシー（Access Policies）] > [デフォルトのデバイス ネットワーク アクセス アイデンティティ（Default Device Network Access Identity）] > [承認（Authorization）] に移動して、アイデンティティ グループをポリシー要素に関連付けるサービス 選択ルールを作成し、ルールの [名前（Name）]、 [ステータス（Status）]、および 条件（Conditions） を適切に指定し、 [追加（Add）] をクリックして[内部ユーザー：すべてのグループ内の UserIdentityGroup（Internal Users:UserIdentityGroup in ALL Groups）]：<identity group name>を追加します。

  2. TACACS+ の場合、サービス選択ルールを作成して ID グループをシェル プロファイルに関連付けるには、 [アクセス ポリシー（Access Policies）] > [デフォルトのデバイス管理アイデンティティ（Default Device Admin Identity）] > [承認（Authorization）]に移動して、アイデンティティ グループをシェル プロファイルに関連付けるサービス 選択ルールを作成します。ルールの [名前（Name）]、 条件（Conditions）を指定し、 [選択（Select）] をクリックして シェルプロファイル（Shell Profile） を適切に選択します。

次のタスク

新しく作成した RADIUS および TACACS + ユーザーを使用して APIC にログインします。割り当てられた RBAC のロールと権限に従って、ユーザーが正しい APIC セキュリティ ドメインにアクセスできることを確認します。ユーザーは、明示的に許可されていない項目にアクセスできてはなりません。読み取り/書き込みアクセス権は、そのユーザーに設定されたものと一致している必要があります。

Cisco AVPair を使用した APIC アクセス用の Windows Server 2012 LDAP の設定

始める前に

  • 最初に LDAP サーバーを設定し、次に Cisco Application Policy Infrastructure Controller （Cisco APIC）を LDAP アクセス用に設定します。

  • Microsoft Windows Server 2012 がインストールされ、オンラインになっていること。

  • Microsoft Windows Server 2012 サーバー マネージャの ADSI Edit ツールがインストールされていること。ADSI Edit をインストールするには、Windows Server 2012 サーバー マネージャのヘルプに記載されている手順に従ってください。

  • [CiscoAVPair] attribute specifications: Common Name = [CiscoAVPair], LDAP Display Name = [CiscoAVPair], Unique X500 Object ID = 1.3.6.1.4.1.9.22.1, Description = [CiscoAVPair], Syntax = [大文字小文字を区別した文字列（Case Sensitive String）]。


    （注）  

    LDAP 設定の場合、ベスト プラクティスは [CiscoAVPair] を属性文字列として使用することです。顧客がオブジェクト ID 1.3.6.1.4.1.9.22.1 を使用して問題が発生した場合、その他のオブジェクト ID 1.3.6.1.4.1.9.2742.1-5 が LDAPサーバにも使用できます。

  • 以下を行うことができる Microsoft Windows Server 2012 ユーザ アカウントを使用できること。

    • ADSI Editを実行して、 [CiscoAVPair] 属性を Active Directory（AD）スキーマに設定します。

    • Active Directory LDAP ユーザーを [CiscoAVPair] 属性パラメータに対するアクセス許可を持つように設定します。

  • ポート 636 は、SSll/TLS と LDAP の統合に必要です。

手順

ステップ 1

ドメイン管理者として Active Directory（AD）サーバーにログインします。

ステップ 2

  [CiscoAVPair] 属性を AD スキーマに追加します。

  1.   [スタート（Start）] > [ファイル名を指定して実行（Run）]に移動し、 MMC と入力して、 Enterを押します。

    Microsoft Management Console（MMC）が開きます。

  2.   [ファイル（File）] > [スナップインの追加と削除（Add/Remove Sanp-in）] > [追加（Add）]に移動します。

  3.   [スタンドアロン スナップインの追加（Add Standalonee Snap-in）] ダイアログ ボックスで、 [Active Directory スキーマ（Active Directory Schema）] を選択し、 [追加（Add）]をクリックします。

    MMC コンソール が開きます。

  4.   [属性（Attributes）] フォルダで、 [属性の作成（Create Attribute）] オプションを選択します。

      [新しい属性の作成（Create New Attribute）] ダイアログボックスが表示されます。

  5.   [CiscoAVPair] を [共通名（Common Name）]として、また [CiscoAVPair] を [LDAP 表示名（LDAP Display Name）]として、 1.3.6.1.4.1.9.22.1 を [一意の X500 オブジェクト ID（Unique X500 Object ID）]として入力し、 [大文字小文字を区別した文字列（Case Sensitive String）] を [構文（Syntax）]として入力します。

  6.   [OK] をクリックして、属性を保存します。

ステップ 3

  [ユーザー プロパティ（User Properties）] クラスを [CiscoAVPair] 属性を含めるように更新します。

  1. MMC コンソールで [クラス（Class）] フォルダを展開し、 [ユーザー（user）] クラスを右クリックして、 [プロパティ（Properties）]を選択します。

      [ユーザー プロパティ（User Properties）] ダイアログ ボックスが開きます。

  2.   [属性（Attributes）] タブをクリックし、 [追加（Add）] をクリックし、 [スキーマオブジェクトの選択（Select Schema Object）] ウィンドウを開きます。

  3.   [スキーマオブジェクトの選択（Select Schema Object）：] リストで、 [CiscoAVPair]を選択し、 [適用（Apply）]をクリックします。

  4. MMC コンソールで、 [Active Directory スキーマ（Active Directory Schema）]を右クリックし、 [スキーマのリロード（Reload the Schema）]を選択します。

ステップ 4

  [CiscoAVPair] 属性の権限を設定します。

ここで、LDAP が [CiscoAVPair] 属性を含むようにするには、LDAP ユーザーに Cisco APIC 権限を、 Cisco APIC RBAC ロールを割り当てて、与える必要があります。

  1. [ADSI Edit] ダイアログ ボックスで、 Cisco APICにアクセスする必要があるユーザーを見つけます。

  2. ユーザー名を右クリックし、 [プロパティ（Properties）]を選択します。

      <user>[プロパティ（Properties）] ダイアログ ボックスが開きます。

  3.   [属性エディタ（Attribute Editor）] タブで、 [CiscoAVPair] 属性を選択し、 [値（Value）] を `shell:domains=<domain>/<role>|<domain>/|`として入力します。

    たとえば、 CiscoAVPair の値が shell:domains = solar/admin/,common// read-all(16001)の場合、 [solar] がセキュリティドメイン、 [admin] が [solar]というセキュリティ ドメインのこのユーザーに書き込み権限を付与するロールで、 [common] が Cisco Application Centric Infrastructure （Cisco ACI）テナント common であり、 [read-all(16001)] は、読み取り権限を持つロールで、このユーザーに Cisco ACI テナント common すべてに対する読み取り権限を付与します。

  4.   [OK] をクリックして変更を保存し <user>[プロパティ（Properties）] ダイアログ ボックスを閉じます。

LDAP サーバーは Cisco APICにアクセスするように設定されます。

次のタスク

  Cisco APIC を LDAP アクセス用に設定します。

LDAP アクセス用の APIC の設定

始める前に

  • Cisco Application Centric Infrastructure（ACI）ファブリックがインストールされていて、Application Policy Infrastructure コントローラがオンラインになっており、APIC クラスタが形成されていて正常に動作していること。

  • LDAP サーバのホスト名または IP アドレス、ポート、バインド DN、ベース DN、およびパスワードを使用できること。

  • APIC 管理エンドポイント グループを使用できること。

手順

ステップ 1

APIC で、LDAP プロバイダーを設定します。

LDAP プロバイダーの設定については、 プロバイダーを作成するを参照してください。

APIC GUI のインバンドまたはアウトオブバンド管理のトグル：

[ナビゲーション（Navigation）] ペインで システム（System） > [システム設定（System Settings）] > [APIC 接続の設定（APIC Connectivity Preferences）]を選択します。[作業 (Work)] ペインで、 [インバンド（inband）] または [アウトオブバンド（ooband）]のいずれかを選択します。

ステップ 2

LDAP の場合。 [ログイン ドメイン（Login Domain）] を作成します。

詳細な手順については、 GUI を使用してローカル ドメインを作成するを参照してください。

次のタスク

これで、APIC LDAP 設定手順は完了です。次に、APIC LDAP ログイン アクセスをテストします。

Cisco AV ペアが欠落しているか不良であるリモート ユーザーのデフォルトの動作の変更

手順

ステップ 1

メニュー バーで、 [管理（Admin）] > [認証（Authentication）] > [AAA] > [ポリシー（Policy）] タブを選択します。

ステップ 2

  [リモート ユーザー ログイン ポリシー（Remote user login policy）] ドロップダウンリストから、 [デフォルト ロールの割り当て（Assign Default Role）]を選択します。

デフォルト値は、 [ログインなし（No Login）]です。  [デフォルトロールの割り当て（Assign Default Role）] オプションは、Cisco AV ペアが欠落しているか不良であるユーザーに最小限の読み取り専用権限を割り当てます。不正な AV ペアは、解析ルール適用時に問題があった AV ペアです。

署名ベースのトランザクションについて

Cisco ACI ファブリックの APIC コントローラは、ユーザを認証するためにさまざまな方法を提供します。

主要な認証方式ではユーザ名とパスワードが使用され、APIC REST API は APIC に対するその後のアクセスに使用できる認証トークンを返します。これは、HTTPS が使用不可であるか有効でない状況では安全でないと見なされます。

提供されている別の認証形式では、トランザクションごとに計算される署名が活用されます。その署名の計算には秘密キーが使用され、そのキーは安全な場所に保管して秘密にしておく必要があります。APIC がトークン以外の署名が付いた要求を受信すると、APIC は X.509 証明書を活用して署名を確認します。署名ベースの認証では、APIC に対するすべてのトランザクションに新しく計算された署名が必要です。これは、ユーザがトランザクションごとに手動で行うタスクではありません。理想的には、この機能は APIC と通信するスクリプトまたはアプリケーションで使用する必要があります。この方法では、攻撃者がユーザ クレデンシャルを偽装またはなりすますためには RSA/DSA キーを解読する必要があるため、最も安全です。

（注）  

また、リプレイ攻撃を防ぐためには HTTPS を使用する必要があります。

認証に X.509 証明書ベースの署名を使用する前に、次の必須タスクが完了していることを確認します。

  1. OpenSSL または同様のツールを使用して X.509 証明書と秘密キーを作成します。

  2. APIC のローカル ユーザを作成します（ローカル ユーザがすでに利用可能である場合、このタスクはオプションです）。

  3. APIC のローカル ユーザに X.509 証明書を追加します。

注意事項と制約事項

次の注意事項と制約事項に従ってください。

  • ローカル ユーザはサポートされます。リモート AAA ユーザはサポートされません。

  • APIC GUI は証明書認証方式をサポートしません。

  • WebSocket と eventchannel は X.509 要求では動作しません。

  • サード パーティにより署名された証明書はサポートされません。自己署名証明書を使用します。

X.509 証明書と秘密キーの生成

手順

ステップ 1

OpenSSL コマンドを入力して、X.509 証明書と秘密キーを生成します。

例:

$ openssl req -new -newkey rsa:1024 -days 36500 -nodes -x509 -keyout userabc.key -out userabc.crt -subj '/CN=User ABC/O=Cisco Systems/C=US'

（注）  

 

  • X.509 証明書が生成されると、APIC のユーザ プロファイルに追加され、署名の確認に使用されます。秘密キーは、署名を生成するためにクライアントによって使用されます。

  • 証明書には公開キーは含まれていますが、秘密キーは含まれていません。公開キーは、計算された署名を確認するために APIC によって使用される主要な情報です。秘密キーが APIC に保存されることはありません。このキーを秘密にしておく必要があります。

ステップ 2

OpenSSL を使用して証明書のフィールドを表示します。

例:

$ openssl x509 -text -in userabc.crt
        Certificate:
            Data:
                Version: 3 (0x2)
                Serial Number:
                    c4:27:6c:4d:69:7c:d2:b6
                Signature Algorithm: sha1WithRSAEncryption
                Issuer: CN=User ABC, O=Cisco Systems, C=US
                Validity
                    Not Before: Jan 12 16:36:14 2015 GMT
                    Not After : Dec 19 16:36:14 2114 GMT
                Subject: CN=User ABC, O=Cisco Systems, C=US
                Subject Public Key Info:
                    Public Key Algorithm: rsaEncryption
                    RSA Public Key: (1024 bit)
                        Modulus (1024 bit):
                            00:92:35:12:cd:2b:78:ef:9d:ca:0e:11:77:77:3a:
                            99:d3:25:42:94:b5:3e:8a:32:55:ce:e9:21:2a:ff:
                            e0:e4:22:58:6d:40:98:b1:0d:42:21:db:cd:44:26:
                            50:77:e5:fa:b6:10:57:d1:ec:95:e9:86:d7:3c:99:
                            ce:c4:7f:61:1d:3c:9e:ae:d8:88:be:80:a0:4a:90:
                            d2:22:e9:1b:25:27:cd:7d:f3:a5:8f:cf:16:a8:e1:
                            3a:3f:68:0b:9c:7c:cb:70:b9:c7:3f:e8:db:85:d8:
                            98:f6:e3:70:4e:47:e2:59:03:49:01:83:8e:50:4a:
                            5f:bc:35:d2:b1:07:be:ec:e1
                        Exponent: 65537 (0x10001)
                X509v3 extensions:
                    X509v3 Subject Key Identifier:
                        0B:E4:11:C7:23:46:10:4F:D1:10:4C:C1:58:C2:1E:18:E8:6D:85:34
                    X509v3 Authority Key Identifier:
                        keyid:0B:E4:11:C7:23:46:10:4F:D1:10:4C:C1:58:C2:1E:18:E8:6D:85:34
                        DirName:/CN=User ABC/O=Cisco Systems/C=US
                        serial:C4:27:6C:4D:69:7C:D2:B6
        
                    X509v3 Basic Constraints:
                        CA:TRUE
            Signature Algorithm: sha1WithRSAEncryption
                8f:c4:9f:84:06:30:59:0c:d2:8a:09:96:a2:69:3d:cf:ef:79:
                91:ea:cd:ae:80:16:df:16:31:3b:69:89:f7:5a:24:1f:fd:9f:
                d1:d9:b2:02:41:01:b9:e9:8d:da:a8:4c:1e:e5:9b:3e:1d:65:
                84:ff:e8:ad:55:3e:90:a0:a2:fb:3e:3e:ef:c2:11:3d:1b:e6:
                f4:5e:d2:92:e8:24:61:43:59:ec:ea:d2:bb:c9:9a:7a:04:91:
                8e:91:bb:9d:33:d4:28:b5:13:ce:dc:fe:c3:e5:33:97:5d:37:
                cc:5f:ad:af:5a:aa:f4:a3:a8:50:66:7d:f4:fb:78:72:9d:56:
                91:2c
        [snip]

ローカル ユーザの設定

GUI を使用したローカル ユーザーの作成とユーザー証明書の追加

手順

ステップ 1

メニュー バーで、 [管理（ADMIN）] > [AAA]を選択します。。

ステップ 2

次に [ナビゲーション（Navigation）] ペインで、 [ユーザー （Users）] をクリックし、 [ローカルユーザー（Local Users）] を [作業（Work）] ペインでクリックします。

ステップ 3

  [作業（Work）] ペインで、 [ローカルユーザー（Local Users）] タブが表示されていることを確認します。

デフォルトでは admin ユーザーが存在します。

ステップ 4

  [作業（Work）] タスク アイコンのドロップダウン リストをクリックし、 [ローカル ユーザーの作成（Create Local User）]を選択します。

ステップ 5

  [セキュリティ（Security）] ダイアログボックスで、ユーザーに必要なセキュリティ ドメインを選択し、 [次へ（Next）]をクリックします。

ステップ 6

  [ロール（Roles）] ダイアログボックスで、ユーザーのロールを選択するためのオプション ボタンをクリックし、 [次へ（Next）]をクリックします。

読み取り専用または読み取り/書き込み権限を提供できます。

ステップ 7

  [ユーザー アイデンティティ（User Identity）] ダイアログボックスで、次の操作を実行します。

  1.   [ログイン ID（Login ID）] フィールドに、ID を追加します。

  2.   パスワード（Password） フィールドにパスワードを入力します。

  3.   パスワードの確認（Confirm Password） フィールドで、パスワードを確認します。

  4. （オプション）証明書ベースの認証の場合は、 [ユーザー証明書属性（User Certificate Attribute）] フィールドに、認証証明書からのユーザー アイデンティティを入力します。

  5.   [終了（Finish）]をクリックします。

ステップ 8

  [ナビゲーション（Navigation）] ペインで、作成したユーザーの名前をクリックします。  [作業（Work）] ペインで、 [+] 記号（ [セキュリティ ドメイン（Security Domains）] のユーザーの横）を展開します。

ユーザのアクセス権限が表示されます。

ステップ 9

  [作業（Work）] ペインの [ユーザー証明書（User Certificates）] エリアで、ユーザー証明書の [+] 記号をクリックし、 [X.509 証明書の作成（Create X509 Certificate）] ダイアログ ボックスで、次の操作を実行します：

  1.   [名前（Name）] フィールドに、証明書の名前を入力します。

  2.   [データ（Date）] フィールドに、ユーザー証明書の詳細を入力します。

  3.   [送信（Submit）]をクリックします。

X509 証明書がローカル ユーザー用に作成されます。

Python SDK を使用したローカル ユーザの作成

手順

ローカル ユーザを作成します。

例:


#!/usr/bin/env python
from cobra.model.pol import Uni as PolUni
from cobra.model.aaa import UserEp as AaaUserEp
from cobra.model.aaa import User as AaaUser
from cobra.model.aaa import UserCert as AaaUserCert
from cobra.model.aaa import UserDomain as AaaUserDomain
from cobra.model.aaa import UserRole as AaaUserRole
from cobra.mit.access import MoDirectory
from cobra.mit.session import LoginSession
from cobra.internal.codec.jsoncodec import toJSONStr

APIC = 'http://10.10.10.1'
username = ‘admin’
password = ‘p@$$w0rd’

session = LoginSession(APIC, username, password)
modir = MoDirectory(session)
modir.login()

def readFile(fileName=None, mode="r"):
   if fileName is None:
      return ""
   fileData = ""
   with open(fileName, mode) as aFile:
      fileData = aFile.read()
   return fileData

# Use a dictionary to define the domain and a list of tuples to define
# our aaaUserRoles (roleName, privType)
# This can further be abstracted by doing a query to get the valid
# roles, that is what the GUI does

userRoles = {'all': [
               ('aaa', 'writePriv'),
               ('access-admin', 'writePriv'),
               ('admin', 'writePriv'),
               ('fabric-admin', 'writePriv'),
               ('nw-svc-admin', 'writePriv'),
               ('ops', 'writePriv'),
               ('read-all', 'writePriv'),
               ('tenant-admin', 'writePriv'),
               ('tenant-ext-admin', 'writePriv'),
               ('vmm-admin', 'writePriv'),
           ],
}

uni = PolUni('') # '' is the Dn string for topRoot
aaaUserEp = AaaUserEp(uni)
aaaUser = AaaUser(aaaUserEp, 'userabc', firstName='Adam',
                  email='userabc@cisco.com')

aaaUser.lastName = 'BC'
aaaUser.phone = '555-111-2222'
aaaUserCert = AaaUserCert(aaaUser, 'userabc.crt')
aaaUserCert.data = readFile("/tmp/userabc.crt")
# Now add each aaaUserRole to the aaaUserDomains which are added to the
# aaaUserCert
for domain,roles in userRoles.items():
   aaaUserDomain = AaaUserDomain(aaaUser, domain)
   for roleName, privType in roles:
       aaaUserRole = AaaUserRole(aaaUserDomain, roleName,
                                 privType=privType)
print toJSONStr(aaaUser, prettyPrint=True)

cr = ConfigRequest()
cr.addMo(aaaUser)
modir.commit(cr)
# End of Script to create a user

秘密キーを使用した署名の計算

始める前に

次の情報を用意する必要があります：

  • HTTP メソッド：GET、POST、DELETE

  • 要求される REST API URI（クエリ オプションを含む）

  • POST 要求の場合、APIC に送信される実際のペイロード

  • ユーザの X.509 証明書の生成に使用される秘密キー

  • APIC のユーザ X.509 証明書の宛先名

手順

ステップ 1

HTTP メソッド、REST API URI、およびペイロードをこの順序で連結し、ファイルに保存します。

OpenSSL で署名を計算するには、この連結データをファイルに保存する必要があります。この例では、ファイル名 payload.txt を使用します。秘密キーは userabc.key というファイルにあることに注意してください。

例:

GET の例： 
GET http://10.10.10.1/api/class/fvTenant.json?rsp-subtree=children
POST の例： 
POST http://10.10.10.1/api/mo/tn-test.json{"fvTenant": {"attributes": {"status": "deleted", "name": "test"}}}

ステップ 2

payload.txt ファイルに正しい情報が含まれていることを確認します。

たとえば、前の手順で示したような取得例を使用します。

GET http://10.10.10.1/api/class/fvTenant.json?rsp-subtree=children

payload.txt ファイルには、次の情報のみ含める必要があります。

GET/api/class/fvTenant.json?rsp-subtree=children

ステップ 3

payload ファイルを作成するときに新しい行を間違って作成していないことを確認します。

例:

# cat –e payload.txt

次と同じように出力の最後に $ 記号があるか確認します。 

GET/api/class/fvTenant.json?rsp=subtree=children$

ある場合、ペイロード ファイルを作成したときに新しい行が作成されたことを意味します。ペイロード ファイルの生成時に新しい行が作成されることを防ぐには、次のようなコマンドを使用します：

echo -n "GET/api/class/fvTenant.json?rsp-subtree=children" >payload.txt

ステップ 4

OpenSSL を使用して、秘密キーとペイロード ファイルを使用して署名を計算します。

例:

openssl dgst -sha256 -sign userabc.key payload.txt > payload_sig.bin
生成されたファイルには、複数行に印字された署名があります。

ステップ 5

署名を base64 形式に変換します。

例:

openssl base64 -A -in payload_sig.bin -out payload_sig.base64

ステップ 6

Bash を使用して、署名から改行文字を取り除きます。

例:

$ tr -d '\n' < payload_sig.base64
P+OTqK0CeAZjl7+Gute2R1Ww8OGgtzE0wsLlx8fIXXl4V79Zl7
Ou8IdJH9CB4W6CEvdICXqkv3KaQszCIC0+Bn07o3qF//BsIplZmYChD6gCX3f7q
IcjGX+R6HAqGeK7k97cNhXlWEoobFPe/oajtPjOu3tdOjhf/9ujG6Jv6Ro=

（注）  

 

これは、この特定の要求に関して APIC に送信される署名です。その他の要求では、独自の署名を計算する必要があります。

ステップ 7

署名を文字列内に配置し、APIC が署名をペイロードと照合して確認できるようにします。

この完全な署名が、要求のヘッダー内のクッキーとして APIC に送信されます。

例:

APIC-Request-Signature=P+OTqK0CeAZjl7+Gute2R1Ww8OGgtzE0wsLlx8f
IXXl4V79Zl7Ou8IdJH9CB4W6CEvdICXqkv3KaQszCIC0+Bn07o3qF//BsIplZmYChD6gCX3f
7qIcjGX+R6HAqGeK7k97cNhXlWEoobFPe/oajtPjOu3tdOjhf/9ujG6Jv6Ro=; 
APIC-Certificate-Algorithm=v1.0; APIC-Certificate-Fingerprint=fingerprint; 
APIC-Certificate-DN=uni/userext/user-userabc/usercert-userabc.crt

（注）  

 

ここで使用される DN が、次のステップの x509 証明書を含むユーザ認定オブジェクトの DN に一致する必要があります。

ステップ 8

署名を使用して APIC と通信するには、Python SDK の CertSession クラスを使用します。

次のスクリプトは、ACI Python SDK の CertSession クラスを使用して、署名を使用して APIC に要求する方法の例です。

例:


#!/usr/bin/env python
# It is assumed the user has the X.509 certificate already added to
# their local user configuration on the APIC
from cobra.mit.session import CertSession
from cobra.mit.access import MoDirectory

def readFile(fileName=None, mode="r"):
    if fileName is None:
        return ""
    fileData = ""
    with open(fileName, mode) as aFile:
        fileData = aFile.read()
    return fileData

pkey = readFile("/tmp/userabc.key")
csession = CertSession("https://ApicIPOrHostname/",
                       "uni/userext/user-userabc/usercert-userabc", pkey)

modir = MoDirectory(csession)
resp = modir.lookupByDn('uni/fabric')
pring resp.dn
# End of script

（注）  

 

前のステップで使用した DN が、このステップの x509 証明書を含むユーザ認定オブジェクトの DN に一致する必要があります。

アカウンティング

Cisco Application Centric Infrastructure （ACI）ファブリック アカウンティングは、障害およびイベントと同じメカニズムで処理される以下の 2 つの管理対象オブジェクトによって扱われます。

  •   aaaSessionLR 管理対象オブジェクトは、 Cisco Application Policy Infrastructure Controller （APIC）およびスイッチでのユーザー アカウントのログインとログアウト セッション、およびトークンの更新を追跡します。  Cisco ACI ファブリック セッション アラート機能は、次のような情報を保存します：

    • ユーザー名

    • セッションを開始した IP アドレス

    • タイプ（telnet、HTTPS、REST など）


      （注）  

      5.3(1) リリース以降、telnet はサポートされていません。

    • セッションの時間と長さ

    • トークン更新：ユーザー アカウントのログイン イベントは、ユーザー アカウントが Cisco ACI ファブリックでの権利を行使するために必要な、有効なアクティブ トークンを生成します。


      （注）  
      トークンはログインとは関係なく期限切れになります。ユーザーはログアウトできますが、トークンは含まれているタイマー値の期間に従って期限切れになります。

  •   aaaModLR 管理対象オブジェクト は、ユーザーがオブジェクトに対して行う変更、およびいつ変更が発生したかを追跡します。

  • AAA サーバーへの ping が可能でない場合は、使用不可としてマークされ、エラーが表示されます。

  aaaSessionLR および aaaModLR 両方のイベント ログは、 Cisco APIC シャードに保存されます。データがプリセットされているストレージ割り当てサイズを超えると、古いものから順にレコードが上書きされます。


（注）  
ディスク クラッシュや火災など、 Cisco APIC クラスター ノードを破壊する破壊的なイベントが発生した場合、イベント ログが失われます。イベント ログは、クラスター全体には複製されません。

  aaaModLR および aaaSessionLR 管理対象オブジェクトは、クラスまたは識別名（DN）でクエリできます。クラスのクエリは、ファブリック全体のすべてのログ レコードを提供します。ファブリック全体のすべての aaaModLR レコードは、GUI の [ファブリック（Fabric）] > [インベントリ（Inventory）] > [POD] > [履歴（History）] > [監査ログ（Audit Log）] セクションで利用できます。 Cisco APIC GUI の [履歴（History）] > [監査ログ（Audit Log）] オプションを使用すると、 GUIで、特定の識別オブジェクトのイベント ログを表示できます。

標準の syslog、callhome、REST クエリ、および CLI エクスポート メカニズムは、 aaaModLR および aaaSessionLR 管理対象オブジェクトのクエリ データで完全にサポートされます。このデータをエクスポートするデフォルト ポリシーはありません。

  Cisco APIC には、一連のオブジェクトまたはシステム全体のデータの集約を報告する、事前設定されたクエリはありません。ファブリック管理者は、 aaaModLR および aaaSessionLR のクエリ データを定期的に syslog サーバーにエクスポートするエクスポート ポリシーを設定できます。エクスポートされたデータを定期的にアーカイブし、システムの一部またはシステム ログ全体のカスタム レポートを生成するために使用できます。

共有サービスとしての外部ネットワークへのルーテッド接続の課金と統計情報

  Cisco Application Policy Infrastructure Controller （APIC）は、共有サービスとして外部ネットワークへのルーテッド接続用に設定されたポートからバイト カウントおよびパケット カウント課金統計情報を収集するように設定できます。外部ネットワークは、 Cisco Application Centric Infrastructure （ACI）内の外部 L3Out エンドポイント グループ（l3extInstP 管理対象オブジェクト）として表されます。。任意のテナントの任意の EPG は、外部ネットワークへのルーテッド接続のために外部 L3Out EPG を共有できます。課金統計情報は、共有サービスとして外部 L3Out EPG を使用するテナントの各 EPG について収集できます。外部 L3Out EPG がプロビジョニングされているリーフ スイッチは、課金統計情報を集約先である Cisco APIC に転送します。アカウンティング ポリシーは、これらの課金統計情報を定期的にサーバーにエクスポートするように設定できます。