EAP-TLS メッセージ交換は、次の表に示すように行われます。

ステップ I：

• スイッチ上で dot1x が有効になっていると、スイッチはサプリカントによるデータの送信を許可せず、EAP アイデンティティ要求を送信します。
• 次にサプリカントは、EAP アイデンティティ レスポンスでオーセンティケータに応答します。
• オーセンティケータは、EAP アイデンティティ レスポンスを RADIUS プロトコルで EAP サーバに転送します。
• EAP サーバは、EAP-TLS 開始パケットをサプリカントに送信します。この時点で EAP-TLS カンバセーションが開始されます。

ステップ II：

• サプリカントは、client_hello ハンドシェイク メッセージを含む EAP 応答を認証サーバに送り返します。

ステップ III：

サーバはサプリカントに証明書を提示するだけでなく、サプリカントから有効な証明書を要求します。認証サーバは、以下を含む EAP 要求パケットで応答します。

server_hello

ハンドシェイク メッセージ

サーバ証明書

server_key_exchange

証明書要求

server_hello_done

ステップ IV

サプリカントは、以下を含む EAP 応答メッセージで応答します。

• クライアント証明書
• client_key_exchange
• certificate_verify：サーバが信頼されていることを確認します。
• change_cipher_spec
• TLS 完了

ステップ V

EAP サーバはクライアント証明書を検証し、暗号仕様とサーバ完了メッセージで応答します。

クライアント証明書の検証に基づいて、EAP サーバは EAP の成功/失敗を送信します。

PEAP メッセージ交換は、次の表に示すように行われます。

EAP-PEAP では、2 つの段階があります。

• TLS トンネルの確立（ステップ I ～ IV）
• 認証メッセージの交換（ステップ V および VI）

ステップ I ～ IV は EAP-TLS の場合と同じです。ただし、大きな違いがステップ 4 にあり、ここではクライアントは自身の証明書をサーバと交換せず、代わりに TLS トンネルを確立します。認証メッセージは、TLS トンネル内で安全に交換できます。TLS トンネルは、暗号仕様の交換によって形成されます。

ステップ V

• トンネルが確立された後、EAP サーバが EAP 要求を送信します。
• サプリカントがセキュアな TLS トンネル内でサーバに EAP 応答フレームを送信します。
• サーバがチャレンジ要求を送信し、サプリカントがチャレンジ応答で応答します。

ステップ VI

• 最後に、EAP サーバがユーザ ID を検証して、RADIUS Access-Accept（または Reject）を送信し、オーセンティケータがそれを EAP-Success（または Failure）に変換します。

サーバの応答（Pass または Fail）に基づいて、オーセンティケータはポートのブロック解除/ブロックを行います。

1. トランク ポート、ダイナミック ポート、またはイーサ チャネル ポートでは 802.1X はサポートされていません。

2. 誤って設定されたクレデンシャル/無効な証明書から回復するためにコントローラから使用できる設定はありません。誤って設定された AP 接続を修正してコントローラに戻すには、スイッチ ポート Dot1x 認証を無効にする必要があります。

3. NEAT/CISP はサポートされません。

4. 証明書失効チェックは AP では実装されません。

5. LSC 証明書は、802.1Xポート認証および CAPWAP join に使用できます。AP 上でダウンロード/プロビジョニングできる LSC 証明書は 1 つだけです（LSC の更新は問題ありません）。802.1X 認証または CAPWAP DTLS 認証のいずれかで LSC が有効になっていない場合は、AP で LSC 証明書を削除する必要があります。

6. イメージ バージョンのダウングレードは、システム管理者が適切に管理する必要があります。802.1X EAP-FAST は 8.6 リリースでサポートされ、EAP-TLS および PEAP サポートが追加されます。イメージが 8.7 から 8.6 にダウングレードされると、デフォルトでは EAP-FAST が AP で起動されます。イメージがダウングレードされると、ISE は EAP-FAST を許可する必要があります。さらに、AP 有線ポートの dot1x サポートの場合、ステージングと展開の 2 つの段階があります。顧客がダウングレードまたはアップグレードを希望している場合は、それに応じてステージを計画する必要があります。

7. AP の設定を消去すると 802.1X 機能が無効になり、AP 上のすべての LSC 証明書が削除されます。802.1X サポートが必要な場合は、AP を再設定して LSC を再プロビジョニングする必要があります（EAP-FAST 以外の方法の場合）。

1. AP 上の 802.1X：DISABLED、スイッチ：DISABLED

   AP が起動し、CAPWAP ディスカバリ プロセスを開始して、コントローラに参加します。これは現在の通常の動作です。

2. AP 上の 802.1X：DISABLED、スイッチ：ENABLED

   AP はコントローラに参加しません。

   AP が起動し、802.1X 認証が有効になっていないので、通常の CAPWAP ディスカバリ プロセスまたは DHCP（DHCP 用に設定されている場合）を開始します。スイッチ ポートで 802.1X 認証が必要なため、トラフィックは AP からスイッチへと通過できません。スイッチ ポートで dot1x 認証が無効になるまで、AP は同じ初期段階にとどまり続けます。

   1. ケース 1：AP にスタティック IP がある

      ローカル モードの AP はディスカバリ状態のままになります

      FlexConnect モードの AP はディスカバリ状態（スタンドアロン モードではない）のままになります

   2. AP に DHCP が設定されている

      ローカル モードの AP は DHCP 要求にとどまります

      FlexConnect モードの AP は DHCP 要求にとどまります

3. AP 上の 802.1X：ENABLED、スイッチ：DISABLED

   AP がコントローラに参加する

   AP が起動し、イーサネット ポートが UP 状態になると、AP WPA サプリカントはスイッチからの EAP アイデンティティ要求を待機し、受信しない場合は EAPOL-START メッセージを開始して再試行します。

   スイッチから EAP 応答を受信しないと、AP は dot1x の開始を中断し、コントローラをディスカバリする通常のプロセスを開始します。

   このシナリオでは、AP は自動的に非 dot1x CAPWAP ディスカバリにフォールバックする必要があります。また、AP WPA サプリカントは、EAP アイデンティティ要求（AP の dot1x が CAPWAP の実行状態で有効になっているが、dot1x を実行していない）があった場合はいつでも、開始ステートに移行し、スイッチで dot1x 認証を開始する必要があります。

4. AP 上の 802.1XS：ENABLED、スイッチ：ENABLED

   AP がコントローラに参加し、ポート認証をポストします

   AP が起動し、イーサネット ポートが UP 状態になると、、AP はスイッチからの EAP アイデンティティ要求を待機し、その後も待機状態が続く場合は、EAPOL-START メッセージを開始して、所定の回数だけ再試行します。

   dot1x 認証が正常に行われると、AP はコントローラに参加するためのメッセージを送信できるようになります。

認証に失敗した場合、AP は再試行します。失敗が繰り返される場合は、次の手順の組み合わせを実行する必要があります。

1. 設定された AP dot1x クレデンシャルが認証サーバに存在することを確認します
2. スイッチ ポートで [Dot1x Enable] を無効にします
3. IOS CLI を使用して、AP で適切な dot1x クレデンシャルを設定します
4. PAC プロビジョニング用に認証サーバで匿名プロビジョニングが有効になっていることを確認します
5. 認証サーバが到達可能であることを確認します

AP ポート EAP TLS/PEAP プロセスの事前要件は次のとおりです。

• 既存の方法を使用して、WLC と AP に LSC をプロビジョニングし、ダウンロードした LSC 証明書を使用して DTLS 接続を確立するように AP を設定します。

• 認証サーバ（AS）として機能する ISE に LSC 証明書を追加します。

第 1 段階：

• WLC で 802.1X クレデンシャルと EAP 方式を設定します。COS ベースの AP は、WLC から 802.1X クレデンシャルと EAP 方式を受信します。もう 1 つの方法は、これらの 802.1X クレデンシャルと共にラボ内で AP を「事前準備」することです。これを行うには、次の CLI を使用します。

  capwap ap dot1x username <name> password <pwd>

• EAP-TLS/PEAP 用に設定する必要がある LSC 証明書

第 2 段階：

• スイッチ ポートで 802.1X を有効にし、802.1X 認証を通じて WLC に再参加します。

• dot1x ユーザ/EAP 方式が変更されるたびに、認証プロセスが再開されます。

802.1X サプリカントをスイッチ ポートで動作させるには、AP の接続先になるスイッチ ポートで次の設定を実行する必要があります。次の設定例を参照してください。

スイッチ ポート Dot1x 設定の例：

switch#configure terminal
switch(config)#dot1x system-auth-control
switch(config)#aaa new-model
!--- Enables 802.1x on the Switch.
switch(config)#aaa authentication dot1x default group radius
switch(config)#aaa authorization network default group radius
switch(config)#radius server ISE
switch(config)# address ipv4 1.4.126.10 auth-port 1812 acct-port 1813
switch(config)# key cisco123 
!--- Configures the RADIUS server with shared secret and enables switch to send 
!--- 802.1x information to the RADIUS server for authentication.
switch(config)#ip radius source-interface vlan 14
!--- We are sourcing RADIUS packets from VLAN 253 with NAS IP: 192.168.153.10.
switch(config)interface gigabitEthernet 0/11
switch(config-if)switchport mode access
switch(config-if)switchport access vlan 253
switch(config-if)spanning-tree portfast
!--- gig0/11 is the port number on which the AP is connected.
switch(config-if)dot1x pae authenticator
!--- Configures dot1x authentication.
switch(config-if)dot1x port-control auto
!--- With this command, the switch initiates the 802.1x authentication.
 
switch(config-if)authentication priority dot1x
switch(config-if)authentication port-control auto

1.3 以降の ISE には内部認証局（CA）として証明書を発行する機能が備わっています。企業のほとんどは何らかの PKI インフラストラクチャを利用しており、かつ一般的な展開では Windows サーバが CA として使用されているため、ISE が発行する証明書は通常 BYOD にしか使用されません。そのため今回の設定では、MS Windows Server 2012 以降で CA サーバを使用する場合に焦点を当てます。

（注）	手順の詳細については、「Windows Server 2012 以降の Microsoft CA 証明書のインストール」および『Cisco ISE 2.3 Administration Guide』を参照してください。次の情報は一般的なものであり、段階を追ったものではありません。

最初に、[Active Directory Certificate Services Web Enrollment ] ページ（https://AD-IP-address/certsrv）に移動して、CA 証明書をダウンロードします。必要に応じて、この証明書を ISE の信頼できる証明書ストアに追加します。認証局を使用して証明書署名要求への署名を開始する前にその認証局を信頼する必要があるため、これは最初の重要なステップです。ページが表示されたら、[Download a CA certificate, certificate chain, or CRL] リンクをクリックします。

次のページで、Base 64 のオプション ボタンを選択し、[Download CA certificate] リンクをクリックします。これで、CA 証明書がローカルにダウンロードされます。

ISE にログインし、[Administration] > [System] > [Certificate] > [Certificate Management] > [Trusted Certificates] に移動して、[Import] をクリックします。

次のページで、直前にダウンロードした CA 証明書をアップロードします。わかりやすい名前と、証明書の内容を示す説明を付けます。このような詳細を追加しておくと、後からその管理を任される可能性がある他の ISE 管理者にとって常に役立ちます。次のチェックボックスをオンにします。

[Trust for authentication within ISE]：信頼できる証明書ストアにロードされた同じ信頼できる CA 証明書が付与されている限り、新しい ISE ノードを追加できます。

[Trust for client authentication and Syslog]：この証明書を使用し、EAP によって ISE に接続するエンドポイントを認証したり、セキュア Syslog サーバを信頼したりする場合は、このチェックボックスをオンにします。

[Trust for authentication of Cisco Services]：フィード サービスなどの外部のシスコ サービスに対してこの証明書を信頼できるようにする場合にのみ、このチェックボックスをオンにする必要があります。

これで CA 証明書を信頼できる証明書ストアに追加したので、証明書署名要求（CSR）を発行し、得られた証明書を ISE ノードにバインドすることができます。これを行うには、最初に、[Administration] > [System] > [Certificates] > [Certificate Signing Requests] に移動し、[Generate Certificate Signing Requests (CSR)] をクリックして CSR を発行する必要があります。表示されるページでは、証明書はドロップダウンでマルチユースに使用されます。ISE ノードの隣にあるチェックボックスをオンにし、自身またはその所属先組織が識別しやすいことを前提にしてサブジェクト情報を入力します。入力が完了したら、[Generate] をクリックし、表示されるポップアップで [Export] をクリックします。作成した CSR 要求がダウンロードされます。

ダウンロードした CSR をメモ帳で開き、[Microsoft AD CA Web Enrollment] ページの最初のページを再度開きます。[Request a certificate] リンクをクリックします。次のページで、[advanced certificate request] リンクをクリックします。

この時点で、[Certificate Request] ページが表示されます。ここで CSR を使用して証明書を生成します。メモ帳から CSR の本文をコピーして [Base-64-encoded certificate request] フィールドに貼り付け、[Certificate Template] ドロップダウンで [Web Server] テンプレートを選択します（ISE 2.0 または 2.1 を使用している場合は、単にテンプレートとして [pxGrid] を選択します）。[Submit] をクリックします。

次のページで、[Base 64 encoded] のオプション ボタンを選択し、[Download certificate] リンクをクリックします。これで、CSR から生成された CA によって署名された証明書がダウンロードされます。

ISE GUI に戻り、[Administration] > [System] > [Certificates] > [Certificate Management] > [Certificate Signing Request] に移動して、作成してある CSR の横のチェックボックスをオンにします。[Bind Certificate] ボタンをクリックします。

次に、ダウンロードした証明書をアップロードし、ISE 向けのわかりやすい名前を付けます。この例では、わかりやすい名前として「CA-BIND」を使用しました。また、[Admin] と [EAP authentication] の横にあるチェックボックスもオンにしました。[Portal] も選択できますが、これはゲスト/スポンサー/ホットスポット/ などのポータル用なので、公開形式の署名された証明書を使用することをお勧めします。その理由は、ユーザまたはゲストがネットワークに接続していて、ISE ポータルがゲスト ポータル用の非公開で署名された証明書を使用している場合、証明書エラーが発生したり、ブラウザがアクセスをブロックする可能性があるためです。そのすべてを回避するには、ポータル用の公開形式で署名された証明書を使用して、より良いユーザ エクスペリエンスを確保します。

[Submit] をクリックすると、ISE ノードがサービスを再開します。VM に割り当てられているバージョンとリソースによっては、このプロセスに 5 ～ 15 分かかることがあります。アプリケーションの再起動のステータスを確認するには、ISE コマンド ラインを開き、show application status ise を入力します。

ここで、証明書認証プロファイルの作成に進みます。このプロファイルは、後の投稿で作成する認証方法に必要です。このポリシーでは EAP 証明書ベースの認証方法を使用するため、ISE はクライアントから受信した証明書とサーバ内の証明書を比較して、ユーザまたはコンピュータの信頼性を検証します。これは従来のユーザ名とパスワードの方法よりはるかに安全な方法と考えられています。

ISE GUI で、[Administration] > [Identity Management] > [External Identity Management] > [Certificate Authentication Profile] に移動し、[Add] をクリックします。

プロファイルには、ユーザが識別しやすい名前を指定できます。このラボでは、AD_CA_AltName という名前を付けました。[Identity Store] ドロップダウンから、AD サーバを選択して、この証明書テンプレートを Active Directory CA に関連付けます。[Certificate Attribute] オプション ボタンが選択されていることを確認し、ドロップダウンボックスから [Subject Alternative Name] オプションを選択します。これにより、ISE が LDAP から取得して比較する必要がある証明書属性の値が指定されます。[Match Client Certificate Against Certificate in Identity Store] オプションでは、通常はデフォルトの [Only to resolve identity ambiguity] のままにします。

ISE で SCEP を介して BYOD 用の証明書を発行するには、ここで SCEP プロファイルを設定する必要があります。[Administration] > [System] > [Certificates] > [Certificate Authority] > [External CA Settings] に移動し、[Add] をクリックします。次のページでは、このプロファイルの名前と SCEP サーバへのリンクを指定する必要があります。デフォルトによる URL は http://CA-ip-address/certsrv/mscep/mscep.dll です。

[Submit] をクリックする前に、必ずこのプロファイルで接続をテストしてください。

（注）	追加の証明書設定手順については、『ISE configuration Guide』を参照してください。https://www.cisco.com/c/en/us/td/docs/security/ise/2-2/admin_guide/b_ise_admin_guide_22.html

802.1X が完了した後、コントローラで AP 接続を確認すると、証明書タイプが LSC として表示されます。