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

はじめに

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

前提条件

要件

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

使用するコンポーネント

このドキュメントの情報は、AireOS 8.xを使用するすべての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はその要求をインターセプトし、WebサイトのIPアドレスを模倣した「webauth」ログインページを返します。外部WebAuthを使用すると、WLCはWebサイトのIPアドレスを含むHTTP応答で応答し、ページが移動したことを示します。

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

要約すると、WLCでは、クライアントは、WEBAUTH_REQD 状態で、DNSを解決してIPアドレスを自動的に取得できます。

ポート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/秒
1番目の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 を設定する方法

カスタムwebauthは、Securityタブの「redirectUrl」で設定できます。これにより、入力した特定のWebページに強制的にリダイレクトされます。

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

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

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

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

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

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

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

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

カスタムページを設定するには、『シスコワイヤレス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アドレス)、スイッチのWebサーバへの接続に必要なaction_URLなどのパラメータが付加されます。
   
   
3. 外部 Web サーバ URL は、ユーザをログイン ページに送信します。ユーザは、事前認証アクセスコントロールリスト(ACL)を使用してサーバにアクセスできます。
   
   
4. ログインページが、WLC Webサーバのaction_URLにユーザクレデンシャル要求(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)ペアで応答します。

その後、ISEが認可変更(CoA)要求で許可するまで、ユーザはPOSTURE_REQD状態になります。同様のことは、Posture または Central WebAuth でも発生します。

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

外部ユーザ認証（RADIUS）

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

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

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

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

3. 次に、グローバルRADIUSサーバリストを、network userがチェックされるRADIUSサーバと照合してチェックします。

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

これは、グローバルリストのRADIUSサーバで「network user」がチェックされるためです。

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つのコントローラを使用して設定できます（一方が自動アンカーの場合のみ）。

有線ゲストユーザの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」タブには、「Ingress」および「Egress」の2つのドロップダウンリストがあります。Ingressはユーザの送信元のVLAN(VLAN 50)、Egressはユーザの送信先のVLANです。
   
   Ingressでは、VLAN50を選択します。
   
   Egressの場合は異なります。コントローラが1つのみの場合は、別のダイナミックインターフェイスを作成し、今度は「standard」（ゲストLANではない）を作成して、このインターフェイスに有線ユーザを送信します。この場合、DMZ コントローラに送信します。したがって、インターEgress フェイスに対しては、Management Interfaceを選択します。
   
   このゲストLANの「WLAN」の「Security」モードはWebAuthです。これは許容範囲です。検証するにはOkをクリックします。
   
   
3. 外部コントローラ（本社）を設定します。
   
   WLAN listの行の最後にあるMobility Anchorをクリックして、使用しているDMZコントローラをGuest LAN選択します。ここでは、両方のコントローラが互いを認識することを前提としています。増加していない場合は、Controller > Mobility Management > Mobility groupに移動し、WLC1に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 設定を調整することもできます。設定は両端で同じにする必要があります。たとえば、WLC1のWLAN AdvancedタブでAllow AAA overrideをクリックする場合、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インターフェイス)に移動し、myWLC . comなどのvirtual DNS hostnameを入力します。

これにより、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出力では、「issued by」が提供されたCA証明書の名前と一致しないため、opensslでデバイス証明書を検証できないことに注意してください。

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)
---

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

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

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

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

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

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

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 その結果、パスワードcheck123を持つ.pemが動作するようになります。
   
   

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

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

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

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

• ユーザをゲスト WLAN に関連付けることができない。
  
  これは、WebAuth に関連するものです。クライアント設定、WLAN のセキュリティ設定、これが有効にされているかどうか、無線がアクティブで機能しているかどうかなどを確認します。
  
  
• ユーザが IP アドレスを取得できない。
  
  ゲスト アンカーの場合、これは多くの場合、外部およびアンカーが同じ方法で設定されていない場合に発生します。それ以外の場合、DHCP 設定や接続などを確認します。
• 他の WLAN が同じ DHCP サーバを正常に使用できるかどうかを確認します。これは、WebAuth とは関係ありません。
  
  
• ユーザがログイン ページにリダイレクトされない。
  
  これは、一般的な症状ですが、より正確に説明します。この問題が発生する状況は次の 2 つあります。
  
  
  1. ユーザがリダイレクトされない（ユーザが URL を入力しても、WebAuth ページにアクセスできない）。 この場合、次のことを確認します。
     
     
     • 有効なDNSサーバがDHCP(ipconfig /all)経由でクライアントに割り当てられていることを確認します。
       
       
     • DNSにクライアントからアクセスできることを確認します(nslookup (website URL)。
       
       
     • リダイレクトされる有効な 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(secure)と入力しても機能しません。これは、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に対して例外を作成する必要があります。次にHTTP要求を192.0.2.1に送信し、WebAuthに進みます。

認証されると、すべての通信が再びプロキシを通過します。例外設定は、通常、プロキシ サーバの設定同様、ブラウザにあります。次に、「これらのIPアドレスにはプロキシを使用しない」というメッセージが表示されます。

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

有効にされると、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