RADIUS、TACACS+、LDAP、RSA、SAML、OAuth 2、DUO

この章は、次の項で構成されています。

概要

この記事では、RADIUS、TACACS+、LDAP、RSA、DUO、SAML、OAuth 2 ユーザーが APIC にアクセスできるようにする方法について、順を追って説明します。読者が Cisco アプリケーション セントリック インフラストラクチャの基本 マニュアル（特に「ユーザー アクセス、認証、およびアカウンティング」の章）に十分通じていることを前提としています。

Cisco APIC リリース 6.0(1) から、APIC GUI の [管理（Admin）] > [AAA]パスは変更されています。詳細については、 Cisco APIC GUI の機能強化を参照してください。


（注）  

クラスタ内の 1 つを除くすべての APIC が失われるなどの障害シナリオの場合、APIC はリモート認証を無効にします。このシナリオでは、ローカル管理者アカウントのみがファブリック デバイスにログインできます。

（注）  

セキュリティ上の理由により、AAA 認証に shell:domains=all/read-all/ を使用するリモート ユーザーは、ファブリック内のリーフ スイッチおよびスパイン スイッチにアクセスすることはできません。このことは、4.0(1h) までのすべてのバージョンに当てはまります。

  [APIC] Bash シェルでのユーザー ID

Linux シェル用の [APIC] でのユーザー ID は、ローカル ユーザーのため、 [APIC] で生成されます。認証クレデンシャルが外部サーバーで管理されているユーザーは、Linux シェル用のユーザー ID を cisco-av-pair で指定できます。リモート ユーザーがデフォルトの Linux ユーザー ID 23999 を取得すれば、上記の cisco-av-pair の（16001）を省略することが可能です。Linux ユーザー ID は bash セッション中に使用され、標準の Linux 権限が適用されます。また、ユーザーが作成するすべての管理対象オブジェクトは、そのユーザーの Linux ユーザー ID によって作成されたとマークされます。

次は、 [APIC] の Bash シェルで表示される、ユーザー ID の例です： 

admin@ifav17-ifc1:~> touch myfile
admin@ifav17-ifc1:~> ls -l myfile
-rw-rw-r-- 1 admin admin 0 Apr 13 21:43 myfile
admin@ifav17-ifc1:~> ls -ln myfile
-rw-rw-r-- 1 15374 15374 0 Apr 13 21:43 myfile
admin@ifav17-ifc1:~> id
uid=15374(admin) gid=15374(admin) groups=15374(admin)

外部認証サーバーの 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 ぺアを割り当てるためのベスト プラクティス

ベストプラクティスとして、ユーザーが（SSH、Telnet またはシリアル/KVM コンソールを通じて）Bash シェルを使用する場合には、そのユーザーに割り当てられる AV ペア用に、16000 ～ 23999 の範囲で一意の UNIX ユーザー ID を割り当てることを推奨します。Cisco AV ペアが UNIX ユーザー ID を提供しない状況が発生すると、そのユーザーにはユーザー ID 23999（または範囲内のそれに近い番号）が割り当てられますが、その場合、そのユーザーのホーム ディレクトリ、ファイル、およびプロセスに、UNIX ID 23999 を持つリモート ユーザーもアクセスできるようになってしまいます。


（注）  

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

リモート認証サーバーが cisco-av-pair 応答で明示的に UNIX ID を割り当てているかどうかを確認するには、 [Cisco Application Policy Infrastructure Controller] （[APIC]）への SSH セッションを開いて、リモート ユーザー アカウントを使用して管理者としてログインします。ログイン後、次のコマンドを実行します（useridはログイン時に使用したユーザー名で置き換えてください）。 


admin@apic1:remoteuser-userid> cd /mit/uni/userext/remoteuser-userid
admin@apic1:remoteuser-userid> cat summary

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

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

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


（注）  

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

手順の概要

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

手順の詳細

外部認証サーバの 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)

リモート ユーザーの設定

ローカルユーザーを設定する代わりに、一元化された企業クレデンシャル データセンターで、 [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 サーバーのホスト名ですでに名前解決されている必要があります。

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

NX-OS スタイル CLI を使用したリモート ユーザーの設定

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

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

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

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

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 AV ペアを持つリモート ユーザーのデフォルトの動作を NX-OS スタイル CLI を使用して変更する

Cisco APIC では、管理者が外部認証サーバーで Cisco AV ペアを設定する必要があります。これを行うには、管理者は既存のユーザー レコードに Cisco AV ペアを追加します。Cisco AV ペアは、ユーザーの RBAC ロールおよび権限に必要な [APIC] を指定します。Cisco AV ペアの形式は、RADIUS、LDAP、または TACACS+ のものと同じです。AV ペアの形式には Cisco UNIX ユーザー ID が含まれるものと含まれないものがあります。すべてのリモート ユーザーが同じロールを持ち、相互ファイル アクセスが許可される場合はどちらの形式でも問題ありません。UNIX ユーザー ID を指定しないと、APIC システムによって ID 23999 が適用され、AV ペア ユーザーに対して複数のロールまたは読み取り権限が指定されます。これは、グループ設定で設定された権限よりも高いかまたは低い権限がユーザーに付与される原因になることがあります。このトピックでは、許可されない動作を変更する方法について説明します。

NX-OS スタイル CLI を使用して欠落または不良 Cisco AV ペアを持つリモート ユーザーのデフォルトの動作を変更するには、次の手順を実行します。

手順

ステップ 1

NX-OS CLI で、コンフィギュレーション モードを開始します。

例:


apic1#
apic1# configure

ステップ 2

aaa ユーザー デフォルト ロールを設定します。

例:


apic1(config)# aaa user default-role
 assign-default-role  assign-default-role
 no-login             no-login

ステップ 3

aaa 認証ログイン メソッドを設定します。

例:


apic1(config)# aaa authentication
 login  Configure methods for login

apic1(config)# aaa authentication login
 console  Configure console methods
 default  Configure default methods
 domain   Configure domain methods

apic1(config)# aaa authentication login console
 <CR>

apic1(config)# aaa authentication login domain
 WORD      Login domain name
 fallback

プロバイダーを作成する

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

始める前に

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

手順

ステップ 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）]。

ログイン ドメイン

ログイン ドメインは、ユーザーの認証ドメインを定義します。ログイン ドメインは、ローカル、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 アプリケーション セントリック インフラストラクチャ（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）] 画面） 。

RADIUS 認証

Remote Authentication Dial-In User Service（RADIUS）は、ネットワーク サービスに接続し使用するユーザー向けに、一元化された認証、認可、およびアカウンティング(AAA)管理を提供するネットワーキング プロトコルです。

RADIUS サーバーでユーザーを設定するには、 [APIC] 管理者は、必要な属性(shell:domains）を cisco-av-pair 属性を使用して設定する必要があります。デフォルトのユーザ ロールは、network-operator です。

SNMPv3 認証プロトコルに指定できるオプションは、SHA と MD5 です。プライバシー プロトコルに指定できるオプションは、AES-128 と DES です。これらのオプションが cisco-av-pair 属性で指定されていない場合、 MD5 と DES がデフォルト認証プロトコルになります。

たとえば、SNMPv3 認証とプライバシー プロトコルの属性は次のように指定できます： 

snmpv3:auth=SHA priv=AES-128

同様に、ドメインのリストは次のようになります： 

shell:domains="domainA domainB …"

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 サーバーを設定します。

REST API を使用して APIC 内の RADIUS を設定する


HTTP POST to https://{{apichost}}/api/node/mo/.xml
<aaaRadiusProvider authPort="1812" authProtocol="pap" descr="myradius"        monitorServer="disabled"      name="server.radius.local" key="mykey"     retries="1" timeout="5"/>

REST API を使用して RADIUS のログイン ドメインを設定するには： 


HTTP POST to https://{{apichost}}/api/node/mo/.xml
<aaaUserEp  descr="" dn="uni/userext"  name=""  pwdStrengthCheck="yes" rn="" status="modified">
    <aaaLoginDomain descr="" name="RadDom" rn="logindomain-RadDom" status="created">
        <aaaDomainAuth name="" providerGroup="RadDom" realm="radius" rn="domainauth"  status="created"/>
    </aaaLoginDomain>
    <aaaRadiusEp descr="" name="" retries="1" rn="radiusext" status="modified" timeout="5">
        <aaaRadiusProviderGroup descr=""  name="RadDom"  rn="radiusprovidergroup-RadDom"  status="created">
            <aaaProviderRef descr="acs" name="radius1.server.com" order="1"                    rn="providerref-radius.server.com" status="created" />
            <aaaProviderRef descr="acs" name="radius2.server.com" order="2"                    rn="providerref-radius2.server.com" status="created" />
        </aaaRadiusProviderGroup>
    </aaaRadiusEp>
</aaaUserEp>

TACACS+ 認証

Terminal Access Controller Access Control device Plus（TACACS+）は、シスコのシステムでサポートされている、もう 1 つのリモート AAA プロトコルです。TACACS+ には、RADIUS 認証にはない次の利点があります。

  • 独立した AAA ファシリティを提供する。たとえば、 [Cisco Application Policy Infrastructure Controller] （[APIC]）は、認証を行わずにアクセスを許可できます。

  • AAA クライアントとサーバー間のデータ送信に TCP を使用しているため、コネクション型プロトコルで確実に転送されます。

  • スイッチと AAA サーバー間でプロトコルペイロード全体が暗号化されるため、高いデータ機密性が確保されます。RADIUS ではパスワードしか暗号化されません。

  • シンタックスと設定が RADIUS と異なる av-pairs を使用しますが、 [Cisco APIC] は、 shell:domainsをサポートします。

次のXMLの例では、IP アドレス 10.193.208.9 の TACACS+ プロバイダーと連携するように 、 [Cisco アプリケーション セントリック インフラストラクチャ（Cisco Application Centric Infrastructure）] （[ACI]）ファブリックを設定しています。 

<aaaTacacsPlusProvider name="10.193.208.9"            key="test123"            authProtocol="pap"/>

（注）  

この例では IPv4 アドレスを使用していますが、IPv6 アドレスも使用できます。

TACACS+ を使用するときには、次の制約事項および使用上のガイドラインが適用されます：

  • TACACS サーバーおよび TACAC ポートは、ping で到達可能である必要があります。

  • 優先順位が最も高い TACACS サーバーが、最初にプライマリ サーバーと見なされます。

TACACS+ over TLS 認証

リリース 6.1.4 以降では、Transport Layer Security（TLS）を介して TACACS+ プロバイダーを設定できます。TACACS+ over TLS は、証明書ベースの認証を使用し、TLSバージョン 1.3 をサポートします。

TACACS+ ログイン ドメインは、TLS ベースの TACACS+ プロバイダーまたは非 TLS ベースの TACACS+ プロバイダーのいずれかを使用する必要がありますが、両方を同時に使用することはできません。

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

始める前に

  •   [Cisco アプリケーション セントリック インフラストラクチャ（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 サーバー設定に関するトピックに進みます。

REST API を使用して APIC の TACACS を設定する

  aaaTacacsPlusProviderGroup を TACACS ログイン ドメインと同じ名前で設定したことを確認します。 


HTTP POST to https://{{apichost}}/api/node/mo/.xml
<aaaTacacsPlusProvider name="server.tacacs.local"      authProtocol="pap"      monitorServer="enabled" monitoringUser="user1" monitoringPassword="mypwd"      port="49" retries="1" key="mykey" timeout="15" />

REST API を使用して TACACS のログインドメインを構成するには：


HTTP POST to https://{{apichost}}/api/node/mo/.xml
<aaaUserEp  descr="" dn="uni/userext"  name=""  pwdStrengthCheck="yes" rn="" status="modified">
    <aaaLoginDomain  descr=""  name="Tacacs" nameAlias=""  rn="logindomain-Tacacs" status="created,modified">
        <aaaDomainAuth  descr="" name="" nameAlias=""  providerGroup="Tacacs"              realm="tacacs" rn="domainauth" status="created,modified"/>
    </aaaLoginDomain>
    <aaaTacacsPlusEp  descr="" name="" nameAlias=""  retries="1" rn="tacacsext" status="created,modified" timeout="5">
        <aaaTacacsPlusProviderGroup  descr="" name="Tacacs" nameAlias=""              rn="tacacsplusprovidergroup-Tacacs" status="created,modified">
            <aaaProviderRef descr="testing" name="tacacs.server.com" nameAlias="" order="1"                  rn="providerref-tacacs.server.com"  status="created,modified" />
            <aaaProviderRef descr="testing" name="tacacs2.server.com" nameAlias="" order="2"                  rn="providerref-tacacs2.server.com"  status="created,modified" />
        </aaaTacacsPlusProviderGroup>
    </aaaTacacsPlusEp>
</aaaUserEp>

REST API を使用して APIC ノードのキーリング証明書を設定するには：


HTTP POST https://{{apichost}}/api/node/mo/uni/userext/pkiext/keyring-{{tacacs-tls-keyring}}.xml
<pkiKeyRing dn="uni/userext/pkiext/keyring-{{tacacs-tls-keyring}}"        tp="tacacs-tls-tp" eccCurve="none" keyType="RSA"      descr="tac client ca" status="created,modified"     key="-----BEGIN PRIVATE KEY-----    ..................................    ..................................     -----END PRIVATE KEY-----"       cert="-----BEGIN CERTIFICATE-----    ..................................    ..................................     -----END CERTIFICATE-----" /pkiKeyRing>

REST API を使用して TACACS+プロバイダーを信頼するようにトラストポイントを設定するには：


HTTP POST https://{{apichost}}/api/node/mo/uni/userext/pkiext/tp-{{tacacs-tls-tp}}.xml
<polUni>
    <aaaUserEp>
        <pkiEp>
            <pkiTP dn="uni/userext/pkiext/tp-{{tacacs-tls-tp}}" name="tacacs-tls-tp"                 certUsage="WebSvcOrAuth" status="created,modified"                 certChain="-----BEGIN CERTIFICATE-----       ....................................       ....................................             -----END CERTIFICATE-----"/>
        </pkiEp>
    </aaaUserEp>
</polUni>

REST API を使用して TLS を介する TACACS+ プロバイダーを設定するには：


https://{{apic-ip}}/api/node/mo/uni.xml

<?xml version="1.0" encoding="UTF-8"?>
<imdata totalCount="1">
    <aaaTacacsPlusProvider enableTLS="true" dn="uni/userext/tacacsext/tacacsplusprovider-{{tacacs-tls-providername}}"  SSLValidationLevel="permissive" port="6049" status="created,modified" descr="TLS ISE provider"  keyring="{{tacacs-tls-keyring}}" name="{{tacacs-tls-providername}}" tp="{{tacacs-tls-tp}}"  key="" userdom="all">
    <aaaRsSecProvToEpg tDn="uni/tn-mgmt/mgmtp-default/oob-default"/>
    </aaaTacacsPlusProvider>
</imdata>

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 セキュリティ ドメインにアクセスできることを確認します。ユーザーは、明示的に許可されていない項目にアクセスできてはなりません。読み取り/書き込みアクセス権は、そのユーザーに設定されたものと一致している必要があります。

LDAP/Active Directory の認証

RADIUS および TACACS+ と同様、LDAP により、ネットワーク要素はユーザーを認証し、特定のアクションの実行を許可するために使用できる AAA クレデンシャルを取得できます。追加された認証局の設定は管理者によって実行でき、LDAPS（SSL 経由の LDAP）の信頼性をイネーブルにし、中間者攻撃を防ぐことができます。

次に示す XML の例では、ACI ファブリックが IP アドレス 10.30.12.128 の LDAP プロバイダーを使用するように設定しています。


（注）  

この例では IPv4 アドレスを使用していますが、IPv6 アドレスも使用できます。

 
<aaaLdapProvider name="10.30.12.128"            rootdn="CN=Manager,DC=ifc,DC=com"            basedn="DC=ifc,DC=com"            SSLValidationLevel="strict"            attribute="CiscoAVPair"            enableSSL="yes"       key="myldappwd"            filter="cn=$userid"            port="636" />

（注）  

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

Cisco AVPair を設定する代わりに、APIC で LDAP グループ マップを作成するオプションがあります。

LDAP の設定

LDAP 設定には 2 つのオプションがあります。Cisco AVPair を設定したり、APIC 内で LDAP グループ マップを設定したりできます。このセクションには、両方の設定オプションの手順が含まれています。

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 アプリケーション セントリック インフラストラクチャ（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 APIC での LDAP グループ マップ ルールの設定

Cisco APIC での LDAP グループ マップの設定には、最初の作成時の LDAP グループ マップ ルールが必要です。このセクションでは、LDAP グループ マップ ルールを作成する方法について説明します。

始める前に

LDAP サーバーが設定されているグループのマッピングを実行していること。

手順

ステップ 1

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

ステップ 2

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

ステップ 3

[作業（Work）] ペインで、 [LDAP グループ マップ（LDAP Group Maps）] > [LDAP グループ マップ ルール（LDAP Group Map Rules）] を選択します。

ステップ 4

  [アクション（Actions）] ボタン > [LDAP グループマップルールの作成（Create LDAP Group Map Rule）]をクリックします。

ステップ 5

表示されている [LDAP グループマップルールの作成（Create LDAP Group Map Rule）] 画面で、タイプ、グループマップルール名、説明（オプション）、グループ DN を指定します。

ステップ 6

[セキュリティ ドメイン（Security Domain）] ペインで、 セキュリティドメインの追加（Add Security Domain）をクリックします。[セキュリティドメイン（Security Domains）] ポップアップウィンドウで、次の詳細を入力します：

  1.   [セキュリティドメインの選択（Select Security Domain）] をクリックして、セキュリティ ドメインを選択します。

  2.   [ロールの追加（Add Role）] をクリックしてロールを追加し、ドロップダウンリストから権限を選択します。チェックマークをクリックして、選択した権限をロールに割り当てます。この手順を繰り返して、複数のロールをセキュリティドメインに追加します。

  3. [セキュリティドメイン（Security Domains）] ウィンドウで 追加（Add） をクリックします。

ステップ 7

[LDAP グループマップルールの作成（Create LDAP Group Map Rule）] 画面で [保存（Save）] をクリックします。

次のタスク

LDAP グループ マップ ルールを指定した後に、LDAP グループ マップを作成します。

Cisco APIC での LDAP グループ マップの設定

このセクションでは、LDAP グループ マップを作成する方法について説明します。

始める前に

  • 実行中の LDAPサーバは、グループ マッピングで設定されます。

手順

ステップ 1

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

ステップ 2

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

ステップ 3

[作業（Work）] ペインで、 [LDAP グループ マップ（LDAP Group Maps）] > [LDAP グループ マップ（LDAP Group Maps）]を選択します。

ステップ 4

  [アクション（Actions）]> [LDAP グループマップルールの作成（Create LDAP Group Map Rule）]をクリックします。

ステップ 5

表示される [LDAP グループマップルールの作成（Create LDAP Group Map Rule）] 画面で、タイプ、グループ マップ名、説明（オプション）を指定、 [LDAP グループ マップ ルールの追加（Add LDAP Group Map Rule）]をクリックして、LDAP グループ マップ ルールを選択します。

LDAP グループマップルールが使用できない場合は、 [LDAP グループマップルールの作成（Create LDAP Group Map Rule）]をクリックします。LDAP グループ マップ ルールの作成に関する詳細な手順については、 LDAP グループ マップ ルールの設定 の手順を参照してください。

ステップ 6

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

DUO による多要素認証

Cisco APIC は、Duo セキュリティによる多要素認証をサポートしています。Duo セキュリティ自体は、ユーザー ID のリポジトリとして機能しません。オンプレミスまたはクラウドベースの組織の既存の認証に加えて、2 要素（2F）認証を提供します。Duo による 2 要素認証は、ユーザーが組織のプライマリ認証ソースでの認証を完了すると発生します。

プライマリ認証ソースで認証を完了した後、Duo は 3 種類の 2F 認証方法をサポートします。

  • スマートフォンの Duo モバイル アプリを使用したモバイルでの通知プッシュ。

  • 登録済みの電話または携帯電話での通話。

  • Duo モバイル アプリで生成されるパスコード。

ユーザーは、次のサーバーを使用して認証されます。

  • Duo プロキシ RADIUS サーバーは、Cisco APIC の多要素認証を使用して、RADIUS PAP プライマリ認証方式を使用して分散クライアント/サーバー システムを認証します。

  • Duo プロキシ LDAP サーバーは、Cisco APIC の多要素認証を使用して、Cisco AVPair または Group Maps 認証方法を使用してリモート サーバーを認証します。

DUO RADIUS プロバイダーまたは DUO LDAP プロバイダーの作成については、 プロバイダーを作成する の手順を参照してください。

REST API を使用して DUO プロキシを設定する

The URL for all XML data : 
POST  https://{{apichost}}/api/node/mo/.xml

以下は、プロキシ RADIUS およびプロキシ LDAP サーバーを使用した Duo の設定例です。

RADIUS の設定

  • DUO RADIUS プロバイダーを追加します。

    <aaaRadiusProvider authPort="1812" authProtocol="pap" descr="duoradius"        dn="uni/userext/duoext/radiusprovider-duoproxy.host.com"          monitorServer="disabled" monitoringUser=""        name="duoproxy.host.com"  key="mypasswd"        retries="1" status="created" timeout="30"/>

  • DUO RADIUS プロキシ プロバイダーを使用してログイン ドメインを追加します。

    <aaaUserEp  descr="" dn="uni/userext"  name="" pwdStrengthCheck="yes" rn="" status="modified">
    <aaaLoginDomain descr="" name="DuoRadDom" rn="logindomain-DuoRadDom" status="created">
        <aaaDomainAuth descr="" name="" providerGroup="DuoRadDom" realm="radius" realmSubType="duo" rn="domainauth" status="created"/>
    </aaaLoginDomain>
    <aaaDuoEp descr="" name="" retries="1" rn="duoext" status="modified" timeout="40">
        <aaaDuoProviderGroup name="DuoRadDom" providerType="radius" secFacAuthMethods="auto,push"              rn="duoprovidergroup-DuoRadDom" status="created">
            <aaaProviderRef descr="duoradproxy" name="duoproxy.host.com" order="1"                 rn="providerref-duoproxy.host.com" status="created" />
        </aaaDuoProviderGroup>
    </aaaDuoEp>
</aaaUserEp>

LDAP 設定

  • 属性 [Cisco AVPair]：で DUO LDAP プロキシ プロバイダーを追加します。 

    <aaaLdapProvider name="duoproxy.host.com"     SSLValidationLevel="strict"     attribute="CiscoAvPair"     basedn="CN=Users,DC=host,DC=com"     dn="uni/userext/duoext/ldapprovider-duoproxy.host.com" enableSSL="no" filter="cn=$userid"     monitorServer="disabled"     port="389" retries="1"     rootdn="CN=admin,CN=Users,DC=host,DC=com"     timeout="60"     key="12345"/>

  • 属性 memberOf：で DUO LDAP プロキシ プロバイダーを追加します。 

    <aaaLdapProvider name="duoproxy.host.com"     SSLValidationLevel="strict"     attribute="memberOf"     basedn="CN=Users,DC=host,DC=com"     dn="uni/userext/duoext/ldapprovider-duoproxy.host.com" enableSSL="no" filter="cn=$userid"     monitorServer="disabled"     port="389" retries="1"     rootdn="CN=admin,CN=Users,DC=host,DC=com"     timeout="60"     key="12345"/>

  • LDAP GroupMap ルールを追加します：

    <aaaLdapGroupMapRule name="DuoEmpRule" dn="uni/userext/duoext/ldapgroupmaprule-DuoEmpRule"        groupdn="CN=Employee,CN=Users,DC=host,DC=com" status="created">
       <aaaUserDomain name="all" rn="userdomain-all" status="created,modified">
           <aaaUserRole name="fabric-admin" privType="writePriv" rn="role-fabric-admin" status="created,modified"/>
       </aaaUserDomain>
</aaaLdapGroupMapRule>

  • LDAP GroupMap を追加します：

    <aaaLdapGroupMap name="DuoEmpGroupMap" dn="uni/userext/duoext/ldapgroupmap-DuoEmpGroupMap"  status="created">
    <aaaLdapGroupMapRuleRef name="DuoEmpRule" rn="ldapgroupmapruleref-DuoEmpRule" status="created"/>
</aaaLdapGroupMap>

  • GroupMap を使用して DUO LDAP ログイン ドメインを追加します：

    <polUni>
    <aaaUserEp dn="uni/userext" name="" pwdStrengthCheck="yes" rn="" status="modified">
        <aaaDuoEp attribute="memberOf" basedn="" filter="sAMAccountName=$userid"             name="" retries="1" rn="duoext" status="modified" timeout="30">
            <aaaDuoProviderGroup name="DuoLdapDom" authChoice="LdapGroupMap" providerType="ldap"                  rn="duoprovidergroup-DuoLdapDom" ldapGroupMapRef="DuoEmpGroupMap" secFacAuthMethods="auto,push" status="modified">
                <aaaProviderRef name="duoproxy.host.com" order="1"                     rn="providerref-duoproxy.host.com" status="modified"/>
            </aaaDuoProviderGroup>
        </aaaDuoEp>
        <aaaLoginDomain name="DuoLdapDom" rn="logindomain-DuoLdapDom" status="modified">
            <aaaDomainAuth name="" providerGroup="DuoLdapDom" realm="ldap" realmSubType="duo" rn="domainauth" status="modified"/>
        </aaaLoginDomain>
    </aaaUserEp>
</polUni>

GUI のログイン ドメインを取得する

ログイン ドメインの GET URL：

GET https://apic.host.com/api/aaaListDomains.json
{   "totalCount": "5",
    "imdata": [{   
            "name": "DuoRadDom",
            "type": "DUO",
            "secAuths": "auto,push"
        }, {   
            "name": "DuoLdapDom",
            "type": "DUO",
            "secAuths": "auto,push"
        }, {   
            "name": "RadDom",
            "type": "OTHER"
        }, {   
            "name": "LdapDom",
            "type": "OTHER"
        }, {   
            "name": "DefaultAuth",
            "guiBanner": "",
            "type": "OTHER"
        }
    ] }

RSA Secure ID 認証

RSA 認証は、使用できる組み合わせで固定キーを使用して、パスワードを作成するさまざまな方法でトークンを提供します。これは、ハードウェア トークンとソフトウェア トークンの両方をサポートします。

GUI を使用して RSA アクセス用の APIC を設定する

始める前に

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

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

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

手順

ステップ 1

  [APIC]で、RSA プロバイダを作成します。

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

ステップ 2

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

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

次のタスク

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

SAML 認証

SAML は XML ベースのオープン規格のデータ形式であり、いずれかのアプリケーションにサインインした後に、管理者は定義された一連のシスコのコラボレーション アプリケーションにシームレスにアクセスできます。SAML では、信頼できるビジネス パートナー間で、セキュリティに関連した情報交換を記述します。これは、サービス プロバイダーによってユーザーの認証に使用される認証プロトコルです。SAML により、ID プロバイダー（IdP）とサービス プロバイダーの間で、セキュリティ認証情報を交換できます。

SAML SSO は SAML 2.0 プロトコルを使用して、シスコのコラボレーション ソリューションのドメイン間と製品間で、シングル サインオンを実現しています。SAML 2.0 は、Cisco アプリケーション全体で SSO を有効にし、Cisco アプリケーションと IdP 間でフェデレーションを有効にします。SAML 2.0 では、高度なセキュリティ レベルを維持しながら、シスコの管理ユーザが安全なウェブ ドメインにアクセスして、IdP とサービス プロバイダーの間でユーザ認証と承認データを交換できます。この機能が安全なメカニズムを提供していることで、さまざまなアプリケーションにわたり、共通の資格情報や関連情報を使用します。

SAML SSO の管理者権限は、シスコのコラボレーション アプリケーションでローカルに設定されたロールベース アクセス コントロール（RBAC）に基づき認証されます。

SAML SSO は、IdP とサービス プロバイダーの間のプロビジョニング プロセスの一部として、メタデータと証明書を交換することで信頼の輪（CoT）を確立します。サービス プロバイダーは IdP のユーザ情報を信頼しており、さまざまなサービスやアプリケーションにアクセスできるようにします。


（注）  

サービス プロバイダーが認証にかかわることはありません。SAML 2.0 では、サービス プロバイダーではなく、IdP に認証を委任します。

クライアントは IdP に対する認証を行い、IdP はクライアントにアサーションを与えます。クライアントはサービス プロバイダーにアサーションを示します。CoT が確立されているため、サービス プロバイダーはアサーションを信頼し、クライアントにアクセス権を与えます。

SAML SSO を有効にすると、次のようないくつかの利点が得られます。

  • 異なるユーザー名とパスワードの組み合わせを入力する必要がなくなるため、パスワードの劣化が軽減します。

  • アプリケーションをホストしているお使いのシステムからサード パーティのシステムに、認証を転送します。SAML SSO を使用することで、IdP とサービス プロバイダーの間で信頼の輪を作成できます。サービス プロバイダーは IdP 信頼して、ユーザを認証します。

  • 認証情報を保護し、安全に保ちます。暗号化機能により、IdP、サービス プロバイダー、ユーザの間で認証情報を保護します。SAML SSO では、IdP とサービス プロバイダー間で転送される認証メッセージを外部ユーザから保護することもできます。

  • 同じ ID に資格情報を再入力する時間が省けるため、生産性が向上します。

  • パスワードをリセットするためのヘルプ デスクへの問い合わせが減るため、コスト削減につながります。

SAML の基本要素

  • クライアント（ユーザのクライアント）：これは、認証用にブラウザ インスタンスを活用できる、ブラウザ ベースのクライアントまたはクライアントです。システム管理者のブラウザはその一例です。

  • サービス プロバイダー：これは、クライアントがアクセスを試みるアプリケーションまたはサービスです。

  • ID プロバイダー（IdP）サーバ：これは、ユーザ資格情報を認証し、SAML アサーションを発行するエンティティです。

  • Lightweight Directory Access Protocol（LDAP）ユーザ：これらのユーザは、Microsoft Active Directory や OpenLDAP などの LDAP ディレクトリと統合されます。非 LDAP ユーザは、Unified Communications サーバ上にローカルに存在します。

  • SAML アサーション：これは、ユーザ認証のために、IdP からサービス プロバイダーに転送されるセキュリティ情報で構成されます。アサーションは、ユーザ名や権限などのサブジェクトに関する信頼されたステートメントを含む、XML ドキュメントです。通常では、信頼性を確保するために、SAML アサーションはデジタル署名されます。

  • SAML 要求：これは、Unified Communications アプリケーションにより生成される認証要求です。LDAP ユーザを認証するために、Unified Communications アプリケーションは認証要求を IdP に委任します。

  • 信頼の輪（CoT）：これは、共同で 1 つの IdP に対して共有と認証を行うさまざまなサービス プロバイダーで構成されます。

  • メタデータ：これは、IdP と同様に ACI アプリケーションによって生成された、XML ファイルです。SAML メタデータの交換により、IdP とサービス プロバイダーの間に信頼関係が確立します。

  • Assertion Consumer Service（ACS）URL：この URL は、アサーションをポストする場所を IdP に指示します。ACS URL は、最終的な SAML 応答を特定の URL にポストすることを IdP に指示します。


（注）  

認証が必要なすべてのインスコープ サービスでは、SSO のメカニズムとして SAML 2.0 を使用します。

サポートされている IdP および SAML コンポーネント

サポートされている IdP

ID プロバイダー（IdP）は、ユーザー、システム、サービスの ID 情報を作成、維持、管理する認証モジュールです。また、分散ネットワーク内のその他のアプリケーションやサービス プロバイダーに対して認証も行います。

SAML SSO で、IdPs はユーザーのロールまたは各 Cisco コラボレーション アプリケーションのログイン オプションに基づいて、認証オプションを提供します。IdP は、ユーザー資格情報を保管、検証し、ユーザーがサービス プロバイダーの保護リソースにアクセスできる SAML 応答を生成します。


（注）  

IdP サービスを十分理解している必要があります。現在インストールされていて、操作可能であることを確認してください。

APIC の SAML SSO 機能は、次の IdP でテストされています。

SAML のコンポーネント

SAML SSO ソリューションは、特定のアサーション、プロトコル、バインディング、プロファイルの組み合わせに基づきます。さまざまなアサーションは、プロトコルやバインディングを使用しているアプリケーション間やサイト間で交換され、これらのアサーションによりサイト間でユーザーを認証します。SAML のコンポーネントは次のとおりです。

  • SAML アサーション：これは、IdP からサービス プロバイダーに転送される情報の構造と内容を定義します。セキュリティ情報のパケットで構成され、さまざまなレベルのアクセス コントロール決定にサービス プロバイダの用途があることを示す文書が含まれます。SAML SSO は次の種類の文書を提供します。

    • 認証ステートメント：これらのステートメントは、IdP とブラウザの間で特定の時間に行う認証の方法について、サービス プロバイダーにアサートします。

    • 属性ステートメント：これらのステートメントは、ユーザーに関連付ける特定の属性（名前と値のペア）についてアサートします。属性アサーションには、ユーザーに関する具体的な情報が含まれます。サービス プロバイダーは、属性を使用してアクセス制御の決定を行います。

  • SAML プロトコル：SAML プロトコルは、SAML がアサーションをどのように要求し、取得するかを定義します。このプロトコルは、特定の SAML エレメントまたはアサーションで構成されている、SAML 要求と応答エレメントに対応します。SAML 2.0 には次のプロトコルがあります。

    • アサーション クエリと要求のプロトコル

    • 認証要求のプロトコル

  • SAML バインディング：SAML バインディングは、SOAP 交換のような、標準メッセージング形式または通信プロトコルとの SAML アサーションまたはプロトコル メッセージ（またはその両方）の交換のマッピングを指定します。ACI は次の SAML 2.0 バインディングをサポートしています。

    • HTTP Redirect（GET）バインディング

    • HTTP POST バインディング

  • SAML プロファイル：SAML プロファイルでは、明確に定義された使用事例をサポートするために、SAML アサーション、プロトコル、およびバインディングの組み合わせについて詳細に説明しています。

NTP の設定

SAML SSO で、Network Time Protocol（NTP）では APIC および IdP 間のクロック同期が可能です。SAML は時間の精度に敏感なプロトコルであり、IdP は SAML アサーションが有効であることを時間ベースで判断します。IdP および APIC クロックが同期されていない場合、アサーションが無効になり SAML SSO 機能が停止します。IdP および APIC の間で許可される最大時差は 3 秒です。


（注）  

SAML SSO を動作させるには、NTP 設定を正しくインストールする必要があり、IdP と APIC アプリケーション間の時間差が 3 秒を超えていないことを確認する必要があります。IdP および APIC クロックが同期されていない場合、ユーザーは IdP で認証に成功した後でも APIC のログイン ページにリダイレクトされます。

DNS の設定

Domain Name System（DNS）により、ホスト名とネットワーク サービスをネットワーク（複数可）内の IP アドレスにマッピングできるようになります。ネットワーク内に配置された DNS サーバーは、ネットワーク サービスをホスト名にマッピングし、次にホスト名を IP アドレスにマッピングするデータベースを備えています。ネットワーク上のデバイスは、DNS サーバーに照会して、ネットワークにある他のデバイスの IP アドレスを受信できます。そのため、ネットワーク デバイス間の通信が容易になります。

まとめると、APIC および Idp は互いの完全修飾ドメイン名を IP アドレスに対して解消でき、クライアントによって解消される必要があります。

Certificate Authority：認証局

シスコは、次のいずれかの種類の認証局（CA）により署名されるサーバー証明書を使用することを推奨します。

  • パブリック CA：サードパーティ企業が、サーバーの識別情報を確認し、信頼できる証明書を発行します。

  • プライベート CA：自身でローカルの CA を作成および管理し、信頼できる証明書を発行します。

署名プロセスは製品ごとに異なり、サーバーのバージョン間でも異なる場合があります。各サーバーのすべてのバージョンに関する詳細な手順については、このマニュアルの範囲外になります。CA により署名された証明書を取得する方法の詳細な手順については、該当するサーバーのマニュアルを参照してください。

パブリック CA により署名されたサーバー証明書を取得する場合、パブリック CA は、クライアント コンピュータの信頼ストアで、ルート証明書をあらかじめ提示しておくようにします。この場合、クライアント コンピュータでルート証明書をインポートする必要はありません。プライベート CA など、CA により署名される証明書が信頼ストアにまだ存在しない場合は、ルート証明書をインポートしてください。SAML SSO では、CN または SAN での正しいドメインが記載された CA 署名付き証明書が、IdP およびサービス プロバイダーに必要になります。正しい CA 証明書が検証されない場合、ブラウザはポップアップ警告を出します。

APIC の信頼ストアに IdP のルート証明書が含まれていない場合は、新しい認証局を作成する必要があります。APIC で SAML プロバイダを設定する際は、この認証局を後で使用する必要があります。

SAML アクセス用の APIC の設定


（注）  

SAML ベースの認証は、 [Cisco APIC] GUI 専用であり、CLI または REST API 用ではありません。また、SAML はリーフ スイッチとスパイン スイッチには適用されません。  [Cisco APIC] CLI を使用して SAML 構成を構成することはできません。

始める前に

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

  • SAML サーバーのホスト名または IP アドレスと、IdP メタデータの URL を使用できます。

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

  • 次の設定を行います。

    • 時刻同期と NTP

    • DNS プロバイダーと接続するための DNS サービス ポリシー

    • カスタム証明書： [Cisco ACI] HTTPS アクセス

    詳細については、 Cisco APIC ベーシック コンフィギュレーション ガイドを参照してください。

手順

ステップ 1

  [Cisco APIC] GUI で、SAML プロバイダーを作成します。

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

ステップ 2

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

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

REST API を使用して APIC で SAML を設定する

REST API を使用して SAML を構成するには、最初に次の例のような SAML プロバイダーを作成します。

<aaaSamlProvider name="auth.pingone.asia"   dn="uni/userext/samlext/samlprovider-auth.pingone.asia"   entityId="https://192.168.32.1/api/aaaLoginSSO.json"   spEntityId="https://apic.host.com"   guiBannerMessage="" idP="ping identity"   metadataUrl="https://auth.pingone.com/c5f09515-6ce4-4776-a770-3d2ad98f078e/     saml20/metadata/9a0cd2a5-daf6-40dd-9004-c562221fc6e2"   monitorServer="disabled" retries="1" timeout="5" tp="pingonecert"   wantAssertionsEncrypted="no" wantAssertionsSigned="yes" wantRequestsSigned="yes"   wantResponseSigned="yes" sigAlg="SIG_RSA_SHA256" status="created,modified" />

（注）  

  metadataUrl 値には、読みやすくするために改行が含まれています。ただし、実際の値には改行を含めないでください。

次に、ログイン ドメインを作成します。認証には、CiscoAVPair またはグループ マップのいずれかを使用できます。

CiscoAVPair を使用した認証：

<aaaUserEp dn="uni/userext" status="created,modified">
    <aaaLoginDomain dn="uni/userext/logindomain-TestSAML"       name="TestSAML" status="created,modified">
        <aaaDomainAuth dn="uni/userext/logindomain-TestSAML/domainauth"           providerGroup="TestSAML" realm="saml" realmSubType="default"           status="created,modified"/>
    </aaaLoginDomain>
    <aaaSamlEp rn="samlext" status="modified">
        <aaaSamlProviderGroup dn="uni/userext/samlext/samlprovidergroup-TestSAML"           name="TestSAML" authChoice="CiscoAVPair" status="created,modified">
            <aaaProviderRef dn="uni/userext/samlext/samlprovider-auth.pingone.asia"               name="auth.pingone.asia" order="1" status="created,modified"/>
        </aaaSamlProviderGroup>
    </aaaSamlEp>
</aaaUserEp>

グループマップを使用した認証：

<aaaUserEp dn="uni/userext" status="created,modified">
    <aaaLoginDomain dn="uni/userext/logindomain-TestSAML" name="TestSAML"       status="created,modified">
        <aaaDomainAuth dn="uni/userext/logindomain-TestSAML/domainauth"           providerGroup="TestSAML" realm="saml" realmSubType="default"           status="created,modified"/>
    </aaaLoginDomain>
    <aaaSamlEp rn="samlext" status="modified">
        <aaaSamlProviderGroup dn="uni/userext/samlext/samlprovidergroup-TestSAML"           name="TestSAML" authChoice="LdapGroupMap" groupAttribute="memberOf"           status="created,modified">
            <aaaUserGroupMapRule name="AdminRule"               userGroup="CN=Domain Admins,CN=Users,DC=insaaadev,DC=net"               status="created,modified">
                <aaaUserDomain name="all" rn="userdomain-all" status="created,modified">
                    <aaaUserRole name="fabric-admin" privType="writePriv"                       rn="role-fabric-admin" status="created,modified"/>
                </aaaUserDomain>
                <aaaUserDomain name="mgmt" rn="userdomain-mgmt" status="created,modified">
                    <aaaUserRole name="access-admin" privType="writePriv"                       rn="role-access-admin" status="created,modified"/>
                    <aaaUserRole name="nw-svc-policy" privType="writePriv"                       rn="role-nw-svc-policy" status="created,modified"/>
                </aaaUserDomain>
            </aaaUserGroupMapRule>
            <aaaUserGroupMapRule name="EmpRule"               userGroup="CN=Employee,CN=Users,DC=insaaadev,DC=net"               status="created,modified">
                <aaaUserDomain name="mgmt" rn="userdomain-mgmt" status="created,modified">
                    <aaaUserRole name="ops" privType="writePriv" rn="role-ops"                       status="created,modified"/>
                </aaaUserDomain>
            </aaaUserGroupMapRule>
            <aaaProviderRef dn="uni/userext/samlext/samlprovider-auth.pingone.asia"               name="auth.pingone.asia" order="1" status="created,modified"/>
        </aaaSamlProviderGroup>
    </aaaSamlEp>
</aaaUserEp>

AD FS での証明書利用者信頼の設定

AD FS 管理コンソールで証明書利用者信頼を追加します：

手順

ステップ 1

証明書利用者信頼を追加します：

  1. AD FS サーバーの AD FS 管理コンソールにログインし、 [ADFS] > [信頼関係（Trust Relationships）] > [証明書利用者信頼（Relying Party Trusts）] に移動し、 [証明書利用者信頼の追加（Add Relying Party Trust）] を右クリックして [開始（Start）]をクリックします。

  2.   [証明書利用者についてのデータを手動で入力する（Enter data about the relying party manually）] または [証明書利用者についてのデータをファイルからインポートする（ステップ d、e、f、および g をスキップ）（Import data about relying party from a file）] を選択します。この場合、APIC の対応するログイン ドメイン セットアップで利用できる、 [SAML メタデータのダウンロード（Download SAML Metadata）] オプションを使用して生成されたメタデータ ファイルをインポートします。

  3. 証明書利用者信頼の優先 表示名（Display Name） を入力し、 [次へ（Next）]をクリックします。

  4. AD FS プロファイルを選択し、 [次へ（Next）]をクリックします。

  5.   [次へ（Next）] をもう一度クリックします。

  6.   [SAML 2.0 Web SSOプロトコルのサポートの有効化（Enable support for the SAML 2.0 Web SSO Protocol）] を選択し、 [証明書利用者の SAML 2.0 SSO サービスの URL（Relying party SAML 2.0 SSO service URL）] で に https://<APIC_hostname>/api/aaaLoginSSO.json?name =<Login_domain_name> を入力して、 [次へ（Next）]をクリックします。

  7. 次の情報を入力します。 [証明書利用者信頼の識別子（Relying party trust identifier）] として https://<APIC_hostname>/api/aaaLoginSSO.json を入力します。

  8.   [この時点では証明書利用者の多要素認証設定を構成しない（I do not want to configure multi-factor authentication settings for this relying party trust at this time）] を選択して [次へ（Next）]をクリックします。

  9. 移行方法 [この証明書利用者のアクセスをすべてのユーザーに許可（Permit all users to access this relying party）] を選択して [次へ（Next）]をクリックします。

  10. この証明書利用者信頼に対し、ウィザードが閉じるときに、 [請求ルールの編集ダイアログを開く（Open the Edit Claim rules）] を選択して、 [閉じる（Close）]をクリックします。

ステップ 2

以下の 要求（Claim） ルールを追加します：

  1. LDAP 属性を要求として送信します：

    • リスト [要求ルールの編集（Edit Claim Rules）] ウィンドウで、 [ルールの追加（Add Rule）]をクリックします。

    •   [要求ルール テンプレート（Claim Rule Template）] を送信 LDAP 属性として [要求（Claims）] と同じく選択し、 [次へ（Next）]をクリックします。

    •   Rule_Name を入力し、 [Active Directory] を属性ストアとして選択します。

    • CiscoAvpair を保存するための予約済みユーザー属性を選択（たとえば、 部署名（Department））を LDAP 属性タイプとして選択し、それを [出力方向の要求の手動タイプ（Outgoing Claim Manually Type）] に [CiscoAvpair]としてマップします。

    • LDAP 属性（LDAP Attirbute）の [E-Mail-Addresses（電子メールアドレス）] を選択し、LDAP属性を編集し、それを [出力方向の要求のタイプ（Outgoing Claim Type）] [電子メール アドレス（E-mail Address）] にマッピングし、 [終了（Finish）]をクリックします。

  2. 着信要求を変換します：

    •   [ルールの追加（Add Rule）] を [要求ルールの編集（Edit Claim Rules）] ウィンドウでもう一度クリックし、 [入力要求を要求ルール テンプレートとして変換（Transform an Incoming Claim as Claim Rule Template）] を選択し、 [次へ（Next）]をクリックします。

    •   [電子メールアドレス（E-Mail Address）] を [入力要求タイプ（Incoming claim type）] として選択します。

    •   [名前ID（Name ID））] を [出力要求タイプ（Outgoing claim type）] として選択します。

    • 選択 [一時識別子（Transient Identifier）] を [出力名 ID 形式（Outgoing name ID format）] として選択します。

ステップ 3

APIC のクラスターを追加するには、複数の [証明書利用者信頼（Relying Party Trusts）] をセットアップするか、単一の [証明書利用者信頼（Relying Party Trust）] をセットアップしてから、複数の [証明書利用者識別子（Relying Party Identifier）] および [SAML アサーション コンシューマ エンドポイント（SAML Assertion Consumer Endpoints）] をそれに追加します。

  1. 上記で作成した同じ証明書利用者信頼を持つクラスタ内に、他の APIC を追加します。

    1.   [ADFS 管理コンソール（ADFS Management Console）] > [ADFS] > [信頼関係（Trust Relationships）] > [証明書利用者信頼（Relying Party Trusts）] に移動し、 [CiscoAPIC] > [プロパティ（Properties）]を右クリックします。

    2. [識別子（Identifiers）] タブをクリックし、クラスター内の他の APIC を次のように追加します： https://<APIC2_hostname>/api/aaaLoginSSO.json、 https://<APIC3_hostname>/api/aaaLoginSSO.json

    3.   [エンドポイント（Endpoints）] タブをクリックし、他の 2 つの APIC を [Add SAML（SAML の追加）]をクリックして追加します。 [SAML Post バインディングの追加（Add SAML Post Binding）]で、インデックスを 1 とし、信頼できるURLを次のように入力します： https://<APIC2_hostname>/api/aaaLoginSSO.json?name=<Login_domain_name>、および [SAML Post バインディングの追加（Add SAML Post Binding）] を https://<APIC3_hostname>/api/aaaLoginSSO.json?name=<Login_domain_name>とします。

ステップ 4

メッセージとアサーションは、ADFS サーバ内の powershell から ADFS で署名する必要があります。ADFS サーバーでメッセージおよびアサーションを署名するには：

  1. Windows Powershell を開き（管理者として実行する必要があります）、次のコマンドを実行します。

  2. Set-AdfsRelyingPartyTrust -TargetName RelyingpartytrustnameOfCiscoAPIC SamlResponseSignature MessageAndAssertion。

OAuth 2 / OIDC 認証

Open Authorization (OAuth) 2.0 は、オープン標準の認証プロトコルです。OAuth 2.0 を使用すると、ID プロバイダー (IdP) によって信頼または承認されたアプリケーション（サービスプロバイダー、すなわち SP）にアクセスできます。OAuth 2.0 は、承認トークンを使用して、コンシューマー アプリケーションに ID と承認請求を提供します。

OAuth 2.0 の詳細については、RFC 6749 を参照してください。

OAuth 2.0 は、サービスプロバイダー アプリケーションから REST API を使用するさまざまなクライアントタイプをサポートするように設計されています。これには、企業内の Web サービスにアクセスするブラウザアプリケーションと、顧客のモバイルデバイスで実行されるアプリケーションの両方が含まれます。OAuth プロトコルでは、認証トークンを取得するための複数のメカニズムを定義し、さまざまなメカニズムがクライアントタイプの制約を認識します。単純な OAuth の例は、「https://service.example.com」などの Web サイトにログインしようとすると、ソーシャルメディア プラットフォームのログインまたは電子メールログインを使用して自分自身を識別するように求められる場合があります。これらの ID プロバイダーにログインしている場合は、何度もログインする必要はありません。いずれかのオプションを選択するとすぐに、「https://service.example.com」にログインすることが（OAuth を使用して）許可されます。

Cisco ACI での OAuth 2.0 認証

ACIで使用される OAuth のタイプは、 [承認付与フロー（authorization grant flow）]です。この方法では、Cisco APIC は最初に認証されたユーザーによる承認付与を要求し、APIC は次に承認付与を使用して、承認情報を持つアクセス トークンを取得します。フローを次の図に示します。

OAuth の要素

  • リソース所有者（ユーザー）：データ所有者

  • Web アプリケーション：APIC（または Cloud APIC ）

  • 承認サーバー（AS）または ID プロバイダー（IdP）サーバー：ユーザーを認証および承認します。

  • リソース サーバー：APIC


（注）  

承認サーバーが ID トークンとアクセス トークンの両方を提供する場合、ID トークンは、ユーザー名と CiscoAvpair クレームのアクセス トークンよりも優先されます。ID トークンで CiscoAvpair が利用できない場合、ユーザー名と CiscoAvpair の両方の要求がアクセス トークンから取得されます（利用可能な場合）。APIC は、両方のトークンからのユーザー名と CiscoAvpair クレームを結合しません。つまり、ID トークンからのユーザー名とアクセス トークンからの CiscoAvpair は考慮しません。また、その逆も考慮しません。どのトークンにも CiscoAvpair 要求がない場合、ID トークンからのユーザー名が取得され、設定されている場合はデフォルトの認証が試行されます。

Cisco APIC で OAuth を設定する

  [Cisco Application Policy Infrastructure Controller] （[APIC]）で OAuth を構成するには、次の手順に従います。

前提条件

認証サーバーで次のアクションを実行します：

  •   [Cisco APIC]用の OAuth アプリケーションを作成します。クライアント ID とシークレットを書き留めます。

  •   [Cisco APIC]へのアクセスを許可する認証ポリシーがセットアップされていることを確認します。

  •   authorize および token エンドポイントに注意してください [Cisco アプリケーション セントリック インフラストラクチャ（Cisco Application Centric Infrastructure）] （[ACI]）によって使用されるものです。

  •   [Cisco APIC]を使用するユーザーをアプリケーションに割り当てます。

  •   CiscoAvpair が、 [Cisco ACI]での承認のために、ユーザーに対して正しく設定されていることを確認します。

  • トークン URL の証明書チェーンを保存します。

アイデンティティ プロバイダーでの OAuth 2.0 アプリケーションの構成の詳細については、関連するドキュメントを参照してください。

OAuth 2 アクセス用の APIC の設定

この手順に従って、OAuth 2 プロバイダーを作成し、ログインドメインを関連付けます。

手順

ステップ 1

  [APIC]で、OAuth 2 プロバイダーを作成します。

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

ステップ 2

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

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

認証局を作成する

トークン URL に使用される証明書チェーンを使用して認証局を作成するには、この手順を使用します。

手順

ステップ 1

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

ステップ 2

[ナビゲーション（Navigation）] ペインで [セキュリティ（Security）]を選択します。

ステップ 3

[作業（Work）] ペインで、 [認証局（Certificate Authorities）]を選択します。

ステップ 4

  [アクション（Actions）] > [認証局の作成（Create Certificate Authority）]をクリックします。

ステップ 5

  [名前（Name）]、 [説明（Description）]、および 証明書チェーン (Certificate Chain)を入力します。

  [証明書チェーン（Certificate Chain）]を取得するには、以下の手順を実行します。

  1. 承認サーバーからトークン URL を選択します。

  2. ブラウザ ウィンドウで、トークン URL を入力します。

  3. 右クリックして、 [詳細情報（More Information）]を選択します。

  4. 表示されたポップアップ ウィンドウから、 [新しい証明書（New Certificate）] ボタンをクリックします。

  5.   [証明書（Certificate）] 画面で、 [PEM（チェーン）（PEM（Chain））] 証明書をダウンロードします。

  6. 適切なプログラムを選択してファイルを開きます。

  7. 表示された証明書のチェーンから必要な証明書を選択します。

（注）  

 

最大 8 つの認証局を作成できます。

ステップ 6

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

OAuth を使用したユーザー ログイン

OAuth 用に作成されたログイン ドメインを使用して APIC にログインしようとすると、認可サーバーのログイン ページにリダイレクトされます（まだ認証されていない場合）。ユーザーが認証されると、Web ブラウザを介して認可サーバーから APIC に認可コードが送信されます。APIC は、APIC アプリケーションのクライアント ID とシークレットを使用して、IdP からのアクセス トークンとこのコードを交換します。アクセス トークンには、 CiscoAvpairのユーザー名と認証の詳細が含まれています。その後、APIC にログインします。APIC では、ログインしているユーザーがそれに応じて示されます。

REST API を使用して APIC で OAuth を設定する

この手順を使用して、REST API を使用し APIC で OAuth を設定します。

手順

ステップ 1

OAuth プロバイダーを作成します。


<aaaOauthProvider name="auth.pingone.asia"   dn="uni/userext/oauthext/oauthprovider-auth.pingone.asia"   status="created,modified"   timeout="5"   key="vCnIq1EGCTPfqMU"   oidcEnabled="no"   verifyEnabled="yes"   baseUrl="https://auth.pingone.asia/oauth2/default"   clientId="0oa9g25h1cE7yZZ0t696"   usernameAttribute="EmailId"   scope="openid groups" tp="pingonecert"/>

ステップ 2

OAuth ログイン ドメインを作成します。認証には、CiscoAVPair またはグループ マップのいずれかを使用できます。

CiscoAVPair を使用した認証：

<aaaUserEp dn="uni/userext" status="created,modified">
    <aaaLoginDomain dn="uni/userext/logindomain-TOAUTH" name="TOAUTH"       status="created,modified">
        <aaaDomainAuth dn="uni/userext/logindomain-TOAUTH/domainauth"           providerGroup="TOAUTH" realm="oauth" realmSubType="default"           status="created,modified"/>
    </aaaLoginDomain>
    <aaaOauthEp rn="oauthext" status="modified">
        <aaaOauthProviderGroup dn="uni/userext/oauthext/oauthprovidergroup-TOAUTH"           name="TOAUTH" authChoice="CiscoAVPair" status="created,modified">
            <aaaProviderRef               dn="uni/userext/oauthext/oauthprovidergroup-TOAUTH/                 providerref-auth.pingone.asia"               name="auth.pingone.asia" order="1" status="created,modified"/>
        </aaaOauthProviderGroup>
    </aaaOauthEp>
</aaaUserEp>

（注）  

 

  aaaProviderRef dn 値には、読みやすくするために改行が含まれています。ただし、実際の値には改行を含めないでください。

グループ マップを使用した認証：

<aaaUserEp dn="uni/userext" status="created,modified">
    <aaaLoginDomain dn="uni/userext/logindomain-TOAUTH" name="TOAUTH"       status="created,modified">
        <aaaDomainAuth dn="uni/userext/logindomain-TOAUTH/domainauth"           providerGroup="TOAUTH" realm="oauth" realmSubType="default"           status="created,modified"/>
    </aaaLoginDomain>
    <aaaOauthEp rn="oauthext" status="modified">
        <aaaOauthProviderGroup dn="uni/userext/oauthext/oauthprovidergroup-TOAUTH"           name="TOAUTH" authChoice="LdapGroupMap" groupAttribute="memberOf"           status="created,modified">
            <aaaUserGroupMapRule name="AdminRule" userGroup="Domain Admins"               status="created,modified">
                <aaaUserDomain name="all" rn="userdomain-all" status="created,modified">
                    <aaaUserRole name="fabric-admin" privType="writePriv"                       rn="role-fabric-admin" status="created,modified"/>
                </aaaUserDomain>
                <aaaUserDomain name="mgmt" rn="userdomain-mgmt" status="created,modified">
                    <aaaUserRole name="access-admin" privType="writePriv"                       rn="role-access-admin" status="created,modified"/>
                    <aaaUserRole name="nw-svc-policy" privType="writePriv"                       rn="role-nw-svc-policy" status="created,modified"/>
                </aaaUserDomain>
            </aaaUserGroupMapRule>
            <aaaUserGroupMapRule name="EmpRule" userGroup="Employee"               status="created,modified">
                <aaaUserDomain name="mgmt" rn="userdomain-mgmt"                   status="created,modified">
                    <aaaUserRole name="ops" privType="writePriv" rn="role-ops"                       status="created,modified"/>
                </aaaUserDomain>
            </aaaUserGroupMapRule>
            <aaaProviderRef               dn="uni/userext/oauthext/oauthprovidergroup-TOAUTH/                 providerref-auth.pingone.asia"               name="auth.pingone.asia" order="1" status="created,modified"/>
        </aaaOauthProviderGroup>
    </aaaOauthEp>
</aaaUserEp>

（注）  

 

  aaaProviderRef dn 値には、読みやすくするために改行が含まれています。ただし、実際の値には改行を含めないでください。