ワイヤレス LAN コントローラ（WLC）での Web 認証について

概要

このドキュメントでは、ワイヤレスLANコントローラ(WLC)でのWeb認証のプロセスについて説明します。 

前提条件

要件

WLC 設定に関する基本的な知識があることをお勧めします。

使用するコンポーネント

このドキュメントの情報は、すべての WLC ハードウェア モデルに基づいています。

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

Web 認証の内部プロセス

Web 認証のセキュリティ機能としての位置付け

Web 認証（WebAuth）はレイヤ 3 セキュリティです。これは、ブラウザを実行する任意のステーションで機能する使いやすいセキュリティを提供します。

任意の事前共有キー(PSK)セキュリティ（レイヤ2セキュリティポリシー）と組み合わせることができます。

WebAuthとPSKの組み合わせによってユーザフレンドリな部分は減少しますが、クライアントトラフィックを暗号化できるという利点があります。

WebAuth は、暗号化のない認証方法です。

WLCソフトウェアリリース7.4をインストールして同時に設定するまでは、WebAuthに802.1x/RADIUS(Remote Authentication Dial-In User Service)を設定できません。

クライアントはdot1x認証とWeb認証の両方を通過する必要があります。これは、ゲストではなく、従業員（802.1xを使用する従業員）用のWebポータルの追加を目的としています。

従業員またはゲストの Web ポータルの dot1x に対するオールインワンの Service Set Identifier（SSID）はありません。

WebAuth の動作の仕組み

802.11 認証プロセスはオープンであるため、認証および関連付けを問題なく行うことができます。その後、関連付けられますが、WLCには表示されません RUN になる。

Web認証を有効にすると、 WEBAUTH_REQD ネットワークリソースにアクセスできない。

オプションにDNSサーバのアドレスを含むDHCP IPアドレスを受信する必要があります。

ブラウザで有効なURLを入力してください。クライアントは、DNS プロトコルを介して URL の名前解決を行います。次に、クライアントは、その HTTP 要求を Web サイトの IP アドレスに送信します。

WLCはその要求をインターセプトし、 webauth WebサイトのIPアドレスを模倣したログインページ。外部WebAuthを使用すると、WLCはWebサイトのIPアドレスを含むHTTP応答で応答し、ページが移動したことを示します。

ページは、WLC により使用される外部 Web サーバに移動されます。認証されると、すべてのネットワークリソースにアクセスできるようになり、最初に要求されたURLにデフォルトでリダイレクトされます（WLCで強制リダイレクトが設定されていない場合）。

要約すると、WLCではクライアントがDNSを解決し、IPアドレスを自動的に WEBAUTH_REQD になる。

ポート80の代わりに別のポートを監視するには、 config network web-auth-port このポートでもリダイレクトを作成します。

たとえば、ポート 2002 を使用する Access Control Server（ACS）Web インターフェイスやその他の同様のアプリケーションです。

HTTPSリダイレクションに関する注意：デフォルトでは、WLCはHTTPSトラフィックをリダイレクトしませんでした。つまり、ブラウザにHTTPSアドレスを入力しても何も起こりません。HTTPSで提供されたログインページにリダイレクトするには、HTTPアドレスを入力する必要があります。

バージョン8.0以降では、CLIコマンドを使用してHTTPSトラフィックのリダイレクトを有効にできます config network web-auth https-redirect enable.

これにより、多数のHTTPS要求が送信される場合に、WLC用の多くのリソースが使用されます。この機能のスケーラビリティが強化されたWLCバージョン8.7以前では、この機能を使用することは推奨されません。この場合、証明書の警告は避けられないことに注意してください。クライアントが任意のURL(https://www.cisco.comなど)を要求した場合でも、WLCは仮想インターフェイスIPアドレスに対して発行された独自の証明書を提示します。これは、クライアントが要求したURL/IPアドレスと一致せず、クライアントがブラウザで例外を強制しない限り、証明書は信頼されません。

8.7より前のWLCソフトウェアリリースの場合、パフォーマンスの低下を示す指標となります。

WebAuth	達成率
3つのURL:HTTP	140/秒
最初のURL:HTTP 第2および第3のURL:HTTPS	20/秒
3つのURL:HTTPS（大規模展開）	< 1/秒
3つのURL:HTTPS（最大100クライアント）	10/秒

このパフォーマンス表では、3つのURLを次のように参照します。

• エンドユーザが入力した元のURL
• WLCがブラウザをリダイレクトするURL
• 最終的なクレデンシャルの送信

パフォーマンステーブルは、3つのURLがすべてHTTPの場合、3つのURLがすべてHTTPSの場合、またはクライアントがHTTPからHTTPSに移動した場合（通常）のWLCのパフォーマンスを示します。

内部ページで内部（ローカル）WebAuth を動作させる方法

動作可能なダイナミックインターフェイスを使用してWLANを設定するために、クライアントはDHCPを通じてDNSサーバのIPアドレスも受け取ります。

攻撃前 webauth 、が設定されている場合、WLANが正しく動作し、DNS要求を解決できることを確認します(nslookup)、およびWebページを参照できます。

Web認証をレイヤ3セキュリティ機能として設定します。ローカルデータベースまたは外部RADIUSサーバにユーザを作成します。

詳細については、「 ワイヤレス LAN コントローラ（WLC）上の Web 認証の設定例」を参照してください。

カスタム ページでカスタムのローカル WebAuth を設定する方法

Custom webauth  次のように設定できます。 redirectUrl Security tab.これにより、入力した特定のWebページに強制的にリダイレクトされます。

ユーザが認証されると、クライアントが要求した元のURLが上書きされ、リダイレクトが割り当てられたページが表示されます。

カスタム機能を使用すると、デフォルトのログイン ページではなく、カスタム HTML ページを使用できます。HTML およびイメージ ファイル バンドルがコントローラにアップロードされます。

アップロードページで、 webauth bundle tar形式で保存します。PicoZipはWLCと互換性のあるtarを作成します。

WebAuth バンドルの例については、「ワイヤレス コントローラ WebAuth バンドルのソフトウェアのダウンロード」ページを参照してください。WLCに適したリリースを選択します。

既存のバンドルをカスタマイズすることをお勧めします。新しいバンドルを作成しないでください。

～にはいくつかの制限がある。 custom webauth バージョンやバグによって異なります 

• .tarファイルのサイズ（5MB以下）
• .tar のファイル数
• ファイルのファイル名の長さ（30文字以内）
  
  

パッケージが機能しない場合は、単純なカスタムパッケージを試してください。ユーザが使用しようとしたパッケージに到達するために、ファイルと複雑さを個別に追加します。これは問題を特定するのに役立ちます。

カスタムページを設定するには、『CiscoワイヤレスLANコントローラコンフィギュレーションガイド、リリース7.6』の「カスタマイズされたWeb認証ログインページの作成」を参照してください。

グローバル設定をオーバーライドする手法

override global configコマンドを使用して設定し、各WLANにWebAuthタイプを設定します。これにより、別のWLANに対して、内部/デフォルトWebAuthとカスタム内部/デフォルトWebAuthが許可されます。

これにより、WLANごとに異なるカスタムページを設定できます。

同じバンドル内のすべてのページを組み合わせて、WLCにアップロードします。

各WLANでoverride global configコマンドを使用してカスタムページを設定し、バンドル内のすべてのファイルからログインページにするファイルを選択します。

各WLANのバンドル内で異なるログインページを選択します。

リダイレクションの問題

HTML バンドルには、リダイレクションを可能にする変数があります。ここに強制リダイレクション URL を含めないでください。

カスタムWebAuthでのリダイレクトの問題については、バンドルを確認することをお勧めします。

WLC GUI に += を使用するリダイレクト URL を入力すると、バンドル内で定義されている URL でオーバーライドされるか、これに追加されます。

たとえば、WLC GUIでは、 redirectURL フィールドはwww.cisco.comに設定されていますが、バンドル内では次のように表示されます。 redirectURL+= '(webサイトのURL)'。+=を指定すると、無効なURLにユーザがリダイレクトされます。

外部ページで外部（ローカル）Web 認証を動作させる方法

外部WebAuthサーバの使用は、ログインページの外部リポジトリにすぎません。ユーザ クレデンシャルは、WLC により認証されます。外部Webサーバでは、特別なログインページまたは別のログインページのみが許可されます。

外部WebAuthに対して実行される手順は次のとおりです。

1. クライアント（エンド ユーザ）が Web ブラウザを開き、URL を入力します。
   
   
2. このクライアントが認証されず、外部 Web 認証が使用される場合、WLC は、このユーザを外部 Web サーバ URL にリダイレクトします。WLCは、模倣されたIPアドレスを使用してHTTPリダイレクトをクライアントに送信し、外部サーバのIPアドレスをポイントします。外部Web認証のログインURLには、 AP_Mac_Address,ページ client_url (クライアントURLアドレス)、 action_URL スイッチのWebサーバに接続するために必要です。
   
   
3. 外部 Web サーバ URL は、ユーザをログイン ページに送信します。ユーザは、事前認証アクセスコントロールリスト(ACL)を使用してサーバにアクセスできます。
   
   
4. ログインページは、ユーザクレデンシャル要求を action_URL(WLC Webサーバのhttp://192.0.2.1/login.htmlなど)。これはリダイレクトURLへの入力パラメータとして提供されます。ここで、192.0.2.1はスイッチの仮想インターフェイスアドレスです。
   
   
5. WLC Web サーバは、認証のためにユーザ名とパスワードを送信します。
   
   
6. WLC は RADIUS サーバ要求を開始するか、WLC 上のローカル データベースを使用してユーザを認証します。
   
   
7. 認証が成功した場合、WLC Web サーバは、設定されたリダイレクト URL またはクライアントが入力した URL にユーザを転送します。
   
   
8. 認証が失敗すると、WLC WebサーバはユーザログインURLにユーザをリダイレクトして戻します。

注：このドキュメントでは、仮想IPの例として192.0.2.1を使用しています。仮想IPはルーティングできないため、192.0.2.xの範囲を使用することを推奨します。古いドキュメントでは、「1.1.1.x」を参照するか、または以前はデフォルト設定だったためWLCで設定されたままの状態になっている可能性があります。ただし、このipは有効なルーティング可能ipアドレスになったため、代わりに192.0.2.xサブネットが推奨されます。

アクセスポイント(AP)がFlexConnectモードの場合、 preauth ACLは無関係です。認証されないクライアントに Web サーバへのアクセスを許可するには、Flex ACL を使用できます。

「ワイヤレス LAN コントローラを使用した外部 Web 認証の設定例」を参照してください。

Web パススルー

Webパススルーは、内部Web認証の一種です。Web パススルーでは、警告またはアラート ステートメントを示すページが表示され、クレデンシャル プロンプトは表示されません。

ユーザはokをクリックします。電子メール入力を有効にすると、ユーザはユーザ名となる電子メールアドレスを入力できます。

ユーザが接続されたら、アクティブクライアントのリストを確認し、ユーザ名として入力した電子メールアドレスでユーザがリストされていることを確認します。

詳細については、『ワイヤレスLANコントローラ5760/3850のWebパススルーの設定例』を参照してください。

条件付き Web リダイレクト

条件付き Web リダイレクトを有効にすると、802.1X 認証が正常に完了した後に、ユーザは条件付きで特定の Web ページにリダイレクトされます。

リダイレクト ページ、および、RADIUS サーバでリダイレクトを実行する条件を指定できます。

条件には、有効期限に達した場合や、ユーザが使用/アクセスを継続するために料金を支払う必要がある場合にパスワードを含めることができます。

RADIUSサーバがCisco AVペア url-redirectユーザがブラウザを開くと、指定されたURLにリダイレクトされます。

サーバがCisco AVペアも返す場合、 url-redirect-aclを選択すると、指定したACLがこのクライアントの事前認証ACLとしてインストールされます。

クライアントはこの時点で完全に認証されていないと見なされ、事前認証 ACL によって許可されるトラフィックのみを送信できます。指定されている URL でクライアントが特定の操作（パスワードの変更や料金の支払いなど）を完了した後で、クライアントは再度認証を行う必要があります。

RADIUSサーバが url-redirectクライアントは完全に認証されたものと見なされ、トラフィックを渡すことを許可されます。

注：条件付きWebリダイレクト機能は、802.1xまたはWPA+WPA2レイヤ2セキュリティ用に設定されたWLANでのみ使用できます。

RADIUSサーバの設定後、コントローラGUIまたはCLIを使用して、条件付きWebリダイレクトをコントローラに設定します。詳細な手順については、『Webリダイレクトの設定(GUI)』および『Webリダイレクトの設定(CLI)』を参照してください。

スプラッシュ ページ Web リダイレクト

スプラッシュ ページ Web リダイレクトを有効にすると、802.1X 認証が正常に完了した後に、ユーザは特定の Web ページにリダイレクトされます。ユーザは、リダイレクト後、ネットワークにフル アクセスできます。

RADIUS サーバでリダイレクト ページを指定できます。RADIUSサーバがCisco AVペア url-redirectユーザがブラウザを開くと、指定されたURLにリダイレクトされます。

この時点でクライアントは完全に認証されたものと見なされ、RADIUSサーバが url-redirectを参照。

注：スプラッシュページリダイレクト機能は、802.1xまたはWPA+WPA2レイヤ2セキュリティ用に設定されたWLANでのみ使用できます。

RADIUSサーバの設定後、コントローラGUIまたはCLIを使用して、コントローラでスプラッシュページWebリダイレクトを設定します。

MAC フィルタ失敗時の WebAuth

WebAuth on MAC Filter FaFailureを使用すると、レイヤ2セキュリティメニューでMACフィルタを設定できます。

ユーザがMACアドレスで正常に検証されると、直接 run になる。

そうでない場合は、 WEBAUTH_REQD 通常のWeb認証が行われます。

注：これはWebパススルーではサポートされていません。詳細については、拡張要求に関するアクティビティを確認してください。Cisco Bug ID CSCtw73512

中央 Web 認証

中央 Web 認証は、WLC がサービスをホストしない状況で使用されます。クライアントはISE Webポータルに直接送信され、WLC上の192.0.2.1を通過しません。ログイン ページおよびポータル全体は外部に配置されます。

中央 Web 認証は、RADIUS ネットワーク アドミッション コントロール（NAC）を WLAN の詳細設定で有効にし、MAC フィルタを有効にしている場合に発生します。

WLCがRADIUS認証（通常はMACフィルタ用）をISEに送信し、ISEが redirect-url 属性値(AV)ペア。

その後、ユーザは POSTURE_REQD iseが認可変更(CoA)要求による認可を与えるまで状態を続けます。同様のことは、Posture または Central WebAuth でも発生します。

中央 WebAuth は、WPA-Enterprise/802.1x には対応しません。これは、拡張認証プロトコル（EAP）の場合のようにゲスト ポータルが暗号化キーのセッションキーを返すことができないためです。

外部ユーザ認証（RADIUS）

外部ユーザ認証(RADIUS)は、WLCがクレデンシャルを処理する場合、またはレイヤ3 Webポリシーが有効になっている場合にのみ、ローカルWeb認証に対して有効です。ローカルまたはWLC上で、あるいはRADIUSを介して外部でユーザを認証します。

WLC は次の順にユーザのクレデンシャルをチェックします。

1. いずれの場合でも、独自のデータベースが参照されます。

2. そこでユーザが見つからない場合、ゲスト WLAN で設定されている RADIUS サーバがチェックされます。

3. 次に、グローバルRADIUSサーバリストをRADIUSサーバと照合して確認します。ここで、 network user チェックが入っていることを確認します。

この3番目のポイントは、そのWLANにRADIUSを設定しないユーザの質問に対する回答ですが、コントローラでユーザが見つからない場合でもRADIUSと照合してチェックされることに注意してください。

これは、次の理由によります network user は、グローバルリストのRADIUSサーバに対してチェックされます。

WLC は、パスワード認証プロトコル（PAP）、チャレンジ ハンドシェイク認証プロトコル（CHAP）または EAP-MD5（メッセージ ダイジェスト 5）でユーザを RADIUS サーバに認証できます。

これは、グローバル パラメータで、GUI または CLI から設定できます。

GUIを使用する場合：次に移動します。 Controller > Web RADIUS Authentication

CLIで、次のように入力します config custom-web RADIUSauth

注:NACゲストサーバはPAPのみを使用します。

有線ゲスト WLAN の設定方法

有線ゲストWLANの設定は、ワイヤレスゲストの設定に似ています。1つまたは2つのコントローラを使用して設定できます（1つが自動アンカーの場合のみ）。

有線ゲストユーザのVLANとして、VLAN 50などのVLANを選択します。有線ゲストがインターネットにアクセスする場合、VLAN 50 に設定されているスイッチのポートにラップトップを接続します。

この VLAN 50 は、WLC トランク ポートを介したパスで許可し、そこに存在する必要があります。

2 つの WLC（アンカーと外部）を使用する場合、この有線ゲスト VLAN は、アンカーではなく、外部 WLC（WLC1）に接続する必要があります。

次にWLC1は、DMZ WLC（アンカー、WLC2という名前）へのトラフィックトンネルを処理し、DMZ WLCはルーテッドネットワークでトラフィックを解放します。

次に、有線ゲスト ユーザ アクセスを設定する 5 つのステップを示します。

1. 有線ゲスト ユーザ アクセス用の動的インターフェイス（VLAN）を設定します。
   
   WLC1 で、動的インターフェイス VLAN50 を作成します。内 interface configuration ページで、 Guest LAN ボックス。次に、次のようなフィールドがあります IP address と gateway 消えろ。WLCは、トラフィックがVLAN 50からルーティングされることを認識する必要があります。これらのクライアントは、有線ゲストです。
   
   
2. ゲスト ユーザ アクセス用の有線 LAN を作成します。
   
   コントローラで、インターフェイスは、WLAN に関連付けられる場合に使用されます。次に、本社のコントローラでWLANを作成します。移動先 WLANs をクリックして Newを参照。イン WLAN Type,選択 Guest LANを参照。
   
   [Profile Name] および [WLAN SSID] で、この WLAN を識別する名前を入力します。これらの名前を変更できますが、スペースを含めることはできません。WLAN という名前が使用されますが、このネットワーク プロファイルはワイヤレス ネットワーク プロファイルには関連しません。
   
   「 General タブには、次の2つのドロップダウンリストがあります。 Ingress と Egressを参照。入力はユーザの送信元のVLAN(VLAN 50)、出力はユーザの送信先のVLANです。
   
   を参照 Ingress,選択 VLAN50を参照。
   
   を参照 Egressとは異なります。コントローラが1つだけの場合は、別のダイナミックインターフェイスを作成し、 standard （ゲストLANではなく）一度だけ実行し、有線ユーザをこのインターフェイスに送信します。この場合、DMZ コントローラに送信します。したがって、 Egress インターフェイスを選択し、 Management Interfaceを参照。
   
   「 Security このゲストLAN「WLAN」のモードはWebAuthであり、これは許容範囲です。クリック Ok 検証します。
   
   
3. 外部コントローラ（本社）を設定します。
   
   WLAN listをクリックし、 Mobility Anchor 最後に – Guest LAN DMZコントローラを選択します。ここでは、両方のコントローラが互いを認識することを前提としています。表示されない場合は、 Controller > Mobility Management > Mobility groupWLC1にDMZWLCを追加します。次に、DMZ の WLC1 を追加します。両方のコントローラが同じモビリティグループに属していないこと。同じ場合、基本セキュリティ規則に違反します。
   
   
4. アンカー コントローラ（DMZ コントローラ）を設定します。
   
   本社のコントローラの準備ができました。次に、DMZコントローラを準備します。DMZ コントローラに Web ブラウザ セッションを開き、[WLANs] に移動します。新規 WLAN を作成してください。イン WLAN Type,選択 Guest LANを参照。
   
   イン Profile Name と WLAN SSIDで、このWLANを識別する名前を入力します。本社コントローラと同じ値を入力します。
   
   「 Ingress インターフェイスは Noneを参照。トラフィックはEthernet over IP(EoIP)トンネルを介して受信されるため、これは重要ではありません。入力インターフェイスを指定する必要はありません。
   
   「 Egress インターフェイスは、クライアントが送信される場所です。たとえば、 DMZ VLAN VLAN 9です。DMZWLC上にVLAN 9の標準ダイナミックインターフェイスを作成し、 VLAN 9 出力インターフェイスとして設定します。
   
   モビリティアンカートンネルの終端を設定します。WLANリストから、 Mobility Anchor for Guest LANを参照。トラフィックをローカル コントローラ DMZWLC に送信します。これで、両端の準備ができました。
   
   
5. ゲスト LAN を調整します。
   
   両端の WLAN 設定を調整することもできます。設定は両端で同じである必要があります。たとえば、 WLAN Advanced tab, Allow AAA override wlc1で、DMZWLCと同じボックスにチェックマークを付けます。どちらかの側でWLANに違いがある場合、トンネルは切断されます。DMZWLCはトラフィックを拒否します。次のメッセージが表示されます。 run debug mobilityを参照。
   
   すべての値（IPアドレス、VLAN値など）は実際にはDMZWLCから取得されることに注意してください。WLC1 側を個別に設定し、要求を WLCDMZ にリレーします。

ログイン ページ用の証明書

このセクションでは、WebAuthページに独自の証明書を配置するプロセス、または192.0.2.1 WebAuth URLを非表示にして名前付きURLを表示するプロセスについて説明します。

コントローラの Web 認証用の証明書のアップロード

GUI(WebAuth > Certificate)またはCLI (転送タイプ webauthcert)を使用して、証明書をコントローラにアップロードできます。

認証局(CA)で作成された証明書であっても、サードパーティの公式証明書であっても、.pem形式である必要があります。

送信前に、証明書のキーを入力する必要もあります。

アップロード後、証明書を有効にするには、リブートする必要があります。再起動したら、GUIのWebAuth証明書ページに移動し、アップロードした証明書の詳細（有効期間など）を確認します。

重要なフィールドは、証明書に発行される名前である、Common Name（CN）です。このフィールドについては、このドキュメントの「コントローラ上の認証局などの証明書」セクションで説明します。

リブートして証明書の詳細を確認すると、WebAuthログインページに新しいコントローラ証明書が表示されます。ただし、次の 2 つの状況が発生します。

1. 証明書の発行元が、確実に信頼できる主要ルート CA のいずれかである場合は問題ありません。たとえば、VeriSign です。ただし、通常、Verisign サブ CA や非ルート CA により署名されます。記載されている CA が信頼できるかどうかは、ブラウザで証明書ストアをチェックできます。
   
   
2. 小規模な企業/CA から取得した証明書は、すべてのコンピュータで信頼されません。会社/CA証明書をクライアントにも提供し、ルートCAの1つがその証明書を発行します。最終的には、「Certificate has been issued by CA x > CA x certificate has been issued by CA y > CA y certificate has been issued by this trusted root CA」というチェーンが作成されます。最終的には、クライアントが信頼する CA に到達します。

コントローラ上の認証局などの証明書

「this certificate is not trusted」という警告を削除するには、コントローラ上でコントローラ証明書を発行したCAの証明書を入力します。

次に、コントローラは両方の証明書（コントローラ証明書とそのCA証明書）を提示します。CA証明書は、信頼できるCAであるか、CAを検証するためのリソースを備えている必要があります。信頼できる CA に送信される CA 証明書のチェーンを構築できます。

チェーン全体を同じファイルに配置します。このファイルには、次の例のような内容が含まれています。

BEGIN CERTIFICATE ------ device certificate*   END CERTIFICATE ------ BEGIN 
CERTIFICATE ------ intermediate CA certificate*   END CERTIFICATE ------ BEGIN 
CERTIFICATE ------ Root CA certificate*   END CERTIFICATE ------

証明書を URL に一致させる方法

WebAuth URL は自身を認証するために 192.0.2.1 に設定され、証明書が発行されます（これは、WLC 証明書の CN フィールドです）。

たとえば、WebAuth URLを「myWLC . com」に変更するには、 virtual interface configuration (192.0.2.1インターフェイス)にアクセスし、 virtual DNS hostname（myWLC . comなど）。

これにより、URL バーの 192.0.2.1 が置換されます。この名前は解決できる必要があります。スニファトレースはすべての動作を示しますが、WLCがログインページを送信すると、WLCはmyWLC . comアドレスを表示し、クライアントはこの名前をDNSで解決します。

この名前は192.0.2.1として解決される必要があります。つまり、WLCの管理にも名前を使用する場合は、WebAuthにも別の名前を使用します。

WLC管理IPアドレスにマッピングされたmyWLC . comを使用する場合は、myWLCwebauth.comのようにWebAuthに別の名前を使用する必要があります。

証明書の問題のトラブルシューティング

このセクションでは、証明書問題をトラブルシューティングの確認方法および確認内容について説明します。

確認方法

OpenSSL（Windowsの場合は、OpenSSL Win32を検索）をダウンロードしてインストールします。設定を行わずに、binディレクトリに移動して、 openssl s_client –connect (your web auth URL):443、

このURLがWebAuthページがDNSにリンクされているURLである場合は、このドキュメントの次のセクションの「確認項目」を参照してください。

証明書でプライベートCAを使用する場合は、ルートCA証明書をローカルマシンのディレクトリに配置し、opensslオプションを使用します -CApathを参照。中間CAがある場合は、同じディレクトリに配置します。

証明書に関する一般的な情報を取得して確認するには、次のコマンドを使用します。

openssl x509 -in certificate.pem -noout -text
openssl verify certificate.pem

また、opensslを使用して証明書を変換することも役立ちます。

openssl x509 -in certificate.der -inform DER -outform PEM -out certificate.pem

確認内容

接続時にクライアントに送信される証明書を確認できます。デバイス証明書の読み取り：CNは、Webページが到達可能なURLである必要があります。

デバイス証明書の「issued by」行を参照します。これは、セカンド証明書の CN と一致する必要があります。この2番目の証明書「issued by」は、次の証明書のCNと一致している必要があります。以下同様に続きます。一致しない場合、チェーンは確立されません。

次に示すOpenSSLの出力では、次のことに注意してください。 openssl デバイス証明書を検証できません。デバイス証明書の「issued by」が、提供されたCA証明書の名前と一致しません。

SSL の出力

Loading 'screen' into random state - done CONNECTED(00000760) depth=0 /O=
<company>.ac.uk/OU=Domain Control Validated/CN=<company>.ac.uk verify error:
num=20:unable to get local issuer certificate verify return:1 depth=0 /O=
<company>.ac.uk/OU=Domain Control Validated/CN=<company>.ac.uk verify error:
num=27:certificate not trusted verify return:1 depth=0 /O=<company>.ac.uk/OU=
Domain Control Validated/CN=<company>.ac.uk verify error:num=21:
unable to verify the first certificate verify return:1 --- Certificate chain
0 s:/O=<company>.ac.uk/OU=
Domain Control Validated/CN=<company>.ac.uki:/C=US/   ST=
Arizona/L=Scottsdale/O=.com/OU=http://certificates.gocompany.com/repository/CN=
Secure Certification Authority/serialNumber=079 
692871 s:/C=US/O=Company/OU=Class 2 Certification Authority 
i:/C=US/O=Company/OU=Class 2 Certification Authority --- Server certificate

BEGIN CERTIFICATE-----
MIIE/zCCA+egAwIBAgIDRc2iMA0GCSqGSIb3DQEBBQUAMIHKMQswCQYDVQQGEwJV
output cut*
YMaj/NACviEU9J3iot4sfreCQSKkBmjH0kf/Dg1l0kmdSbc=

END CERTIFICATE-----
subject=/O=<company>.ac.uk/OU=Domain Control Validated/CN=<company>c.ac.uk 
issuer=/C=US/ST=Arizona/L=Scottsdale/O=.com/OU=http://certificates. 
.com/repository/CN=Secure Certification Authority/serialNumber=0 
7969287 --- No client certificate CA names sent --- SSL handshake has read 
2476 bytes and written 322 bytes --- New, TLSv1/SSLv3, Cipher is AES256-SHA 
Server public key is 1024 bit Compression: NONE Expansion: NONE SSL-Session:

Protocol  : TLSv1
Cipher    : AES256-SHA
Session-ID: A32DB00A7AB7CD1CEF683980F3696C2BBA31A1453324F711F50EF4B86A4A7F03

Session-ID-ctx:Master-Key: C95E1BDAC7B1A964ED7324955C985CAF186B92EA34CD69E10
   5F95D969D557E19
939C6A77C72350AB099B3736D168AB22

   Key-Arg   : None
Start Time: 1220282986
Timeout   : 300 (sec)
Verify return code: 21 (unable to verify the first certificate)
---

もう1つの問題として、証明書をコントローラにアップロードできないことが考えられます。この場合、有効期間、CA などは問題ではありません。

これを確認するには、トリビアルファイル転送プロトコル(TFTP)の接続を確認し、コンフィギュレーションファイルの転送を試みます。を入力した場合、 debug transfer all enable コマンドを発行して、証明書のインストールに問題があることに注意してください。

この原因は、証明書で使用されるキーが正しくないことが考えられます。また、証明書のフォーマットが正しくない、または壊れていることも考えられます。

証明書の内容を確実に有効な証明書と比較することをお勧めします。これにより、 LocalkeyID 属性はすべての0を表示します（すでに発生しています）。その場合、証明書を再変換する必要があります。

OpenSSL では、.pem から .p12 に変換し、目的のキーで .pem を再発行できる 2 つのコマンドがあります。

証明書とキーを含む .pem を受け取った場合、キーの部分をコピー/ペーストします。 ----BEGIN KEY ---- until ------- END KEY ------ を「key.pem」に変換します。

1. openssl pkcs12 -export -in certificate.pem -inkey key.pem -out newcert.p12 ?キーを入力するように求められます。次のように入力します check123.


2. openssl pkcs12 -in newcert.p12 -out workingnewcert.pem -passin pass:check123 -passout pass:check123 その結果、パスワードを含む.pemが動作するようになります check123を参照。
   
   

トラブルシューティングを行うその他の状況

このドキュメントではモビリティ アンカーについては説明していませんが、アンカー ゲストの場合、モビリティ エクスチェンジが正しく発生し、クライアントがアンカーに到達することを確認します。

WebAuth 問題が発生した場合、アンカーでトラブルシューティングを行う必要があります。

次に、トラブルシューティングできる一般的な問題をいくつか示します。

• ユーザをゲスト WLAN に関連付けることができない。
  
  これは、WebAuth に関連するものです。クライアント設定、WLAN のセキュリティ設定、これが有効にされているかどうか、無線がアクティブで機能しているかどうかなどを確認します。
  
  
• ユーザが IP アドレスを取得できない。
  
  ゲスト アンカーの場合、これは多くの場合、外部およびアンカーが同じ方法で設定されていない場合に発生します。それ以外の場合、DHCP 設定や接続などを確認します。
• 他の WLAN が同じ DHCP サーバを正常に使用できるかどうかを確認します。これは、WebAuth とは関係ありません。
  
  
• ユーザがログイン ページにリダイレクトされない。
  
  これは、一般的な症状ですが、より正確に説明します。この問題が発生する状況は次の 2 つあります。
  
  
  1. ユーザがリダイレクトされない（ユーザが URL を入力しても、WebAuth ページにアクセスできない）。この場合、次のことを確認します。
     
     
     • 有効なDNSサーバがDHCP(ipconfig /all!--- インターネット（VPN 以外）上の
       
       
     • DNSがクライアントから到達可能であること(nslookup (website URL!--- インターネット（VPN 以外）上の
       
       
     • リダイレクトされる有効な URL をユーザが入力している。
       
       
     • ユーザがポート 80 の HTTP URL にアクセスしている（たとえば、http://localhost:2002 で ACS にアクセスするには、ポート 80 ではなくポート 2002 に送信されるまでリダイレクトされません）。
       
       
  2. ユーザは、192.0.2.1 に正しくリダイレクトされるが、ページ自体が表示されない。
     
     これは、通常、WLC 問題（バグ）またはクライアント側の問題です。クライアントに何らかのファイアウォール、ソフトウェア、またはポリシーブロックが存在する可能性があります。また、Web ブラウザでプロキシを設定している可能性もあります。
     
     推奨事項：クライアントPCでスニファトレースを実行します。ワイヤレス アダプタで実行し、WLC が応答しリダイレクトするか示す Wireshark 以外、特殊なワイヤレス ソフトウェアは必要ありません。可能性は2つあります。WLCから応答がない、またはWebAuthページのSSLハンドシェイクに問題がある、のいずれかです。SSL ハンドシェイク問題については、ユーザ ブラウザで SSLv3 が許可されているかどうか（一部では SSLv2 のみ許可）、また証明書検証での頻度を確認できます。
     
     共通して、DNS なしで Web ページが表示されるかどうかを確認するには、http://192.0.2.1 を手動で入力します。実際、http://10.0.0.0 を入力しても効果は同じです。WLC は、入力された IP アドレスをリダイレクトします。そのため、http://192.0.2.1 と入力しても、Web リダイレクションは回避されません。https://192.0.2.1（セキュア）と入力した場合、WLCはHTTPSトラフィックをリダイレクトしないため、これは機能しません（デフォルトでは、これはバージョン8.0以降で実際に可能です）。リダイレクトせずにページを直接ロードする最良の方法は、https://192.0.2.1/login.html を入力することです。
     
     
• ユーザが認証できない。
  
  このドキュメントで認証について説明しているセクションを参照してください。RADIUS でローカルにクレデンシャルを確認します。
  
  
• ユーザが WebAuth を介して正常に認証できるが、その後インターネットにアクセスできない。
  
  WLANのセキュリティからWebAuthを削除してから、WLANを開きます。次に、Web や DNS などにアクセスできます。ここでも問題が発生する場合、WebAuth 設定も削除して、インターフェイス設定を確認します。
  
  

詳細については、「ワイヤレスLANコントローラ(WLC)でのWeb認証のトラブルシューティング」を参照してください。

HTTP プロキシ サーバとその動作方法

HTTP プロキシ サーバを使用できます。192.0.2.1 がプロキシ サーバを通過しない例外をクライアントのブラウザに追加する必要がある場合、プロキシ サーバのポート（通常は 8080）で HTTP トラフィックに対する WLC リッスンを作成できます。

この状況を理解するには、HTTP プロキシの動作を認識する必要があります。これは、ブラウザでのクライアント側の設定内容（IP アドレスおよびポート）です。

ユーザが Web サイトにアクセスする場合、通常、DNS で名前が IP に解決され、Web ページから Web サーバに要求されます。プロセスは常にページのHTTP要求をプロキシに送信します。

プロキシは、必要に応じて DNS を処理し、Web サーバに転送します（ページがプロキシでキャッシュされていない場合）。記述は、クライアントとプロキシ間のみです。プロキシが実際の Web ページを取得するかどうかは、クライアントとは関係ありません。

次に、Web 認証プロセスを示します。

• ユーザが URL を入力します。

• クライアント PC がプロキシ サーバに送信します。

• WLCが代行受信してプロキシサーバIPを模倣し、192.0.2.1へのリダイレクトでPCに応答します。

この段階で、PC が設定されていない場合、プロキシに 192.0.2.1 WebAuth ページが要求されるので、機能しません。PCは192.0.2.1に対して例外を作成する必要があります。その後、192.0.2.1にHTTP要求を送信し、WebAuthに進みます。

認証されると、すべての通信が再びプロキシを通過します。例外設定は、通常、プロキシ サーバの設定同様、ブラウザにあります。次に、「Do not use proxy for these IP addresses」というメッセージが表示されます。

WLCリリース7.0以降では、この機能は webauth proxy redirect グローバルWLC設定オプションで有効にできます。

有効にされると、WLC は、クライアントがプロキシを手動で使用するように設定されているか確認します。この場合、クライアントは、正常に機能するようにプロキシ設定を変更する方法を示すページにリダイレクトされます。

WebAuth プロキシ リダイレクトは、さまざまなポートで機能するように設定でき、中央 Web 認証に対応します。

WebAuth プロキシ リダイレクションの例については、「Web Authentication Proxy on a Wireless LAN Controller Configuration Example」を参照してください。

HTTPS ではなく HTTP での Web 認証

HTTPS ではなく HTTP で Web 認証にログインできます。HTTP でログインする場合、証明書アラートは受け取りません。

WLC リリース 7.2 よりも前のコードでは、WLC の HTTPS 管理を無効にし、HTTP 管理をそのままにしておく必要があります。ただし、この場合、HTTP を介した WLC の Web 管理だけが許可されます。

WLCリリース7.2のコードの場合は、 config network web-auth secureweb disable コマンドを使用して無効にします。この場合、管理ではなく、Web 認証の HTTPS だけが無効になります。この場合、コントローラをリブートする必要があることに注意してください。

WLC リリース 7.3 以降のコードでは、GUI および CLI を介してのみ WebAuth の HTTPS を有効/無効にできます。

関連情報

• ワイヤレス LAN コントローラの Web 認証の設定例
• ワイヤレス コントローラ WebAuth バンドルのソフトウェアのダウンロード
• カスタマイズされた Web 認証ログイン ページの作成
• ワイヤレス LAN コントローラを使用した外部 Web 認証の設定例
• ワイヤレス LAN コントローラ 5760/3850 の Web パススルーの設定例
• Webリダイレクトの設定(GUI)
• Webリダイレクトの設定(CLI)
• 『ワイヤレス LAN コントローラ（WLC）上の Web 認証のトラブルシューティング』
• ワイヤレス LAN コントローラ上の Web 認証プロキシの設定例
• Requests for Comments (RFCs)
• テクニカル サポートとドキュメント - Cisco Systems