Cisco Secure Access Control Server 4.2.1 ユーザ ガイド
システム設定:認証と証明書
システム設定:認証と証明書
発行日;2012/02/02 | 英語版ドキュメント(2010/05/12 版) | ドキュメントご利用ガイド | ダウンロード ; この章pdf , ドキュメント全体pdf (PDF - 5MB) | フィードバック

目次

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

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

デジタル証明書

EAP-TLS 認証

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

EAP-TLS と ACS

EAP-TLS での制限事項

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

NAC/NAP 環境での EAP-TLS および ACS

PEAP 認証

PEAP プロトコルについて

PEAP と ACS

PEAP と未知ユーザ ポリシー

PEAP 認証のイネーブル化

EAP-FAST 認証

EAP-FAST について

マスター キーについて

PAC について

プロビジョニング モード

PAC のタイプ

匿名の TLS 再ネゴシエーション用の EAP-FAST

PAC Free EAP-FAST

EAP-FAST PKI 認可バイパス

マスター キーと PAC TTL

複製と EAP-FAST

EAP-FAST のイネーブル化

ステートレスなサーバ セッション再開

[Global Authentication Setup]

認証オプションの設定

ACS 証明書のセットアップ

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

認証局証明書の追加

証明書信頼リストの編集

証明書信頼リストからの証明書の削除

証明書失効リストの管理

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

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

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

証明書署名要求の生成

自己署名証明書の使用

自己署名証明書について

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

自己署名証明書の生成

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

EAP-FAST PAC ファイルの生成(ACS SE)

PAC ファイルの生成オプション

PAC ファイルの生成

[Advanced System Configuration] ページ リファレンス

[Global Authentication Setup] ページ

[EAP-FAST Configuration] ページ

[Cipher Suite Configuration] ページ

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

この章では、Cisco Secure Access Control Server リリース 4.2(以降は ACS と表記)の [System Configuration] セクションにある認証機能について説明します。

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

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

「[Global Authentication Setup]」

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

「EAP-FAST PAC ファイルの生成(ACS SE)」

「[Advanced System Configuration] ページ リファレンス」

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

ACS は、Extensible Authentication Protocol-Transport Layer Security(EAP-TLS)、Extensible Authentication Protocol-Flexible Authentication via Secure Tunneling(EAP-FAST)、および Protected Extensible Authentication Protocol(PEAP)の各認証プロトコルをデジタル認証と組み合せて使用して、認証情報の保護と正当性を保証しています。

ここでは、次の項目について説明します。

「デジタル証明書」

「EAP-TLS 認証」

「PEAP 認証」

「EAP-FAST 認証」

デジタル証明書

ACS Web インターフェイスに安全にアクセスするための Secure HyperText Transfer Protocol(HTTPS; セキュア ハイパーテキスト転送プロトコル)プロトコルのサポートに加えて、EAP-TLS、EAP-FAST、および PEAP の各認証をサポートするために、[ACS Certificate Setup] ページを使用してデジタル証明書をインストールします。ACS は、X.509 v3 デジタル証明書標準を使用します。証明書ファイルは、Base64-encoded X.509 形式または Distinguished Encoding Rules(DER)-encoded バイナリ X.509 形式にする必要があります。さらに、ACS は証明書の手動登録をサポートし、Certificate Trust List(CTL; 証明書信頼リスト)と Certificate Revocation List(CRL; 証明書失効リスト)を管理する手段を提供します。

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


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


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

EAP と TLS は、Internet Engineering Task Force(IETF; インターネット技術特別調査委員会)RFC 標準です。EAP プロトコルは、初期認証情報、具体的には IEEE 802.1X で確立されている EAP over LAN(EAPOL)のカプセル化を伝達します。TLS は、ユーザ認証とダイナミック短期セッション キー生成に証明書を使用します。EAP-TLS 認証プロトコルは、ACS とエンドユーザ クライアントの証明書を使用して、クライアントと ACS の相互認証を適用します。EAP、TLS、および EAP-TLS の詳細については、IETF RFC( Extensible Authentication Protocol(EAP)RFC 3784 The TLS Protocol RFC 2246 、および PPP EAP TLS Authentication Protocol RFC 2716 )を参照してください。

EAP-TLS 認証では、2 つの信頼要素が必要です。

EAP-TLS ネゴシエーションにおいて、証明書によって署名されているキーペアをユーザが所有していることを RSA 署名検証で確認することによって、エンドユーザの信頼を確立する。これによって、エンドユーザが特定のデジタル証明書に対する正当なキー所有者であること、およびその証明書内のユーザ ID に対応していることが確認されます。しかし、ユーザが証明書を所有していることを信頼しても、ユーザ名/キーペアを確認するに過ぎません。

証明書の情報を確認する第三者署名、通常は CA の署名を使用する。第三者による確認は、パスポートのスタンプの確認にあたります。パスポートが信頼できるのは、特定の国/地域のパスポート発行機関が、そのパスポートを作成する際に行った準備と身元確認が信頼できるためです。ルート証明書 CA の署名がインストールされていることで、デジタル証明書は信頼されます。

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

EAP-TLS は、エンド クライアントおよび Authentication, Authorization, and Accounting(AAA; 認証、認可、アカウンティング)クライアントからのサポートを必要とします。EAP-TLS クライアントの例としては、Microsoft Windows XP オペレーティング システムが挙げられます。

EAP-TLS に準拠した AAA クライアントの例としては、次のものが挙げられます。

Cisco 802.1x 対応のスイッチ プラットフォーム(Catalyst 6500 シリーズなど)

Cisco Aironet Wireless ソリューション

EAP-TLS は、セキュアな Cisco Aironet 接続を実現するために、各ユーザ、各接続に固有の動的なセッション キーを生成します。

EAP-TLS と ACS

ACS は、Windows XP、Funk(Juniper)または Meetinghouse クライアントなど、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/en/US/products/hw/wireless/ps430/products_white_paper09186a008009256b.shtml

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

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

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

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

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


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


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

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

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


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


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

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

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

EAP-TLS での制限事項

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

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

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

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


) ACS は、Active Directory(AD)で認証を行う場合のみ、ユーザ名とパスワードに対する UTF-8(8 ビットの Universal Coded Character Set(UCS)/Unicode Transformation Format)をサポートしています。UTF-8 形式は、US-ASCII 文字の全範囲を保持し、既存の ASCII 処理ソフトウェアと互換性があります。


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

この項では、EAP-TLS 認証をサポートするように ACS を設定するために必要な手順について説明します。


) EAP-TLS をサポートするようにエンドユーザ クライアント コンピュータを設定する必要があります。ここでは、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社 の Web サイトにある適切な Knowledge Base の記事を参照してください。

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


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


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


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

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

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

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

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


 

NAC/NAP 環境での EAP-TLS および ACS

ACS は、Cisco Network Admission Control(ネットワーク アドミッション コントロール)および Microsoft Network Access Protection(ネットワーク アクセス保護)(NAC/NAP)環境に展開できます。NAC/NAP 環境では、NAP クライアント コンピュータは、EAP over UDP(EoU)または EAP over 802.1x を使用して ACS で認可されます。

NAP クライアント(Windows または Windows Longhorn Server を実行しているコンピュータ)は、接続時に NAP エージェントを使用して、次のいずれかを ACS に送信します。

Statements of Health(SoH; 正常性ステートメント)のリスト。

クライアントが Microsoft Health Registration Authority(HRA; 正常性登録機関)から取得した証明書。

ACS ホストは、次のようにしてクライアントのクレデンシャルを確認します。

NAP エージェントが SoH のリストを送信する場合、ACS は Cisco Host Credentials Authorization Protocol(HCAP)を使用して、そのリストを Microsoft Network Policy Server(NPS; ネットワーク ポリシー サーバ)に送信します。NPS が SoH を評価します。次に、ACS が適切なネットワーク アクセス プロファイルをネットワーク アクセス デバイス(スイッチ、ルータ、VPN など)に送信して、認可したアクセスのレベルをクライアントに許可します。

NAP エージェントが SoH のリストではなく、正常性証明書を送信する場合、ACS はクライアントの全体的な正常性の状態を判断するために EAP-FAST セッションが確立される際に、証明書を確認します。次に、ACS は適切なネットワーク アクセス プロファイルをネットワークに送信して、認可したアクセスのレベルをクライアントに許可します。

NAC/NAP 環境で ACS が動作するようにカスタマイズする 1 つ以上のネットワーク アクセス プロファイルを設定することで、NAP クライアントからのアクセス要求を処理するように ACS を設定できます。NAC/NAP 環境で ACS が機能するように設定する方法の詳細については、『 Configuration Guide for Cisco Secure ACS 4.2 』の第 9 章「NAC/NAP Configuration Scenario」を参照してください。

PEAP 認証

ここでは、次の項目について説明します。

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

「PEAP と ACS」

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

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

PEAP プロトコルについて

PEAP プロトコルは、EAP トランザクションの暗号化に使用するクライアント サーバ型のセキュリティ アーキテクチャです。これによって、EAP 認証の内容が保護されます。

PEAP 認証には常に 2 つのフェーズがあります。

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


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


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

EAP-MSCHAPv2

EAP-GTC

EAP-TLS

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

PEAP と ACS

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

Cisco Aironet PEAP クライアントでの PEAP

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

PEAP と Microsoft Windows Active Directory

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

セッション再開機能

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


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


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

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

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

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

PEAP 高速再接続機能のイネーブル化は、[Global Authentication Setup] ページで行うことができます。この機能のイネーブル化の詳細については、「[Global Authentication Setup]」を参照してください。


) 高速再接続を介して確立されたセッションの再使用は、ACS のダイナミック ユーザが削除されていない場合にのみ機能します。ダイナミック ユーザが明示的に削除されていて、確立されたセッションを再使用できない場合、ACS は通常の方法で完全な認証を試みます。


PEAP と未知ユーザ ポリシー

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

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

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

PEAP 認証のイネーブル化

ここでは、PEAP 認証をサポートするように ACS を設定するために必要な手順について概説します。


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


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


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


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


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

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

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

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


 

EAP-FAST について

EAP Flexible Authentication via Secured Tunnel(EAP-FAST)プロトコルは、パブリックにアクセス可能な新しい IEEE 802.1X EAP タイプです。これは、強力なパスワード ポリシーを適用できないユーザがデジタル証明書を必要としない 802.1X EAP タイプを展開できるように、シスコが開発しました。EAP-FAST は、さまざまなタイプのユーザ データベースやパスワード データベース、パスワードの変更や有効期間をサポートしています。そのため、柔軟性があり、展開や管理も容易です。EAP-FAST と他の EAP タイプとの比較の詳細については、次のサイトを参照してください。

www.cisco.com/en/US/products/hw/wireless/ps430/products_qanda_item09186a00802030dc.shtml

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

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

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


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


[Allow anonymous in-band PAC provisioning] オプションを選択すると、EAP-FAST フェーズ 0 を使用してエンドユーザ クライアントに PAC がプロビジョニングされます。このチェックボックスをオンにすると、ACS は、エンドユーザ クライアントに新規 PAC を提供するために、そのクライアントとの安全な接続を確立します。このオプションでは、エンドユーザ クライアントと ACS の間で匿名の TLS ハンドシェイクが可能になります (内部方式として EAP-MS-CHAP だけが使用されます)。

[Allow authenticated in-band PAC provisioning] オプションを選択すると、TLS サーバ側の認証とともに EAP-FAST フェーズ 0 を使用してエンドユーザ クライアントに PAC がプロビジョニングされます。このオプションを選択する場合は、ACS にサーバ証明書と信頼できるルート CA をインストールする必要があります。

ACS は、デフォルトで TLS サーバ側の認証をサポートしています。ただし、クライアントがユーザ証明書を ACS に送信する場合は、相互 TLS 認証が実行され、内部方式はバイパスされます。

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

[Accept client on authenticated provisioning] オプションを選択すると、ACS がプロビジョニング フェーズ(フェーズ 0)の終わりに必ず Access-Reject を送信するため、クライアントはトンネル PAC を使用して再認証を受ける必要があります。このオプションでは、クライアントに Access-Accept が送信されます。このオプションは、[Allow authenticated in-band PAC provisioning] チェックボックスをオンにした場合にだけイネーブルにすることができます。

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

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

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

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


) このバージョンの ACS は NAC フェーズ 2 に対して EAP-FAST フェーズ 2 をサポートしており、有線クライアントだけを対象としています。


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

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

マスター キーについて

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

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

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

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

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

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


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


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

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

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

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

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

PAC について

PAC は、ACS および EAP-FAST エンドユーザ クライアントをイネーブルにし、互いを認証して EAP-FAST フェーズ 2 で使用する TLS トンネルを確立する強力な共有秘密です。ACS は、アクティブ マスター キーとユーザ名を使用して PAC を生成します。

PAC は、次のもので構成されています。

PAC-Key :クライアント(およびクライアント デバイス)とサーバの ID にバインドされている共有秘密。

PAC Opaque :クライアントがキャッシュしてサーバに渡す暗号化されたフィールド。サーバは、PAC-Key およびクライアント ID を復号化して、クライアントとの相互認証を行います。

PAC-Info :クライアントがさまざまな PAC をキャッシュできるように、少なくともサーバの ID が含まれています。PAC の有効期限などの情報が含まれていることもあります。

EAP-FAST エンドユーザ クライアントは、クライアントを使用してネットワークにアクセスする各ユーザの PAC を保存します。さらに、EAP-FAST をサポートする AAA サーバには独自の認証局 ID があります。エンドユーザ クライアントは、ユーザの PAC を、それを生成した AAA サーバの認証局 ID と関連付けます。PAC により PKI(デジタル証明書)が不要になります。

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

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

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

プロビジョニング モード

ACS は、アウトオブバンド プロビジョニング モードとインバンド プロビジョニング モードをサポートしています。インバンド プロビジョニング モードは、ピアが ACS サーバを認証する前に Authenticated Diffie-Hellman Key Agreement Protocol(ADHP)トンネル内で機能します。

認証されていないサーバがプロビジョニングされるため、プレーン テキストのパスワードを使用することはできません。したがって、トンネルの内部で MS-CHAP クレデンシャルだけを使用できます。MS-CHAPv2 は、ピアの身元を証明するため使用され、その後の認証セッション用に PAC を受信します。この方式により、ユーザのクレデンシャルを危険にさらす可能性が最小限に抑えられます。

EAP-FAST は、機能が拡張されて、PAC プロビジョニングが実行される認証済みトンネル(サーバ証明書を使用)をサポートするようになりました。EAP-FAST および特にサーバ証明書に対する機能拡張となる、新しい暗号スイートが使用されます。

トンネル セットアップの一部としてサーバが認証されるため、トンネル内部であまり強力でない EAP 方式(EAP-GTC など)を使用して、サプリカントの認証を提供できます。

認証済みトンネルを使用するプロビジョニング セッションの終わりに、ネットワーク アクセスを許可できます。これは、サーバとユーザが互いを認証したためです。

ACS は、プロビジョニングのためにトンネル内部で次の EAP タイプをサポートしています。

EAP-GTC

EAP-MS-CHAPv2

EAP-TLS


) デフォルトでは、EAP-GTC および EAP-MSCHAP 内部方式を使用している場合、ACS は、最初の認証の試行が失敗した場合に、SSL トンネル内で 3 回まで認証の試行を許可します。SSL トンネル内部での 4 回目の認証の試行が失敗すると、ACS は EAP カンバセーションを終了し、RADIUS Access-Reject の状態になります。


PAC のタイプ

ACS は、共有秘密を含む PAC をサプリカントにプロビジョニングします。この共有秘密は、サプリカントと ACS の間に TLS トンネルを構築する場合に使用されます。ACS がサプリカントにプロビジョニングする PAC は、状況に応じてさまざまな用途を持ちます。

サーバ ポリシーに従って、次のタイプの PAC が ACS にプロビジョニングされます。

トンネル(共有秘密)PAC、ユーザまたはマシン :ピアと ACS の間で配布される共有秘密であり、安全なトンネルを確立するため、およびトンネル内で何を実行する必要があるかまたは何を実行できるかというポリシーを伝達するために使用されます。ポリシーには、トンネル内で許可される EAP 方式、TLV 交換、ID などが含まれます。PAC を使用する後続の認証でポリシーを適用するために必要な情報を PAC に含めるのは、サーバ ポリシーの役割です。たとえば、EAP-FAST プロトコル バージョン 1 では、サーバ ポリシーの一部としてユーザ ID(I-ID)が含まれます。これにより、内部 EAP 方式が、プロビジョニングされるユーザ ID に対してだけ伝達されるように制限されます。許可される EAP 方式や暗号スイートなど、他のタイプの情報も含めることができます。PAC にサーバ ポリシーが含まれていない場合、その PAC を使用して確立されるトンネル内には、内部 EAP 方式やユーザ ID に対する検証も制限もありません。マシンの PAC ユーザには、タイプ フィールドが含まれています。マシンの形式は、 ホスト/マシン名 となります。

ユーザ認可 PAC :配布される、ユーザ認証および認可の結果であり、以前の認証に基づいています。この PAC をトンネル PAC と組み合せて使用して、後続のユーザ認証をバイパスできます。この PAC は、存続期間が短く、ピアによって制御されるものとして設計されています。ユーザ認証の結果に影響を及ぼすようなユーザ状態の変化があった場合(たとえば、ユーザがログオンまたはログオフした場合など)、ピアはこの PAC を廃棄して、再び使用しません。ユーザ認可 PAC をトンネル PAC と組み合せて使用すると、「ステートレスなサーバ セッション再開」で説明しているように、ステートレスなサーバ セッション再開ができるようになります。

ポスチャ PAC :配布される、ポスチャ チェックおよび認可の結果であり、以前のポスチャ確認に基づいています。再確認が頻繁に行われる場合は、ポスチャ PAC を使用して、ポスチャ確認を最適化できます。この結果は、ポスチャ確認アプリケーションに固有のもので、EAP-FAST のコンテンツの外部で使用できます。

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

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

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

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

手動プロビジョニング :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 の終わりに ACS がユーザ用の新規 PAC を生成し、それをエンドユーザ クライアントに提供します。

自動 PAC プロビジョニング

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

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


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


EAP-FAST フェーズ 0 ではネットワーク サービスはイネーブルにならないので、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 プロビジョニング」を参照してください。


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

手動 PAC プロビジョニング

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

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


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


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

特定のユーザ名、ユーザ グループ、ユーザ名リスト、またはすべてのユーザに対して PAC ファイルを生成できます。ユーザ グループまたはすべてのユーザに対して PAC ファイルを生成する場合、ユーザは未知ユーザではなく、既知ユーザまたは検出ユーザである必要があります。


) ACS for Windows のみ:ACS for Windows では、CSUtil.exe を使用した PAC ファイルの作成をサポートしています。CSUtil.exe を使用した PAC の作成の詳細については、「PAC ファイルの生成」を参照してください。


匿名の TLS 再ネゴシエーション用の EAP-FAST

匿名の PAC プロビジョニング スキーマを使用する場合、パスワードの入力を 2 回求められることがあります。最初にパスワードを入力したときに、ACS は PAC をプロビジョニングして、access-reject をクライアントに送信します。次に、クライアントがプロンプトに対してパスワードを再入力すると、認証が可能になり、ネットワークへのアクセスが許可されます。

ACS は TLS クライアントのハンドシェイク レコードを確認します。TLS クライアントのハンドシェイク レコードを確認できた場合、ACS は、ユーザのアクセス要求を拒否する代わりに、EAP-FAST フェーズ 0 の最後に TLS 再ネゴシエーションを開始します。


) ホストが匿名の PAC プロビジョニングを使用している場合、Vista クライアントではこのオプションを使用する必要があります。このオプションをイネーブルにしている場合、ACS は、PAC プロビジョニング後にアクセスの試行を拒否する代わりに、EAP-FAST フェーズ 0 の最後にクライアントへの TLS 再ネゴシエーション要求の送信を開始します。


PAC Free EAP-FAST

PAC Free EAP-FAST 認証を使用すると、トンネルまたはマシン生成の PAC を発行したり、受け入れたりせずに、ACS で EAP-FAST を実行できます。一部の PAC は存続期間が長く、アップデートされていないことが原因で、認証およびセキュリティの問題が生じる場合があります。PAC Free EAP- FAST をイネーブルにすると、PAC に対する要求は無視されます。EAP-FAST フェーズ 0 で開始される認証および PAC に対する後続の要求はすべて無視されます。フローは EAP- FAST フェーズ 2 に移動します。ACS は、PAC なしで Success-TLV メッセージを返します。クライアントが PAC とのトンネルを確立しようとすると、ACS は PAC Invalid メッセージを返します。トンネルの確立は行われず、Access access-reject Reject が送信されます。ホスト/サプリカントは、接続を再度試みることができます。

ADHP とも呼ばれる匿名のフェーズ 0 では、PAC Free はサポートされていません。これは、プロトコルがフェーズ 2 へのロールオーバーをサポートしていないためです。PAC Free EAP-FAST は、設定をサポートしており、クライアント証明書を必要としません。PAC Free EAP-FAST を設定する方法の詳細については、「[Protocols Settings for profile_name] ページ」を参照してください。

EAP-FAST PKI 認可バイパス

EAP-FAST PKI 認可バイパスを使用すると、ACS はユーザをデータベースに対して認可しなくても、EAP-FAST トンネルの確立を行うことができます。認可は、ユーザのグループ データおよび証明書を外部データベースから取得することで行われます。取得後、ACS は少なくとも 1 つの証明書、CN または SAN と、クライアントが提供した証明書から受け取った値を比較します。比較が成功すると、グループが ACS ユーザグループにマッピングされます。成功しなかった場合は、認証に失敗します。PKI 認可バイパスがイネーブルになっている場合、このステージは省略され、セッションは事前に定義されたユーザ グループにマッピングされます。この機能によって、外部データベースに依存しない設定が可能になり、信頼性が向上します。

EAP-FAST PKI 認可バイパス機能は、PAC Free EAP-FAST 機能とは異なるものですが、PAC Free がイネーブルでない場合は PKI 認可バイパスをイネーブルにできません。この依存性により、CRL または外部データベース検索による相互に認証されたハンドシェイクを強制することで、ユーザまたはマシンのアクセスを無効にする手段を提供します。PKI 認可バイパスを PAC Free EAP- FAST なしで実装できるようにしてしまうと、ユーザに PAC が発行された場合に、その PAC が期限切れになるまでネットワークへのアクセスを無効にできなくなります。

マスター キーと PAC TTL

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

表 9-1 に、PAC とマスター キーの状態に関する ACS の動作をまとめてあります。

 

表 9-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

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

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

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

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

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

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

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

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


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


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

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

 

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

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

EAP-FAST がイネーブル

なし

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

マスター キー TTL

あり

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

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

あり

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

PAC TTL

あり

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

認証局 ID

あり

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

認証局 ID 情報

あり

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

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

あり

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

マスター キー

あり

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

EAP-FAST マスター サーバ

なし

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

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

なし

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

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

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

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


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


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


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


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

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

EAP-FAST のイネーブル化

この項では、EAP-FAST 認証をサポートするように ACS を設定する手順について説明します。


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


始める前に

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

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


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


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


ACS は、未知ユーザ ポリシーの使用と 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 をイネーブルにします。詳細な手順については、「認証オプションの設定」を参照してください。

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


) 「the workstation not allowed」エラーが表示された場合、内部 ID はロギングされません。SSL ハンドシェイクは失敗し、EAP-PAC がプロビジョニングされ、ACS は無効な PAC を受け取ります。


ステートレスなサーバ セッション再開

サーバ パフォーマンス、ロード バランシング、および別のサーバへのピア ローミングに対する優れたサポートを提供するため、EAP-FAST は、存続期間の短い認可 PAC を使用するステートレスなサーバ セッション再開をサポートしています。ピアが TLS セッションを確立して認証されると、EAP サーバはピアにトンネル PAC をプロビジョニングできます。トンネル PAC を使用すると、通常の TLS ハンドシェイクよりもかなり速く TLS セッションを確立できます。通常の TLS セッション再開では、EAP サーバが TLS セッションのキャッシュと、ピアの認証および認可の結果を保持する必要があります。このストレージ要件により、サーバのパフォーマンスが低下したり、サーバのロード バランシングや、別のサーバへのピア ローミングで問題が生じたりすることが多くあります。トンネル PAC を使用すると、TLS セッションのキャッシュを保持する必要がなくなります。高速かつ安全な方法で TLS セッションを迅速に確立できます。ただし、迅速なセッション再開を実現するには、サーバがピアの以前の認証および認可の状態をキャッシュする必要があります。

ユーザ認可 PAC をトンネル PAC と組み合せて使用して、さらに最適化できます。サーバで生成されたキーにより、ピアの以前の認証および認可の状態を格納するユーザ認可 PAC が保護されます。ピアは、接続先の EAP サーバに対応する(A-ID が一致する)認可 PAC を持っており、ピアに影響を及ぼす状態変化がないことを検出すると、それらの PAC の Opaque 部分を TLS アプリケーション データとして Client TLS Finished とともに PAC-TLV に実装できます。この TLV は、ネゴシエートされる TLS 暗号スイートによって保護されます。この方法により、さらにラウンドトリップを導入しなくても、攻撃者による認可 PAC のスヌーピングを防ぐことができます。EAP サーバは、認可 PAC を受信して復号化すると、ピアの認証および認可の結果に基づいて、以前の状態情報を再作成できます。これらの PAC 内の状態情報がまだ有効である場合、EAP サーバは、サーバ側のポリシーに基づいて、内部 EAP 方式の認証を 1 つまたはすべてバイパスできます。内部方式がバイパスされる場合、EAP サーバは、Crypto-binding TLV は送信せず Result TLV だけを送信し、ピアは成功を示す Result TLV で応答します。1 つまたはすべての PAC が存在しないまたは受け入れられない場合、EAP サーバは EAP 認証シーケンスのすべてまたは一部を開始できます。

ACS は、次の内部方式と TLV 交換の組み合せをサポートしています。

EAP-MS-CHAP 認証 + ポスチャ確認 TLV 交換

EAP-GTC 認証 + ポスチャ確認 TLV 交換

EAP-TLS 認証 + ポスチャ確認 TLV 交換

認証なしのポスチャ確認 TLV 交換


) 認可 PAC を使用して確立されたセッションの再使用は、ACS のダイナミック ユーザが削除されていない場合にのみ機能します。ダイナミック ユーザが明示的に削除されていて、確立されたセッションを再使用できない場合、ACS は通常の方法で完全な認証を試みます。


[Global Authentication Setup]

ACS でサポートされている認証プロトコルの一部をイネーブルまたはディセーブルにするには、[Global Authentication Setup] ページを使用します。また、[Global Authentication Setup] ページ上のプロトコルの一部について、オプションを設定することができます。

ここでは、次の項目について説明します。

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

「[EAP-FAST Configuration] ページ」

「[Cipher Suite Configuration] ページ」


注意 ネットワーク アクセス プロファイル設定は、グローバル認証設定よりも優先されます。

認証オプションの設定

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

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

「[EAP-FAST Configuration] ページ」を使用して、認証設定オプションを設定します。


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


始める前に

オプションについては、「[EAP-FAST Configuration] ページ」を参照してください。

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


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

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

[Global Authentications] ページが表示されます。

ステップ 3 必要に応じて、オプションを設定します。EAP-FAST におけるオプションの署名の詳細については、「[EAP-FAST Configuration] ページ」を参照してください。[Cipher Suite Configuration] におけるオプションの署名の詳細については、「[Cipher Suite Configuration] ページ」を参照してください。

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

ACS がサービスを再起動し、選択した認証設定オプションが ACS に実装されます。

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


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


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


 

ACS 証明書のセットアップ

ここでは、次の項目について説明します。

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

「認証局証明書の追加」

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

「証明書信頼リストからの証明書の削除」

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

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

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

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

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

ACS 用のサーバ証明書をインストール(登録)するには、次の手順を実行します。証明書登録を実行すると、GUI で ACS にアクセスするための HTTPS プロトコルのサポートに加えて、EAP-TLS 認証と PEAP 認証をサポートできます。

サーバ証明書の取得方法として、次の 3 つのオプションがあります。

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

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

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

始める前に

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

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

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

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

ACS for Windows


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

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

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

[Install ACS Certificate] ページが表示されます。


) ACS 証明書は、ACS がインストールされているローカル サーバにインストールする必要があります。


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

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

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


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


ローカル マシンの証明書ストレージに保存されている特定の既存証明書を使用するには、[Select Certificate from Storage] オプションを選択して、ドロップダウン リストから証明書を選択します。

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


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



ヒント この秘密鍵は、サーバ証明書に関連した秘密鍵です。


ステップ 6 [Private key password] ボックスに、秘密鍵のパスワードを入力します。


ヒント 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:]


 

ACS SE


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

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

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

[Install ACS Certificate] ページが表示されます。

ステップ 4 新しい証明書をインストールするには、[Read certificate from file] オプションをクリックした後、[Download certificate file] リンクをクリックします。

[Download Certificate File] ページが表示されます。

ステップ 5 証明書ファイルを ACS にダウンロードするには、[Download File] テーブルに次の情報を入力します。

a. [FTP Server] ボックスに、ダウンロードする証明書ファイルが格納されている FTP サーバの IP アドレスまたはホスト名を入力します。


ヒント ホスト名を指定する場合、DNS がネットワーク上で正常に動作している必要があります。


b. [Login] ボックスに、ACS が FTP サーバへのアクセスに使用できる有効なユーザ名を入力します。

c. [Password] ボックスに、[Login] ボックスで指定したユーザ名のパスワードを入力します。

d. [Remote FTP Directory] ボックスに、ACS が FTP サーバからダウンロードする証明書ファイルが含まれているディレクトリのパスを、FTP サーバのルート ディレクトリからの相対パスで入力します。

e. [Remote FTP File Name] ボックスに、ACS が FTP サーバからダウンロードする証明書ファイルの名前を入力します。

f. [Submit] をクリックします。

証明書ファイルがダウンロードされ、[Install ACS Certificate] ページの [Certificate] ファイル ボックスにファイル名が表示されます。


ヒント ファイル転送中にエラーが発生した場合は、右側のペインにエラーが表示されます。


ステップ 6 ACS を使用して要求を生成した場合は、[Download private key file] リンクをクリックします。

[Download Private Key File] ページが表示されます。

ステップ 7 秘密鍵ファイルを ACS にダウンロードするには、[Download File] テーブルに次の情報を入力します。

a. [FTP Server] ボックスに、ダウンロードする秘密鍵ファイルが格納されている FTP サーバの IP アドレスまたはホスト名を入力します。


ヒント ホスト名を指定する場合、DNS がネットワーク上で正常に動作している必要があります。


b. [Login] ボックスに、ACS が FTP サーバへのアクセスに使用できる有効なユーザ名を入力します。

c. [Password] ボックスに、[Login] ボックスで指定したユーザ名のパスワードを入力します。

d. [Remote FTP Directory] ボックスに、ACS が FTP サーバからダウンロードする秘密鍵ファイルが含まれているディレクトリのパスを、FTP サーバのルート ディレクトリからの相対パスで入力します。

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

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

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


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


ステップ 9 ACS を使用して要求を生成した場合は、秘密鍵を含むファイルのフル ディレクトリ パスと名前を [Private key file] ボックスに入力します。


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



ヒント この秘密鍵は、サーバ証明書に関連した秘密鍵です。


ステップ 10 [Private key password] ボックスに、秘密鍵のパスワードを入力します。

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

秘密鍵ファイルがダウンロードされ、[Install ACS Certificate] ページの [Private key file] ボックスにファイル名が表示されます。


ヒント ファイル転送中にエラーが発生した場合は、右側のペインにエラーが表示されます。


ステップ 12 [Private key password] ボックスに、秘密鍵のパスワードを入力します。


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


ステップ 13 [Submit] をクリックします。

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

[Issued to: certificate subject ]

[Issued by: CA common name ]

[Valid from:]

[Valid to:]

[Validity:]


 

認証局証明書の追加

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

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

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

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

ACS for Windows


ステップ 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 が信頼できることを指定する必要があります。詳細については、「証明書信頼リストの編集」を参照してください。



 

ACS SE


) CA 証明書は FTP サーバからダウンロードする必要があります。



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

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

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

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

ステップ 4 FTP サーバから証明書をダウンロードするには、次の手順を実行します。

a. FTP の IP アドレスを入力します。

b. 証明書がある場所のパスを入力します。

c. サーバにログインしてパスワードを入力します。

d. ディレクトリの格納場所から証明書ファイルをダウンロードします。

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

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

秘密鍵ファイルがダウンロードされて、[Install ACS Certificate] ページの [Private key file] ボックスにファイル名が表示されます。


ヒント ファイル転送中にエラーが発生した場合は、右側のペインにエラーが表示されます。


ステップ 7 [Private key password] ボックスに、秘密鍵のパスワードを入力します。

ステップ 8 [Submit] をクリックします。

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


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



 

証明書信頼リストの編集

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

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

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

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

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


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

ステップ 2 [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 Issuers] ページに、選択した証明書信頼リストが自動的に表示されます。


 

証明書信頼リストからの証明書の削除

証明書信頼リストから証明書を削除するには、次の手順を実行します。


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

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

ステップ 3 [Delete Certificate from Certificate Trust List] をクリックします。

削除可能な証明書信頼リストの一覧が表示されます。

ステップ 4 [Submit] をクリックします。

選択した CA 証明書が、ローカル証明書ストレージから削除されます。


 

証明書失効リストの管理

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

ここでは、次の項目について説明します。

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

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

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

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

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

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

ACS の CRL 機能は、次のとおりです。

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

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


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


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

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

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

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

[Name]:CA 発行元によって与えられた名前。

[Description]:この CRL 発行元に関する説明。

[CRL Distribution URL]:ACS が CRL の取得に使用する URL。CA 証明書に CRL distribution points パラメータが含まれている場合、このフィールドには自動的にデータが入力されます。CA 証明書にこのパラメータが含まれていない場合は、[Issuer's Certificate] リストから選択した CA に対応する CRL 用の URL を指定してください。HTTP、LDAP、または FTP を使用する URL を指定できます。あるいは、ファイル自体の URL を指定することもできますが、それが必要になるのは、リポジトリ URL に複数のファイルが示されている場合だけです。

HTTP の URL の例を次に示します。

http://crl.verisign.com/pca1.1.1.crl

LDAP の URL の例を次に示します。

ldap://10.36.193.5:388/CN=development-CA,CN=acs-westcoast2,CN=CDP,CN=Public Key Services,CN=Services,CN=Configuration,DC=cisco,DC=com


) LDAP では、CRL のデフォルトの位置は objectclass=crlDistributionPoint の下です。ACS は、オブジェクト クラス情報を URL に追加します。CRL が別の場所にある場合は、オブジェクト クラスを URL に追加する必要があります。たとえば、CRL が objectclass=CertificateRevocationList の下にある場合、URL を ldap://10.36.193.5:388/CN=development-CA,CN=acs-westcoast2,CN=CDP,CN=Public Key Services,CN=Services,CN=Configuration,DC=cisco,DC=com?(objectclass=
CertificateRevocationList
) とする必要があります。



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


[Retrieve CRL]:ACS は最初に CA から CRL をダウンロードしようとします。CRL が正常にダウンロードされた後、インストール ディレクトリに CRL のフォルダおよびファイルが作成されます。CRL 発行元は変更できません。CRL ファイルの [Next Update] フィールドには、次回のアップデート用の値が含まれています。ACS が CRL の取得に使用する方法を選択します。

[Automatically]:CRL ファイルの [Next Update] フィールド内の値を使用して、CA から新しい CRL を取得します。取得に失敗した場合、ACS は最初の失敗から 10 分おきに、成功するまで CRL の取得を試みます。

[Every]:取得試行の頻度を指定します。時間間隔を入力します。


) 自動 CRL 取得機能を使用する場合は、EAP-TLS をイネーブルにしていることを確認してください。



) どちらのモードでも、取得に失敗すると、10 分おきに再試行されます。


[Last Retrieve Date]:このエントリには、最後に CRL の取得を実行または試行したときのステータス、日付、および時刻が示されます。

[Options]:期限切れの CRL に照らして証明書をチェックするには、[Ignore Expiration Date] チェックボックスをオンにします。

[Ignore Expiration Date] がオフの場合、ACS は、CRL ファイルの [Next Update] フィールドで CRL の有効期限を調べ、CRL の有効期限が切れていてもその CRL を使用し続けます。有効期限が切れている場合、CRL は有効でないため、すべての EAP-TLS 認証は拒否されます。

[Ignore Expiration Date] がオンの場合、ACS は期限切れの CRL を使用し続け、CRL の内容に従って EAP-TLS 認証を許可または拒否します。

[CRL is in Use]:オンの場合、CRL はアクティブで、EAP-TLS 認証プロセスに使用されます。

[Submit]:CRL をダウンロードして発行元の公開鍵で確認するには、[Submit] をクリックします。矛盾がある場合は [CRL Issuer Configuration] エラーが生成されます。

送信に成功した場合は、ACS を再起動して新しい設定を適用する必要があります。

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

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


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

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

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

[CRL Issuers] ページが表示されます。

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

選択した CRL 発行元の [CRL Issuer Edit] ページが表示されます。

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

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

ACS で、対応する CRL が、編集した発行元の CRL に変更されます(または、[Retrieve CRL] フィールドに指定した時刻に変更されるようにスケジューリングされます)。


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



 

証明書署名要求の生成

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


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


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


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

ステップ 2 [ACS Certificate Setup] を選択し、[Generate Certificate Signing Request] を選択します。

[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

表 9-3 では、[Certificate subject] ボックスに組み込むことができる有効なフィールドを定義しています。

 

表 9-3 [Certificate Subject] のフィールド

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

CN

commonName

1

64

はい

OU

organizationalUnitName

--

--

いいえ

O

organizationName

--

--

いいえ

S

stateOrProvinceName

--

--

いいえ

C

countryName

2

2

いいえ

E

emailAddress

0

40

いいえ

L

localityName

--

--

いいえ

ステップ 4 [Private key file] ボックスで、次の手順を実行します。

ACS for Windows:秘密鍵を保存するファイルのフル ディレクトリ パスと名前(たとえば、 c:¥privateKeyFile.pem )を入力します。

ACS SE:秘密鍵を保存するファイルの名前(たとえば 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] をクリックします。

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

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

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


 

自己署名証明書の使用

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

ここでは、次の項目について説明します。

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

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

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

自己署名証明書について

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

自己署名証明書のインストールでは、証明書を取得する際に CA と連携しないことを除き、その他のデジタル証明書と同じユーザ アクションが必要になります。ACS は自己署名証明書の複製をサポートしていませんが、複数の ACS で使用するために証明書をエクスポートすることができます。

ACS for Windows

自己署名証明書の作成をイネーブルにするには、証明書ファイル( .cer 形式)と対応する秘密鍵ファイル( .pvk 形式)を、他の ACS にコピーします。これにより、通常の方法で証明書をインストールできます。証明書のインストールの詳細については、「ACS サーバ証明書のインストール」を参照してください。

ACS SE

自己署名証明書の作成をイネーブルにするには、証明書ファイル( .cer 形式)と対応する秘密鍵ファイル( .pvk 形式)を転送する FTP サーバを指定する必要があります。他の ACS は FTP サーバから証明書を取得して、標準的な方法でインストールすることができます。証明書のインストールの詳細については、「ACS サーバ証明書のインストール」を参照してください。

プラットフォーム共通

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

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

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

[Certificate subject]: cn= というプレフィクスが付けられた証明書の件名。これには 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]:作成する証明書ファイル。このページを送信すると、ACS は、指定された場所とファイル名を使用して証明書ファイルを作成します。

ACS for Windows:ファイルのフル ディレクトリ パスと名前(たとえば、 c:¥acs_server_cert¥acs_server_cert.cer )を入力します。

ACS SE:ファイルの名前だけ(たとえば、 acs_server_cert.cer )を入力します。

[Private key file]:作成する秘密鍵ファイル。このページを送信すると、ACS は、指定された場所とファイル名を使用して秘密鍵ファイルを作成します。

ACS for Windows:ファイルのフル ディレクトリ パスと名前(たとえば、 c:¥acs_server_cert¥acs_server_cert.pvk )を入力します。

ACS SE:ファイルの名前だけ(たとえば、 acs_server_cert.pvk )を入力します。

[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] をクリックしたときに、生成した自己署名証明書が ACS でインストールされるようにするには、このチェックボックスをオンにします。このオプションをオンにした場合は、新しい設定を有効にするため、ページを送信した後に ACS サービスを再起動する必要があります。このオプションをオフにした場合は、証明書ファイルと秘密鍵ファイルが生成され保存されますが、ローカル マシン ストレージにはインストールされません。

次のオプションは、ACS SE のみに適用されます。

[Generate Self-Signed Certificate edit] ページには、証明書ファイルとそれに対応する秘密鍵ファイルを転送する FTP サーバの指定に使用する必須の設定フィールドもあります。

[FTP Server]:証明書ファイルと対応する秘密鍵ファイルが転送される FTP サーバの IP アドレスまたはホスト名。ホスト名を指定する場合は、DNS がネットワーク上で有効になっており、シリアル コンソールに正しく設定されている必要があります。

[Login]:ACS から FTP サーバへのアクセスを可能にする有効なユーザ名です。


ヒント [Login] ボックスは、DOMAIN\username 形式でドメイン修飾ユーザ名を受け入れます。これは、Microsoft FTP サーバを使用している場合に必要です。


[Password]:[Login] ボックスに入力されたユーザ名のパスワードです。

[Remote Directory]:ファイルの転送先のディレクトリです。ディレクトリは、FTP ルート ディレクトリから相対的に指定する必要があります。

自己署名証明書の生成

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

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


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

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

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

[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] オプションを選択する場合は、新しい設定を有効にするため、このフォームの送信後に ACS サービスを再起動する必要があります。



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


ステップ 12 ACS SE:[FTP Server] ボックスに、証明書ファイルと対応する秘密鍵ファイルの転送先になる FTP サーバの IP アドレスまたはホスト名を入力します。


ヒント ホスト名を指定する場合、DNS がネットワーク上で正常に動作している必要があります。


ステップ 13 ACS SE:[Login] ボックスに、ACS が FTP サーバへのアクセスに使用できる有効なユーザ名を入力します。

ステップ 14 ACS SE:[Password] ボックスに、[Login] ボックスで指定したユーザ名のパスワードを入力します。

ステップ 15 ACS SE:[Remote FTP Directory] ボックスに、ACS が FTP サーバに証明書ファイルと対応する秘密鍵ファイルを転送するディレクトリのパスを、FTP サーバのルート ディレクトリからの相対パスで入力します。

ステップ 16 [Submit] をクリックします。

指定した証明書ファイルと秘密鍵ファイルが生成され、保存されます。[Install generated certificate] オプションを選択した場合は、ACS サービスを再起動後に初めて証明書が有効になります。


 

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

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


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

新しい ACS 証明書をインストールするには、次の手順を実行します。


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

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

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


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


ステップ 3 [Install New Certificate] をクリックします。

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

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

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

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


 

EAP-FAST PAC ファイルの生成(ACS SE)

[EAP-FAST PAC Files Generation] ページを使用して、手動の PAC プロビジョニング用の PAC ファイルを作成できます。

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

ここでは、次の項目について説明します。

「PAC ファイルの生成オプション」

「PAC ファイルの生成」

PAC ファイルの生成オプション

PAC ファイルを生成するときには、次のオプションを使用できます。

[Specific user]:ACS は [User Name] ボックスに入力したユーザ名の PAC ファイルを生成します。たとえば、このオプションを選択して [User Name] ボックスに seaniemop と入力した場合、ACS は seaniemop.pac という名前の PAC ファイルを 1 つ生成します。


ヒント DOMAIN\username の形式で、ドメイン修飾されたユーザ名を指定することもできます。たとえば、ENIGINEERING\augustin と指定すると、ACS によって ENGINEERING_augustin.pac という名前の PAC ファイルが生成されます。


[Users from specific ACS group]:ACS は、ACS グループ リストに指定されているユーザ グループ内の各ユーザに対して PAC ファイルを生成します。ACS には 0 ~ 499 の番号が付けられた 500 のグループがあります。たとえば、グループ 7 に、43 人のユーザがいるとします。このオプションを選択して、ACS グループ リストから グループ 7 を選択すると、ACS は、グループ 7 のメンバーである各ユーザに 1 つずつ、合計 43 の PAC ファイルを生成します。各 PAC ファイルには、次の形式で名前が付けられます。

username.pac (特定のユーザの名前)


) 特定のグループ内のユーザに対して PAC ファイルを生成すると、CSAuth サービスが再起動します。CSAuth が使用できない間、ユーザ認証は行われません。



ヒント 複数のユーザ グループに PAC ファイルを生成するには、各グループに対して別々に PAC ファイルを生成します。たとえば、グループ 7 ~ 10 のユーザに PAC ファイルを生成するには、PAC ファイルを 4 回生成し、それぞれでグループ 7、8、9、10 を指定します。


[All users in ACS internal DB]:ACS は、ACS 内部データベース内の各ユーザに対して PAC ファイルを生成します。たとえば、ACS 内部データベースに 3278 人のユーザがいる場合に、このオプションを選択すると、ACS は各ユーザに 1 ファイル、合計 3278 の PAC ファイルを生成します。各 PAC ファイルには、次の形式で名前が付けられます。

username.pac

) ACS 内部データベース内のすべてのユーザに対して PAC ファイルを生成すると、CSAuth サービスが再起動します。CSAuth が使用できない間、ユーザ認証は行われません。


[Users from list]:ACS は、指定した FTP サーバから取得したファイルに含まれている各ユーザ名に対して PAC ファイルを生成します。

ユーザ名のリストには、行ごとに 1 つのユーザ名を入力し、追加のスペースや他の文字は使用しません。

たとえば、FTP サーバから取得したリストに次のユーザ名が含まれている場合。

seaniemop
jwiedman
echamberlain

ACS は 3 つの PAC ファイル、 seaniemop.pac、jwiedman.pac、echamberlain.pac を生成します。


ヒント DOMAIN\username の形式で、ドメイン修飾されたユーザ名を指定することもできます。たとえば、ENIGINEERING\augustin と指定すると、ACS は ENGINEERING_augustin.pac という名前の PAC ファイルを生成します。


ユーザ名リストを取得するためのオプションは次のとおりです。

[FTP Server]:[User list file] ボックスで指定したファイルがある FTP サーバの IP アドレスまたはホスト名。ホスト名を指定する場合は、DNS がネットワーク上でイネーブルになっており、ACS SE コンソールに正しく設定されている必要があります。ACS の IP 設定の詳細については、『 Installation and Setup Guide for Cisco Secure ACS Solution Engine 』を参照してください。

[Login]:ACS から FTP サーバへのアクセスを可能にする有効なユーザ名。


ヒント [Login] ボックスは、DOMAIN\username 形式でドメイン修飾ユーザ名を受け入れます。これは、Microsoft FTP サーバを使用している場合に必要です。


[Password]:[Login] ボックスにあるユーザ名のパスワード。

[Remote Directory]: Users list file ボックス内にあるユーザ名のファイルを含んでいるディレクトリ。ディレクトリは、FTP ルート ディレクトリから相対的に指定する必要があります。たとえば、ユーザ名ファイルが、FTP ルート ディレクトリのサブディレクトリである paclist というディレクトリにある場合は、[Remote Directory] ボックスに paclist と入力します。


ヒント FTP のルート ディレクトリを指定するには、ピリオド、つまり「ドット」(.)を 1 つ入力します。


[Users list file]:ユーザ名リストのファイル名。たとえば、ユーザ名ファイルの名前が eapfastusers.txt の場合は、[User list file] ボックスに eapfastusers.txt と入力します。

[Encrypt PAC file(s) with]:各 PAC ファイルは、ACS およびエンドユーザ クライアントに既知のデフォルトのパスワードまたはユーザが指定するパスワードを使用して、常に暗号化されます。PAC ファイルを暗号化することで、不正なユーザが盗んだ PAC ファイルを使用してネットワークにアクセスするのを防ぐことができます。デフォルトのパスワードは強力なパスワードですが、すべての ACS および EAP-FAST のエンドユーザ クライアントが使用しています。

ACS およびすべての EAP-FAST エンドユーザ クライアント:


) パスワードは、デフォルトではなくユーザが指定するパスワードを使用することを推奨します。


[Default password]:ACS はデフォルトのパスワードを使用して、生成する PAC ファイルを保護します。


) パスワードは、デフォルトではなくユーザが指定するパスワードを使用することを推奨します。


[This password]:ACS はデフォルトのパスワードではなく、指定したパスワードを使用して、生成する PAC ファイルを保護します。指定するパスワードは、ACS が保護する PAC が EAP-FAST エンドユーザ クライアントにロードされる場合に必要になります。

PAC パスワードは大文字と小文字を区別して、4 ~ 128 文字の英数字で指定します。ACS は強力なパスワード規則は適用していませんが、強力なパスワードを使用することを推奨します。つまり、PAC パスワードは次のようにする必要があります。

非常に長い。

大文字と小文字を使用している。

文字のほかに数字も使用している。

一般的な単語や名前は使用していない。

PAC ファイルの生成

ACS に PAC ファイルを生成するように指示を出すたびに、ACS は PACFiles.cab という名前のキャビネット ファイルを 1 つ作成します。このファイルは、HTML インターフェイスにアクセスするために使用するブラウザからアクセスできる場所にダウンロードします。任意のファイル圧縮ユーティリティを使用して、 PACFiles.cab ファイルから .pac ファイルを抽出します。たとえば、 WinZip は、キャビネット ファイルからファイルを抽出できます。

始める前に

ACS では、EAP-FAST がイネーブルな場合にのみ PAC ファイルを生成できます。EAP-FAST をイネーブルにする方法については、「EAP-FAST のイネーブル化」を参照してください。

PAC ファイルを生成する対象のユーザを決定します。ユーザをテキスト ファイルで指定する場合は、テキスト ファイルを作成し、ACS SE からアクセス可能な FTP サーバの FTP ルート ディレクトリの下にあるディレクトリに配置します。ユーザ名リストの使用方法については、「PAC ファイルの生成オプション」を参照してください。

[EAP-FAST PAC Generation] ページのオプションについては、「PAC ファイルの生成オプション」を参照してください。

PAC ファイルを生成するには、次の手順を実行します。


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

ステップ 2 [EAP-FAST PAC Files Generation] をクリックします。

[EAP-FAST PAC Files Generation] ページが表示されます。

ステップ 3 4 つあるオプションのいずれかを使用して、ACS が PAC ファイルを生成する対象のユーザを指定します。オプションの意味の詳細については、「PAC ファイルの生成オプション」を参照してください。


) 特定のグループの ACS 内部データベース内のすべてのユーザに PAC ファイルを生成すると、CSAuth サービスが再起動します。CSAuth が使用できない間は、ユーザ認証は行われません。


ステップ 4 [Submit] をクリックします。

指定したユーザ(複数可)の PAC ファイルの生成が開始されます。[Users from list] オプションを使用する場合、ACS はまず指定した FTP サーバからリストを取得します。

[EAP-FAST PAC Files Generation] ページに、 C urrent PAC CAB ファイルの生成ステータス メッセージが表示されます。

 

ステップ 5 Current PAC CAB ファイル生成ステータスに、「CAB file generation is in progress」と表示されている場合は、Current PAC CAB ファイル生成ステータスに、「CAB file is ready」と表示されるまで、[Refresh] を何回かクリックします。[Download] を押して、ファイルを取得します。

指定したユーザの数に応じて、PAC ファイルの生成には数秒から数分かかります。

ステップ 6 Current PAC CAB ファイル生成ステータスに、「CAB file is ready, Click Download to retrieve the file」と表示されたら、[download] をクリックします。


) ファイルのダウンロード オプションは、使用している Web ブラウザによって異なりますが、基本的な手順は次のようになります。


[File Download] ダイアログボックスが表示されます。

ステップ 7 [File Download] ダイアログボックスで、[Save] をクリックします。

[Save As] ダイアログボックスが表示されます。

ステップ 8 [Save As] ダイアログボックスを使用して、 PACFiles.cab ファイルを保存する場所、およびファイル名を指定します。次に [Save] をクリックします。

ACS が PACFiles.cab ファイルを Web ブラウザに送信し、指定した場所にファイルが保存されます。ダウンロードが完了すると、[Download Complete] ダイアログボックスが表示されます。

ステップ 9 PACFiles.cab ファイルの場所を書き留めて、[Close] をクリックします。

ステップ 10 任意のファイル圧縮ユーティリティを使用して、 PACFiles.cab ファイルから PAC ファイルを抽出します。


 

[Advanced System Configuration] ページ リファレンス

ここでは、次の内容について説明します。

「[Global Authentication Setup] ページ」

「[EAP-FAST Configuration] ページ」

「[Cipher Suite Configuration] ページ」

[Global Authentication Setup] ページ

このページで、さまざまな認証プロトコルの設定を指定します。

このページを表示するには、[System configuration] > [Global Authentication Setup] を選択します。

 

フィールド
説明

EAP Configuration

PEAP は証明書ベースの認証プロトコルです。認証が行われるのは、[ACS Certificate Setup] ページで必要な手順を完了した場合に限られます。

PEAP

PEAP タイプを選択します。ほとんどの場合、EAP を指定する 3 つのボックスすべてをオンにする必要があります。1 つも選択しない場合、認証に PEAP は許可されません。

Allow EAP-MSCHAPv2

これをオンにして、PEAP クライアントを使って EAP-MS-CHAPv2 認証を試みるように指定します。

(注) このボックスをオンにすると、ACS は、EAP タイプについてエンドユーザ PEAP クライアントとネゴシエートします。

Allow EAP-GTC

PEAP クライアントを使用して EAP-GTC 認証を試みるように指定するには、これをオンにします。

Allow Posture Validation

Network Admission Control(NAC:ネットワーク アドミッション コントロール)クライアントのポスチャ確認に PEAP を使用できるようにするには、これをオンにします。

Allow EAP-TLS

PEAP クライアントを使用して EAP-TLS 認証を試みるように指定するには、これをオンにします。このチェックボックスをオンにする場合、1 つ以上の EAP-TLS 比較方式を選択します。

[Certificate SAN comparison]:ACS がユーザ ID を確認する場合に、エンドユーザ証明書の [Subject Alternative Name] フィールド内の名前を、該当するユーザ データベース内のユーザ名と比較するようにするには、このチェックボックスをオンにします。

[Certificate CN comparison]:ACS がユーザ ID を確認する場合に、エンドユーザ証明書の [Common Name] フィールド内の名前を、該当するユーザ データベース内のユーザ名と比較するようにするには、このチェックボックスをオンにします。

[Certificate Binary comparison]:ACS がユーザ ID を確認する場合に、エンドユーザ証明書と、Active Directory に格納されているユーザ証明書とのバイナリ比較を行うようにするには、このチェックボックスをオンにします。

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

EAP_TLS Session Timeout 値、Cisco クライアント初期メッセージ、PEAP セッション タイムアウトを指定し、高速再接続をイネーブルにするかどうかを示します。

[EAP-TLS session timeout (minutes)]:EAP-TLS セッションの最大時間を定義する値(分単位)を入力します。

ACS は、新しい EAP-TLS 認証中に作成された TLS セッションをキャッシュする EAP-TLS セッション再開機能をサポートしています。EAP-TLS クライアントが再接続すると、証明書比較を行わずに、キャッシュされた TLS セッションを使用してセッションが復元されます。これにより EAP-TLS のパフォーマンスが向上します。ACS は、キャッシュされた TLS セッションがタイムアウトになると、セッションを削除します。ACS またはエンドユーザ クライアントを再起動した場合は、セッション タイムアウト間隔に達していなくても、証明書の比較が必要になります。セッション再開機能をディセーブルにするには、タイムアウト値をゼロ(0)に設定します。

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

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

[Enable Fast Reconnect]:MS PEAP 認証のフェーズ 2 を実行せずに MS PEAP クライアントのセッションを再開する場合は、このチェックボックスをオンにします。このチェックボックスをオフにすると、PEAP セッションがタイムアウトしていない場合でも、MS PEAP 認証のフェーズ 2 が実行されます。

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

EAP-FAST

[EAP-FAST Configuration]:選択すると、「[EAP-FAST Configuration] ページ」が開きます。

(注) ACS を使用して NAC を実装する場合は、各オプションをイネーブルにしてから [Submit] をクリックします。ページが再表示されたら、[EAP-FAST Configuration] を選択して [EAP-FAST Settings] ページを開きます。

EAP-TLS Configuration

EAP-TLS 認証プロトコルを使用する場合、および EAP-TLS 設定値を設定する場合は、このボックスをオンにします。エンドユーザ クライアントからの EAP Identity 応答で提示されたユーザ ID を ACS が確認する方法を指定できます。ユーザ ID は、エンドユーザ クライアントによって提示された証明書の情報に照らして確認されます。この比較は、ACS とエンドユーザ クライアントとの間に EAP-TLS トンネルが確立された後に行われます。

(注) EAP-TLS は、証明書ベースの認証プロトコルです。EAP-TLS 認証が行われるのは、[ACS Certificate Setup] ページで必要な手順を完了した場合に限られます。詳細は「ACS サーバ証明書のインストール」を参照してください。

このチェックボックスをオンにして EAP-TLS をイネーブルにする場合、1 つ以上の EAP-TLS 比較方式を選択します。その方式は次のとおりです。

[Certificate SAN comparison]:ACS がユーザ ID を確認する場合に、エンドユーザ証明書の [Subject Alternative Name] フィールド内の名前を、該当するユーザ データベース内のユーザ名と比較するようにするには、このチェックボックスをオンにします。

[Certificate CN comparison]:ACS がユーザ ID を確認する場合に、エンドユーザ証明書の [Common Name] フィールド内の名前を、該当するユーザ データベース内のユーザ名と比較するようにするには、このチェックボックスをオンにします。

[Certificate Binary comparison]:ACS がユーザ ID を確認する場合に、エンドユーザ証明書と、Active Directory に格納されているユーザ証明書とのバイナリ比較を行うようにするには、このチェックボックスをオンにします。

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

EAP_TLS Session Timeout 値、Cisco クライアント初期メッセージ、PEAP セッション タイムアウトを指定し、高速再接続をイネーブルにするかどうかを示します。

[EAP-TLS session timeout (minutes)]:EAP-TLS セッションの最大時間を定義する値(分単位)を入力します。

ACS は、新しい EAP-TLS 認証中に作成された TLS セッションをキャッシュする EAP-TLS セッション再開機能をサポートしています。EAP-TLS クライアントが再接続すると、証明書比較を行わずに、キャッシュされた TLS セッションを使用してセッションが復元されます。これにより EAP-TLS のパフォーマンスが向上します。ACS は、キャッシュされた TLS セッションがタイムアウトになると、セッションを削除します。ACS またはエンドユーザ クライアントを再起動した場合は、セッション タイムアウト間隔に達していなくても、証明書比較が必要になります。セッション再開機能をディセーブルにするには、タイムアウト値をゼロ(0)に設定します。

Select one of the following options for setting username during authentication.

EAP-TLS 認証ハンドシェイク完了後に、ACS が認証要求を送信するときに使用するユーザ ID を指定できます。このオプションは、選択した ID を基にデータベース内のユーザを検索するために使用します。デフォルトでは、EAP-TLS 認証には外部 ID が使用されます。次のオプションのいずれかを選択します。

[Use Outer Identity]:外部 ID がデータベース内で検索するユーザ名として使用されます。

[Use CN as Identity]:証明書名がデータベース内で検索するユーザ名として使用されます。

[Use SAN as Identity]:ユーザ証明書の Subject Alternative Name がデータベース内で検索するユーザ名として使用されます。

(注) SAN および CN の外部 ID は、EAP TLS マシンの認証には使用できません。

LEAP

[Allow LEAP (For Aironet only)] チェックボックスにより、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

EAP ベースの Message Digest 5 ハッシュ認証をイネーブルにするには、このチェックボックスをオンにします。

Allow EAP request timeout (seconds)

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

EAP カンバセーション中、ACS は IETF RADIUS Session-Timeout (27) アトリビュートを使用して [AP EAP request timeout] ボックスで定義された値を送信します。

(注) 同じ設定が、Cisco Airespace ワイヤレス LAN コントローラと IOS アクセス ポイントに適用されます。これらのデバイスには、ACS セッション タイムアウト設定を上書きする設定オプションもあります。

MS-CHAP Configuration

RADIUS 認証の場合、ACS は MS-CHAP バージョン 1 と 2 をサポートしています。AAA プロトコルが RADIUS である場合は、ACS が MS-CHAP を使用してユーザを認証するかどうか、認証する場合はどのバージョンの MS-CHAP を使用するかを設定できます。

RADIUS ベースの認証で MS-CHAP をイネーブルにするには、使用する MS-CHAP バージョンに対応するチェックボックスをオンにします。どちらのバージョンの MS-CHAP も使用できるようにするには、両方のチェックボックスをオンにします。

RADIUS ベースの認証で MS-CHAP をディセーブルにするには、両方のチェックボックスをオフにします。

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

Cipher Suite Configuration

このオプションを使用して、EAP-Tls および PEAP のハンドシェイク認証時に使用する暗号スイートの順序を設定できます。

[EAP-FAST Configuration] ページ

このページで、EAP-FAST 認証設定を設定します。

このページを表示するには、[System configuration] > [Global Authentication Setup] > [EAP-FAST Configuration] を選択します。

 

フィールド
説明

Allow EAP-FAST

ACS が EAP-FAST 認証を許可するかどうか。

Active master key TTL

マスター キーが新規 PAC の生成に使用される期間。マスター キーが新規 Protected Access Credentials(PAC)の生成に使用される期間の値を入力します。マスター キーに定義されている存続可能時間(TTL)が満了すると、マスター キーは非アクティブであると見なされ、新規マスター キーが生成されます。デフォルトのマスター キー TTL は 1 か月です。マスター キーは、マスター キー TTL と非アクティブ マスター キー TTL の合計よりも古くなると期限切れになるので、マスター キー TTL を少なくすると、非アクティブ マスター キーが期限切れになりやすくなります。そのため、マスター キー TTL を少なくすると、新しく期限切れになったマスター キーに基づく PAC を持つエンドユーザ クライアントに対して PAC プロビジョニングが必要になります。マスター キーの詳細については、「マスター キーについて」を参照してください。

Retired master key TTL

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

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

Tunnel PAC TTL

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

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

Client initial display message

EAP-FAST クライアントで認証されたユーザに送信するメッセージを指定します。最大長は 40 文字です。ユーザに初期メッセージが示されるのは、エンドユーザ クライアントがその表示をサポートしている場合だけです。

Authority ID Info

この ACS サーバに関する説明のテキストであり、エンド ユーザは、このテキストを使用して、認証を受ける ACS サーバを特定できます。このフィールドの入力は必須です。

Allow full TLS renegotiation in case of Invalid PAC

このチェックボックスをオンにしている場合、PAC が無効なために SSL トンネルの確立が失敗したことを ACS が検出すると、完全な TLS 再ネゴシエーションにフォールバックします。

Allow anonymous in-band PAC provisioning

ACS が、EAP-FAST フェーズ 0 を使用してエンドユーザ クライアントに PAC をプロビジョニングします。このチェックボックスをオンにすると、ACS は、エンドユーザ クライアントに新規 PAC を提供するために、そのクライアントとの安全な接続を確立します。

Enable anonymous TLS renegotiation

このオプションでは、エンドユーザ クライアントと ACS の間で匿名の TLS ハンドシェイクが可能になります。フェーズ 0 の内部方式として EAP-MS-CHAP だけが使用されます。

Allow authenticated in-band PAC provisioning

ACS が、SSL サーバ側の認証とともに EAP-FAST フェーズ 0 を使用してエンドユーザ クライアントに PAC をプロビジョニングします。このオプションを選択する場合は、ACS にサーバ証明書と信頼できるルート CA がインストールされている必要があります。許可されている内部方式の 1 つがユーザの認証に使用されます。

さらに、クライアントがその証明書をサーバに送信することにより、相互 TLS 認証を実行できます。この場合、ACS は内部方式をスキップして PAC をプロビジョニングします。

Accept client on authenticated provisioning

このオプションは、[Allow authenticated in-band PAC provisioning] オプションが選択されている場合にだけ使用できます。サーバがプロビジョニング フェーズの終わりに必ず Access-Reject を送信するため、クライアントはトンネル PAC を使用して再認証を受ける必要があります。このオプションでは、ACS がプロビジョニング フェーズの終わりにクライアントに Access-Accept を送信できます。

Require client certificate for provisioning

証明書に基づく PAC プロビジョニングだけを許可します。PAC プロビジョニング用の他の内部 EAP 方式は許可されません。最初の TLS ハンドシェイク中にクライアントが証明書を提示しない場合、サーバは TLS 再ネゴシエーションを開始します。再ネゴシエーションで、クライアントは、新しい TLS ハンドシェイクを開始するよう要求されます。最初のハンドシェイクでネゴシエートされた暗号方式により、新しいハンドシェイクが保護されます。2 番目の TLS ハンドシェイク中に、サーバはクライアントの証明書を要求します。証明書が送信されない場合、ハンドシェイクは失敗し、ユーザはアクセスを拒否されます。

When receiving client certificate, select one of the following lookup methods:

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

[Certificate SAN comparison]:エンドユーザ証明書の [Subject Alternative Name] フィールド内の名前を、該当するユーザ データベース内のユーザ名と比較してユーザ ID を確認するには、このチェックボックスをオンにします。

[Certificate CN comparison]:エンドユーザ証明書の [Common Name] フィールド内の名前を、該当するユーザ データベース内のユーザ名と比較してユーザ ID を確認するには、このチェックボックスをオンにします。

Allow Machine Authentication

ACS が、エンドユーザ クライアントにマシン PAC をプロビジョニングし、マシン認証を実行します(マシン クレデンシャルを持たないエンドユーザ クライアントの場合)。マシン PAC は、要求(インバンド)によって、または管理者(アウトオブバンド)によって、クライアントにプロビジョニングできます。ACS がエンドユーザ クライアントから有効なマシン PAC を受信すると、その PAC からマシン ID の詳細が抽出され、ACS データベースまたは外部データベースで確認されます。その詳細が正しいことが確認されると、その後の認証は実行されません。

(注) [Required] チェックボックスまたは [Posture Only] チェックボックスがオンになっている場合は、マシン認証の実行後、ACS はポスチャ クレデンシャルも要求します。

Machine PAC TTL

マシン PAC を使用するために受け入れることができる期間の値を入力します。ACS は、期限切れのマシン PAC を受け取ると、(エンドユーザ クライアントからの新規マシン PAC 要求を待たずに)エンドユーザ クライアントに新規マシン PAC を自動的に再プロビジョニングします。

Allow Stateless session resume

次の場合は、このオプションをオフにします。

ACS が EAP-FAST クライアントに認可 PAC をプロビジョニングしないようにする場合

EAP-FAST のフェーズ 2 を常に実行する場合

Authorization PAC TTL

このオプションにより、ユーザ認可 PAC の有効期限が決まります。ACS が期限切れの認可 PAC を受信すると、[Allow Stateless session resume] が失敗するため、フェーズ 2 の EAP-FAST 認証が実行されます。

Allowed inner methods

このオプションにより、EAP-FAST TLS トンネル内で実行できる内部 EAP 方式が決まります。匿名インバンド プロビジョニングを実行する場合は、下位互換性を確保するために EAP-GTC と EAP-MS-CHAP をイネーブルにする必要があります。[Allow anonymous in-band PAC provisioning] を選択した場合は、EAP-MS-CHAP(フェーズ 0)および EAP-GTC(フェーズ 2)を選択する必要があります。[Allow authenticated in-band PAC provisioning] を選択した場合は、認証フェーズの内部方式をネゴシエートできます (デフォルトでは、フェーズ 0 で EAP-GTC が使用されます)。次の内部方式のうち、1 つまたは複数を選択します。

[EAP-GTC]:EAP FAST 認証で EAP-GTC をイネーブルにするには、このボックスをオンにします。

[EAP-MS-CHAPv2]:EAP FAST 認証で EAP-MS-CHAPv2 をイネーブルにするには、このボックスをオンにします。

[EAP-TLS]:EAP FAST 認証で EAP-TLS をイネーブルにするには、このボックスをオンにします。

(注) ACS は必ず、最初にイネーブルになった EAP 方式を実行します。たとえば、[EAP-GTC] と [EAP-MS-CHAPv2] を選択する場合、最初にイネーブルになる EAP 方式は EAP-GTC です。

Choose one or more of the following EAP-TLS comparison methods:

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

[Certificate SAN comparison]:エンドユーザ証明書の [Subject Alternative Name] フィールド内の名前を、該当するユーザ データベース内のユーザ名と比較してユーザ ID を確認するには、このチェックボックスをオンにします。

[Certificate CN comparison]:エンドユーザ証明書の [Common Name] フィールド内の名前を、該当するユーザ データベース内のユーザ名と比較してユーザ ID を確認するには、このチェックボックスをオンにします。

[Certificate Binary comparison]:エンドユーザ証明書と、Active Directory に格納されているユーザ証明書とのバイナリ比較を行ってユーザ ID を確認するには、このチェックボックスをオンにします。

EAP-TLS session timeout (minutes)

[EAP-TLS session timeout (minutes)]:EAP-TLS セッションの最大時間を定義する値(分単位)を入力します。

ACS は、新しい EAP-TLS 認証中に作成された TLS セッションをキャッシュする EAP-TLS セッション再開機能をサポートしています。EAP-TLS クライアントが再接続すると、証明書比較を行わずに、キャッシュされた TLS セッションを使用してセッションが復元されます。これにより EAP-TLS のパフォーマンスが向上します。ACS は、キャッシュされた TLS セッションがタイムアウトになると、セッションを削除します。ACS またはエンドユーザ クライアントを再起動した場合は、セッション タイムアウト間隔に達していなくても、証明書の比較が必要になります。セッション再開機能をディセーブルにするには、タイムアウト値をゼロ(0)に設定します。

EAP-FAST Master Server

このチェックボックスをオンにすると、ACS は独自のマスター キーを作成し、独自の EAP-FAST 設定と認証局 ID を使用します。このチェックボックスをオフにすると、ACS は、複製された別の(スレーブまたは複製)ACS から受信した EAP-FAST 設定、マスター キー、および認証局 ID を使用します。この設定を変更する場合は、[Submit + Apply] をクリックします。

Actual EAP-FAST server status

このオプションにより、ACS の状態が表示されます。[EAP-FAST Master Server] チェックボックスをオフにした場合、ACS が複製 EAP-FAST 設定を受信するまで、サーバの状態は Slave に変わりません。

のままになります。

[Cipher Suite Configuration] ページ

このページで、必要に応じた暗号スイートの順序を設定します。

このページを表示するには、[System configuration] > [Global Authentication Setup] > [Cipher Suite Configuration] を選択します。

 

フィールド
説明

Note: Enable EAP-TLS or PEAP protocol to use this section.

デフォルトでは、[Cipher Suite Selection] ページのオプションはディセーブルになっています。この注記は、ページ上部に表示されます。このページのオプションをイネーブルにするには、次の手順を実行します。

1. [System Configuration] > [Global Authentication Setup] ページに移動します。

2. EAP-TLS または PEAP をイネーブルにします。少なくとも 1 つのプロトコルをイネーブルにする必要があります。

プロトコルをイネーブルにすると、この注記はページに表示されなくなります。

Let ACS decide the preferred Cipher-Suites

Eap-Tls 認証および PEAP 認証のハンドシェイク フェーズ中に使用する最適な暗号スイートの順序を ACS が決定できるようにするには、このオプションを選択します。この順序は、「強~弱」の形式になります。

Use the list from selected Cipher-Suites

必要に応じた暗号スイートの順序を作成するには、このオプションを選択します。Eap-Tls 認証および PEAP 認証のハンドシェイク中には、ACS により、選択した内容と同じ順序での暗号スイートの検索が実行されます。選択した暗号スイートが、クライアントの暗号スイート リストに 1 つ以上含まれていない場合、ハンドシェイクは失敗します。