Catalyst 9800 WLCおよびISEでのCWAの設定

はじめに

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

前提条件

要件

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

使用するコンポーネント

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

• 9800 WLC Cisco IOS® XE Gibraltar v17.6.x
• Identity Service Engine(ISE)v3.0

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

背景説明

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

CWAフロー

設定

ネットワーク図

9800 WLC での AAA 設定

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

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

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

注：バージョン17.4.X以降では、RADIUSサーバを設定する際に、CoAサーバキーも必ず設定してください。共有秘密と同じキーを使用します（ISEではデフォルトで同じです）。 RADIUSサーバで設定されている場合は、共有秘密キーとは異なるキーをCoAにオプションで設定します。Cisco IOS XE 17.3では、Web UIでCoAキーと同じ共有秘密が使用されました。

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

図に示すように [Configuration] > [Security] > [AAA] > [AAA Method List] > [Authorization] > [+ Add] に移動します。

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

注:Cisco Bug ID CSCvh03827が原因で、（Cisco IOS XE CLI設定から）RADIUSサーバをロードバランスすることにした場合、CWAは機能しません。外部ロードバランサの使用は問題ありません。ただし、calling-station-id RADIUS属性を使用して、ロードバランサがクライアント単位で動作していることを確認してください。UDP送信元ポートに依存するメカニズムは、9800からのRADIUS要求のバランシングではサポートされていません。

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

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

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

WLAN 設定

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

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

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

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

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：新しいポリシープロファイルを作成します。

[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拡張タイプにして、すべてのルールを図に示すようにシーケンスとして追加します。

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

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

この例では、ISEノードに向かうすべてのトラフィックを許可することにします。これは、ゲストクライアントに対してISEの管理インターフェイスへのアクセスを許可できるため、優れた方法ではありません。通常はゲストポータルで使用されるポートであるポート8443に制限することをお勧めします（ただし、特定のケースでは他のポートを使用することもできます）。

特定の状況では、DNSトラフィック（DNSサーバIPに対してのみ送信される可能性があります）、DHCPおよびNTPを拒否する必要もあります。

注：リダイレクションACLでは、denyアクションは（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

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

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

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

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

注:HTTPトラフィックのリダイレクションは、FlexConnectローカルスイッチングの場合でも、CAPWAP内で発生します。WLCが代行受信作業を行うため、APはCAPWAPトンネル内でHTTP(S)パケットを送信し、WLCからのリダイレクトをCAPWAPで受信します

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

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

また、GUIのパラメータマップ(Configuration > Security > Web Auth)でオプション「Web Auth intercept HTTPS」をチェックして、このオプションを実行することもできます。
  

注：デフォルトでは、ブラウザはHTTP Webサイトを使用してリダイレクトプロセスを開始します。HTTPSリダイレクションが必要な場合は、Web Auth intercept HTTPSにチェックマークを入れる必要があります。ただし、この設定はCPU使用率を増加させるため、お勧めしません。

ISE 設定

9800 WLC の ISE への追加

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

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

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

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

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

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の順に移動し、リストの最初のポリシーセットの歯車をクリックして、新しい行を挿入するか、右側の青い矢印をクリックして、デフォルトのポリシーセットを選択します。


ステップ 2：Authentication policyを展開します。MABルール（有線またはワイヤレスMABでの一致）に対して、Optionsを展開し、「If User not found」が表示される場合はCONTINUEオプションを選択します。

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

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

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

ステップ 1：同じポリシーセットページで、図に示すように、Authentication Policyを閉じ、Authorization Policy を展開します。

ステップ 2：最近のISEバージョンは、大部分のニーズに一致するWiFi_Redirect_to_Guest_Loginという作成済みのルールで始まります。有効にするには、左側の灰色の記号をオンにします。

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

ステップ 4：ここで、ユーザがポータルで認証された後にネットワークアクセスの詳細を返すために、ゲストフロー条件に一致する、より高い優先順位で定義された2番目のルールが必要です。最近の ISE バージョンではデフォルトで事前に作成されている [Wifi Guest Access] ルールも使用できます。後は左側のマークを緑色にして、ルールを有効にするだけです。   デフォルトのPermitAccessを返すか、より厳密なアクセスリスト制限を設定できます。

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

ルールの下部にある [Save] をクリックします。

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

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

Configuration > Tags & Profiles > Flexの順に移動し、Flexプロファイルを選択します。次に、Policy ACLタブに移動します。

図のように [Add] をクリックします。

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

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

Saveを押してからUpdateを押して、デバイスに適用することを忘れないでください。

証明書

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

確認

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

# 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

トラブルシュート

留意事項

認証が成功した場合に、最終的なRADIUS access-acceptでVLAN割り当てを行うことは推奨されません。WLCとネットワークインフラストラクチャには、クライアントがそのIPアドレスを確実に更新するための有効な手段がないため、ネットワーク内のクライアントデバイスによってはランダムな誤動作が発生する可能性があります。クライアントがまだ認証をパスしていない場合は制限ACLを割り当て、認証が成功した場合はユーザごとの適切なACLで上書きするように設計する方が安全です。

Checklist

• クライアントが接続し、有効なIPアドレスを取得していることを確認します。
• リダイレクトが自動でない場合は、ブラウザを開いてランダムなIPアドレスを試してください。たとえば、10.0.0.1 などです。リダイレクトが機能する場合は、DNS解決に問題がある可能性があります。DHCP経由で提供された有効なDNSサーバがあり、ホスト名を解決できることを確認します。 
• HTTPでのリダイレクションが機能するように、ip http serverコマンドが設定されていることを確認します。Web管理ポータルの設定は、Web認証ポータルの設定と関連付けられており、リダイレクトするにはポート80にリストされている必要があります。 HTTPは、グローバルに有効にする(ip http serverコマンドを使用)か、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シリーズワイヤレスコントローラには、GigabitEthernet 0ポートと呼ばれるサービスポートがあります。バージョン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> 

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

常時オンのトレースで調査中の問題のトリガーを特定するのに十分な情報が得られない場合は、条件付きデバッグを有効にして、ラジオアクティブ（RA）トレースをキャプチャできます。これにより、指定の条件（この場合はクライアントの MAC アドレス）と相関するすべてのプロセスのデバッグレベルのトレースが可能になります。 条件付きデバッグを有効にするには、次の手順に進みます。

ステップ 5：有効なデバッグ条件がない状態にします。

# clear platform condition all

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

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

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

注：一度に複数のクライアントをモニターするには、MAC アドレスごとに debug wireless mac <aaaa.bbbb.cccc> コマンドを実行します。

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

ステップ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 は認証を拒否しました。これは、認可がSSID名に完全に一致する一方で、APのMACアドレスにSSID名が追加されて、送信されたCalled-station-ID属性が表示されるためです。ルールが「equal」ではなく「contains」に変更されると修正されます。

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

WLC Web UIのTroubleshooting > Radioactive traceページに移動します。

ほとんどの場合、常時接続のログを使用でき、問題を再現せずに過去の接続試行からログを取得することもできます。

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

この場合、問題は、ACL名を作成したときに入力ミスを行い、ISEから返されたACL名と一致しないか、または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.