概要
この記事は、RADIUS、TACACS +、LDAP ユーザーが APIC にアクセスできるようにする手順を説明します。読者が Cisco プリケーション セントリック インフラストラクチャの基礎マニュアル、特にユーザー アクセス権、認証、アカウンティングの章を十分に利害していると仮定しています。
この製品のマニュアルセットは、偏向のない言語を使用するように配慮されています。このマニュアルセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザーインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブランゲージに対する取り組みの詳細は、こちらをご覧ください。
このドキュメントは、米国シスコ発行ドキュメントの参考和訳です。リンク情報につきましては、日本語版掲載時点で、英語版にアップデートがあり、リンク先のページが移動/変更されている場合がありますことをご了承ください。あくまでも参考和訳となりますので、正式な内容については米国サイトのドキュメントを参照ください。
この章は、次の項で構成されています。
この記事は、RADIUS、TACACS +、LDAP ユーザーが APIC にアクセスできるようにする手順を説明します。読者が Cisco プリケーション セントリック インフラストラクチャの基礎マニュアル、特にユーザー アクセス権、認証、アカウンティングの章を十分に利害していると仮定しています。
RADIUS サーバでユーザを設定するには、APIC 管理者は cisco-av-pair
属性を使用して必要な属性(shell:domains
)を設定する必要があります。デフォルトのユーザ ロールは、network-operator です。
SNMPv3 認証プロトコルに指定できるオプションは、SHA と MD5 です。プライバシー プロトコルに指定できるオプションは、AES-128 と DES です。これらのオプションが cisco-av-pair
属性で指定されていない場合は、MD5 および DES がデフォルトの認証プロトコルとなります。
たとえば、SNMPv3 認証とプライバシー プロトコルの属性は次のように指定できます。
snmpv3:auth=SHA priv=AES-128
同様に、ドメインのリストは次のとおりです。
shell:domains="domainA domainB …"
Terminal Access Controller Access Control device Plus(TACACS+)は、シスコ デバイスでサポートされる別のリモート AAA プロトコルです。TACACS+ には、RADIUS 認証にはない次の利点があります。
独立した AAA ファシリティを提供する。たとえば、APICは、認証を行わずにアクセスを許可できます。
AAA クライアントとサーバ間のデータ送信に TCP を使用しているため、コネクション型プロトコルによる確実な転送が可能になります。
スイッチと AAA サーバ間でプロトコル ペイロード全体を暗号化して、高度なデータ機密性を実現します。RADIUS はパスワードのみを暗号化します。
構文と設定が RADIUS と異なる av-pairs を使用しますが、APIC は shell:domains
をサポートします。
(注) |
TACACS サーバおよび TACAC ポートは、ping で到達可能である必要があります。 |
(注) |
この例では IPv4 アドレスを使用していますが、IPv6 アドレスも使用できます。 |
<aaaTacacsPlusProvider name="10.193.208.9"
key="test123"
authProtocol=”pap”/>
APIC での Linux シェル用のユーザ ID は、ローカル ユーザ用に APIC 内で生成されます。認証クレデンシャルが外部サーバで管理されているユーザは、Linux シェル用のユーザ ID を cisco-av-pair で指定できます。上記の cisco-av-pair の(16001)を省略することは、リモート ユーザがデフォルトの Linux ユーザ ID 23999 を取得すれば可能です。Linux ユーザ ID がバッシュ セッション中に使用され、標準の 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)
ログイン ドメインは、ユーザの認証ドメインを定義します。ログイン ドメインは、ローカル、LDAP、RADIUS、または TACACS+ 認証メカニズムを設定できます。REST、CLI、または GUI からシステムにアクセスすると、APIC によりユーザは正しい認証ドメインを選択できます。
たとえば、REST シナリオでは、完全なログイン ユーザ名が次のように表示されるようにユーザ名の頭に文字列が付きます。
apic:<domain>\<username>
システムに GUI からアクセスする場合は、APIC により選択するユーザのドメインのドロップダウン リストが提供されます。apic: domain
が指定されない場合は、デフォルトの認証ドメイン サーバがユーザ名の検索に使用されます。
ACI バージョン 1.0(2x) 以降、APIC のログイン ドメイン フォールバックのデフォルトはローカルになっています。デフォルト認証とコンソール認証方法がどちらも非ローカルの方法に設定されており、両方の非ローカル方法がローカル認証に自動的にフォールバックしない場合でも、APIC にはローカル認証を使用してアクセスすることができます。
GUI からは、apic:fallback\\username を使用します。
REST API からは、apic#fallback\\username を使用します。
(注) |
フォールバック ログイン ドメインは変更しないでください。変更すると、システムからロックアウトされる可能性があります。 |
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"
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 グループ マップを作成するオプションがあります。 |
RSA 認証は、使用できる組み合わせで固定キーを使用して、パスワードを作成するさまざまな方法でトークンを提供します。これは、ハードウェア トークンとソフトウェア トークンの両方をサポートします。
ACI ファブリックが設置され、Application Policy Infrastructure Controller(APIC)がオンラインになっており、APIC クラスタが形成されて正常に動作していること。
RSA サーバのホスト名または IP アドレス、ポート、認証プロトコル、およびキーを使用できること。
APIC 管理エンドポイント グループを使用できること。
ステップ 1 |
APIC で、RSA プロバイダを作成します。
|
ステップ 2 |
RSA プロバイダー グループを作成します。
|
ステップ 3 |
RSA のログイン ドメインを作成します。
|
これで、APIC RSA 設定手順は完了です。次に、RSA サーバを設定します。
ローカル ユーザを設定する代わりに、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 サーバのホスト名ですでに名前解決されている必要があります。
管理サブネットを設定する必要があります。
Cisco APIC では、管理者が外部認証サーバで Cisco AV ペアを設定する必要があります。Cisco AV ペアは、ユーザの RBAC ロールおよび権限に必要な APIC を指定します。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 ペアを選択します。 |
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})$
例:
shell:domains=domainA/writeRole1|writeRole2/
shell:domains=domainA//readRole1|readRole2
(注) |
文字「/」はログイン ドメインごとに writeRole と readRole の間を区切る記号で、使用するロールの種類が 1 つのみである場合も必要です。 Cisco AV ペアの文字列は、大文字と小文字が区別されます。エラーが表示されなくても、使用する大文字と小文字がドメイン名またはロールに一致していない場合は、予期しない権限が付与されることがあります。 |
オープン RADIUS サーバ(/etc/raddb/users)の設定例は次のとおりです。
aaa-network-admin Cleartext-Password := "<password>"
Cisco-avpair = "shell:domains = all/aaa/read-all(16001)"
ベスト プラクティスとして、
Cisco は、bash シェルでユーザに割り当てられる AV ペアには 16000 ~ 23999 の範囲の一意の UNIX ユーザ ID を割り当てることを推奨します(SSH、Telnet または Serial/KVM のコンソールを使用)。Cisco AV ペアが UNIX ユーザ ID を提供しない状況が発生すると、そのユーザにはユーザ ID 23999 または範囲内の類似した番号が割り当てられます。これにより、そのユーザのホーム ディレクトリ、ファイル、およびプロセスに UNIX ID 23999 を持つリモート ユーザがアクセスできるようになってしまいます。
リモート認証サーバがその av ペアを cisco 応答 UNIX ID を明示的に指定していないことを確認するには、(リモート ユーザ アカウントを使用) は、管理者として、APIC とログインへの SSH セッションを開きます。ログインすると、次のコマンド (置換」ユーザ id「ログに記録するユーザ名と) を実行します。
admin@apic1:remoteuser-userid> cd /mit/uni/userext/remoteuser-userid
admin@apic1:remoteuser-userid> cat summary
Cisco AV ペアの文字列は、大文字と小文字が区別されます。エラーが表示されなくても、使用する大文字と小文字がドメイン名またはロールに一致していない場合は、予期しない権限が付与されることがあります。
属性/値(AV)のペア文字列のカッコ内の数字は、セキュア シェル(SSH)または Telnet を使用してログインしたユーザの UNIX ユーザ ID として使用されます。
外部認証サーバの AV ペアを設定します。 例:
次に、例を示します。
|
Cisco Application Centric Infrastructure(ACI)ファブリックが設置され、Application Policy Infrastructure Controller(APIC)がオンラインになっており、APIC クラスタが形成されて正常に動作していること。
TACACS+ サーバのホスト名または IP アドレス、ポート、およびキーを使用できること。
APIC 管理エンドポイント グループを使用できること。
ステップ 1 |
APIC で、TACACS+ プロバイダーを作成します。 |
ステップ 2 |
[TACACS+ Provider Group] を作成します。
|
ステップ 3 |
TACACS+ の [Login Domain] を作成します。
|
これで、APIC TACACS+ 設定手順は完了です。次に、RAIDUS サーバも使用する場合は、RADIUS 用の APIC の設定も行います。TACACS+ サーバのみを使用する場合は、次の ACS サーバ設定に関するトピックに進みます。
ACI ファブリックが設置され、Application Policy Infrastructure Controller (APIC) がオンラインになっており、APIC クラスタが形成されて正常に動作していること。
RADIUS サーバのホスト名または IP アドレス、ポート、認証プロトコル、およびキーを使用できること。
APIC 管理エンドポイント グループを使用できること。
ステップ 1 |
APIC で、RADIUS プロバイダーを作成します。 |
ステップ 2 |
RADIUS プロバイダー グループを作成します。
|
ステップ 3 |
RADIUS のログイン ドメインを作成します。
|
これで、APIC RADIUS 設定手順は完了です。次に、RADIUS サーバを設定します。
Cisco Secure Access Control Server (ACS) バージョン 5.5 がインストールされ、オンラインになっていること。
(注) |
ここでは手順の説明に ACS v5.5 が使用されています。ACS の他のバージョンでもこのタスクを実行できる可能性がありますが、GUI の手順はバージョンによって異なる場合があります。 |
Cisco Application Policy Infrastructure Controller (Cisco APIC) の RADIUS キーまたは TACACS+ キーを使用できること (両方を設定する場合は両方のキー) 。
Cisco APIC がインストールされ、オンラインになっていること。Cisco APIC クラスタが形成されて正常に動作していること。
RADIUS または TACACS+ のポート、認証プロトコル、およびキーを使用できること。
ステップ 1 |
Cisco APIC をクライアントとして設定するには、ACS サーバにログインします。 |
ステップ 2 |
ID グループを作成します。
|
ステップ 3 |
ユーザを ID グループにマッピングします。
|
ステップ 4 |
ポリシー要素を作成します。 |
ステップ 5 |
サービス選択ルールを作成します。
|
新しく作成された RADIUS および TACACS+ のユーザを使用して、Cisco APIC にログインします。割り当てられた RBAC ロールと権限に従って正しい Cisco APIC セキュリティ ドメインにアクセスできることを確認します。ユーザは、明示的に許可されていない項目にアクセスできてはなりません。読み取り/書き込みアクセス権が、そのユーザに設定されたものと一致している必要があります。
LDAP 設定には 2 つのオプションがあります。Cisco AVPair を設定したり、APIC 内で LDAP グループ マップを設定したりできます。このセクションには、両方の設定オプションの手順が含まれています。
最初に LDAP サーバを設定し、次に Cisco Application Policy Infrastructure Controller(Cisco APIC)を LDAP アクセス用に設定する。
Microsoft Windows Server 2008 がインストールされ、オンラインになっていること。
Microsoft Windows Server 2008 サーバ マネージャの ADSI Edit ツールがインストールされていること。ADSI Edit をインストールするには、Windows Server 2008 サーバ マネージャのヘルプに記載されている手順に従ってください。
CiscoAVPair
の属性の指定: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 2008 ユーザ アカウントを使用できること。
ADSI Edit を実行して CiscoAVPair
属性を Active Directory(AD)スキーマに追加します。
CiscoAVPair
属性パラメータに対するアクセス許可を持つように Active Directory LDAP ユーザーを設定します。
ポート 636 は、SSll/TLS と LDAP の連携設定に必要です。
ステップ 1 |
ドメイン管理者として Active Directory(AD)サーバにログインします。 |
ステップ 2 |
AD スキーマに |
ステップ 3 |
[User Properties] クラスを [CiscoAVPair] 属性が含まれるように更新します。 |
ステップ 4 |
CiscoAVPair 属性のアクセス許可を設定します。 LDAP には CiscoAVPair 属性が含まれているため、LDAP ユーザーに Cisco APIC RBAC ロールを割り当てることにより Cisco APIC アクセス許可を付与する必要があります。 |
Cisco APIC を LDAP アクセス用に設定します。
Cisco Application Centric Infrastructure(ACI)ファブリックが設置され、Application Policy Infrastructure Controller(APIC)がオンラインになっており、APIC クラスタが形成されて正常に動作していること。
LDAP サーバのホスト名または IP アドレス、ポート、バインド DN、ベース DN、およびパスワードを使用できること。
APIC 管理エンドポイント グループを使用できること。
ステップ 1 |
APIC で、LDAP プロバイダーを設定します。 |
ステップ 2 |
APIC で、LDAP プロバイダー グループを設定します。 |
ステップ 3 |
APIC で、LDAP のログイン ドメインを設定します。
|
This completes the APIC LDAP configuration steps. Next, test the APIC LDAP login access.
Cisco APIC での LDAP グループ マップの設定には、作成の最初の LDAP グループ マップ ルールが必要です。このセクションでは、LDAP グループ マップ ルールを作成する方法について説明します。
LDAPサーバが設定されているグループのマッピングを実行しています。
ステップ 1 |
Cisco APIC GUI のメニュー バーで、 を選択します。 |
ステップ 2 |
[Navigation] ペインで、 [LDAP Managment] を展開し、[LDAP Group Map Rules] を右クリックして、 [Create LDAP Group Map Rule] をクリックします。[Create LDAP Group Map Rule: Security] ダイアログが表示されます。 |
ステップ 3 |
該当するフィールドにマップ ルールの名前、説明 (オプション)、グループの DN、およびセキュリティ ドメインを指定し、[Next] をクリックします。セキュリティ ドメイン オプションが表示された [Create LDAP Group Map Rule: Roles] ダイアログが表示されます。 |
ステップ 4 |
[+] をクリックして、[Role Name] および [Role Privilege Type] フィールドにアクセスします。 |
ステップ 5 |
[Role Name] ドロップダウン矢印をクリックして、ロール名を選択します。 |
ステップ 6 |
[Role Privilege Type] ドロップダウン矢印をクリックして、ロール権限のタイプを選択します ( [Read] または [Write] )。 ステップ 4 ~ 6 を繰り返して、LDAP グループ マップに他のロールを追加します。 |
ステップ 7 |
完了したら、[Finished] をクリックします。 |
LDAP グループ マップ ルールを指定した後に、LDAP グループ マップを作成します。
Cisco APIC での LDAP グループ マップの設定には、作成の最初の LDAP グループ マップ ルールが必要です。このセクションでは、LDAP グループ マップを作成する方法について説明します。
実行中の LDAPサーバは、グループ マッピングで設定されます。
LDAP グループ マップ ルールが設定されています。
ステップ 1 |
Cisco APIC GUI のメニュー バーで、 を選択します。 |
ステップ 2 |
[Navigation] ペインで、 [LDAP Managment] を展開し、[LDAP Group Maps] を右クリックして、 [Create LDAP Group Map] をクリックします。[Create LDAP Group Map] ダイアログが表示されます。 |
ステップ 3 |
マップの名前と説明(オプション)を指定します。 |
ステップ 4 |
[Rules] フィールドで、[+] をクリックしてから、 [Name] ドロップダウン矢印をクリックして、指定した LDAP グループ マップ ルールを選択し、[Update] をクリックします。 ステップ 4 を繰り返して、LDAP グループ マップに他のルールを追加します。 |
ステップ 5 |
完了したら、[送信(Submit)] をクリックします。 |
ローカル ユーザを設定する代わりに、APIC を一元化された企業クレデンシャルのデータセンターに向けることができます。APIC は、Lightweight Directory Access Protocol(LDAP)、Active Directory、RADIUS、および TACACS+ をサポートしています。
外部認証プロバイダーを通じて認証されたリモート ユーザを設定するには、次の前提条件を満たす必要があります。
DNS 設定は、RADIUS サーバのホスト名ですでに名前解決されている必要があります。
管理サブネットを設定する必要があります。
ステップ 1 |
メニュー バーで、 の順にクリックします。 |
ステップ 2 |
[Navigation] ペインで、[AAA Authentication] をクリックします。 |
ステップ 3 |
[Work] ペインの [Properties] 領域で、[Remote user login policy] ドロップダウン リストから、[Assign Default Role] を選択します。 デフォルト値は [No Login] です。[Assign Default Role] オプションは、Cisco AV ペアが欠落しているか不良であるユーザに最小限の読み取り専用権限を割り当てます。不正な AV ペアは、解析ルール適用時に問題があった AV ペアです。 |
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 で、コンフィギュレーション モードで開始します。 例:
|
ステップ 2 |
aaa ユーザ デフォルト ロールを設定します。 例:
|
ステップ 3 |
aaa 認証ログイン メソッドを設定します。 例:
|
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 に資格情報を再入力する時間が省けるため、生産性が向上します。
パスワードをリセットするためのヘルプ デスクへの問い合わせが減るため、コスト削減につながります。
クライアント(ユーザのクライアント):これは、認証用にブラウザ インスタンスを活用できる、ブラウザ ベースのクライアントまたはクライアントです。システム管理者のブラウザはその一例です。
サービス プロバイダー:これは、クライアントがアクセスを試みるアプリケーションまたはサービスです。
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 を使用します。 |
ID プロバイダー(IdP)は、ユーザ、システム、サービスの ID 情報を作成、維持、管理する認証モジュールです。また、分散ネットワーク内のその他のアプリケーションやサービス プロバイダーに対して認証も行います。
SAML SSO で、IdPs はユーザーのロールまたは各 Cisco コラボレーション アプリケーションのログイン オプションに基づいて、認証オプションを提供します。IdP は、ユーザ資格情報を保管、検証し、ユーザがサービス プロバイダーの保護リソースにアクセスできる SAML 応答を生成します。
(注) |
IdP サービスを十分理解している必要があります。現在インストールされていて、操作可能であることを確認してください。 |
APIC の SAML SSO 機能は、次の IdP でテストされています。
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 アサーション、プロトコル、およびバインディングの組み合わせについて詳細に説明しています。
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 のログイン ページにリダイレクトされます。 |
Domain Name System(DNS)により、ホスト名とネットワーク サービスをネットワーク(複数可)内の IP アドレスにマッピングできるようになります。ネットワーク内に配置された DNS サーバは、ネットワーク サービスをホスト名にマッピングし、次にホスト名を IP アドレスにマッピングするデータベースを備えています。ネットワーク上のデバイスは、DNS サーバに照会して、ネットワークにある他のデバイスの IP アドレスを受信できます。そのため、ネットワーク デバイス間の通信が容易になります。
まとめると、APIC および Idp は互いの完全修飾ドメイン名を IP アドレスに対して解消でき、クライアントによって解消される必要があります。
シスコは、次のいずれかの種類の認証局(CA)により署名されるサーバ証明書を使用することを推奨します。
パブリック CA:サードパーティ企業が、サーバの識別情報を確認し、信頼できる証明書を発行します。
プライベート CA:自身でローカルの CA を作成および管理し、信頼できる証明書を発行します。
署名プロセスは製品ごとに異なり、サーバのバージョン間でも異なる場合があります。各サーバのすべてのバージョンに関する詳細な手順については、このマニュアルの範囲外になります。CA により署名された証明書を取得する方法の詳細な手順については、該当するサーバのマニュアルを参照してください。
パブリック CA により署名されたサーバ証明書を取得する場合、パブリック CA は、クライアント コンピュータの信頼ストアで、ルート証明書をあらかじめ提示しておくようにします。この場合、クライアント コンピュータでルート証明書をインポートする必要はありません。プライベート CA など、CA により署名される証明書が信頼ストアにまだ存在しない場合は、ルート証明書をインポートしてください。SAML SSO では、CN または SAN での正しいドメインが記載された CA 署名付き証明書が、IdP およびサービス プロバイダーに必要になります。正しい CA 証明書が検証されない場合、ブラウザはポップ アップ警告を出します。
APIC の信頼ストアに IdP のルート証明書が含まれていない場合は、新しい証明機関を作成する必要があります。APIC で SAML プロバイダを設定する際は、この認証機関を後で使用する必要があります。
(注) |
SAML ベースの認証と CLI/REST の APIC GUI でのみです。また、リーフ スイッチと背表紙には適用されません。APIC CLI では、SAML 設定を行うことはできません。 |
Cisco Application Centric Infrastructure(ACI)ファブリックが設置され、Application Policy Infrastructure Controller(APIC)がオンラインになっており、APIC クラスタが形成されて正常に動作していること。
SAML サーバ ホスト名または IP アドレスと、IdP メタデータの URL を使用できます。
APIC 管理エンドポイント グループを使用できること。
次の設定を行います。
拡張 GUI を使用した DNS プロバイダーと接続するための DNS サービス ポリシーの設定:https://www.cisco.com/c/en/us/td/docs/switches/datacenter/aci/apic/sw/3-x/basic_config/b_APIC_Basic_Config_Guide_3_x/b_APIC_Basic_Config_Guide_3_x_chapter_011.html#task_750E077676704BFBB5B0FE74628D821E。
GUI を使用した Cisco ACI HTTPS アクセス用カスタム証明書の設定:https://www.cisco.com/c/en/us/td/docs/switches/datacenter/aci/apic/sw/3-x/basic_config/b_APIC_Basic_Config_Guide_3_x/b_APIC_Basic_Config_Guide_3_x_chapter_011.html#task_F037F1B75FF74ED1BCA4F3C75A16C0FA。
ステップ 1 |
APIC で、SAML プロバイダーを作成します。 |
ステップ 2 |
SAML プロバイダー グループを作成します。
|
ステップ 3 |
SAML のログイン ドメインを作成します。
|
Okta で SAML を設定するには、管理者特権を持つユーザーとして Okta 組織にログインします。
(注) |
Okta 組織をお持ちでない場合、空の Okta を作成できます。 https://www.okta.com/start-with-okta/ |
ステップ 1 |
Okta で、青色の [管理者] ボタンをクリックします。 |
||
ステップ 2 |
[アプリケーションの追加] ショートカットをクリックします。 |
||
ステップ 3 |
緑色の [新しいアプリケーションの作成] ボタンをクリックし、次の操作を行います。 |
||
ステップ 4 |
新しく作成した [例 SAML アプリケーション] アプリケーションの [サイン オン] が表示されます。このページを保存し、別のタブまたはブラウザウィンドウで開きます。SAML 設定の [ID プロバイダ メタデータ] をコピーするには、後でこのページに戻ります。
|
AD FS 管理コンソールで信頼当事者証明を追加します。
ステップ 1 |
証明書利用者信頼を追加します。
|
ステップ 2 |
次のクレーム ルールを追加します。 |
ステップ 3 |
APIC のクラスタを追加するには、複数の信頼当事者証明をセットアップするか、または 1 つの信頼当事者証明をセットアップしてから複数の信頼当事者識別子 および SAML アサーション コンシューマ エンドポイント をそれに追加することができます。 |
ステップ 4 |
メッセージとアサーションは、ADFS サーバ内の powershell から ADFS で署名する必要があります。ADFS サーバでメッセージおよびアサーションを署名するには:
|