Cisco Secure ACS ユーザ ガイド Windows 版 Version 3.3
システム設定:認証と証明書
システム設定:認証と証明書
発行日;2012/01/13 | ドキュメントご利用ガイド | ダウンロード ; この章pdf | フィードバック

目次

システム設定:認証と証明書

認証と EAP プロトコルについて

デジタル証明書

EAP-TLS 認証

EAP-TLS プロトコルについて

EAP-TLS と Cisco Secure ACS

EAP-TLS での制限事項

EAP-TLS 認証のイネーブル化

PEAP 認証

PEAP プロトコルについて

PEAP と Cisco Secure ACS

PEAP と未知ユーザ ポリシー

PEAP 認証のイネーブル化

EAP-FAST 認証

EAP-FAST について

マスター キーについて

PAC について

マスター キーと PAC TTL

複製と EAP-FAST

EAP-FAST のイネーブル化

グローバル認証のセットアップ

認証設定オプション

認証オプションの設定

Cisco Secure ACS 証明書のセットアップ

Cisco Secure ACS サーバ証明書のインストール

認証局証明書の追加

証明書信頼リストの編集

証明書失効リストの管理

証明書失効リストについて

証明書失効リストの設定オプション

証明書失効リスト発行者の追加

証明書失効リスト発行者の編集

証明書失効リスト発行者の削除

証明書署名要求の生成

自己署名証明書の使用

自己署名証明書について

自己署名証明書の設定オプション

自己署名証明書の生成

Cisco Secure ACS 証明書のアップデートまたは置き換え

システム設定:認証と証明書

この章では、Cisco Secure ACS Solution Engine の System Configuration セクションにある認証機能について説明します。

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

「認証と EAP プロトコルについて」

「グローバル認証のセットアップ」

「Cisco Secure ACS 証明書のセットアップ」

認証と EAP プロトコルについて

Cisco Secure ACS は、EAP-TLS 認証プロトコルと PEAP 認証プロトコルをデジタル認証と組み合わせて使用して、認証情報の保護と正当性を保証しています。デジタル認証、EAP-TLS、PEAP、およびマシン認証については、これ以降のトピックで説明します。

この項では、次のトピックについて取り上げます。

「デジタル証明書」

「EAP-TLS 認証」

「PEAP 認証」

「EAP-FAST 認証」

デジタル証明書

Cisco Secure ACS HTML インターフェイスに安全にアクセスするための HTTPS プロトコルのサポートに加えて、EAP-TLS 認証と PEAP 認証をサポートするために、ACS Certificate Setup ページを使用してデジタル証明書をインストールできます。Cisco Secure ACS は、X.509 v3 デジタル証明書標準を使用します。証明書ファイルは、Base64-encoded X.509 形式または DER-encoded バイナリ X.509 形式にする必要があります。さらに、Cisco Secure ACS は証明書の手動登録をサポートし、証明書信頼リスト(CTL)と証明書失効リスト(CRL)を管理する手段を提供します。

デジタル証明書は、秘密情報も保存データベース クレデンシャルも共有する必要がありません。どちらも規模拡大が可能で、大きく展開しても信頼できます。正しく管理すれば、共有秘密システムより強力でセキュアな認証方式として動作させることができます。相互信頼には、エンドユーザ クライアント側で確認できる証明書が Cisco Secure ACS にインストールされている必要があります。このサーバ証明書は、認証局(CA)から発行されたものを使用することもできますし、自己署名証明書を使用することもできます。詳細については、「Cisco Secure ACS サーバ証明書のインストール」および 「自己署名証明書の使用」を参照してください。


) 関係するエンドユーザ クライアントによっては、エンドユーザ クライアント コンピュータ上の信頼できる根本の CA 用に、Cisco Secure ACS サーバ証明書を発行した CA の CA 証明書がローカル ストレージで必要になる場合もあります。


EAP-TLS 認証

この項では、次のトピックについて取り上げます。

「EAP-TLS プロトコルについて」

「EAP-TLS と Cisco Secure ACS」

「EAP-TLS での制限事項」

「EAP-TLS 認証のイネーブル化」

EAP-TLS プロトコルについて

EAP と TLS は、どちらも IETF RFC 標準です。EAP プロトコルは、初期認証情報、具体的には EAPOL(IEEE 802.1X で確立されている LAN 上の EAP のカプセル化)を伝達します。TLS は、ユーザ認証とダイナミック短期セッション キー生成の両方に証明書を使用します。EAP-TLS 認証プロトコルは、Cisco Secure ACS とエンドユーザ クライアントの証明書を使用して、クライアントと Cisco Secure ACS の相互認証を適用します。EAP、TLS、および EAP-TLS の詳細については、IETF RFC( PPP Extensible Authentication Protocol [EAP] RFC 2284 The TLS Protocol RFC 2246 、および PPP EAP TLS Authentication Protocol RFC 2716 )を参照してください。

EAP-TLS 認証では、2 つの信頼要素が必要です。信頼要素の 1 つ目は、EAP-TLS ネゴシエーションにおいてエンド ユーザの信頼を RSA 署名検証で確認して確立しているときに、証明書によって署名されているキーペアをユーザが所有していることです。これによって、エンドユーザが特定のデジタル証明書に対する正当なキー所有者であること、およびその証明書に含まれているユーザ ID に対応していることが確認されます。しかし、ユーザが証明書を所有していることを信頼しても、ユーザ名/キーペアを確認するに過ぎません。第 2 の信頼要素は、証明書の情報を確認する第三者署名、通常は認証局(CA)の署名を使用することです。第三者による確認は、パスポートの印証の確認にあたります。パスポートが信頼できるのは、特定の国/地域のパスポート発行機関が、そのパスポートを作成する際に行った準備と身元確認が信頼できるためです。根本の証明書 CA の署名がインストールされていることで、デジタル証明書は信頼されます。

根本の証明書 CA の署名のインストールによって提供されるこの「第 2 の信頼要素」は、必要ない場合もあります。証明書の正当性に対するこのような外部検証が必要ない場合は、Cisco Secure ACS 自己署名証明書機能を使用できます。関係するエンドユーザ クライアントによっては、エンドユーザ クライアント コンピュータ上の信頼できるルート CA 用に、Cisco Secure ACS サーバ証明書を発行した CA の CA 証明書がローカル ストレージで必要になる場合もあります。詳細については、「自己署名証明書について」を参照してください。

EAP-TLS は、エンド クライアントと AAA クライアントの両方からのサポートが必要です。EAP-TLS クライアントの例としては、Microsoft Windows XP オペレーティング システムが挙げられます。EAP-TLS に準拠した AAA クライアントの例としては、Cisco 802.1x 対応のスイッチ プラットフォーム(Catalyst 6500 シリーズなど)および Cisco Aironet Wireless ソリューションが挙げられます。EAP-TLS は、セキュアな Cisco Aironet 接続を実現するために、各ユーザ、各接続に固有のダイナミックなセッション キーを生成します。

EAP-TLS と Cisco Secure ACS

Cisco Secure ACS は、Windows XP など、EAP-TLS をサポートする任意のエンドユーザ クライアントに対して、EAP-TLS をサポートしています。EAP-TLS をサポートしているユーザ データベースを確認するには、「認証プロトコルとデータベースの互換性」を参照してください。EAP-TLS 認証の展開に関する詳細については、『 Extensible Authentication Protocol Transport Layer Security Deployment Guide for Wireless LAN Networks 』を次の Web ページで参照してください。 http://www.cisco.com/warp/public/cc/pd/sqsw/sq/tech/acstl_wp.htm

Cisco Secure ACS は、EAP-TLS を使用して、Microsoft Windows Active Directory に対するマシン認証をサポートすることができます。エンドユーザ クライアントは、ユーザ認証に使用するプロトコルを、マシン認証に使用するプロトコルと同じものに制限している場合があります。つまり、マシン認証に EAP-TLS を使用する場合は、ユーザ認証にも EAP-TLS を使用する必要がある場合があります。マシン認証の詳細については、「マシン認証」を参照してください。

Cisco Secure ACS は、Windows Active Directory を使用した EAP-TLS 認証に対して、ドメイン ストリッピングをサポートしています。詳細については、「EAP-TLS ドメインのストリッピング」を参照してください。

Cisco Secure ACS は、また、証明書を比較する 3 つの方法と、セッション再開機能もサポートしています。ここでは、これらの機能について説明します。

EAP-TLS を使用して認証を受けるユーザまたはコンピュータに対してネットワーク アクセスを許可するには、Cisco Secure ACS で、要求されている識別情報(EAP Identity 応答で提示されている)がユーザの提出した証明書に対応しているかどうかを確認する必要があります。Cisco Secure ACS は、この確認を次の 3 つの方法で実行できます。

証明書の SAN 比較 :ユーザ証明書内の Subject Alternative Name フィールドの名前に基づきます。

証明書の CN 比較 :ユーザ証明書内の Subject Common Name フィールドの名前に基づきます。

証明書のバイナリ比較 :LDAP サーバまたは Active Directory のユーザ オブジェクトに格納されているユーザ証明書と、EAP-TLS 認証中にユーザが提示した証明書とのバイナリ比較に基づきます。ODBC 外部ユーザ データベースに格納されているユーザの認証に、この比較方法を使用することはできません。


) 証明書のバイナリ比較を利用する場合は、ユーザ証明書がバイナリ形式で格納されている必要があります。また、汎用 LDAP と Active Directory の場合、証明書を格納するアトリビュートが「usercertificate」という名前の標準 LDAP アトリビュートである必要があります。


Cisco Secure ACS が使用する比較方法(1 つ、2 つ、またはすべて)は、EAP-TLS をセットアップするときに選択できます。詳細については、「認証オプションの設定」を参照してください。

Cisco Secure ACS は、EAP-TLS 認証済みユーザ セッションに対して、セッション再開機能をサポートしています。この機能は、特に WLAN に対して有用です。WLAN では、ユーザがクライアント コンピュータを移動すると、別の無線アクセス ポイントが使用される場合があります。この機能がイネーブルの場合、Cisco Secure ACS は、ユーザが正常に認証された場合に限り、EAP-TLS 認証中に作成された TLS セッションをキャッシュします。ユーザが再接続しようとする場合、元の EAP-TLS セッションがタイムアウトしていなければ、Cisco Secure ACS はキャッシュされた TLS セッションを使用します。このため、EAP-TLS のパフォーマンスが向上し、AAA サーバの負荷が軽減されます。Cisco Secure ACS が EAP-TLS セッションを再開した場合、ユーザの再認証は SSL ハンドシェイクだけで行われ、証明書の比較は行われません。

実際には、EAP-TLS セッション再開がイネーブルの場合、Cisco Secure ACS は、元の EAP-TLS 認証時にキャッシュされた TLS セッションに基づいてユーザを信頼するようになります。Cisco Secure ACS は新規の EAP-TLS 認証が成功した場合に限って TLS セッションをキャッシュするため、キャッシュされた TLS セッションが存在しているということは、EAP-TLS セッション タイムアウト オプションで定義された時間(分単位)内にユーザが正常に認証されたことの証明となります。


) セッション タイムアウトは、セッションの認証が最初に完全に実行されたときの時間に基づきます。アカウンティング開始メッセージには依存しません。


セッション再開機能を使用しても、外部ユーザ データベース内のグループ割り当ては変更されません。これは、ユーザ セッションが再開されるときには、グループ マッピングが発生しないためです。その代わり、ユーザは、セッションの開始時にマッピングされた Cisco Secure ACS グループにマッピングされます。新規のセッションが開始すると、グループ マッピングにより新規のグループ割り当てが実行されます。

セッション タイムアウトに達する前に EAP-TLS セッションを終了させるには、CSAuth サービスを再開するか、CiscoSecure ユーザ データベースからユーザを削除します。外部ユーザ データベース内のユーザのディセーブル化または削除を行っても影響しません。これは、セッション再開機能では外部ユーザ データベースが使用されないためです。

EAP-TLS セッション再開機能のイネーブル化とタイムアウト間隔の設定は、Global Authentication Setup ページで行えます。この機能のイネーブル化の詳細については、「グローバル認証のセットアップ」を参照してください。

EAP-TLS での制限事項

Cisco Secure ACS の EAP-TLS 実装には、次のような制限事項があります。

サーバ証明書と CA 証明書のファイル形式 :Cisco Secure ACS サーバ証明書と CA 証明書を証明書ストレージからではなく、ファイルからインストールする場合、サーバ証明書ファイルと CA 証明書ファイルは、Base64-encoded X.509 形式または DER-encoded バイナリ X.509 形式である必要があります。

バイナリ比較のための LDAP アトリビュート :ユーザ証明書のバイナリ比較を実行するように Cisco Secure ACS を設定する場合は、ユーザ証明書が Active Directory または LDAP サーバにバイナリ形式で格納されている必要があります。さらに、証明書を格納するアトリビュートが usercertificate という名前である必要があります。

Windows サーバのタイプ :Cisco Secure ACS がメンバー サーバ上で動作しているときに、Active Directory を使用して、EAP-TLS でユーザを認証する場合は、追加設定を行う必要があります。追加設定の手順など、詳細については、『 Installation Guide for Cisco Secure ACS for Windows Server 』を参照してください。

また、Cisco Secure ACS が無効な共有秘密情報を持つ無線アクセス ポイントからトラフィックを受信すると、試行失敗ログに「EAP request has invalid signature.」というエラー メッセージが記録されます。このエラーが発生するのは、次の 3 つの条件のうち、いずれかに該当する場合です。

無効な署名が使用されている。

RADIUS パケットが転送中に破損した。

Cisco Secure ACS が攻撃を受けている。

EAP-TLS 認証のイネーブル化

ここでは、EAP-TLS 認証をサポートするように Cisco Secure ACS を設定する詳細な手順の概要を示します。


) エンドユーザ クライアント コンピュータは、EAP-TLS をサポートするように設定されている必要があります。ここでは、Cisco Secure ACS の設定だけを取り上げます。EAP-TLS 認証の展開に関する詳細については、『Extensible Authentication Protocol Transport Layer Security Deployment Guide for Wireless LAN Networks』を次の Web ページで参照してください。
http://www.cisco.com/warp/public/cc/pd/sqsw/sq/tech/acstl_wp.htm


始める前に

EAP-TLS マシン認証の場合、ドメイン コントローラ上に Microsoft 認証局サーバが設定されているときは、ドメインにコンピュータが追加された際にクライアント証明書が自動的に作成されるように、Active Directory 内のポリシーを設定できます。詳細については、 Microsoft Knowledge Base 記事 313407 『HOW TO: Create Automatic Certificate Requests with Group Policy in Windows』 を参照してください。

EAP-TLS 認証をイネーブルにするには、次の手順を実行します。


ステップ 1 Cisco Secure ACS にサーバ証明書をインストールします。EAP-TLS ではサーバ証明書が必要です。詳細な手順については、「Cisco Secure ACS サーバ証明書のインストール」を参照してください。


) EAP-TLS または PEAP ユーザ認証をサポートするため、またはリモート Cisco Secure ACS 管理の HTTPS 保護をサポートするために、すでに証明書をインストールしている場合は、この手順を実行する必要はありません。証明書ベースの Cisco Secure ACS サービスとリモート管理をすべてサポートする場合でもサーバ証明書は 1 つあれば十分です。ただし、EAP-TLS と PEAP では、サーバ認証用に適した証明書が必要です。


ステップ 2 エンドユーザ クライアント証明書を発行する認証局(CA)が信頼されるように、証明書信頼リストを編集します。この手順を実行しないと、Cisco Secure ACS は、Cisco Secure ACS 内にインストールされている証明書を発行した同一の CA が発行するユーザ証明書だけを信頼します。詳細な手順については、「証明書信頼リストの編集」を参照してください。

ステップ 3 証明書信頼リスト(CTL)に示されている各 CA および証明書タイプについて証明書失効リスト(CRL)を作成します。EAP-TLS 認証の一環として、Cisco Secure ACS は、キャッシュされた CRL に照らしてユーザによって示された証明書のステータスを検証し、それが無効になっていないことを確認します。詳細な手順については、「証明書失効リスト発行者の追加」を参照してください。

ステップ 4 Global Authentication Setup ページで EAP-TLS をイネーブルにします。Cisco Secure ACS では、この手順は、ステップ 1 が正常に完了している場合にだけ実行できます。詳細な手順については、「認証オプションの設定」を参照してください。

ステップ 5 ユーザ データベースを設定します。EAP-TLS 認証をサポートしているユーザ データベースを確認するには、「認証プロトコルとデータベースの互換性」を参照してください。

Cisco Secure ACS が、EAP-TLS 認証を実行できる状態になります。


 

PEAP 認証

この項では、次のトピックについて取り上げます。

「PEAP プロトコルについて」

「PEAP と Cisco Secure ACS」

「PEAP と未知ユーザ ポリシー」

「PEAP 認証のイネーブル化」

PEAP プロトコルについて

PEAP(Protected EAP)プロトコルは、EAP トランザクションを暗号化する手段を提供するクライアント サーバ型のセキュリティ アーキテクチャです。これによって、EAP 認証の内容が保護されます。PEAP は、RSA、シスコ、および Microsoft によって IETF インターネット ドラフトとして提出されたもので、内容は http://www.ietf.org/internet-drafts/draft-josefsson-pppext-eap-tls-eap-05.txt で参照できます。

PEAP 認証には常に 2 つのフェーズがあります。最初のフェーズでは、エンドユーザ クライアントが Cisco Secure ACS を認証します。ここでは、サーバ証明書が要求され、Cisco Secure ACS がエンドユーザ クライアントに対して認証されます。この結果、フェーズ 2 で送信されるユーザまたはマシンのクレデンシャルが、信頼できる CA によって発行された証明書を持つ AAA サーバに送信されます。最初のフェーズは、TLS ハンドシェイクを使用して SSL トンネルを確立します。


) 関係するエンドユーザ クライアントによっては、エンドユーザ クライアント コンピュータ上の信頼できるルート CA 用に、Cisco Secure ACS サーバ証明書を発行した CA の CA 証明書がローカル ストレージで必要になる場合もあります。


フェーズ 2 では、Cisco Secure ACS が EAP 認証プロトコルを使用して、ユーザまたはマシンのクレデンシャルを認証します。EAP 認証は、フェーズ 1 で作成された SSL トンネルによって保護されます。2 番目のカンバセーション中にネゴシエートされる認証タイプは、任意の有効な EAP タイプ、たとえば EAP-GTC(Generic Token Card の場合)になります。PEAP は任意の EAP 認証プロトコルをサポートできるため、PEAP(EAP-GTC) のように EAP プロトコルをカッコで囲んで、PEAP プロトコルと EAP プロトコルの組み合せを個々に示します。PEAP のフェーズ 2 で Cisco Secure ACS がサポートする認証プロトコルについては、「認証プロトコルとデータベースの互換性」を参照してください。

PEAP によりセキュリティが向上していますが、その 1 つに ID 保護があります。この ID 保護より、すべての PEAP トランザクションにおいてユーザ名を保護できます。PEAP のフェーズ 1 が完了すると、通常はクリア テキストで送信されるユーザ名情報も含めて、すべてのデータが暗号化されます。Cisco Aironet PEAP クライアントは、SSL トンネルだけを経由してユーザ ID を送信します。フェーズ 1 で使用される初期 ID(PEAP_ というプレフィックスの付いたエンドユーザ クライアントの MAC アドレス)は、クリア テキストで送信されます。Microsoft PEAP クライアントでは ID 保護は使用できません。Microsoft PEAP クライアントは、PEAP 認証のフェーズ 1 でユーザ名をクリア テキストで送信します。

PEAP と Cisco Secure ACS

Cisco Secure ACS は、Cisco Aironet PEAP クライアントまたは Microsoft PEAP クライアント(Microsoft Windows XP Service Pack 1 に付属)を使用した PEAP 認証をサポートしています。Cisco Secure ACS が Cisco Aironet PEAP クライアントをサポートできるのは、PEAP(EAP-GTC) を使用した場合のみです。Microsoft PEAP(Windows XP Service Pack 1 に付属)の場合、Cisco Secure ACS は PEAP(EAP-MSCHAPv2) だけをサポートします。PEAP プロトコルをサポートしているユーザ データベースについては、「認証プロトコルとデータベースの互換性」を参照してください。

エンドユーザ クライアントが Cisco Aironet PEAP クライアントの場合、Global Authentication Setup ページで PEAP(EAP-GTC) と PEAP(EAP-MSCHAPv2) の両方をイネーブルにすると、Cisco Secure ACS はエンドユーザ クライアントに対して、最初に PEAP(EAP-GTC) 認証を試みます。クライアントがこのプロトコルを拒否(EAP NAK メッセージを送信)した場合、Cisco Secure ACS は PEAP(EAP-MSCHAPv2) を使用して認証を試みます。PEAP 内でサポートされている EAP プロトコルのイネーブル化の詳細については、「グローバル認証のセットアップ」を参照してください。

Cisco Secure ACS は、PEAP(EAP-MSCHAPv2) を使用して、Microsoft Windows Active Directory に対するマシン認証をサポートすることができます。エンドユーザ クライアントは、ユーザ認証に使用するプロトコルを、マシン認証に使用するプロトコルと同じものに制限している場合があります。つまり、マシン認証に PEAP を使用する場合は、ユーザ認証にも PEAP を使用する必要がある場合があります。マシン認証の詳細については、「マシン認証」を参照してください。

Cisco Secure ACS は、PEAP 認証済みユーザ セッションに対して、セッション再開機能をサポートしています。この機能がイネーブルの場合、Cisco Secure ACS は、ユーザが PEAP 認証のフェーズ 2 で正常に認証された場合に限り、PEAP のフェーズ 1 で作成された TLS セッションをキャッシュします。ユーザが再接続しようとする場合、元の PEAP セッションがタイムアウトしていなければ、Cisco Secure ACS はキャッシュされた TLS セッションを使用します。このため、PEAP のパフォーマンスが向上し、AAA サーバの負荷が軽減されます。


) セッション タイムアウトは、認証が成功する時間に基づきます。アカウンティングには依存しません。


PEAP セッション再開機能のイネーブル化とタイムアウト間隔の設定は、Global Authentication Setup ページで行えます。この機能のイネーブル化の詳細については、「グローバル認証のセットアップ」を参照してください。

Cisco Secure ACS は、また、高速再接続機能をサポートしています。セッション再開機能がイネーブルの場合、高速再接続機能を使用すると、Cisco Secure ACS がユーザ クレデンシャルを確認せずに PEAP セッションを再開できるようになります。実際には、この機能がイネーブルの場合、Cisco Secure ACS は、元の PEAP 認証時にキャッシュされた TLS セッションに基づいてユーザを信頼するようになります。Cisco Secure ACS は PEAP 認証のフェーズ 2 が成功した場合に限って TLS セッションをキャッシュするため、キャッシュされた TLS セッションが存在しているということは、PEAP セッション タイムアウト オプションで定義された時間(分単位)内にユーザが正常に認証されたことの証明となります。

セッション再開機能を使用しても、外部ユーザ データベース内のグループ割り当ては変更されません。これは、セッション再開機能によってユーザ セッションが延長されるときには、グループ マッピングが発生しないためです。その代わり、ユーザは、セッションの開始時にマッピングされた Cisco Secure ACS グループにマッピングされます。新規のセッションが開始すると、グループ マッピングにより新規のグループ割り当てが実行されます。

高速再接続機能は、特に無線 LAN に対して有用です。無線 LAN では、ユーザがクライアント コンピュータを移動すると、別の無線アクセス ポイントが使用される場合があります。Cisco Secure ACS が PEAP セッションを再開する場合、セッションがタイムアウトしていない限り、ユーザはパスワードを入力しなくても再認証を受けることができます。エンドユーザ クライアントを再起動した場合は、セッション タイムアウト間隔に達していなくても、ユーザはパスワードを入力する必要があります。

PEAP 高速再接続機能のイネーブル化は、Global Authentication Setup ページで行うことができます。この機能のイネーブル化の詳細については、「グローバル認証のセットアップ」を参照してください。

PEAP と未知ユーザ ポリシー

PEAP 認証時、Cisco Secure ACS は、認証を受ける実際のユーザ名が、認証のフェーズ 2 になるまで未知である場合があります。Microsoft PEAP クライアントは、フェーズ 1 で実際のユーザ名を提示しますが、Cisco PEAP クライアントは提示しません。したがって、使用される PEAP クライアントに関係なく、Cisco Secure ACS は、フェーズ 1 で提示されるユーザ名の検索を試みません。さらに、未知ユーザ ポリシーの使用は、フェーズ 1 には依存しません。

PEAP 認証のフェーズ 2 に移行し、PEAP クライアントが提示するユーザ名が Cisco Secure ACS にとって未知のものであった場合、Cisco Secure ACS はユーザ名を処理します。その処理法は、他の認証プロトコルで提示されるユーザ名を処理する場合と同じです。ユーザ名が未知で、未知ユーザ ポリシーがディセーブルの場合、認証は失敗します。ユーザ名が未知で、未知ユーザ ポリシーがイネーブルの場合、Cisco Secure ACS は、未知ユーザ処理を行って PEAP ユーザの認証を試みます。

未知ユーザ処理の詳細については、「未知ユーザ認証について」を参照してください。

PEAP 認証のイネーブル化

ここでは、PEAP 認証をサポートするように Cisco Secure ACS を設定する詳細な手順の概要を示します。


) エンドユーザ クライアント コンピュータは、PEAP をサポートするように設定されている必要があります。ここでは、Cisco Secure ACS の設定だけを取り上げます。


PEAP 認証をイネーブルにするには、次の手順を実行します。


ステップ 1 Cisco Secure ACS にサーバ証明書をインストールします。PEAP ではサーバ証明書が必要です。詳細な手順については、「Cisco Secure ACS サーバ証明書のインストール」を参照してください。


) EAP-TLS または PEAP ユーザ認証をサポートするため、またはリモート Cisco Secure ACS 管理の HTTPS 保護をサポートするために、すでに証明書をインストールしている場合は、この手順を実行する必要はありません。証明書ベースの Cisco Secure ACS サービスとリモート管理をすべてサポートする場合でもサーバ証明書は 1 つあれば十分です。ただし、EAP-TLS と PEAP では、サーバ認証用に適した証明書が必要です。


ステップ 2 Global Authentication Setup ページで PEAP をイネーブルにします。Cisco Secure ACS では、この手順は、ステップ 1 が正常に完了している場合にだけ実行できます。詳細な手順については、「認証オプションの設定」を参照してください。

ステップ 3 ユーザ データベースを設定します。PEAP 認証をサポートしているユーザ データベースを確認するには、「認証プロトコルとデータベースの互換性」を参照してください。

Cisco Secure ACS が、ほとんどのユーザに対して PEAP 認証を実行できる状態になります。詳細については、「PEAP と未知ユーザ ポリシー」を参照してください。

ステップ 4 PEAP 認証を簡素化するため、未知ユーザ ポリシーをイネーブルにすることを検討します。詳細については、「PEAP と未知ユーザ ポリシー」を参照してください。詳細な手順については、「未知ユーザ ポリシーの設定」を参照してください。


 

EAP-FAST について

EAP Flexible Authentication via Secured Tunnel(EAP-FAST)プロトコルは、TLS トンネルで EAP トランザクションを暗号化するクライアント サーバ型のセキュリティ アーキテクチャです。その点では PEAP に似ていますが、EAP-FAST トンネルの設定は、各ユーザに固有の強力な秘密に基づいていることが大きな相違点です。これらの秘密は Protected Access Credentials(PAC)と呼ばれ、Cisco Secure ACS が、Cisco Secure ACS にしか知られていないマスター キーを使用して生成します。共有秘密に基づくハンドシェイクは PKI に基づくハンドシェイクよりもそもそも速いので、EAP-FAST は、暗号化 EAP トランザクションを提供する 2 つのソリューションの中で、かなり速い方になります。EAP-FAST の実装には証明書管理は必要ありません。

EAP-FAST は 3 つのフェーズで実行されます。

フェーズ 0 :フェーズ 0 は EAP-FAST に固有のフェーズであり、EAP-FAST エンドユーザ クライアントに、ネットワーク アクセスを要求するユーザ用の PAC を提供するトンネル セキュア機能です(「自動 PAC プロビジョニング」を参照してください)。エンドユーザ クライアントに PAC を提供することが、フェーズ 0 の唯一の目的です。トンネルは、匿名の Diffie-Hellman 鍵交換に基づいて確立されます。EAP-MSCHAPv2 認証が成功すると、Cisco Secure ACS はユーザに PAC を提供します。EAP-FAST フェーズ 0 をサポートしているデータベースを確認するには、「認証プロトコルとデータベースの互換性」を参照してください。


) フェーズ 0 はオプションであり、PAC は手動でエンドユーザ クライアントに提供できます(「手動 PAC プロビジョニング」を参照してください)。Cisco Secure ACS がフェーズ 0 をサポートするかどうかを制御するには、Global Authentication Configuration ページで Allow automatic PAC provisioning チェックボックスをオンにします。


EAP-FAST のフェーズ 0 によってイネーブルになるネットワーク サービスはありません。そのため、EAP-FAST フェーズ 0 トランザクションは、成功した場合でも、Cisco Secure ACS Failed Attempts ログに記録されます。

フェーズ 1 :フェーズ 1 では、Cisco Secure ACS とエンドユーザ クライアントが、エンドユーザ クライアントによって示された PAC に基づいて TLS トンネルを確立します。そのためには、ネットワーク アクセスの取得を試行するユーザ用の PAC がエンドユーザ クライアントに提供されていることと、期限の切れていないマスター キーに PAC が基づいていることが必要です。PAC プロビジョニングを実行する手段は関係ありません。自動プロビジョニングと手動プロビジョニングのどちらでも使用できます。

EAP-FAST のフェーズ 1 ではネットワーク サービスはイネーブルになりません。

フェーズ 2 :フェーズ 2 で、Cisco Secure ACS は、EAP-GTC でユーザ クレデンシャルを認証します。これは、フェーズ 1 で作成された TLS トンネルによって保護されています。その他の EAP タイプは EAP-FAST ではサポートされていません。EAP-FAST フェーズ 2 をサポートしているデータベースを確認するには、「認証プロトコルとデータベースの互換性」を参照してください。

Cisco Secure ACS は、EAP-FAST のフェーズ 2 の正常ユーザ認証でネットワーク サービスを許可し、イネーブルになっている場合は
Passed Authentications ログに認証を記録します。また、Cisco Secure ACS は必要に応じて、エンドユーザ クライアント PAC を更新します。この処理により、同じフェーズ 2 トランザクションの Passed Authentication ログに 2 番目のエントリが作成されます。

EAP-FAST は、すべての EAP-FAST トランザクションでユーザ名を保護できます。Cisco Secure ACS は、フェーズ 1 で示されたユーザ名に基づいてユーザ認証を実行しません。ただし、フェーズ 1 でユーザ名が保護されるかどうかは、エンドユーザ クライアントによって異なります。フェーズ 1 でエンドユーザ クライアントが実際のユーザ名を送信しなければ、ユーザ名は保護されます。Cisco Aironet EAP-FAST クライアントは、ユーザ名の代わりに FAST_ MAC address を送信することによって、フェーズ 1 のユーザ名を保護します。EAP-FAST のフェーズ 1 が完了すると、通常はクリア テキストで送信されるユーザ名情報も含めて、すべてのデータが暗号化されます。

Cisco Secure ACS は、Windows ユーザ データベースによって認証されたユーザに対して、EAP-FAST でのパスワード エージングをサポートしています。パスワード エージングは、EAP-FAST のフェーズ 0 またはフェーズ 2 で処理できます。フェーズ 0 中にパスワード エージングでユーザがパスワードを変更する必要がある場合は、新規パスワードがフェーズ 2 で有効になります。Windows ユーザ データベースのパスワード エージングの詳細については、「パスワード エージングを Windows データベースのユーザに対してイネーブルにする」を参照してください。

マスター キーについて

EAP-FAST マスター キーは、Cisco Secure ACS が自動的に生成し、Cisco Secure ACS だけが認識している強力な秘密です。マスター キーがエンドユーザ クライアントに送信されることはありません。EAP-FAST でマスター キーが必要な理由は 2 つあります。

PAC 生成 :Cisco Secure ACS は、アクティブ マスター キーを使用して PAC を生成します。PAC の詳細については、「PAC について」を参照してください。

EAP-FAST フェーズ 1 :Cisco Secure ACS は、エンドユーザ クライアントによって示された PAC が、認識しているマスター キーのいずれか(アクティブ マスター キーまたは非アクティブ マスター キー)によって生成されたかどうかを判別します。

EAP-FAST のセキュリティを強化するため、Cisco Secure ACS は PAC の生成に使用するマスター キーを変更します。Cisco Secure ACS は、定義された存続可能時間(TTL)値を使用して、新規マスター キーを生成するタイミングとすべてのマスター キーの経過時間を決定します。Cisco Secure ACS は、TTL 値に基づいて、マスター キーに次の 3 つの状態のいずれかを割り当てます。

アクティブアクティブ マスター キーは、Cisco Secure ACS が PAC を生成するために使用するマスター キーです。マスター キーがアクティブである期間は、マスター キー TTL 設定によって決まります。アクティブであるマスター キーは常に 1 つだけです。マスター キーと PAC の TTL を定義すると、Cisco Secure ACS は、アクティブ マスター キー TTL よりも短い PAC TTL だけを許可します。この制限により、マスター キーの期限が切れる前に EAP-FAST ユーザが少なくとも一度ネットワークにログインすれば、PAC の生成に使用されたマスター キーの期限が切れる前に少なくとも一度は PAC が更新されます。PAC の更新またはプロビジョニングが必要かどうかが TTL 値によってどのように決まるかについては、「マスター キーと PAC TTL」を参照してください。

複製された EAP-FAST ポリシーとマスター キーを受信するよう Cisco Secure ACS が設定されている場合は、バックアップ マスター キーも、受信されるマスター キーの中に含まれます。バックアップ マスター キーが使用されるのは、アクティブ マスター キーが次の正常なマスター キー複製の前に非アクティブになった場合です。次の正常なマスター キー複製の前にバックアップ マスター キーも非アクティブになった場合、EAP-FAST でネットワーク アクセスを要求するすべてのユーザに対して EAP-FAST 認証が失敗します。


ヒント アクティブ マスター キーとバックアップ マスター キーが非アクティブになり、複製された新規マスター キーを Cisco Secure ACS がまだ受信していないために EAP-FAST 認証が失敗した場合は、EAP-FAST Master Server チェックボックスをオンにして Submit をクリックすることによって、Cisco Secure ACS に独自のマスター キーを生成させることができます。


Cisco Secure ACS は、CSAuth サービス用のログにマスター キーの生成を記録します。

非アクティブ :マスター キーは、マスター キー TTL 設定よりも古くなると、非アクティブ マスター キー設定で指定された期間だけ非アクティブであると見なされます。Cisco Secure ACS は、非アクティブ マスター キーを最大 255 まで保存できます。非アクティブ マスター キーは新規 PAC の生成には使用されませんが、Cisco Secure ACS では、それを使用して生成された PAC を認証するために必要になります。マスター キーの TTL と非アクティブ マスター キーの TTL を定義するとき、Cisco Secure ACS は、255 以下の非アクティブ マスター キーの保存が必要な TTL 設定だけを許可します。たとえば、マスター キー TTL を 1 時間、非アクティブ マスター キー TTL を 4 週間にすると、最大 671 の非アクティブ マスター キーの保存が必要になるため、Cisco Secure ACS はエラー メッセージを表示し、この設定を許可しません。

非アクティブ マスター キーで生成された PAC を使用してユーザがネットワーク アクセスを取得すると、Cisco Secure ACS は、アクティブ マスター キーで生成された新規 PAC をエンドユーザ クライアントに提供します。マスター キーと PAC の状態に関する Cisco Secure ACS の詳細については、「マスター キーと PAC TTL」を参照してください。

期限切れ :マスター キーがマスター キー TTL と非アクティブ マスター TTL 設定の合計よりも古くなると、そのマスター キーは期限切れと見なされ、Cisco Secure ACS によってマスター キーのレコードから削除されます。たとえば、マスター キー TTL が 1 時間で非アクティブ マスター キー TTL が 1 週間である場合、マスター キーは、1 週間と 1 時間よりも古くなると期限切れになります。

期限切れのマスター キーで生成された PAC は、ネットワークへのアクセスには使用できません。EAP-FAST のフェーズ 1 を正常に実行するには、期限切れのマスター キーで生成された PAC を示しているエンドユーザ クライアントに対し、自動または手動のプロビジョニングを使用して新規 PAC を提供する必要があります。

PAC について

PAC は、Cisco Secure ACS および EAP-FAST エンドユーザ クライアントをイネーブルにし、互いを認証して EAP-FAST フェーズ 2 で使用する TLS トンネルを確立する強力な共有秘密です。Cisco Secure ACS は、アクティブ マスター キーとユーザ名を使用して PAC を生成します。EAP-FAST エンドユーザ クライアントは、クライアントを使用してネットワークにアクセスする各ユーザの PAC を保存します。さらに、EAP-FAST をサポートする AAA サーバには独自の認証局 ID があります。エンドユーザ クライアントは、ユーザの PAC を、それを生成した AAA サーバの認証局 ID と関連付けます。

EAP-FAST フェーズ 1 で、エンドユーザ クライアントは、現在のユーザ用、および EAP-FAST トランザクションの開始時に Cisco Secure ACS によって送信された認証局 ID 用に備えている PAC を示します。Cisco Secure ACS は、認識しているマスター キーのいずれか(アクティブまたは非アクティブ)で PAC が生成されたかどうかを判別します(期限切れになったマスター キーで生成された PAC は、ネットワークへのアクセスには使用できません)。期限切れのマスター キーで生成された PAC がエンドユーザ クライアントにある場合、EAP-FAST フェーズを正常に実行するには、エンドユーザ クライアントが新規 PAC を受信する必要があります。PAC プロビジョニングという、エンドユーザ クライアントに PAC を提供する手段については、「自動 PAC プロビジョニング」および 「手動 PAC プロビジョニング」を参照してください。

エンドユーザ クライアントに PAC が提供されると、Cisco Secure ACS は、マスター キーおよび PAC TTL 値で示されているとおりに、それらを更新します。Cisco Secure ACS は、EAP-FAST のフェーズ 2 の最後に、必要に応じて新規 PAC を生成して送信しますが、マスター キー TTL を短くすると、結果として PAC プロビジョニングが実行される場合があります。マスター キーと PAC の状態によって、フェーズ 2 の最後に Cisco Secure ACS が新規 PAC をエンドユーザ クライアントに送信するかどうかがどのように決まるかについては、「マスター キーと PAC TTL」を参照してください。

ユーザの PAC の生成に使用したマスター キーが期限切れになる前に、ユーザが EAP-FAST を使用してネットワークにアクセスしなかった場合は、マスター キー TTL 値の定義に関わらず、PAC プロビジョニングが必要になります。たとえば、マスター キー TTL が 1 週間で非アクティブ マスター キー TTL が 1 週間である場合は、2 週間の休暇に出かけるユーザが使用する各 EAP-FAST エンドユーザ クライアントに、PAC プロビジョニングが必要になります。

次のリストに、エンドユーザ クライアントが PAC を受信するさまざまな手段を示します。

PAC プロビジョニング :エンドユーザ クライアントに PAC がない場合や PAC が期限切れのマスター キーに基づいている場合に必要になります。マスター キーと PAC の状態によって PAC プロビジョニングが必要かどうかがどのように決まるかについては、「マスター キーと PAC TTL」を参照してください。

PAC プロビジョニングについては次の 2 つの手段がサポートされています。

自動プロビジョニング :セキュア ネットワーク接続を使用して PAC を送信します。詳細については、「自動 PAC プロビジョニング」を参照してください。

手動プロビジョニング :Cisco Secure ACS を使用してユーザ用の PAC ファイルを生成し、エンドユーザ クライアントを実行しているコンピュータに PAC ファイルをコピーし、エンドユーザ クライアントに PAC ファイルをインポートする必要があります。詳細については、「手動 PAC プロビジョニング」を参照してください。

PAC 更新 :EAP-FAST フェーズ 2 認証が成功し、マスター キーと PAC TTL によって PAC の更新が指示されている場合に、自動的に実行されます。マスター キーと PAC の状態によって PAC が更新されるかどうかがどのように決まるかについては、「マスター キーと PAC TTL」を参照してください。

PAC については、PAC TTL 設定によって次の 2 つの状態が決定されます。

アクティブ :PAC TTL よりも新しい PAC はアクティブと見なされ、それを生成するために使用されたマスター キーが期限切れになっていなければ、EAP-FAST フェーズ 1 の完了に使用できます。PAC が期限切れのマスター キーに基づいている場合に、EAP-FAST フェーズ 1 を正常に実行させるには、その PAC がアクティブであるかどうかに関わらず、PAC プロビジョニングが必要になります。

期限切れ :PAC TTL よりも古い PAC は期限切れと見なされます。PAC の生成に使用されたマスター キーが期限切れになっていなければ、期限切れの PAC を EAP-FAST フェーズ 1 の実行に使用できます。その場合は、EAP-FAST フェーズ 2 の終わりに Cisco Secure ACS がユーザ用の新規 PAC を生成し、それをエンドユーザ クライアントに提供します。

自動 PAC プロビジョニング

自動 PAC プロビジョニングは、セキュア ネットワーク接続を介して新規 PAC をエンドユーザ クライアントに送信します。Cisco Secure ACS とエンドユーザ クライアントの両方が自動プロビジョニングをサポートするよう設定されている場合、自動 PAC プロビジョニングにネットワーク ユーザまたは Cisco Secure ACS 管理者の介入は必要ありません。

EAP-FAST フェーズ 0 では、ユーザの EAP-MSCHAPv2 認証は必要ありません。ユーザ認証の成功に基づいて、Cisco Secure ACS はエンドユーザ クライアントとの Diffie-Hellman トンネルを確立します。Cisco Secure ACS は、ユーザ用の PAC を生成し、それをこのトンネル内でこの Cisco Secure ACS に関する認証局 ID および認証局 ID 情報とともにエンドユーザ クライアントに送信します。


) EAP-FAST フェーズ 0 とフェーズ 2 は異なる認証方法を使用するので(フェーズ 0 では EAP-MSCHAPv2、フェーズ 2 では EAP-GTC)、フェーズ 2 をサポートするデータベースの中には、フェーズ 0 をサポートしないものもあります。Cisco Secure ACS が各ユーザを単一ユーザ データベースと関連付ける場合、自動 PAC プロビジョニングを使用するには、EAP-FAST フェーズ 0 と互換性のあるデータベースで EAP-FAST ユーザが認証されている必要があります。Cisco Secure ACS が EAP-FAST フェーズ 0 とフェーズ 2 をサポートできるデータベースについては、「認証プロトコルとデータベースの互換性」を参照してください。


EAP-FAST フェーズ 0 ではネットワーク サービスはイネーブルにならないので、Cisco Secure ACS は EAP-FAST フェーズ 0 トランザクションを、PAC プロビジョニングが発生したというエントリとともに Failed Attempts ログに記録します。エンドユーザ クライアントは、正常なフェーズ 0 を介して PAC を受信した後、フェーズ 1 の開始を求める新規 EAP-FAST 要求を送信します。


) フェーズ 0 での PAC の送信は MS-CHAPv2 認証によって保護されており、MS-CHAPv2 はディクショナリ攻撃に弱いので、自動プロビジョニングの使用は EAP-FAST の最初の展開に限ることをお勧めします。大規模な EAP-FAST 配置後は、PAC に対する高度なセキュリティを確保するため、PAC プロビジョニングを手動で実行してください。手動 PAC プロビジョニングの詳細については、「手動 PAC プロビジョニング」を参照してください。


Cisco Secure ACS が自動 PAC プロビジョニングを実行するかどうかを制御するには、System Configuration セクションの Global Authentication Setup ページのオプションを使用します。詳細については、「認証設定オプション」を参照してください。

手動 PAC プロビジョニング

手動 PAC プロビジョニングでは、Cisco Secure ACS 管理者が PAC ファイルを生成し、それを該当するネットワーク ユーザに配布する必要があります。ユーザは PAC ファイルでエンドユーザ クライアントを設定する必要があります。たとえば、EAP-FAST エンドユーザ クライアントが Cisco Aironet Client Utility(ACU)である場合、EAP-FAST をサポートするように ACU を設定するには、PAC ファイルをインポートする必要があります。Cisco ACU の設定の詳細については、ご使用の ACU のコンフィギュレーション ガイドを参照してください。

EAP-FAST を使用してネットワークにアクセスするユーザを制御するには、手動 PAC プロビジョニングを使用します。自動 PAC プロビジョニングをディセーブルにすると、PAC を拒否された EAP-FAST ユーザはネットワークにアクセスできません。Cisco Secure ACS 展開に、各ネットワーク セグメントへのアクセスが個別の Cisco Secure ACS によって制御されるネットワーク セグメンテーションが含まれている場合は、手動 PAC プロビジョニングによってセグメントごとに EAP-FAST アクセスを許可することができます。たとえば、会社がシカゴとボストンのオフィスでのワイヤレス アクセス用に EAP-FAST を使用していて、これら 2 つのオフィスそれぞれの Cisco Aironet Access Point が別々の Cisco Secure ACS を使用するよう設定されている場合に、シカゴのオフィスを訪れたボストンの従業員がワイヤレス アクセスを使用できるかどうかを、従業員ごとに決定することができます。


) EAP-FAST マスター キーとポリシーを複製すると、Cisco Secure ACS ごとに異なる PAC を要求する機能に影響します。詳細については、表 10-2を参照してください。


手動 PAC プロビジョニングの管理オーバーヘッドは自動 PAC プロビジョニングよりもはるかに大きくなりますが、ネットワーク上で PAC を送信するリスクはなくなります。EAP-FAST を初めて展開する場合に手動 PAC プロビジョニングを使用すると、エンドユーザ クライアントで多数の手動設定が必要になりますが、これは PAC を展開する最も安全な方法です。大規模な EAP-FAST 配置後は、PAC に対する高度なセキュリティを確保するため、PAC プロビジョニングを手動で実行することをお勧めします。

特定のユーザ名、ユーザ グループ、ユーザ名リスト、またはすべてのユーザに対して PAC ファイルを生成できます。ユーザ グループまたはすべてのユーザに対して PAC ファイルを生成する場合、ユーザは未知ユーザではなく、既知ユーザまたは検出ユーザである必要があります。Cisco Secure ACS for Windows Server は、CSUtil.exe での PAC ファイルの生成をサポートしています。CSUtil.exe での PAC ファイルの生成の詳細については、「PAC ファイルの生成」を参照してください。

マスター キーと PAC TTL

マスター キーと PAC の TTL 値の状態がどのように決まるかについては、「マスター キーについて」および 「PAC について」を参照してください。マスター キーと PAC の状態によって、EAP-FAST でのネットワーク アクセスを要求するユーザに PAC プロビジョニングまたは PAC 更新が必要かどうかが決まります。 表 10-1 に、PAC とマスター キーの状態に関する Cisco Secure ACS の動作をまとめてあります。

 

表 10-1 マスター キーと PAC の状態

マスター キーの状態
PAC がアクティブ
PAC が期限切れ

マスター キーが
アクティブ

フェーズ 1 が成功します。

フェーズ 2 の最後に PAC は更新されません。

フェーズ 1 が成功します。

フェーズ 2 の最後に PAC は更新されます。

マスター キーが
非アクティブ

フェーズ 1 が成功します。

フェーズ 2 の最後に PAC は更新されます。

フェーズ 1 が成功します。

フェーズ 2 の最後に PAC は更新されます。

マスター キーが
期限切れ

PAC プロビジョニングが必要です。

自動プロビジョニングがイネーブルになっている場合は、フェーズ 0 が実行され、新規 PAC が送信されます。エンドユーザ クライアントは、新規 PAC を使用して新規 EAP-FAST 認証要求を開始します。

自動プロビジョニングがディセーブルになっている場合、フェーズ 0 は実行されず、フェーズ 1 は失敗します。手動プロビジョニングを使用してユーザに新規 PAC を提供する必要があります。

PAC プロビジョニングが必要です。

自動プロビジョニングがイネーブルになっている場合は、フェーズ 0 が実行され、新規 PAC が送信されます。エンドユーザ クライアントは、新規 PAC を使用して新規 EAP-FAST 認証要求を開始します。

自動プロビジョニングがディセーブルになっている場合、フェーズ 0 は実行されず、フェーズ 1 は失敗します。手動プロビジョニングを使用してユーザに新規 PAC を提供する必要があります。

複製と EAP-FAST

CiscoSecure Database Replication 機能は、EAP-FAST 設定、認証局 ID、およびマスター キーの複製をサポートしています。EAP-FAST データの複製が実行されるのは、次の場合だけです。

プライマリ Cisco Secure ACS の Database Replication Setup ページの Send で、EAP-FAST master keys and policies チェックボックスをオンにした場合

プライマリ Cisco Secure ACS の Global Authentication Setup ページで、EAP-FAST をイネーブルにし、EAP-FAST master server チェックボックスをオンにした場合

セカンダリ Cisco Secure ACS の Database Replication Setup ページの Receive で、EAP-FAST master keys and policies チェックボックスをオンにした場合

セカンダリ Cisco Secure ACS の Global Authentication Setup ページで、EAP-FAST をイネーブルにし、EAP-FAST master server チェックボックスをオフにした場合

EAP-FAST 関連の複製は、次の 3 つのイベントに対して実行されます。

マスター キーの生成 :プライマリ Cisco Secure ACS は、新しく生成されたアクティブ マスター キーとバックアップ マスター キーをセカンダリ Cisco Secure ACS に送信します。複製が適切に設定されていて、Database Replication Setup ページの複製スケジューリングの影響を受けない場合、これはマスター キーの生成後にすぐに実行されます。

手動複製 :プライマリ Cisco Secure ACS の Database Replication Setup ページで Replicate Now をクリックすると、複製可能なすべての EAP-FAST コンポーネントが複製されます。複製されたコンポーネントの一部は、HTML インターフェイスで設定できます。EAP-FAST コンポーネントが複製されるかどうかと設定可能かどうかについては、 表 10-2 を参照してください。


) EAP-FAST 複製は、スケジューリングされた複製イベントには含まれません。


EAP-FAST 設定に対する変更 :プライマリ Cisco Secure ACS で複製された設定可能 EAP-FAST コンポーネントを変更すると、Cisco Secure ACS は EAP-FAST 複製を開始します。EAP-FAST コンポーネントが複製されるかどうかと設定可能かどうかについては、 表 10-2 を参照してください。

プライマリ Cisco Secure ACS の Database Replication ログには、マスター キーの複製が記録されます。マスター キー複製に関連するエントリには、「MKEYReplicate」というテキストが含まれています。

 

表 10-2 EAP-FAST コンポーネントと複製

EAP-FAST コンポーネント
複製の有無
設定の可否

EAP-FAST がイネーブル

No

はい、Global Authentication Setup ページでできます。

マスター キー TTL

Yes

はい、Global Authentication Setup ページでできます。

非アクティブ マスター キー TTL

Yes

はい、Global Authentication Setup ページでできます。

PAC TTL

Yes

はい、Global Authentication Setup ページでできます。

認証局 ID

Yes

いいえ、Cisco Secure ACS によって生成されます。

認証局 ID 情報

Yes

はい、Global Authentication Setup ページでできます。

クライアント初期メッセージ

Yes

はい、Global Authentication Setup ページでできます。

マスター キー

Yes

いいえ、TTL 設定で指示された場合に Cisco Secure ACS によって生成されます。

EAP-FAST マスター サーバ

No

はい、Global Authentication Setup ページでできます。

実際の EAP-FAST サーバの状態

No

いいえ、Cisco Secure ACS によって決定されます。

EAP-FAST マスター サーバは、次に示すように、EAP-FAST の認証と複製に大きな影響を与えます。

イネーブル :EAP-FAST master server チェックボックスがオンになっている場合、「Actual EAP-FAST server status」は Master であり、Cisco Secure ACS は、複製中にプライマリ Cisco Secure ACS から受信した EAP-FAST 設定、認証局 ID、およびマスター キーを無視して、生成したマスター キー、その固有の認証局 ID、および HTML インターフェイスで設定された EAP-FAST 設定を使用します。

EAP-FAST マスター サーバ設定をイネーブルにするには、エンドユーザ クライアントに、セカンダリ Cisco Secure ACS の PAC とは異なるプライマリ Cisco Secure ACS の PAC を提供する必要があります。プライマリ Cisco Secure ACS とセカンダリ Cisco Secure ACS は EAP-FAST トランザクションの開始時に異なる認証局 ID を送信するので、エンドユーザ クライアントは、各認証局 ID 用の PAC を持っている必要があります。プライマリ Cisco Secure ACS によって生成された PAC は、セカンダリ Cisco Secure ACS で EAP-FAST マスター サーバ設定がイネーブルになっている複製スキームでは、セカンダリ Cisco Secure ACS によって受け入れられません。


ヒント 複製された Cisco Secure ACS 環境では、EAP-FAST マスター サーバ機能を使用し、それと同時に自動 PAC プロビジョニングを拒否することにより、ネットワーク内の異なるセグメントへの EAP-FAST アクセスを制御します。自動 PAC プロビジョニングを使用しない場合、ユーザは各ネットワーク セグメントの PAC を要求する必要があります。


ディセーブル :EAP-FAST master server チェックボックスがオフになっている場合、Cisco Secure ACS は、プライマリ Cisco Secure ACS から最初の複製 EAP-FAST コンポーネントを受信するまで、AP-FAST マスター サーバとして動作を続けます。「Actual EAP-FAST server status」に Slave というテキストが表示されている場合、Cisco Secure ACS は、生成したマスター キーとその固有の認証局 ID ではなく、複製中にプライマリ Cisco Secure ACS から受信した EAP-FAST 設定、認証局 ID、およびマスター キーを使用します。


) EAP-FAST master server チェックボックスをオフにした場合、「Actual EAP-FAST server status」は、Cisco Secure ACS が複製 EAP-FAST コンポーネントを受信し、「Actual EAP-FAST server status」が Slave に変わるまで、Master のままです。「Actual EAP-FAST server status」が Slave に変わるまで、Cisco Secure ACS はマスター EAP-FAST サーバとして動作し、生成したマスター キー、その固有の認証局 ID、および HTML インターフェイスで設定された EAP-FAST 設定を使用します。


EAP-FAST マスター サーバ設定をディセーブルにすると、プライマリ Cisco Secure ACS とセカンダリ Cisco Secure ACS から異なる PAC を提供する必要がなくなります。これは、プライマリ Cisco Secure ACS とセカンダリ Cisco Secure ACS が EAP-FAST トランザクションの開始時にエンドユーザ クライアントへ同じ認証局 ID を送信するためです。したがって、エンドユーザ クライアントは、いずれの Cisco Secure ACS に対する応答でも、同じ PAC を使用します。また、EAP-FAST マスター サーバ設定がディセーブルになっている複製スキームで 1 つの Cisco Secure ACS によってユーザ用に生成された PAC は、同じ複製スキーム内の他のすべての Cisco Secure ACS に受け入れられます。

複製の詳細については、「CiscoSecure データベース複製」を参照してください。

EAP-FAST のイネーブル化

ここでは、EAP-FAST 認証をサポートするように Cisco Secure ACS を設定する詳細な手順の概要を示します。


) エンドユーザ クライアントは、EAP-FAST をサポートするように設定されている必要があります。ここでは、Cisco Secure ACS の設定だけを取り上げます。


始める前に

この手順のステップの順番は、一例に過ぎません。ご使用のサイトで EAP-FAST をイネーブルにするときは、これらのステップを繰り返したり順番を変えたりして実行しなければならない場合があります。たとえば、この手順では、PAC プロビジョニングをどのようにサポートするかの決定は、EAP-FAST をサポートするようユーザ データベースを設定した後になっています。しかし、自動 PAC プロビジョニングを選択すると、ユーザ データベース サポートの制限が変わります。

Cisco Secure ACS で EAP-FAST 認証を実行できるようにするには、次の手順を実行します。


ステップ 1 EAP-FAST 認証をサポートするようにユーザ データベースを設定します。EAP-FAST 認証をサポートしているユーザ データベースを確認するには、「認証プロトコルとデータベースの互換性」を参照してください。ユーザ データベース設定については、 第13章「ユーザ データベース」 を参照してください。


) EAP-FAST フェーズ 0 とフェーズ 2 に対するユーザ データベース サポートは異なります。


Cisco Secure ACS は、Unknown User Policy の使用と EAP-FAST でのグループ マッピングをサポートしています。また、Windows 外部ユーザ データベースでのパスワード エージングもサポートしています。

ステップ 2 マスター キーと PAC TTL 値を決定します。キーと PAC を頻繁に変更すると、安全性が増すと考えることもできますが、同時に、オフラインになっているマシンで PAC の基になっているマスター キーが期限切れになり、PAC プロビジョニングが必要になる可能性も増します。

また、最初の EAP-FAST の展開で使用した TTL 値を少なくすると、ユーザが期限切れのマスター キーに基づく PAC を持つ可能性が高くなるので、PAC プロビジョニングが実行されやすくなります。

マスター キーと PAC TTL 値によって PAC プロビジョニングまたは PAC 更新が必要かどうかがどのように決まるかについては、「マスター キーと PAC TTL」を参照してください。

ステップ 3 自動 PAC プロビジョニングと手動 PAC プロビジョニングのどちらを使用するかを決めます。PAC プロビジョニングの 2 つの手段については、「自動 PAC プロビジョニング」および 「手動 PAC プロビジョニング」を参照してください。


) 自動 PAC プロビジョニングの使用は EAP-FAST の最初の展開に限定し、その後、少数の新規エンドユーザ クライアントをネットワークに追加する場合や期限切れのマスター キーに基づく PAC を置換する場合は手動 PAC プロビジョニングを使用することをお勧めします。


ステップ 4 ステップ 2およびステップ 3での決定を使用して、Global Authentication Setup ページで EAP-FAST をイネーブルにします。詳細な手順については、「認証オプションの設定」を参照してください。

Cisco Secure ACS が、EAP-FAST 認証を実行できる状態になります。


 

グローバル認証のセットアップ

Global Authentication Setup ページには、Cisco Secure ACS でサポートされている認証プロセスの一部をイネーブルまたはディセーブルにする機能が用意されています。また、Global Authentication Setup ページに表示されるプロトコルの一部について、オプションを設定することができます。

この項では、次のトピックについて取り上げます。

「認証設定オプション」

「認証オプションの設定」

認証設定オプション

Global Authentication Setup ページには、次の設定オプションがあります。

PEAPPEAP に関する次のオプションを設定できます。

Allow EAP-MSCHAPv2 :Cisco Secure ACS が PEAP クライアントに対して EAP-MSCHAPv2 認証を試みるかどうかを指定する。


) Allow EAP-MSCHAPv2 チェックボックスと Allow EAP-MSCHAPv2 チェックボックスの両方がオンの場合、Cisco Secure ACS は、EAP タイプについてエンドユーザ PEAP クライアントとネゴシエートします。


Allow EAP-GTC :Cisco Secure ACS が PEAP クライアントに対して EAP-GTC 認証を試みるかどうかを指定する。

Cisco client initial message :PEAP 認証中に表示させるメッセージ。PEAP クライアントの初期表示メッセージは、Cisco Aironet PEAP クライアントのユーザが認証を受けようとしたときに、最初に目にする指示メッセージです。このメッセージでは、ユーザが次に行う作業を指示する必要があります。たとえば、「Enter your passcode.」と指定します。メッセージは最大 60 文字です。

PEAP session timeout (minutes) :ユーザに許可する PEAP セッションの最大長(分単位)。セッション タイムアウト値を 0(ゼロ)より大きくすれば、PEAP セッション再開機能がイネーブルになります。この機能は、PEAP 認証のフェーズ 1 で作成される TLS セッションをキャッシュします。PEAP クライアントが再接続すると、Cisco Secure ACS はキャッシュされた TLS セッションを使用して、セッションを復元します。この結果、PEAP パフォーマンスが向上します。Cisco Secure ACS は、キャッシュされた TLS セッションがタイムアウトになると、セッションを削除します。デフォルトのタイムアウト値は 120 分です。セッション再開機能をディセーブルにするには、タイムアウト値を 0(ゼロ)に設定します。

Enable Fast Reconnect :Cisco Secure ACS が PEAP 認証のフェーズ 2 を実行せずに PEAP クライアントに対してセッションを再開するかどうかを指定する。Enable Fast Reconnect チェックボックスをオフにすると、Cisco Secure ACS は、常に PEAP 認証のフェーズ 2 を実行するようになります。これは、PEAP セッションがタイムアウトしていない場合にも該当します。

高速再接続が実行されるのは、セッションがタイムアウトしていないことを受けて、Cisco Secure ACS がセッションを再開できるようにした場合のみです。PEAP session timeout (minutes) ボックスに 0(ゼロ)を入力して PEAP セッション再開機能をディセーブルにした場合、Enable Fast Reconnect チェックボックスをオンにしても、PEAP 認証には影響しません。したがって、PEAP 認証のフェーズ 2 は常に実行されます。

EAP-FASTEAP-FAST に関する次のオプションを設定できます。

Allow EAP-FAST :Cisco Secure ACS が EAP-FAST 認証を許可するかどうかを指定する。


) Network Configuration セクションで RADIUS(Cisco Aironet)デバイスとして定義された AAA クライアントを使用してユーザがネットワークにアクセスする場合は、Global Authentication Setup ページで、LEAP、EAP-TLS、または EAP-FAST プロトコルのうち 1 つまたは複数をイネーブルにする必要があります。これ以外の場合、Cisco Aironet ユーザは認証を受けることができません。


Master Key TTL :マスター キーが新規 PAC の生成に使用される期間。マスター キーがマスター キー TTL より古くなると、Cisco Secure ACS はマスター キーを非アクティブにし、新規マスター キーを生成します。デフォルトのマスター キー TTL は 1 ヶ月です。


) マスター キーは、マスター キー TTL と非アクティブ マスター キー TTL の合計よりも古くなると期限切れになるので、マスター キー TTL を少なくすると、非アクティブ マスター キーが期限切れになりやすくなります。そのため、マスター キー TTL を少なくすると、新しく期限切れになったマスター キーに基づく PAC を持つエンドユーザ クライアントに対して PAC プロビジョニングが必要になります。


マスター キーの詳細については、「マスター キーについて」を参照してください。

非アクティブ マスター キー TTL :非アクティブ マスター キーを使用して生成された PAC が EAP-FAST 認証で受け入れられる期間。つまり、非アクティブ マスター キー TTL は、アクティブではなくなったマスター キーを使用して生成された PAC が受け入れられる猶予期間を定義します。エンドユーザ クライアントが非アクティブ マスター キーに基づく PAC を使用してネットワークにアクセスすると、Cisco Secure ACS は新規 PAC をエンドユーザ クライアントに送信します。デフォルトの非アクティブ マスター キー TTL は 3 ヶ月です。

非アクティブ マスター キーは、非アクティブ マスター キー TTL よりも古くなると期限切れになり、Cisco Secure ACS によって削除されます。


) 非アクティブ マスター キー TTL を減らすと、非アクティブ マスター キーが期限切れになりやすくなります。そのため、新たに期限切れになったマスター キーに基づく PAC を持つエンドユーザ クライアントは、PAC プロビジョニングが必要になります。



) 非アクティブ マスター キー TTL を減らすと、非アクティブ マスター キーが期限切れになる場合があります。そのため、非アクティブ マスター キー TTL を減らすと、新たに期限切れになったマスター キーに基づく PAC を持つエンドユーザ クライアントは、PAC プロビジョニングが必要になります。


マスター キーの詳細については、「マスター キーについて」を参照してください。

PAC TTL :PAC が期限切れになり置換する必要が生じるまでの PAC の使用期間。PAC の生成に使用されたマスター キーが期限切れになっていなければ、新規 PAC の作成と割り当ては自動的に行われます。PAC の生成に使用されたマスター キーが期限切れになっている場合は、インバンドまたはアウトバンドのプロビジョニングを使用してエンドユーザ クライアントに新規 PAC を提供する必要があります。デフォルトの PAC TTL は 1 週間です。

PAC の詳細については、「PAC について」を参照してください。

Client initial display message :EAP-FAST クライアントで認証されたユーザに送信するメッセージを指定する。最大長は 40 文字です。


) ユーザに初期表示メッセージが示されるのは、エンドユーザ クライアントがその表示をサポートしている場合だけです。


Authority ID Info :この Cisco Secure ACS に関する短い説明であり、Cisco Secure ACS によって発行された PAC とともに送信される。EAP-FAST エンドユーザ クライアントはこれを使用して、PAC を発行した AAA サーバを記述します。最大長は 64 文字です。


) 認証局 ID 情報は、認証局 ID とは異なります。認証局 ID は Cisco Secure ACS によって自動的に生成され、設定はできません。認証局 ID は、エンドユーザ クライアントがどの PAC を Cisco Secure ACS へ送信するかを決定するために使用されますが、認証局 ID 情報は、厳密には、認証局 ID に関連する読みやすいラベルです。


Allow automatic PAC provisioning :Cisco Secure ACS が、EAP-FAST フェーズ 0 を使用してエンドユーザ クライアントに PAC をプロビジョニングするかどうか。このチェックボックスをオンにすると、Cisco Secure ACS は、新規 PAC を提供するために、エンドユーザ クライアントとの安全な接続を確立します。チェックボックスがオフになっている場合、Cisco Secure ACS はユーザ アクセスを拒否します。その場合、PAC プロビジョニングはアウトバンドで(手動で)実行する必要があります。

EAP-FAST Master Server :このチェックボックスがオフである場合に、複製された EAP-FAST ポリシー、認証局 ID、およびマスター キーを受信すると、Cisco Secure ACS は独自の EAP-FAST ポリシー、認証局 ID、およびマスター キーではなく、それらを使用する。

このチェックボックスがオンである場合、Cisco Secure ACS は独自の EAP-FAST ポリシー、認証局 ID、およびマスター キーを使用します。詳細については、 表 10-2 を参照してください。


) EAP-FAST マスター サーバ設定を変更する場合は、Submit + Restart をクリックします。


Actual EAP-FAST server status :この読み取り専用オプションは、
EAP-FAST に関する Cisco Secure ACS の状態を表示する。このオプションで「Master」と表示されている場合、Cisco Secure ACS は独自のマスター キーと認証局 ID を生成します。このオプションで「Slave」と表示されている場合、Cisco Secure ACS は複製中に受信したマスター キーと認証局 ID を使用します。詳細については、 表 10-2 を参照してください。


ヒント EAP-FAST Master Server チェックボックスをオフにした場合、EAP-FAST サーバの状態は、Cisco Secure ACS が複製 EAP-FAST コンポーネントを受信するまで「Master」のままになります。


EAP-TLSEAP-TLS に関する次のオプションを設定できます。

Allow EAP-TLS :Cisco Secure ACS が EAP-TLS 認証を許可するかどうかを指定する。


) Network Configuration セクションで RADIUS(Cisco Aironet)デバイスとして定義された AAA クライアントを使用してユーザがネットワークにアクセスする場合は、Global Authentication Setup ページで、LEAP、EAP-TLS、または EAP-FAST プロトコルのうち 1 つまたは複数をイネーブルにする必要があります。これ以外の場合、Cisco Aironet ユーザは認証を受けることができません。


Certificate SAN comparison :認証を実行するときに、エンドユーザ クライアント証明書の Subject Alternative Name(SAN)を、該当するユーザ データベース内のユーザ名と比較するかどうかを指定する。


) 複数の比較タイプを選択した場合、Cisco Secure ACS はリスト内の順序で比較を実行します。1 つの比較タイプが失敗すると、Cisco Secure ACS はイネーブルになっている次の比較タイプを試みます。試みが 1 つでも成功すると、比較は停止します。


Certificate CN comparison :認証を実行するときに、エンドユーザ クライアント証明書の Common Name を、該当するユーザ データベース内のユーザ名と比較するかどうかを指定する。

Certificate Binary comparison :認証を実行するときに、エンドユーザ クライアント証明書を、該当するユーザ データベースに格納されているユーザ証明書とバイナリ比較するかどうかを指定する。ODBC 外部ユーザ データベースに格納されているユーザの認証に、この比較方法を使用することはできません。

EAP-TLS session timeout (minutes) :ユーザに許可する EAP-TLS セッションの最大長(分単位)。セッション タイムアウト値を 0(ゼロ)より大きくすれば、EAP-TLS セッション再開機能がイネーブルになります。セッション再開機能を利用すると、セッションがタイムアウトしていない限り、ユーザはユーザ検索や証明書比較を経なくても、再認証を受けることができます。エンドユーザ クライアントを再起動した場合は、セッション タイムアウト間隔に達していなくても、認証時に証明書の検索が必要になります。デフォルトのタイムアウト値は 120 分です。セッション タイムアウト機能をディセーブルにするには、タイムアウト値を 0(ゼロ)に設定します。

LEAP :Allow LEAP (For Aironet only) チェックボックスにより、Cisco Secure ACS が LEAP 認証を実行するかどうかが制御されます。LEAP は、現時点では、Cisco Aironet ワイヤレス ネットワーキングに対してのみ使用されます。このオプションをディセーブルにすると、LEAP 認証を実行するように設定された Cisco Aironet エンドユーザ クライアントは、ネットワークにアクセスできなくなります。Cisco Aironet エンドユーザ クライアントすべてが EAP-TLS などの異なる認証プロトコルを使用する場合は、このオプションをディセーブルにすることを推奨します。


) Network Configuration セクションで RADIUS(Cisco Aironet)デバイスとして定義された AAA クライアントを使用してユーザがネットワークにアクセスする場合は、Global Authentication Setup ページで、LEAP、EAP-TLS、またはその両方をイネーブルにする必要があります。これ以外の場合、Cisco Aironet ユーザは認証を受けることができません。


EAP-MD5 :Allow EAP-MD5 チェックボックスにより、Cisco Secure ACS が EAP-MD5 認証を実行するかどうかが制御されます。このオプションをディセーブルにすると、EAP-MD5 認証を実行するように設定されたエンドユーザ クライアントは、ネットワークにアクセスできなくなります。EAP-MD5 を使用するエンドユーザ クライアントが存在しない場合は、このオプションをディセーブルにすることを推奨します。

AP EAP request timeout (seconds) :Cisco Secure ACS は、指定されたタイムアウト値を EAP カンバセーション中に使用するよう Cisco Aironet Access Points(AP)に指示します。指定された値の秒数が経過した後に、Cisco Aironet AP は、Cisco Secure ACS での EAP トランザクションが失われたため再開する必要があると想定します。値に 0(ゼロ)を指定すると、この機能がディセーブルになります。

EAP カンバセーション中、Cisco Secure ACS は IETF RADIUS Session-Timeout (27) アトリビュートを使用して AP EAP request timeout ボックスで定義された値を送信しますが、カンバセーションの終わりの RADIUS Access-Accept パケットで、Cisco Secure ACS が IETF RADIUS Session-Timeout (27) アトリビュートで送信する値は、Cisco Aironet RADIUS VSA Cisco-Aironet-Session- Timeout (01) で指定された値か、またはそのアトリビュートがイネーブルになっていない場合は IETF RADIUS Session-Timeout (27) アトリビュートで指定された値です。


) Cisco Aironet RADIUS VSA Cisco-Aironet-Session-Timeout (01) は真の RADIUS VSA ではありません。これは、RADIUS 要求を送信する AAA クライアントが Network Configuration で RADIUS(Cisco Aironet)によって認証されたとして定義されている場合に、Cisco Secure ACS が IETF RADIUS Session-Timeout アトリビュートで送信する値を示します。


MS-CHAP Configuration :Allow MS-CHAP Version 1 Authentication チェックボックスと Allow MS-CHAP Version 2 Authentication チェックボックスにより、Cisco Secure ACS が RADIUS 要求に対して MS-CHAP 認証を実行するかどうかが制御されます。2 つのチェックボックスでは、また、RADIUS 要求に対して許可する MS-CHAP のバージョンも制御できます。特定バージョンの MS-CHAP をディセーブルにすると、RADIUS を使用してそのバージョンの認証を実行するように設定されたエンドユーザ クライアントは、ネットワークにアクセスできなくなります。RADIUS に対して特定バージョンの MS-CHAP を使用するように設定されたエンドユーザ クライアントが存在しない場合は、そのバージョンの MS-CHAP をディセーブルにすることを推奨します。


) TACACS+ の場合、Cisco Secure ACS は MS-CHAP バージョン 1 だけをサポートします。MS-CHAP バージョン 1 に対する TACACS+ サポートは常にイネーブルであり、設定はできません。


認証オプションの設定

この手順では、Cisco Secure ACS が認証オプションを処理する方法を選択および設定します。特に、この手順を使用して、許可する各種の EAP を指定および設定し、MS-CHAP バージョン 1 と MS-CHAP バージョン 2 の一方または両方を許可するかどうかを指定できます。

EAP-TLS プロトコルの詳細については、「EAP-TLS 認証」を参照してください。PEAP プロトコルの詳細については、「PEAP 認証」を参照してください。PEAP プロトコルの詳細については、「EAP-FAST 認証」を参照してください。各種のパスワード プロトコルをデータベースがサポートしている状況は、「認証プロトコルとデータベースの互換性」を参照してください。

始める前に

Global Authentication Setup ページのオプションについては、「認証設定オプション」を参照してください。

認証オプションを設定するには、次の手順を実行します。


ステップ 1 ナビゲーション バーの System Configuration をクリックします。

ステップ 2 Global Authentication Setup をクリックします。

Cisco Secure ACS が Global Authentication Setup ページを表示します。

ステップ 3 必要に応じて、オプションを設定します。オプションの意味の詳細については、「認証設定オプション」を参照してください。

ステップ 4 設定した設定値をすぐに実装する場合は、 Submit + Restart をクリックします。

Cisco Secure ACS はサービスを再開して、選択した認証設定オプションを実装します。

ステップ 5 設定した設定値を保存して、後で実装する場合は、 Submit をクリックします。


ヒント System Configuration セクションの Service Control ページを使用すれば、いつでも Cisco Secure ACS サービスを再起動できます。

Cisco Secure ACS が、選択された認証設定オプションを保存します。


 

Cisco Secure ACS 証明書のセットアップ

この項では、次のトピックについて取り上げます。

「Cisco Secure ACS サーバ証明書のインストール」

「認証局証明書の追加」

「証明書信頼リストの編集」

「証明書失効リストの管理」

「証明書署名要求の生成」

「自己署名証明書の使用」

「Cisco Secure ACS 証明書のアップデートまたは置き換え」

Cisco Secure ACS サーバ証明書のインストール

Cisco Secure ACS 用のサーバ証明書をインストール(登録)するには、次の手順を実行します。証明書登録を実行すると、GUI で Cisco Secure ACS にアクセスするための HTTPS プロトコルのサポートに加えて、EAP-TLS 認証と PEAP 認証をサポートできます。サーバ証明書の取得方法には、次の 3 つの基本オプションがあります。

CA から証明書を取得する。

ローカル マシンのストレージから既存の証明書を使用する。

自己署名証明書を生成する。

始める前に

Cisco Secure ACS のサーバ証明書がないとインストールできません。Cisco Secure ACS では、証明書ファイルが Base64-encoded X.509 に準拠している必要があります。サーバ証明書をまだ格納していない場合は、「証明書署名要求の生成」の手順またはその他の手段を利用して、インストールする証明書を入手してください。

既存のサーバ証明書を置換するサーバ証明書をインストールすると、Cisco Secure ACS の CTL 設定と CRL 設定に影響する可能性があります。代わりの証明書のインストール後、CTL 設定や CRL 設定を再設定する必要があるかどうかを判断する必要があります。

ローカル マシンのストレージにあるサーバ証明書を使用する場合は、『 Extensible Authentication Protocol Transport Layer Security Deployment Guide for Wireless LAN Networks 』を一読することを推奨します。このドキュメントは、Cisco Secure ACS CD と http://www.cisco.com/warp/public/cc/pd/sqsw/sq/tech/index.shtml で入手できます。このホワイト ペーパーは、証明書をマシンのストレージに追加する方法、および Microsoft 認証局サーバを Cisco Secure ACS とともに利用するために設定する方法について説明しています。

既存の証明書を Cisco Secure ACS で使用するようにインストールするには、次の手順を実行します。


ステップ 1 ナビゲーション バーの System Configuration をクリックします。

ステップ 2 ACS Certificate Setup をクリックします。

ステップ 3 Install ACS Certificate をクリックします。

Cisco Secure ACS が Install ACS Certificate ページを表示します。

ステップ 4 Cisco Secure ACS に対して、証明書を指定されたファイルから読み取るか、またはローカル マシンにすでに保存されている証明書を使用するかを指定する必要があります。次のいずれか 1 つを実行します。

指定されたファイルから Cisco Secure ACS が証明書を読み取るように指定するには、 Read certificate from file オプションを選択し、証明書ファイルのフル ディレクトリ パスとファイル名を Certificate file ボックスに入力します。

ローカル マシンの証明書ストレージに保存されている特定の既存証明書を Cisco Secure ACS が使用するように指定するには、 Use certificate from storage オプションを選択し、証明書 CN(共通名/対象者名)を Certificate CN ボックスに入力します。


ヒント 証明書 CN だけを入力します。cn= プレフィックスは省略してください。

ステップ 5 Cisco Secure ACS を使用して要求を生成した場合は、プライベート キーを含むファイルのフル ディレクトリ パスと名前を Private key file ボックスに入力します。


) 証明書をプライベート キーとともにストレージにインストールした場合、プライベート キー ファイルは存在せず、入力の必要もありません。



ヒント このプライベート キーは、サーバ証明書に関連したプライベート キーです。

ステップ 6 Private key password ボックスにプライベート キー パスワードを入力します。


ヒント Cisco Secure ACS を使用して証明書署名要求を生成した場合、このパスワードは、Generate Certificate Signing Request ページの Private key password に入力したものです。プライベート キー ファイルが暗号化されていない場合、このボックスは空欄のままにします。

ステップ 7 Submit をクリックします。

次の証明書情報を含む Installed Certificate Information テーブルが表示され、証明書のセットアップが完了します。

Issued to: certificate subject

Issued by: CA common name

Valid from:

Valid to:

Validity


 

認証局証明書の追加

この手順では、新しい認証局(CA)証明書を Cisco Secure ACS のローカル証明書ストレージに追加します。


) クライアントと Cisco Secure ACS が同じ CA から証明書を入手する場合、Cisco Secure ACS は証明書を発行した CA を自動的に信頼するため、この手順を実行する必要はありません。


ユーザ証明書が未知の CA(Cisco Secure ACS を証明しているものとは別の CA)から発行されたものである場合は、その CA を信頼するように Cisco Secure ACS を設定する必要があります。設定しない場合は、認証は失敗します。この手順を実行して CA を追加し、信頼関係を明示的に拡張するまで、Cisco Secure ACS は自分の証明書を発行した CA からの証明書しか認識しません。

特定の CA を信頼するように Cisco Secure ACS を設定するプロセスは、2 つのステップ、つまり、CA の証明書を追加するこの手順と、特定の CA を信頼するように指定する「証明書信頼リストの編集」の手順で構成されています(Cisco Secure ACS ではよく使用される CA のリストがあらかじめ設定されていますが、信頼に値することを明示的に指定するまでは、いずれもイネーブルになっていません)。

認証局証明書をローカル ストレージに追加するには、次の手順を実行します。


ステップ 1 ナビゲーション バーの System Configuration をクリックします。

ステップ 2 ACS Certificate Setup をクリックします。

ステップ 3 ACS Certification Authority Setup をクリックします。

Certification Authorities Setup ページに CA Operations テーブルが表示されます。

ステップ 4 CA certificate file ボックスに、使用する証明書のフル パスとファイル名を入力します。

ステップ 5 Submit をクリックします。

新しい CA 証明書が、ローカル証明書ストレージに追加されます。そして、証明書を発行した CA の名前が、まだ CTL に記載されていない場合は、記載されます。


ヒント この新しい CA 証明書を使用してユーザを認証するには、証明書信頼リストを編集して、この CA が信頼できることを指定する必要があります。詳細については、「証明書信頼リストの編集」を参照してください。


 

証明書信頼リストの編集

Cisco Secure ACS は、CTL を使用してクライアント証明書を確認します。CA が Cisco Secure ACS に信頼されるためには、その CA の証明書を Cisco Secure ACS にインストールし、Cisco Secure ACS 管理者が CTL を編集して、その CA を信頼できると設定する必要があります。Cisco Secure ACS サーバ証明書を置換し、CTL を消去した場合は、Cisco Secure ACS サーバ証明書をインストールまたは置換するたびに、CTL を明示的に設定する必要があります。


) クライアントと Cisco Secure ACS が同じ CA から証明書を取得する場合に限り、CA を信頼するように明示的に指定する作業が不要になります。この場合は、証明書を発行した CA を Cisco Secure ACS が自動的に信頼するため、この CA を CTL に追加する必要はありません。


CTL の編集方法によって、信頼モデルのタイプが決まります。多くの場合は限定信頼モデルが採用されています。限定信頼モデルでは、内密に管理されているごく少数の CA だけが信頼されます。このモデルではセキュリティが最高レベルになりますが、融通性と拡張性は制限されます。これに代わるオープンな信頼モデルでは、より多くの CA や周知の CA が許可されます。この場合は、セキュリティが低くなる代わりに、融通性と拡張性が高くなります。

Cisco Secure ACS で CTL を編集する前に、信頼モデルの意味を十分に理解してください。

この手順では、CTL で、CA を信頼できるか信頼できないかとして設定します。CA を信頼できるとして CTL で設定するには、その CA をローカルの証明書ストレージに追加しておく必要があります。詳細については、「認証局証明書の追加」を参照してください。ユーザの証明書が、Cisco Secure ACS で信頼できると設定していない CA から発行されている場合、認証は失敗します。

CTL を編集するには、次の手順を実行します。


ステップ 1 ナビゲーション バーの System Configuration をクリックします。

ステップ 2 Cisco Secure ACS Certificate Setup をクリックします。

ステップ 3 Edit Certificate Trust List をクリックします。

Edit the Certificate Trust List (CTL) テーブルが表示されます。


警告 自分で管理しない周知の CA を CTL に追加すると、システム セキュリティが低下することがあります。


ステップ 4 CA を信頼できるとして CTL で設定するには、対応するチェックボックスをオンにします。


ヒント 必要な数の CA を選択または選択解除できます。CA のチェックボックスをオフにすると、その CA は信頼できないとして設定されます。

ステップ 5 Submit をクリックします。

指定した CA(複数の場合あり)が、チェックボックスの選択状況に応じて、信頼できるとして、または信頼できないとして設定されます。


 

証明書失効リストの管理

証明書失効リスト(CRL)は、認証を求めるユーザが使用している証明書がまだ有効であることを、それらを発行した CA に従って Cisco Secure ACS が判断する手段です。

この項では、次のトピックについて取り上げます。

「証明書失効リストについて」

「証明書失効リストの設定オプション」

「証明書失効リスト発行者の追加」

「証明書失効リスト発行者の編集」

「証明書失効リスト発行者の削除」

証明書失効リストについて

デジタル証明書が発行されると、ユーザは通常、事前に設定された期限が切れるまでそれが有効であると期待します。しかし、さまざまな状況によって、期限が切れる前に証明書が無効になる場合もあります。そのような状況には、対応するプライベート キーの信頼が損なわれたか、損なわれたおそれがある場合や、CA 発行プログラムが変更された場合などが含まれます。このような場合、CRL は、CA が証明書の正当性を無効にして管理者による置換を要求するメカニズムを提供します。

Cisco Secure ACS は、X.509 CRL プロファイルを使用して証明書の無効化を実行します。CRL は、署名とタイムスタンプが記されたデータ構造です。これは、CA(または CRL 発行者)によって発行され、パブリック リポジトリ(LDAP サーバなど)で自由に使用できます。X.509 CRL プロファイルの操作の詳細については、RFC3280 を参照してください。

Cisco Secure ACS の CRL 機能を次に示します。

Trusted publishers and repositories configuration :Cisco Secure ACS HTML インターフェイスで、CRL 発行者とその CRL Distribution Points(CDP; CRL 配布点)および期間を表示して設定することができます。

Retrieval of CRLs from a CDP :Cisco Secure ACS は、トランスポート プロトコル(LDAP または HTPP)を使用して、設定する各 CA の CRL を定期的に取得するよう設定されます。これらの CRL は、EAP-TLS 認証中に使用するため保存されます。タイムスタンプのメカニズムはありません。Cisco Secure ACS は指定された時間だけ待ってから、自動的に CRL をダウンロードします。新規 CRL が既存の CRL と異なる場合は、新規バージョンが保存され、ローカル キャッシュに追加されます。CRL の取得が CSAuth サービスのログに表示されるのは、サービス ログの詳細レベルを「full」に設定した場合だけです。Cisco Secure ACS HTML インターフェイスの Certificate Revocation List Issuer edit ページに、最後の取得のステータス、日付、および時刻が表示されます。


) 自動 CRL 取得スケジューリングが機能するのは、EAP-TLS がイネーブルである場合だけです。


Verification of certificate status :EAP-TLS 認証中、Cisco Secure ACS は、ユーザによって示された証明書を、ユーザの証明書の CA によって発行された対応する CRL に照らして調べます。現在 Cisco Secure ACS によって保存されている CRL に従って証明書が無効になっている場合、認証は失敗します。

CRL 発行者は、信頼されている CA(つまり、CTL 上の CA)との関連でのみ追加できます。Cisco Secure ACS の新規サーバ証明書をインストールすると、使用している CTL がすべての信頼関係からクリアされます。CTL の CA は再確立する必要がありますが、前に設定した関連する CRL は残るので、再設定する必要がありません。

証明書失効リストの設定オプション

Certificate Revocation List Issuers edit ページには、次の設定オプションがあります。

Name :この CRL 発行者の名前。

Description :この CRL 発行者に関する説明。

Issuer's Certificate :CRL データへの発行者の署名を検証するための CA 証明書。このリストは、設定された CTL の内容から取得されます。

CRL Distribution URL :ここで入力する URL が、Cisco Secure ACS が CRL の取得に使用する URL になります。HTTP または LDAP を使用する URL を指定できます。Issuer's Certificate リストから選択した CA に対応する CRL 用の URL を指定してください。あるいは、ファイル自体の URL を指定することもできますが、それが必要になるのは、リポジトリ URL に複数のファイルが示されている場合だけです。

Retrieve CRL every :Cisco Secure ACS が CRL の取得を実行する間隔。たとえば、10 日間または 2 ヶ月間。

Retrieve on "Submit" :このオプションをオンにすると、新規 CRL 要求ページが処理のため送信されたときに、Cisco Secure ACS はすぐにディストリビューション URL に接続し、最新の CRL を取得しようとします。最初に CRL を取得する場合は、CRL が正常に取得されるよう、このオプションをオンにすることをお勧めします。

Certificate Revocation List Issuers edit ページには、テーブルの下部に Last Retrieve date という行もあります。このエントリには、最後に CRL を取得または取得を試行したときのステータスと日付および時刻が示されます。

証明書失効リスト発行者の追加

始める前に

Cisco Secure ACS に CRL 発行者を追加する前に、システムの CTL で対応する CA を示していることと、証明書の発行者とクラス用に CRL ディストリビューション リポジトリの URL を決定していることを確認してください。自動 CRL 取得機能を使用する場合は、EAP-TLS をイネーブルにしていることを確認してください。

証明書失効リスト発行者を Cisco Secure ACS に追加するには、次の手順を実行します。


ステップ 1 ナビゲーション バーの System Configuration をクリックします。

ステップ 2 ACS Certificate Setup をクリックします。

ステップ 3 Certificate Revocation Lists をクリックします。

Cisco Secure ACS が CRL Issuers edit ページを表示します。

ステップ 4 Add をクリックします。

ステップ 5 Name ボックスで、この CRL 発行者の名前を入力します。

ステップ 6 Description ボックスで、この CRL 発行者の説明を入力します。

ステップ 7 Issuer's Certificate ボックスで、ドロップダウン矢印を使用してリストからこの CRL 発行者に関連する CA 証明書を選択します。


ヒント リストでは、CTL に示されている CRL 発行者だけが選択可能になっています。したがって、発行者の証明書を選択するには、CTL で、そのエントリが信頼されていることを示す必要があります。

ステップ 8 CRL Distribution URL ボックスで、CRL ディストリビューション リポジトリの URL を入力します。


ヒント リポジトリに複数のファイルが含まれている場合、URL は CRL 自体を指定する必要があります。

ステップ 9 Retrieve CRL every ボックスで、Cisco Secure ACS が CRL の取得を実行する間隔を入力します。

ステップ 10 ページが処理用に送信されたときに Cisco Secure ACS が現在の CRL の取得を試みるようにするには、 Retrieve on "Submit" オプションをオンにします。


ヒント Retrieve on "Submit" オプションはオンにすることをお勧めします。提示されたディストリビューション リポジトリから CRL を取得できない場合、Cisco Secure ACS は次のエラー メッセージを表示します。Failed to retrieve CRL.Verify the CRL Distribution URL.

ステップ 11 Submit をクリックします。

指定された CRL が Cisco Secure ACS に追加されます(または、Retrieve on "Submit" オプションがオンになっていない場合は、追加がスケジュールされます)。


ヒント Last Retrieve date: ボックスに、最後に取得が試行されたときのステータス、日付、および時刻が表示されます。


 

証明書失効リスト発行者の編集

証明書失効リスト発行者を編集するには、次の手順を実行します。


ステップ 1 ナビゲーション バーの System Configuration をクリックします。

ステップ 2 ACS Certificate Setup をクリックします。

ステップ 3 Certificate Revocation Lists をクリックします。

Cisco Secure ACS が CRL Issuers edit ページを表示します。

ステップ 4 編集する CRL 発行者の名前をクリックします。

選択した CRL 発行者の詳細がシステムによって表示されます。

ステップ 5 変更する情報と設定を編集します。

ステップ 6 Submit をクリックします。

Cisco Secure ACS で、対応する CRL が、編集された発行者の CRL に変更されます(または、Retrieve on "Submit" オプションがオンになっていない場合は、変更がスケジュールされます)。


ヒント Last Retrieve date: ボックスに、最後に取得が試行されたときのステータス、日付、および時刻が表示されます。


 

証明書失効リスト発行者の削除

証明書失効リスト発行者を削除するには、次の手順を実行します。


ステップ 1 ナビゲーション バーの System Configuration をクリックします。

ステップ 2 ACS Certificate Setup をクリックします。

ステップ 3 Certificate Revocation Lists をクリックします。

Cisco Secure ACS が CRL Issuers edit ページを表示します。

ステップ 4 削除する CRL 発行者の名前をクリックします。

選択した CRL 発行者の詳細がシステムによって表示されます。

ステップ 5 Delete をクリックします。

指定された CRL 発行者およびその発行者のすべての CRL が Cisco Secure ACS から削除されます。


 

証明書署名要求の生成

Cisco Secure ACS を使用して、証明書署名要求(CSR)を生成できます。CSR を生成したら、それを CA に提出することで証明書を取得できます。後ほど証明書登録ツールで使用するための CSR を生成するには、この項で説明する手順を実行します。


) サーバ証明書をすでに保有している場合は、ACS Certificate Setup ページのこの部分を使用する必要はありません。


証明書署名要求を生成するには、次の手順を実行します。


ステップ 1 ナビゲーション バーの System Configuration をクリックします。

ステップ 2 ACS Certificate Setup をクリックし、 Generate Certificate Signing Request をクリックします。

Cisco Secure ACS が Generate Certificate Signing Request ページを表示します。

ステップ 3 Certificate subject ボックスで、CSR の送信先となる CA が要求する証明書フィールドの値を入力します。CN フィールドは必須です。形式は次のようになります。

field=value, field=value, . . .

ここで、 field は CN などのフィールド名、 value は acs01primary など、フィールドに適用できる値です。「Certificate subject」ボックスには最大 256 文字を入力できます。複数の値はコンマで区切ります。例:

CN=acs01primary, O=WestCoast, C=US, S=California

次の表で、「Certificate subject」ボックスに組み込むことができる有効なフィールドを定義します。

 

フィールド
フィールド名
最小長
最大長
必須か
どうか

CN

commonName

1

64

Yes

OU

organizationalUnitName

--

--

No

O

organizationName

--

--

No

S

stateOrProvinceName

--

--

No

C

countryName

2

2

No

E

emailAddress

0

40

No

L

localityName

--

--

No

ステップ 4 Private key file ボックスに、プライベート キーを保存するファイルのフル ディレクトリ パスと名前を、たとえば c:\privateKeyFile.pem と入力します。

ステップ 5 Private key password ボックスに、プライベート キー パスワード(自分で作成したもの)を入力します。

ステップ 6 Retype private key password ボックスに、プライベート キー パスワードを再入力します。

ステップ 7 Key length リストで、使用するキーの長さを選択します。


ヒント Key length の選択肢は 512 ビットと 1024 ビットです。デフォルトでより安全な選択肢は 1024 ビットです。

ステップ 8 Digest to sign with リストで、ダイジェスト(またはハッシュ アルゴリズム)を選択します。選択肢は、MD2、MD5、SHA、および SHA1 です。デフォルト値は SHA1 です。

ステップ 9 Submit をクリックします。

Cisco Secure ACS によって、ブラウザの右側に CSR が表示されます。

ステップ 10 任意の CA に CSR を送信します。

CA から証明書を受信した後、「Cisco Secure ACS サーバ証明書のインストール」のステップを実行します。


 

自己署名証明書の使用

Cisco Secure ACS を使用して、Cisco Secure ACS 管理の PEAP 認証プロトコルまたは HTTPS サポートに使用する自己署名デジタル証明書を生成することができます。この機能は、CA との連係を必要としない TLS/SSL のプロトコルおよび技術をサポートしています。

この項では、次のトピックについて取り上げます。

「自己署名証明書について」

「自己署名証明書の設定オプション」

「自己署名証明書の生成」

自己署名証明書について

Cisco Secure ACS は、PEAP や HTTPS など、デジタル証明書の使用を必要とする TLS/SSL 関連のプロトコルをサポートしています。自己署名証明書を使用すると、管理者は、Cisco Secure ACS 用の証明書を取得しインストールするために、認証局(CA)と連携せずに要件を満たすことができます。Cisco Secure ACS の自己署名証明書機能を使用すると、管理者は、自己署名デジタル証明書を生成し、それを Web 管理サービスの PEAP 認証プロトコルや HTTPS サポートに使用することができます。

自己署名証明書のインストールでは、証明書を取得する際に CA と連携しないことを除き、その他のデジタル証明書と同じアクションが必要になります。Cisco Secure ACS は自己署名証明書の複製をサポートしていませんが、複数の Cisco Secure ACS で使用するために証明書をエクスポートすることができます。そのためには、証明書ファイル(.cer 形式)および対応するプライベート キー ファイル(.pvk 形式)を別の Cisco Secure ACS にコピーし、それを通常の方法でインストールします。証明書のインストールの詳細については、「Cisco Secure ACS サーバ証明書のインストール」を参照してください。

自己署名証明書をクライアントと確実に相互動作させるには、ご使用のクライアントのマニュアルを参照してください。場合によっては、特定のクライアントで自己署名サーバ証明書を CA 証明書としてインポートする必要があります。

自己署名証明書の設定オプション

Generate Self-Signed Certificate edit ページには、次の必須設定フィールドがあります。

Certificate subject :「cn=」というプレフィックスが付けられた証明書の件名。これには Cisco Secure ACS 名を使用することをお勧めします。たとえば、「cn=ACS11」です。この Certificate subject フィールドには、次のようないくつかのエントリをコンマ区切りの項目として入力できます。

CN :共通名(必須項目)

OU :組織ユニット名

O :組織名

S :州または地域

E :電子メール アドレス

L :市区町村名

たとえば、Certificate subject フィールドは次のようになります。

cn=ACS 11, O=Acme Enterprises, E=admin@acme.com

Certificate file :生成する証明書ファイルのフル パスとファイル名。たとえば、「c:\acs_server_cert\acs_server_cert.cer」です。このページを送信すると、Cisco Secure ACS は、指定された場所とファイル名を使用して証明書ファイルを作成します。

Private key file :生成するプライベート キー ファイルのフル パスとファイル名。たとえば、「c:\acs_server_cert\acs_server_cert.pvk」です。このページを送信すると、Cisco Secure ACS は、指定された場所とファイル名を使用してプライベート キー ファイルを作成します。

Private key password :証明書のプライベート キー パスワード。プライベート キー パスワードの最小長は 4 文字、最大長は 64 文字です。

Retype private key password :確認のため、プライベート キー パスワードを再入力します。

Key length :表示された選択肢からキーの長さを選択します。選択肢は、512 ビット、1024 ビット、および 2048 ビットです。

Digest to sign with :表示された選択肢から、キーの暗号化に使用するハッシュ ダイジェストを選択します。選択肢には、SHA1、SHA、MD2、および MD5 があります。

Install generated certificate :Submit をクリックしたときに、生成した自己署名証明書が Cisco Secure ACS でインストールされるようにするには、このチェックボックスをオンにします。このオプションをオンにした場合は、新しい設定を適用するため、ページを送信した後に Cisco Secure ACS サービスを再起動する必要があります。このオプションをオフにした場合は、証明書ファイルとプライベート キー ファイルが生成され保存されますが、ローカル マシン ストレージにはインストールされません。

自己署名証明書の生成

Generate Self-Signed Certificate ページのフィールドはすべて必須です。フィールドの内容については、「自己署名証明書の設定オプション」を参照してください。

自己署名証明書を生成するには、次の手順を実行します。


ステップ 1 ナビゲーション バーの System Configuration をクリックします。

ステップ 2 ACS Certificate Setup をクリックします。

ステップ 3 Generate Self-Signed Certificate をクリックします。

Cisco Secure ACS が Generate Self-Signed Certificate edit ページを表示します。

ステップ 4 Certificate subject ボックスに、 cn=XXXX の形式で証明書の件名を入力します。ここには、その他の情報も入力できます。詳細については、「自己署名証明書の設定オプション」を参照してください。

ステップ 5 Certificate file ボックスに、証明書ファイルのフル パスとファイル名を入力します。

ステップ 6 Private key file ボックスに、プライベート キー ファイルのフル パスとファイル名を入力します。

ステップ 7 Private key password ボックスにプライベート キー パスワードを入力します。

ステップ 8 Retype private key password ボックスに、プライベート キー パスワードを再入力します。

ステップ 9 Key length ボックスで、キーの長さを選択します。

ステップ 10 Digest to sign with ボックスで、キーの暗号化に使用するハッシュ ダイジェストを選択します。

ステップ 11 ページの送信時に自己署名証明書をインストールするには、 Install generated certificate オプションを選択します。


) Install generated certificate オプションを使用する場合は、新しい設定を適用するため、このフォームの送信後に Cisco Secure ACS サービスを再起動する必要があります。



ヒント Install generated certificate オプションをオフにした場合は、次のステップで Submit をクリックしたときに証明書ファイルとプライベート キー ファイルが生成され保存されますが、ローカル マシン ストレージにはインストールされません。

ステップ 12 Submit をクリックします。

指定した証明書ファイルとプライベート キー ファイルが指定どおりに生成され、保存されます。Install generated certificate オプションもオンにした場合は、Cisco Secure ACS サービスを再起動した後に、証明書が有効になります。


 

Cisco Secure ACS 証明書のアップデートまたは置き換え

この手順では、既存の Cisco Secure ACS 証明書が古くなった場合または使用できなくなった場合にアップデートまたは置換します。


注意 この手順を実行すると、既存の Cisco Secure ACS 証明書は削除され、CTL 設定は消去されます。

新しい ACS 証明書を実装するには、次の手順を実行します。


ステップ 1 ナビゲーション バーの System Configuration をクリックします。

ステップ 2 ACS Certificate Setup をクリックします。

ACS Certificate Setup ページに Installed Certificate Information テーブルが表示されます。


) Cisco Secure ACS に証明書が登録されていない場合、Installed Certificate Information テーブルは表示されません。その代わりに Install new certificate テーブルが表示されます。この場合はステップ 5 に進んでください。


ステップ 3 Enroll New Certificate をクリックします。

確認ダイアログボックスが表示されます。

ステップ 4 新しい証明書を登録することを確認するために、 OK をクリックします。

既存の Cisco Secure ACS 証明書が削除され、CTL 設定が消去されます。

ステップ 5 ここで、代わりの証明書をオリジナルの証明書と同じ方法で実装できます。詳細な手順については、「Cisco Secure ACS サーバ証明書のインストール」を参照してください。