Catalyst 9800 WLCおよびISEでの中央Web認証(CWA)の設定

はじめに

このドキュメントでは、Catalyst 9800 WLCおよびISEでCWAワイヤレスLAN(WLAN)を設定する方法について説明します。

前提条件

要件

9800ワイヤレスLANコントローラ(WLC)の設定に関する知識があることが推奨されます。

使用するコンポーネント

このドキュメントの情報は、次のソフトウェアとハードウェアのバージョンに基づいています。

• 9800 WLC Cisco IOS® XEジブラルタルv17.6.x
• Identity Service Engine(ISE)v3.0

このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されました。このドキュメントで使用するすべてのデバイスは、クリアな（デフォルト）設定で作業を開始しています。本稼働中のネットワークでは、各コマンドによって起こる可能性がある影響を十分確認してください。

背景説明

CWAプロセスを次に示します。ここでは、例としてAppleデバイスのCWAプロセスを確認できます。

設定

ネットワーク図

9800 WLC での AAA 設定

ステップ 1：ISEサーバを9800 WLC設定に追加します。

移動先  Configuration > Security > AAA > Servers/Groups > RADIUS > Servers > + Add  次の図に示すように、RADIUSサーバ情報を入力します。

将来的に中央 Web 認証（または CoA を必要とするあらゆる種類のセキュリティ）を使用する予定がある場合は、CoA のサポートが有効になっていることを確認します。 

ステップ 2：許可方式リストを作成します。

移動先  Configuration > Security > AAA >  AAA Method List > Authorization > + Add  図に示すように。

ステップ3:（オプション）図に示すように、アカウンティング方式リストを作成します。

注:Cisco Bug ID CSCvh03827により、（Cisco IOS XE CLI設定から）RADIUSサーバのロードバランシングを行う場合、CWAは機能しません。外部ロードバランサの使用は問題ありません。

ステップ4:（オプション）AAAポリシーを定義して、SSID名をCalled-station-id属性として送信できます。これは、この条件を後でプロセスでISEで利用する場合に便利です。

移動先  Configuration > Security > Wireless AAA Policy デフォルトのAAAポリシーを編集するか、新しいポリシーを作成します。

次のいずれかを選択できます  SSID オプション1を選択します。SSIDだけを選択した場合でも、着信側ステーションIDはSSID名にAP MACアドレスを付加することに注意してください。

WLAN 設定

ステップ 1：WLANを作成します。

移動先  Configuration > Tags & Profiles > WLANs > + Add  必要に応じてネットワークを設定します。

ステップ 2：WLANの一般情報を入力します。

ステップ 3：次に移動します。  Security  タブをクリックし、必要なセキュリティ方式を選択します。この場合、「MACフィルタリング」とAAA許可リスト(手順2で作成したもの。  AAA Configuration  セクション)が必要です。

CLI：

#config t
(config)#wlan cwa-ssid 4 cwa-ssid
(config-wlan)#mac-filtering CWAauthz
(config-wlan)#no security ft adaptive
(config-wlan)#no security wpa
(config-wlan)#no security wpa wpa2
(config-wlan)#no security wpa wpa2 ciphers aes
(config-wlan)#no security wpa akm dot1x
(config-wlan)#no shutdown

ポリシープロファイルの設定

ポリシープロファイル内では、他の設定(アクセスコントロールリスト(ACL)、Quality of Service(QoS)、モビリティアンカー、タイマーなど)の中から、VLANを割り当てるクライアントを決定できます。

デフォルトのポリシープロファイルを使用することも、新規に作成することもできます。

GUI：

ステップ 1：新しい  Policy Profileを参照。

移動先  Configuration > Tags & Profiles > Policy  次のいずれかを設定します。  default-policy-profile  新しいプロファイルを作成します。

プロファイルを有効にします。

ステップ 2：VLANを選択します。

次に移動します。  Access Policies  タブをクリックし、ドロップダウンからVLAN名を選択するか、VLAN-IDを手動で入力します。ポリシープロファイルで ACL を設定しないでください。

ステップ 3： ISEオーバーライド（AAAオーバーライドを許可）および認可変更(CoA)（NAC状態）を受け入れるようにポリシープロファイルを設定します。必要に応じて、アカウンティング方法も指定できます。

CLI：

# config
# wireless profile policy <policy-profile-name>
# aaa-override
# nac
# vlan <vlan-id_or_vlan-name>
# accounting-list <acct-list>
# no shutdown

ポリシータグの設定

ポリシータグで、SSID をポリシープロファイルにリンクします。新しいポリシータグを作成するか、default-policy タグを使用します。

注:default-policyタグは、1 ～ 16のWLAN IDを持つSSIDをdefault-policyプロファイルに自動的にマッピングします。変更や削除はできません。ID 17以降のWLANがある場合、default-policyタグは使用できません。

GUI：

移動先  Configuration > Tags & Profiles > Tags > Policy  図に示すように、必要に応じて新しいプロファイルを追加します。

WLAN プロファイルを目的のポリシープロファイルにリンクします。

CLI：

# config t
# wireless tag policy <policy-tag-name>
# wlan <profile-name> policy <policy-profile-name>

ポリシータグの割り当て

必要な AP にポリシータグを割り当てます。

GUI：

タグを1つのAPに割り当てるには、次の場所に移動します。  Configuration > Wireless > Access Points > AP Name > General Tagsをクリックして必要な割り当てを行い、  Update & Apply to Deviceを参照。

注:APでポリシータグを変更すると、9800 WLCとの関連付けが失われ、約1分以内に元に戻ることに注意してください。

同じポリシータグを複数のAPに割り当てるには、次の順に移動します  Configuration > Wireless > Wireless Setup > Advanced > Start Nowを参照。

タグを割り当てるAPを選択し、  + Tag APs  図に示すように。

whishedタグを選択して、  Save & Apply to Device 図に示すように。

CLI：

# config t
# ap <ethernet-mac-addr>
# policy-tag <policy-tag-name>
# end

リダイレクト ACL 設定

ステップ 1：移動先  Configuration > Security > ACL > + Add  新しいACLを作成します。 

ACLの名前を選択し、作成します  IPv4 Extended  図に示すように、すべてのルールを入力してシーケンスとして追加します。

ISE PSN ノードへのトラフィックと DNS を拒否し、他はすべて許可する必要があります。このリダイレクトACLは、セキュリティACLではなく、追加の処理（リダイレクトなど）のためにCPUに送られる（許可された）トラフィックと、データプレーンに留まる（拒否された）トラフィックを定義し、リダイレクトを回避するパントACLです。

ACLは次のようになります（この例では10.48.39.28をISE IPアドレスで置き換えます）。

注：リダイレクションACLでは、  deny （トラフィックを拒否するのではなく）拒否リダイレクトとして動作し、  permit 許可リダイレクションとして動作します。WLCは、リダイレクト可能なトラフィックのみを調べます（デフォルトではポート80および443）。

CLI：

ip access-list extended REDIRECT
 deny ip any host <ISE-IP>
 deny ip host<ISE-IP> any
 deny udp any any eq domain
 deny udp any eq domain any
 permit tcp any any eq 80

注:ACLの末尾に  permit ip any any ポート80に焦点を当てた許可の代わりに、WLCはHTTPSもリダイレクトします。これは、独自の証明書を提供する必要があり、常に証明書違反を作成するため、望ましくない場合がよくあります。これは、CWAの場合にWLC上の証明書は必要ないという前述の文の例外です。HTTPS代行受信を有効にしている場合は証明書が必要ですが、いずれにしろ有効であると見なされることはありません。

ISEサーバに対してゲストポート8443のみを拒否するようにアクションを実行することで、ACLを改善できます。

HTTPまたはHTTPSのリダイレクトを有効にする

Web管理ポータルの設定はWeb認証ポータルの設定と関連付けられており、リダイレクトするにはポート80でリッスンする必要があります。したがって、リダイレクションが正しく動作するには、HTTPを有効にする必要があります。グローバルに有効にすることも選択できます（コマンドを使用）。  ip http serverまたは、HTTPを有効にして web認証モジュールのみ(コマンドを使用して  webauth-http-enable パラメータマップの下)。

HTTPS URLにアクセスしようとするときにリダイレクトされるようにするには、次のコマンドを追加します  intercept-https-enable パラメータマップの下に表示されますが、これは最適な設定ではなく、WLCのCPUに影響を与え、証明書エラーを生成します。

parameter-map type webauth global
 type webauth
 intercept-https-enable
 trustpoint xxxxx

また、パラメータマップ(Configuration > Security > Web Auth）。
  

ISE 設定

9800 WLC の ISE への追加

ステップ 1： ISEコンソールを開き、Administration > Network Resources > Network Devices > Add 図に示すように。

ステップ 2：ネットワークデバイスを設定します。

オプションで、モデル名、ソフトウェアバージョン、および説明を指定し、デバイスタイプ、ロケーション、またはWLCに基づいてネットワークデバイスグループを割り当てることができます。

このIPアドレスは、認証要求を送信するWLCインターフェイスに対応します。デフォルトでは、次の図に示すように管理インターフェイスになります。

ネットワークデバイスグループの詳細については、ISE管理ガイドの章「ネットワークデバイスの管理：ISE – ネットワークデバイスグループ」を参照してください。

ISE での新しいユーザの作成

ステップ 1：移動先  Administration > Identity Management > Identities > Users > Add  図に示すように。

ステップ 2：情報を入力します。

この例では、このユーザはというグループに属しています。  ALL_ACCOUNTS ただし、図に示すように、必要に応じて調整できます。

認証プロファイルの作成

ポリシープロファイルは、パラメータ（MACアドレス、クレデンシャル、使用されるWLANなど）に基づいてクライアントに割り当てられる結果です。仮想ローカルエリアネットワーク(VLAN)、アクセスコントロールリスト(ACL)、Uniform Resource Locator(URL)リダイレクトなどの特定の設定を割り当てることができます。

ISE の最近のバージョンでは、Cisco_Webauth 許可の結果がすでに存在することに注意してください。WLC で設定したものと一致させるには、ここで編集して、リダイレクト ACL 名を変更します。

ステップ 1：移動先  Policy > Policy Elements > Results > Authorization > Authorization Profilesを参照。クリック  add 独自のプロファイルを作成したり、  Cisco_Webauth デフォルトの結果

ステップ 2：リダイレクト情報を入力します。ACL名が9800 WLCで設定されたものと同じであることを確認します。

認証ルール（Authentication Rule）の設定

ステップ 1： ポリシーセットは、認証ルールと許可ルールの集合を定義します。作成するには、に移動します。Policy > Policy Setsリストの最初のポリシーセットの歯車をクリックし、Insert new row or click the blue arrow on the right to choose the defaut Policy Set.


ステップ 2：拡張  Authentication ポリシーに該当するトラフィックを区別します。の場合  MAB ルール（有線またはワイヤレスMABでの一致）、展開  Optionsを選択し、  CONTINUE 「If User not found」が表示される場合に使用します。

ステップ 3：クリック  Save  変更を保存します。

許可ルール（Authorization Rule）の設定

許可ルールは、クライアントに適用される許可（認証プロファイル）の結果を決定するためのものです。

ステップ 1：同じポリシーセットページで、  Authentication Policy 拡大する  Authorziation Policy  図に示すように。

ステップ 2：最近のISEバージョンは、という事前に作成されたルールで始まります  Wifi_Redirect_to_Guest_Login ほとんどのニーズに対応できます左側の灰色の標識を～に変えなさい  enableを参照。

ステップ 3：このルールはWireless_MABのみに一致し、CWAリダイレクト属性を返します。必要に応じて、少しツイストを追加し、特定のSSIDのみに一致させることができます。条件を選択して（現時点ではWireless_MAB）、Conditions Studioを表示します。右側に条件を追加し、  Radius 辞書(  Called-Station-ID 考えることができます。SSID 名と一致するようにします。次を使用して検証します。 Use 画面の下部に表示されます。

ステップ 4：次に、より高いプライオリティで定義され、  Guest Flow ユーザがポータルで認証された後にネットワークアクセスの詳細を返すための条件。コントローラ GUI または CLI を使用して  Wifi Guest Access 新しいISEバージョンでもデフォルトで作成済みのルール。後は左側のマークを緑色にして、ルールを有効にするだけです。   デフォルトのPermitAccessを返すか、より詳細なアクセスリスト制限を設定できます。

ステップ 5：ルールを保存します。

クリック  Save  ルールの一番下に表示されます

FlexConnect ローカル スイッチング アクセス ポイントのみ

FlexConnect ローカル スイッチング アクセス ポイントと WLAN がある場合はどうなりますか？前のセクションの手順が使用できます。ただし、事前にAPにリダイレクトACLをプッシュするには、追加の手順が必要です。

移動先  Configuration > Tags & Profiles > Flex Flexプロファイルを選択します。次に、  Policy ACL tab.

クリック  Add  図に示すように。

リダイレクトACL名を選択し、中央Web認証を有効にします。このチェックボックスをオンにすると、AP自体のACLが自動的に反転します（「deny」文はCisco IOS XEのWLCで「このIPにリダイレクトしない」を意味するためです）。ただし、APでは「deny」文はその逆を意味します。したがって、このチェックボックスは、APへのプッシュを行うときにすべての許可を自動的に入れ替えて拒否します。これは、次のコマンドで確認できます。  show ip access list APのCLIから)を使用します。

注:Flexconnectローカルスイッチングのシナリオでは、ACLで特にreturn文を指定する必要があります（これはローカルモードでは必ずしも必要ではありません）。そのため、すべてのACLルールで両方の方法のトラフィック（ISEとの間など）がカバーされていることを確認してください。

ヒットすることを忘れないでください  Save その後  Update and apply to the deviceを参照。

証明書

Web認証証明書をクライアントに信頼させるには、提示される証明書は（クライアントが信頼する必要がある）ISE証明書だけであるため、WLCに証明書をインストールする必要はありません。

確認

以下のコマンドを使用して、現在の設定を確認できます。

# show run wlan
# show run aaa
# show aaa servers
# show ap config general
# show ap name <ap-name> config general 
# show ap tag summary
# show ap name <AP-name> tag detail
# show wlan { summary | id | nme | all }
# show wireless tag policy detailed <policy-tag-name>
# show wireless profile policy detailed <policy-profile-name> 

この例に対応するWLCの設定の関連部分を次に示します。

aaa new-model
!
aaa authorization network CWAauthz group radius
aaa accounting identity CWAacct start-stop group radius
!
aaa server radius dynamic-author
 client <ISE-IP> server-key cisco123
!
aaa session-id common
!
!
radius server ISE-server
 address ipv4 <ISE-IP> auth-port 1812 acct-port 1813
 key cisco123
!
!
wireless aaa policy default-aaa-policy
wireless cts-sxp profile default-sxp-profile

wireless profile policy default-policy-profile
 aaa-override
 nac
 vlan 1416
 no shutdown
wireless tag policy cwa-policy-tag
 wlan cwa-ssid policy default-policy-profile
wlan cwa-ssid 4 cwa-ssid
 mac-filtering CWAauthz
 no security ft adaptive
 no security wpa
 no security wpa wpa2
 no security wpa wpa2 ciphers aes
 no security wpa akm dot1x
 no shutdown

ip http server (or "webauth-http-enable" under the parameter map)
ip http secure-server

トラブルシュート

Checklist

• クライアントが接続し、有効なIPアドレスを取得することを確認します。
• リダイレクトが自動でない場合は、ブラウザを開いてランダムなIPアドレスを試してください。たとえば、10.0.0.1 などです。リダイレクションが機能している場合は、DNS解決に問題がある可能性があります。DHCP経由で提供された有効なDNSサーバがあり、ホスト名を解決できることを確認します。 
• 次のコマンドが入力されていることを確認します。  ip http server HTTPでのリダイレクションが機能するように設定されています。Web管理ポータルの設定はWeb認証ポータルの設定に関連付けられており、リダイレクトするにはポート80にリストされている必要があります。 グローバルに有効にすることも選択できます（コマンドを使用）。  ip http serverまたは、HTTPを有効にして web認証モジュールのみ(コマンドを使用して  webauth-http-enable パラメータマップの下)。
• HTTPS URLへのアクセスを試みたときにリダイレクトされず、それが必要な場合は、次のコマンドを実行していることを確認します  intercept-https-enable パラメータマップの下で、次の手順を実行します。
  
  

parameter-map type webauth global
 type webauth
 intercept-https-enable
 trustpoint xxxxx

パラメータマップで「Web Auth intercept HTTPS」オプションがオンになっていることを、GUIを介して確認することもできます。
  

RADIUSのサービスポートサポート

Cisco Catalyst 9800シリーズWireless Controllerには、次のように呼ばれるサービスポートがあります  GigabitEthernet 0port.バージョン17.6.1以降では、RADIUS（CoAを含む）がこのポートを介してサポートされています。

RADIUSのサービスポートを使用する場合は、次の設定が必要です。

aaa server radius dynamic-author 
client 10.48.39.28 vrf Mgmt-intf server-key cisco123

interface GigabitEthernet0
 vrf forwarding Mgmt-intf
 ip address x.x.x.x x.x.x.x

!if using aaa group server:
aaa group server radius group-name
 server name nicoISE
 ip vrf forwarding Mgmt-intf
 ip radius source-interface GigabitEthernet0

デバッグの収集

WLC 9800 では、ALWAYS-ON トレース機能を利用できます。これにより、クライアント接続に関連するすべてのエラー、警告、および通知レベルのメッセージが常にログに記録され、発生後にインシデントまたは障害状態のログを表示できます。

注：ログには数時間から数日まで遡ることができますが、生成されるログの量によって異なります。

9800 WLCがデフォルトで収集したトレースを表示するには、SSH/Telnet経由で9800 WLCに接続し、次の手順を実行します（セッションをテキストファイルに記録していることを確認します）。

ステップ 1：WLCの現在の時刻を確認して、問題が発生した時刻までのログを追跡できるようにします。

# show clock

ステップ 2：システム設定に従って、WLCバッファまたは外部syslogからsyslogを収集します。これにより、システムの状態とエラー（ある場合）を簡単に確認できます。

# show logging

ステップ 3：デバッグ条件が有効になっているかどうかを確認します。

# show debugging
Cisco IOS XE Conditional Debug Configs:

Conditional Debug Global State: Stop

Cisco IOS XE Packet Tracing Configs:


Packet Infra debugs:

Ip Address                                               Port
------------------------------------------------------|----------

注：リストされている条件は、有効な条件（MACアドレス、IPアドレスなど）に遭遇するすべてのプロセスについて、トレースがデバッグレベルで記録されていることを意味します。これにより、ログの量が増加します。したがって、アクティブにデバッグを行わない場合は、すべての条件をクリアすることを推奨します。

ステップ 4：テスト対象のMACアドレスがステップ3の条件としてリストされていないという前提で、特定のMACアドレスのalways-on notice levelトレースを収集します。

# show logging profile wireless filter { mac | ip } { <aaaa.bbbb.cccc> | <a.b.c.d> } to-file always-on-<FILENAME.txt> 

セッションで内容を表示するか、ファイルを外部 TFTP サーバーにコピーできます。

# more bootflash:always-on-<FILENAME.txt>
or
# copy bootflash:always-on-<FILENAME.txt> tftp://a.b.c.d/path/always-on-<FILENAME.txt> 

条件付きデバッグとラジオアクティブトレース

常時接続トレースで、調査中の問題のトリガーを判別するのに十分な情報が得られない場合は、条件付きデバッグを有効にしてRadio Active(RA)トレースをキャプチャできます。これにより、指定された条件（この場合はクライアントMACアドレス）と対話するすべてのプロセスにデバッグレベルのトレースが提供されます。条件付きデバッグを有効にするには、次の手順を実行します。

ステップ 5：有効なデバッグ条件がないことを確認します。

# clear platform condition all

手順 6：監視するワイヤレスクライアントのMACアドレスのデバッグ条件を有効にします。

次のコマンドは、指定された MAC アドレスの 30 分間（1800 秒）のモニターを開始します。必要に応じて、この時間を最大 2085978494 秒まで増やすことができます。

# debug wireless mac <aaaa.bbbb.cccc> {monitor-time <seconds>}

注：複数のクライアントを同時にモニタするには、debug wireless macを実行します   コマンドをmacアドレスごとに発行します。

注：ターミナルセッションでは、すべてが内部的にバッファされて後で表示されるため、クライアントアクティビティの出力は表示されません。

ステップ7’監視する問題または動作を再現します。

ステップ 8：デフォルトまたは設定されたモニタ時間がアップする前に問題が再発した場合は、デバッグを停止します。

# no debug wireless mac <aaaa.bbbb.cccc>

モニタ時間が経過するか、ワイヤレスのデバッグが停止すると、9800 WLCは次の名前のローカルファイルを生成します。

ra_trace_MAC_aaaabbbbcccc_HHMMSS.XXX_timezone_DayWeek_Month_Day_year.log

ステップ9:MACアドレスアクティビティのファイルを収集します。次のいずれかをコピーできます  ra trace .log 外部サーバに送信するか、出力を画面に直接表示します。

RA トレースファイルの名前を確認します。

# dir bootflash: | inc ra_trace

ファイルを外部サーバーにコピーします。

# copy bootflash: ra_trace_MAC_aaaabbbbcccc_HHMMSS.XXX_timezone_DayWeek_Month_Day_year.log  tftp://a.b.c.d/ra-FILENAME.txt

内容を表示します。

# more bootflash: ra_trace_MAC_aaaabbbbcccc_HHMMSS.XXX_timezone_DayWeek_Month_Day_year.log 

ステップ 10：根本原因がまだ明らかでない場合は、デバッグレベルのログのより詳細なビューである内部ログを収集します。すでに収集されて内部で保存されているデバッグログをさらに詳しく調べるだけなので、クライアントを再度デバッグする必要はありません。

# show logging profile wireless internal filter { mac | ip } { <aaaa.bbbb.cccc> | <a.b.c.d> } to-file ra-internal-<FILENAME>.txt

注：このコマンド出力は、すべてのプロセスのすべてのログレベルのトレースを返し、非常に膨大です。これらのトレースの解析については、Cisco TACにお問い合わせください。

次のいずれかをコピーできます  ra-internal-FILENAME.txt 外部サーバに送信するか、出力を画面に直接表示します。

ファイルを外部サーバーにコピーします。

# copy bootflash:ra-internal-<FILENAME>.txt tftp://a.b.c.d/ra-internal-<FILENAME>.txt

内容を表示します。

# more bootflash:ra-internal-<FILENAME>.txt

ステップ 11デバッグ条件を削除します。

# clear platform condition all

注：トラブルシューティングセッションの後は、必ずデバッグ条件を削除してください。

例

認証結果が予想と異なる場合、ISEに移動することが重要です  Operations > Live logs ページに移動し、認証結果の詳細を取得します。

障害の理由（障害がある場合）とISEが受信したすべてのRadius属性が表示されます。

次の例では、許可ルールが一致しなかったため、ISE は認証を拒否しました。これは、APのMACアドレスにSSID名が付加されて送信されるCalled-station-ID属性が表示され、認可がSSID名と完全に一致するためです。ルールが「equal」ではなく「contains」に変更されると修正されます。

この問題を解決しても、WiFiクライアントはSSIDに関連付けられませんが、ISEは認可が成功したと主張し、正しいCWA属性を返します。

次の場所に移動できます。  Troubleshooting > Radioactive trace ページを参照してください。

ほとんどの場合、常時接続のログを信頼でき、問題を再現することなく、過去の接続試行からログを取得することもできます。

クライアントのMACアドレスを追加し、  Generate  図に示すように。

この場合、問題は、ACL名の作成時に入力ミスがあり、ISEから返されたACL名と一致しないか、またはWLCがISEから要求されるようなACLがないという苦情をWLCが出したことにあります。

2019/09/04 12:00:06.507 {wncd_x_R0-0}{1}: [client-auth] [24264]: (ERR): MAC: e836.171f.a162  client authz result: FAILURE
2019/09/04 12:00:06.516 {wncd_x_R0-0}{1}: [ewlc-infra-evq] [24264]: (ERR): SANET_AUTHZ_FAILURE - Redirect ACL Failure username E8-36-17-1F-A1-62, audit session id 7847300A0000012EFC24CD42, 
2019/09/04 12:00:06.518 {wncd_x_R0-0}{1}: [errmsg] [24264]: (note): %SESSION_MGR-5-FAIL: Authorization failed or unapplied for client (e836.171f.a162) on Interface capwap_90000005 AuditSessionID 7847300A0000012EFC24CD42. Failure Reason: Redirect ACL Failure. Failed attribute name REDIRECT.