WLC と ISE での中央 Web 認証の設定例

概要

このドキュメントでは、ワイヤレス LAN コントローラ（WLC）で中央 Web 認証（CWA）を実行するために使用する設定例を示します。

この文書よりも、次の URL にある、より包括的なゲスト導入ガイドが優先されます。https://communities.cisco.com/docs/DOC-77590

前提条件

要件

このドキュメントに特有の要件はありません。

使用するコンポーネント

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

• Cisco ^® Identity Services Engine(ISE)ソフトウェアリリース3.0
  
  
• Cisco WLC ソフトウェアリリース 8.3.150.0

設定

Web 認証の最初の方法は、ローカル Web 認証です。この場合、WLC では HTTP トラフィックを内部サーバまたは外部サーバにリダイレクトし、そこでユーザは認証のための入力を求められます。WLC では、次にクレデンシャル（資格情報）を取得して（外部サーバの場合は HTTP GET リクエストによって送り返される）、RADIUS 認証を行います。ゲストユーザの場合、ポータルがデバイス登録やセルフプロビジョニングなどの機能を提供するため、Identity Services Engine(ISE)などの外部サーバが必要です。フローには、次の手順が含まれます。

1. ユーザが Web 認証サービス セット識別子（SSID）に関連付けられます。
   
   
2. ユーザはブラウザを開きます。
   
   
3. URLが入力されると、WLCはゲストポータル（ISEなど）にリダイレクトします。
   
   
4. ポータルで認証します。
   
   
5. ゲスト ポータルは WLC にリダイレクトして入力されたクレデンシャルを戻します。
   
   
6. WLC で、RADIUS によってゲスト ユーザを認証します。
   
   
7. WLC が元の URL にリダイレクトします。

このフローには、複数のリダイレクションが含まれています。新しいアプローチは、CWA を使用することです。フローには、次の手順が含まれます。

1. ユーザは、実際にはオープンなWeb認証SSIDに関連付けられます。レイヤ2およびレイヤ3セキュリティは有効ではなく、Macフィルタリングのみが有効です。
   
   
2. ユーザはブラウザを開きます。
   
   
3. WLC はゲストのポータルにリダイレクトします。
   
   
4. ポータルで認証します。
   
   
5. ISE では、そのユーザが有効であることをコントローラに示すために RADIUS 認可変更（CoA - UDP ポート 1700）を送信し、最後にアクセス コントロール リスト（ACL）などの RADIUS 属性をプッシュします。
   
   
6. ユーザは元の URL の再試行を促されます。

使用するセットアップは、次のとおりです。

WLC の設定

WLC の設定は比較的簡単です。ISE からダイナミックな認証 URL を取得するために、（スイッチ上と同様に）あるテクニックを使用します（そのテクニックでは認可変更（CoA）を使用するため、セッションを作成する必要があり、そのセッション ID はこの URL の一部になります）。 MAC フィルタリングを使用するように SSID を設定します。MACアドレスが見つからない場合でもaccess-acceptを返すようにISEが設定され、すべてのユーザにリダイレクションURLが送信されます。 

それに加えて、ISE のネットワーク アドミッション コントロール（NAC）と、認証、認可、およびアカウンティング（AAA）のオーバーライドを有効にする必要があります。ISE NAC により、ISE は、ユーザが認証済みで、ネットワークにアクセスできることを示す CoA 要求を送信できます。また、RADIUS NAC は、ISE がポスチャ結果に基づいてユーザ プロファイルを変更するポスチャ アセスメントにも使用されます。

RADIUSサーバでCoAのサポートが有効になっていることを確認します。これはデフォルトです。

最後に、リダイレクト ACL を作成します。この ACL は ISE の Access-Accept で参照され、リダイレクトすべきトラフィック（ACL によって拒否される）、およびリダイレクトすべきでないトラフィック（ACL によって許可される）を定義します。 ここでは、トラフィックを ISE に向けてリダイレクトできないようにするだけです。より具体的にポート 8443 で ISE（ゲスト ポータル）との間でやり取りされるトラフィックだけを禁止することができますが、ユーザがポート 80/443 で ISE にアクセスを試みるとリダイレクトされます。

注：7.2 や 7.3 など、以前のバージョンの WLC ソフトウェアリリースでは、ドメインネームシステム（DNS）の指定が不要でしたが、より新しいコードバージョンでは、そのリダイレクト ACL で DNS トラフィックを許可する必要があります。

これで、WLCの設定は完了です。

ISE の設定

許可プロファイルの作成

ISE で、認可プロファイルを作成する必要があります。その次に、認証ポリシーと認可ポリシーを設定します。WLC がネットワーク デバイスとして設定済みである必要があります。

認可プロファイルに、上述の WLC で作成した ACL の名前を入力します。

1. [Policy] をクリックして、[Policy Elements] をクリックします。
   
   
2. [Results] をクリックします。
   
   
3. [Authorization] を展開して、[Authorization profile] をクリックします。
   
   
4. [Add] ボタンをクリックして、中央 webauth の新しい許可プロファイルを作成します。
   
   
5. [Name] フィールドに、プロファイルの名前を入力します。この例では、WLC_CWA を使用します。
   
   
6. [Access Type] ドロップダウン リストから [ACCESS_ACCEPT] を選択します。
   
   
7. [Web Redirection] チェックボックスをオンにし、ドロップダウン リストから [Centralized Web Auth] を選択します。
   
   
8. [ACL] フィールドに、リダイレクトされるトラフィックを定義するスイッチ上の ACL の名前を入力します。この例では、cwa_redirect を使用します。
   
   
9. [値（Value）] フィールドでは、ドロップダウンリストから [スポンサーゲストポータル（Sponsored Guest Portal）] または [アカウント登録ゲストポータル（Self-Registered Guest Portal）] を選択できます。スポンサーのゲストポータルでは、スポンサーがゲストアカウントを作成し、ゲストは自分の割り当てられたユーザ名とパスワードを使用してネットワークにアクセスし、自己登録ゲストポータルでは自分のアカウントを作成し、割り当てられたユーザとパスワードを使用できます。次の例では、スポンサーゲストポータルを使用しています。

認証ルールの作成

ISE で WLC からのすべての MAC 認証を必ず受け入れるようにし、ユーザが見つからない場合でも認証を続行するようにします。

[Policy] > [Policy Sets] > [Default Policy Set]で、[Authentication]をクリックします。

次の画像は、認証ポリシー ルールを設定する方法の例を示しています。この例では、MAB の検出時にルールがトリガーされるように設定されています。

1. 認証ルールの名前を入力します。この例では、ISEに既に既に存在するMABを使用しています。
   
   
2. 条件フィールドでプラス(+)アイコンを選択します。
   
   
3. Conditions StudioからエディタウィンドウでWireless_MABをドラッグし、[Save]をクリックします
   
   
4. 内部エンドポイントを使用してください。
   
   
5. [Options]をクリックし、[If user not found a]ドロップダウンリストから[Continue]を選択します

注：MAB認証ルールは、デフォルトでISE上にすでに作成されています。

認可ポリシーの作成

認可ポリシーを設定します。2 つの認証と認可が存在することを理解することが重要です。

• 1 つ目は、ユーザが SSID（この場合は「CWA」）に関連付けられ、CWA プロファイルが返るときの仕組みです。
  この例では、条件としてAirespace-Wlan-Idが使用されます。クライアントがSSIDに接続すると、ISEへのRADIUSアクセス要求にAirespace-WLAN-ID属性が含まれます。ISE では、この属性を使用してポリシーを決定します。そのため、不明なクライアントがSSID CWAに接続すると、ISEはリダイレクトURL（Webポータル）とACLを使用してaccess-acceptを送信します。Airespace-Wlan-Id ルールを使用すると、CWA SSID に接続しただけで、ユーザに、ポータルページが表示されるようになります。 

• 2 つ目は、ユーザが Web ポータルで認証を行うときの認証と認可です。この場合、この設定（要件を満たすように設定可能）のデフォルト ルール（内部ユーザ）に照合します。 認証部分が CWA プロファイルと再度一致しないことが重要です。この照合を行うと、リダイレクションのループが発生します。Network Access:UseCase Equals Guest Flow属性は、この2番目の認証を照合するために使用できます。結果は、次のようになります。

上の各画像で示すように認可ルールを作成するには、次の手順を実行します。

1. 新しいルールを作成し、名前を入力します。この例では、Guest Redirection を使用します。
   
   
2. 条件フィールドの鉛筆アイコンをクリックし、新しい条件を作成します。
   
   
3. [エディタ]で、をクリックして属性を追加します。
   
   
4. [半径]を選択し、展開します。
   
   
5. [Radius・Called-Station-ID]をクリックし、CONTAINS演算子を選択します。
   
   
6. 右側のフィールド（この例1の場合）にCWAを入力します。 
   
   
7. [General Authorization]ページで、[Results]の下の[WLC_CWA (Authorization Profile)]を選択します。
   
   この手順により、ISE は、ユーザ（または MAC アドレス）が CWA SSID に接続したときに不明とされ、ログインポータルが提示される場合にも処理を続行できます。
   
   
8. [ゲストリダイレクション]ルールの最後にある[アクション]ボタンをクリックし、その上に新しいルールを挿入することを選択します。
   
   

   注：この新しいルールが [Guest Redirection] ルールの前にあることが非常に重要です。

   
   
   
9. 新しいルールの名前を入力しますこの例では、Guest Portal Auth を使用します。
   
   
10. 条件フィールドで、鉛筆アイコンをクリックし、新しい条件を作成することを選択します。
    
    
11. [Network Access] を選択し、[UseCase] をクリックします。
    
    
12. 演算子として [Equals] を選択します。
    
    
13. 右のオペランドとして [GuestFlow] を選択します。
    
    
14. 承認ページで、[Results]の下のドロップダウンオプションをクリックします
    
    PermitAccessのデフォルトの許可プロファイルオプションを選択するか、カスタムプロファイルを作成して、必要なVLANまたは属性を返すことができます。[If GuestFlow] の上に、ユーザ グループに基づいてさまざまな認可プロファイルを返すためにさらに条件を追加できます。ステップ7で説明したように、このゲストポータル認証ルールは、ポータルのログインが成功した後、およびクライアントを再認証するためにISEがCoAを送信した後に開始される2番目のMACアドレス認証と一致します。この 2 つ目の認証の違いは、単に認証の MAC アドレスが ISE に渡されるのではなく、ISE がポータルで入力されたユーザ名を記憶していることです。この認可ルールに、ゲスト ポータルで数ミリ秒前に入力されたクレデンシャルを考慮させることができます。

注：マルチコントローラ環境では、WLAN-IDはWLC全体で同じである必要があります。Airespace-Wlan-Id 属性を条件として使用しない場合は、Wireless_MAB（組み込みの条件）要求を照合することをお勧めします。 

IP 更新の有効化（オプション：非推奨）

VLAN を割り当てる場合、最後のステップとして、クライアント PC 用の IP アドレスを更新します。このステップは、Windows クライアント用のゲスト ポータルによって実行できます。前の手順で、2nd AUTH ルールに VLAN を設定していない場合は、このステップを省略できます。クライアントが IP アドレスを取得した後に、VLAN を変更すると、接続が中断されるため、この設計は推奨されません。クライアントによっては、誤った反応を示す可能性があり、正常に動作させるには、Windows の管理者権限が必要になります。

VLAN を割り当てた場合は、次の手順を実行し、IP 更新を有効にします。

1. [ワークセンター] > [ゲストアクセス]をクリックし、[ポータルとコンポーネント]をクリックします。
   
   
2. [ゲストポータル（Guest Portals）] をクリックします。
   
   
3. [スポンサーゲストポータル（Sponsored Guest Portal）]（この例で使用）をクリックし、[VLAN DHCPリリースページの設定（VLAN DHCP Release Page Settings）] を展開します。
   
   
4. [VLAN DHCP Release] チェックボックスをオンにします。
   
   

   注：VLAN DHCPリリースサポートは、Windowsデバイスでのみ使用できます。モバイルデバイスでは使用できません。登録されているデバイスがモバイルで、VLAN DHCPリリースオプションが有効になっている場合、ゲストはIPアドレスを手動で更新するように要求されます。モバイルデバイスユーザの場合、VLANを使用するのではなく、WLCでアクセスコントロールリスト(ACL)を使用することを推奨します。

アンカーと外部のシナリオ

このセットアップは、WLC の自動アンカー機能でも動作可能です。唯一の問題点は、この Web 認証方式がレイヤ 2 であるため、すべての RADIUS 処理が外部 WLC で実行されることに注意する必要があることです。外部 WLC のみが ISE と通信し、リダイレクション ACL も外部 WLC 上に存在する必要があります。外部 WLC で保持が必要なのは ACL 名のみです（ACL エントリは不要です）。 外部 WLC は ACL 名をアンカーに送信します。リダイレクションの適用はアンカーで行われます（そのため、アンカーには、適切な ALC エントリが必要です）。

他のシナリオでと同様、外部 WLC ではクライアントが RUN 状態になったとすぐに表示されますが、これは完全に正しいわけではありません。これは、トラフィックが外部 WLC からアンカーに送信されたことを意味しているだけです。実際のクライアントの状態は、アンカー上で確認できます。そこには、CENTRAL_WEBAUTH_REQD と表示されるはずです。

anchor-foreign 設定のフローを次に示します。

1. クライアントが、外部 WLC の SSID に接続します。外部 WLC は MAB の ISE サーバと通信します。ISE は、リダイレクト URL およびリダイレクト ACL とともに access-accept を外部 WLC に送信します。
2. これで、クライアントはアンカー WLC に固定され、IP アドレスを取得して CENTRAL_WEBAUTH_REQD の状態になります。
3. クライアントが Web サイトにアクセスすると、アンカー WLC は、クライアントを ISE ポータルページにリダイレクトします。クライアントには、ログインページが表示されます。
4. ログインが成功すると、ISE は外部 WLC に CoA を送信します。
5. 外部 WLC は、アンカー WLC に接続して、クライアントを RUN 状態にすることを伝達します。
6. すべてのクライアントトラフィックが外部からアンカーに転送され、アンカーWLCから送信されます。

WLC と ISE 間の通信に必要な、ファイアウォールのポートは次のとおりです。

• UDP：1645、1812（RADIUS 認証）
• UDP：1646、1813（RADIUS アカウンティング）
• UDP：1700（RADIUS CoA）
• TCP：8443（ゲストポータル）、または 8905（ポスチャを使用している場合） 

注：中央 Web 認証（CWA）を使用するアンカーと外部のセットアップは、リリース 7.3 以降でのみ動作します。

注：Cisco Bug ID CSCul83594により、IP-to-MACバインディングが不足している可能性があるため、アンカーと外部の両方でアカウンティングを実行できません。また、アカウンティングではゲスト ポータルのセッション ID に関する問題も多数発生します。アカウンティングを設定したい場合は、外部コントローラでアカウンティングを設定します。8.6 WLCソフトウェアを起動する場合は、アンカーと外部コントローラの間でセッションIDが共有され、両方でアカウンティングが有効になる場合は、この問題が解決されないことに注意してください。

確認

ここでは、設定が正常に機能しているかどうかを確認します。

1. ユーザが SSID に関連付けられると、WLC は ISE に問い合わせます（MAC フィルタリングが設定されているため）。ISE は、リダイレクト URL および ACL とともに access-accept を返すように設定されています。これが最初の認証です。

   WLC のクライアントの詳細に、リダイレクション URL と ACL が適用されたことが表示されます。

   
   

   WLC クライアントと AAA のすべてのデバッグで、ISE がリダイレクト URL および ACL とともに送信した access-accept を確認できます。

   *radiusTransportThread: d0:37:45:89:ef:64 Access-Accept received from RADIUS server 10.106.32.25 (qid:4) with port:1812, pktId:24 for mobile d0:37:45:89:ef:64 receiveId = 0
   *radiusTransportThread: AuthorizationResponse: 0x166ab570
   
   
   *radiusTransportThread:  structureSize................................425
   
   *radiusTransportThread:  resultCode...................................0
   
   *radiusTransportThread:  protocolUsed.................................0x00000001
   
   *radiusTransportThread:  proxyState...................................D0:37:45:89:EF:64-00:00
   
   *radiusTransportThread:  Packet contains 4 AVPs:
   
   *radiusTransportThread:  AVP[01] User-Name................................D0-37-45-89-EF-64 (17 bytes)
   
   *radiusTransportThread:  AVP[02] Class....................................CACS:0a6a207a0000000a5fe8f217:ISE3-1/397801666/90 (49 bytes)
   
   *radiusTransportThread:  AVP[03] Cisco / Url-Redirect-Acl.................CWA_Redirect (12 bytes)
   
   *radiusTransportThread:  AVP[04] Cisco / Url-Redirect.....................DATA (175 bytes)
   
   *radiusTransportThread:  d0:37:45:89:ef:64 processing avps[0]: attribute 1
   *radiusTransportThread:  d0:37:45:89:ef:64 username = D0-37-45-89-EF-64
   
   !
   *apfReceiveTask: d0:37:45:89:ef:64 Redirect URL received for client from RADIUS. Client will be moved to WebAuth_Reqd state to facilitate redirection. Skip web-auth Flag = 0

   ISE でも同じ内容を確認できます。[Operations] > [Radius livelogs]に移動します。該当する MAC の [詳細（Details）] をクリックします。

   最初の認証（MAC フィルタリング）では、認証ルールである MAB と、認証ポリシーであるゲストリダイレクションに一致したとして、ISE が、認証プロファイル WLC_CWA を返していることがわかります。 

   

   
   

2. この時点で、クライアントはIPアドレスを取得します。これで、クライアントの状態が CENTRAL_WEB_AUTH に遷移します。クライアントで任意のアドレスを開くと、そのブラウザが ISE にリダイレクトされます。DNS が正しく設定されていることを確認します。

   
   

3. 正しいログイン情報を入力すると、ネットワークアクセスが許可されます。これは 2 番目の認証です。

   

   
   

   ログイン情報が入力されると、ISE はクライアントを認証し、CoA を送信します。 

   
   

   
   

   WLC では、AAA のすべてのデバッグで、次のログを確認できます。

   *radiusCoASupportTransportThread: audit session ID recieved in CoA = 0a6a207a0000000b5fe90410
   *radiusCoASupportTransportThread: Received a 'CoA-Request' from 10.106.32.25 port 23974
   
   *radiusCoASupportTransportThread: CoA - Received IP Address : 10.106.32.122, Vlan ID: (received 0)
   *radiusCoASupportTransportThread: d0:37:45:89:ef:64 Calling-Station-Id ---> d0:37:45:89:ef:64
   *radiusCoASupportTransportThread: Handling a valid 'CoA-Request' regarding station d0:37:45:89:ef:64
   *radiusCoASupportTransportThread: Sending Radius CoA Response packet on srcPort: 1700, dpPort: 2, tx Port: 23974
   *radiusCoASupportTransportThread: Sent a 'CoA-Ack' to 10.106.32.25 (port:23974)

   次の段階の後、クライアントは再認証され、ネットワークへのアクセスが許可されます。 

   

4. コントローラでは、ポリシーマネージャの状態と RADIUS NAC の状態が CENTRAL_WEB_AUTH から RUN に遷移します。

   注：リリース 7.2 以前では、状態 CENTRAL_WEB_AUTH は POSTURE_REQD と呼ばれていました。

ISE が返す CoA のタイプが、後のバージョンで更新されていることに注目してください。ISE 3.0は、最後の方法（この場合はMAB）を使用して再認証を開始するようにWLCに要求します。WLCは、Authorize-Only属性を使用してRADIUS Access-Requestを送信するときに、ユーザを再認証します。

ISE 3.0 での CoA 要求の例

その後、WLCは関連付け解除フレームをクライアントに送信せず、RADIUS認証を再度実行し、新しい結果をクライアントに透過的に適用します。8.3以降、WLCはCWA SSIDでのWPA事前共有キーの設定をサポートします。従来の非PSKシナリオと同じユーザエクスペリエンスが維持され、WLCはクライアントに関連付け解除フレームを送信せず、新しい許可結果を適用するだけです。ただし、「関連付け応答」はクライアントから受信されることはありませんが、スニファトレースを分析する際に興味深いと思われる「関連付け要求」はクライアントに送信されます。

トラブルシュート

CWA の問題のトラブルシューティングまたは分離を行うには、次の手順を実行します。

1. コントローラで debug client <mac address of client> コマンドを入力し、クライアントが CENTRAL_WEBAUTH_REQD 状態に達するかどうかを判断するためにモニタします。ISE から WLC に存在しない（または正しく入力されていない）リダイレクト ACL が返される場合、一般的な問題が検出されます。この場合は、CENTRAL_WEBAUTH_REQD 状態に達するとクライアントは認証解除され、これによってプロセスが再度開始されます
   
   
2. 正しいクライアントの状態に達することができた場合、WLC の Web GUI で [monitor] > [clients] に移動し、正しいリダイレクト ACL と URL がクライアントに適用されていることを確認します。
   
   
3. 正しい DNS が使用されていることを確認します。クライアントは、インターネットの Web サイトと ISE のホスト名を解決できる必要があります。これは、nslookup で確認できます。
   
   
4. ISE で次の認証手順がすべて実行されていることを確認します。
   
   
   • CWA 属性が返される MAC 認証が最初に実行されている必要がある。
     
     
   • ポータルのログイン認証が実行されている。
     
     
   • ダイナミック認可が実行されている。
     
     
   • 最後の認証が ISE 上のポータルのユーザ名を示す MAC 認証である。この認証に対して最終的な認可結果が返される（最後の VLAN と ACL など）。

アンカーのシナリオに関する特別な考慮事項

モビリティ シナリオでの CWA プロセスの効率を制限する、次の Cisco Bug ID を考慮してください（特にアカウンティングが設定されている場合）。

• CSCuo56780：ISE RADIUS サービスの Denial of Service の脆弱性
  
  
• CSCul83594：ネットワークが開いている場合に、セッション ID がモビリティ全体で同期されない