Web ベース認証について
Web ベース認証の概要
IEEE 802.1x サプリカントが実行されていないホストシステムでエンドユーザを認証するには、Web 認証プロキシとして知られている Web ベース認証機能を使用します。
HTTP セッションを開始すると、Web ベース認証は、ホストからの入力 HTTP パケットを代行受信し、ユーザに HTML ログイン ページを送信します。ユーザはクレデンシャルを入力します。このクレデンシャルは、Web ベース認証機能により、認証のために認証、許可、アカウンティング(AAA)サーバに送信されます。
認証が成功すると、Web ベース認証はログイン成功 HTML ページをホストに送信し、AAA サーバから返されたアクセス ポリシーを適用します。
認証に失敗した場合、Web ベース認証は、ログインの失敗を示す HTML ページをユーザに転送し、ログインを再試行するように、ユーザにプロンプトを表示します。最大試行回数を超過した場合、Web ベース認証は、ログインの期限切れを示す HTML ページをホストに転送し、このユーザは待機期間中、ウォッチ リストに載せられます。
(注) |
中央 Web 認証リダイレクト用の HTTPS トラフィック インターセプションはサポートされていません。 |
(注) |
グローバル パラメータ マップ(method-type、custom、redirect)は、すべてのクライアントおよび SSID で同じ Web 認証方式(consent、web consent、webauth など)を使用するときにのみ使用する必要があります。これにより、すべてのクライアントが同じ Web 認証方式になります。 要件により、1 つの SSID に consent、別の SSID に webauth を使用する場合、名前付きパラメータ マップを 2 つ使用する必要があります。1 番目のパラメータ マップには consent を設定し、2 番目のパラメータ マップには webauth を設定する必要があります。 |
(注) |
Webauth クライアントの認証試行時に受信する traceback には、パフォーマンスや行動への影響はありません。これは、ACL アプリケーションの EPM に FFM が返信したコンテキストがすでにキュー解除済み(タイマーの有効期限切れの可能性あり)で、セッションが「未承認」になった場合にまれに発生します。 |
Web ページがホストされている場所に基づいて、ローカル Web 認証は次のように分類できます。
-
内部:ローカル Web 認証時に、コントローラの内部デフォルト HTML ページ(ログイン、成功、失敗、および期限切れ)が使用されます。
-
カスタマイズ:ローカル Web 認証時に、カスタマイズされた Web ページ(ログイン、成功、失敗、および期限切れ)がコントローラにダウンロードされ、使用されます。
-
外部:組み込みまたはカスタム Web ページを使用する代わりに、外部 Web サーバ上でカスタマイズされた Web ページがホストされます。
さまざまな Web 認証ページに基づき、Web 認証のタイプは次のように分類できます。
-
Webauth:これが基本的な Web 認証です。この場合、コントローラはユーザ名とパスワードの入力が必要なポリシー ページを提示します。ネットワークにアクセスするには、ユーザは正しいクレデンシャルを入力する必要があります。
-
Consent または web-passthrough:この場合、コントローラは [Accept] ボタンまたは [Deny] ボタンが表示されたポリシー ページを提示します。ネットワークにアクセスするには、ユーザは [Accept] ボタンをクリックする必要があります。
-
Webconsent:これは webauth と consent の Web 認証タイプの組み合わせです。この場合、コントローラは [Accept] ボタンまたは [Deny] ボタンがあり、ユーザ名とパスワードの入力が必要なポリシー ページを提示します。ネットワークにアクセスするには、ユーザは正しいクレデンシャルを入力して [Accept] ボタンをクリックする必要があります。
デバイスのロール
Web ベース認証では、ネットワーク上のデバイスに次のような固有の役割があります。
-
クライアント:LAN およびサービスへのアクセスを要求し、スイッチからの要求に応答するデバイス(ワークステーション)。このワークステーションでは、Java Script がイネーブルに設定された HTML ブラウザが実行されている必要があります。
-
認証サーバ:クライアントを認証します。認証サーバはクライアントの識別情報を確認し、そのクライアントが LAN およびスイッチのサービスへのアクセスを許可されたか、あるいはクライアントが拒否されたのかをスイッチに通知します。
-
スイッチ:クライアントの認証ステータスに基づいて、ネットワークへの物理アクセスを制御します。スイッチはクライアントと認証サーバとの仲介デバイス(プロキシ)として動作し、クライアントに識別情報を要求し、その情報を認証サーバで確認し、クライアントに応答をリレーします。
ホストの検出
スイッチは、検出されたホストに関する情報を格納するために、IP デバイス トラッキング テーブルを維持します。
レイヤ 2 インターフェイスでは、Web ベース認証は、これらのメカニズムを使用して、IP ホストを検出します。
-
ARP ベースのトリガー:ARP リダイレクト ACL により、Web ベース認証は、スタティック IP アドレス、またはダイナミック IP アドレスを持つホストを検出できます。
-
ダイナミック ARP インスペクション
-
DHCP スヌーピング:スイッチがホストの DHCP バインディング エントリを作成するときに Web ベース認証が通知されます。
セッションの作成
Web ベース認証により、新しいホストが検出されると、次のようにセッションが作成されます。
-
例外リストをレビューします。
ホスト IP が例外リストに含まれている場合、この例外リスト エントリからポリシーが適用され、セッションが確立されます。
-
認証バイパスをレビューします。
ホスト IP が例外リストに含まれていない場合、Web ベース認証は応答しないホスト(NRH)要求をサーバに送信します。
サーバの応答が access accepted であった場合、認証はこのホストにバイパスされます。セッションが確立されます。
-
HTTP インターセプト ACL を設定します。
NRH 要求に対するサーバの応答が access rejected であった場合、HTTP インターセプト ACL がアクティブ化され、セッションはホストからの HTTP トラフィックを待機します。
認証プロセス
Web ベース認証をイネーブルにすると、次のイベントが発生します。
-
ユーザが HTTP セッションを開始します。
-
HTTP トラフィックが代行受信され、認証が開始されます。スイッチは、ユーザにログイン ページを送信します。ユーザはユーザ名とパスワードを入力します。スイッチはこのエントリを認証サーバに送信します。
-
認証に成功した場合、スイッチは認証サーバからこのユーザのアクセス ポリシーをダウンロードし、アクティブ化します。ログインの成功ページがユーザに送信されます
-
認証に失敗した場合は、スイッチはログインの失敗ページを送信します。ユーザはログインを再試行します。失敗の回数が試行回数の最大値に達した場合、スイッチはログイン期限切れページを送信します。このホストはウォッチ リストに入れられます。ウォッチ リストのタイム アウト後、ユーザは認証プロセスを再試行することができます。
-
認証サーバがスイッチに応答せず、AAA 失敗ポリシーが設定されている場合、スイッチはホストに失敗アクセス ポリシーを適用します。ログインの成功ページがユーザに送信されます
-
ホストがレイヤ 2 インターフェイス上の ARP プローブに応答しなかった場合、またはホストがレイヤ 3 インターフェイスでアイドル タイムアウト内にトラフィックを送信しなかった場合、スイッチはクライアントを再認証します。
-
ホストがレイヤ 2 インターフェイス上の ARP プローブに応答しない場合、スイッチはクライアントを再認証します。
-
この機能は、ダウンロードされたタイムアウト、またはローカルに設定されたセッション タイムアウトを適用します。
-
Termination-Action が RADIUS である場合、この機能は、サーバに NRH 要求を送信します。Termination-Action は、サーバからの応答に含まれます。
-
Termination-Action がデフォルトである場合、セッションは廃棄され、適用されたポリシーは削除されます。
ローカル Web 認証バナー
Web 認証を使用して、デフォルトのカスタマイズ済み Web ブラウザ バナーを作成して、スイッチにログインしたときに表示するようにできます。
このバナーは、ログイン ページと認証結果ポップアップ ページの両方に表示されます。デフォルトのバナー メッセージは次のとおりです。
-
認証成功
-
認証失敗
-
認証期限切れ
ローカル Web 認証バナーは、次のように設定できます。
-
レガシー モード:ip admission auth-proxy-banner http グローバル コンフィギュレーション コマンドを使用します。
-
新スタイル モード:parameter-map type webauth global banner グローバル コンフィギュレーション コマンドを使用します。
ログイン ページには、デフォルトのバナー、Cisco Systems、および Switch host-name Authentication が表示されます。Cisco Systems は認証結果ポップアップ ページに表示されます。
バナーは次のようにカスタマイズ可能です。
-
スイッチ名、ルータ名、または会社名などのメッセージをバナーに追加する。
-
レガシーモード: ip admission auth-proxy-banner http banner-text グローバル コンフィギュレーション コマンドを使用します。
-
新スタイル モード:parameter-map type webauth global banner グローバル コンフィギュレーション コマンドを使用します。
-
-
ロゴまたはテキスト ファイルをバナーに追加する。
-
レガシーモード:ip admission auth-proxy-banner http file-path グローバル コンフィギュレーション コマンドを使用します。
-
新スタイル モード:parameter-map type webauth global banner グローバル コンフィギュレーション コマンドを使用します。
-
バナーがイネーブルにされていない場合、Web 認証ログイン画面にはユーザ名とパスワードのダイアログボックスだけが表示され、スイッチにログインしたときにはバナーは表示されません。
Web 認証カスタマイズ可能な Web ページ
Web ベース認証プロセスでは、スイッチ内部の HTTP サーバは、認証中のクライアントに配信される 4 種類の HTML ページをホストします。サーバはこれらのページを使用して、ユーザに次の 4 種類の認証プロセス ステートを通知します。
-
ログイン:資格情報が要求されています。
-
成功:ログインに成功しました。
-
失敗:ログインに失敗しました。
-
期限切れ:ログインの失敗回数が多すぎて、ログイン セッションが期限切れになりました。
ガイドライン
-
デフォルトの内部 HTML ページの代わりに、独自の HTML ページを使用することができます。
-
ロゴを使用することもできますし、ログイン、成功、失敗、および期限切れ Web ページでテキストを指定することもできます。
-
バナー ページで、ログイン ページのテキストを指定できます。
-
これらのページは、HTML で記述されています。
-
成功ページには、特定の URL にアクセスするための HTML リダイレクト コマンドを記入する必要があります。
-
この URL 文字列は有効な URL(例:http://www.cisco.com)でなければなりません。不完全な URL は、Web ブラウザで、「ページが見つかりません」またはこれに類似するエラーの原因となる可能性があります。
-
HTTP 認証で使用される Web ページを設定する場合、これらのページには適切な HTML コマンド(例:ページのタイム アウトを設定、暗号化されたパスワードの設定、同じページが 2 回送信されていないことの確認など)を記入する必要があります.
-
設定されたログイン フォームがイネーブルにされている場合、特定の URL にユーザをリダイレクトする CLI コマンドは使用できません。管理者は、Web ページにリダイレクトが設定されていることを保証する必要があります。
-
認証後、特定の URL にユーザをリダイレクトする CLI コマンドを入力してから、Web ページを設定するコマンドを入力した場合、特定の URL にユーザをリダイレクトする CLI コマンドは効力を持ちません。
-
設定された Web ページは、スイッチのブート フラッシュ、またはフラッシュにコピーできます。
-
スタック可能なスイッチでは、アクティブスイッチまたはメンバスイッチのフラッシュから設定済みのページにアクセスできます。
-
ログインページを任意のフラッシュ上に、成功ページと失敗ページを別のフラッシュ(たとえば、アクティブスイッチ、またはメンバスイッチのフラッシュ)に配置できます。
-
4 ページすべてを設定する必要があります。
-
Web ページを使ってバナー ページを設定した場合、このバナー ページには効果はありません。
-
システム ディレクトリ(たとえば、flash、disk0、disk)に保存されていて、ログイン ページに表示する必要のあるロゴ ファイル(イメージ、フラッシュ、オーディオ、ビデオなど)すべてには、必ず、web_auth_<filename> の形式で名前をつけてください。
-
設定された認証プロキシ機能は、HTTP と SSL の両方をサポートしています。
デフォルトの内部 HTML ページの代わりに、自分の HTML ページを使用することができます。認証後のユーザのリダイレクト先で、内部成功ページの代わりとなる URL を指定することもできます。
認証プロキシ Web ページの注意事項
カスタマイズされた認証プロキシ Web ページを設定する際には、次の注意事項に従ってください。
-
カスタム Web ページ機能をイネーブルにするには、カスタム HTML ファイルを 4 個すべて指定します。指定したファイルの数が 4 個未満の場合、内部デフォルト HTML ページが使用されます。
-
これら 4 個のカスタム HTML ファイルは、スイッチのフラッシュ メモリ内に存在しなければなりません。各 HTML ファイルの最大サイズは 8 KB です。
-
カスタム ページ上のイメージはすべて、アクセス可能は HTTP サーバ上に存在しなければなりません。インターセプト ACL は、管理ルール内で設定します。
-
カスタム ページからの外部リンクはすべて、管理ルール内でのインターセプト ACL の設定を必要とします。
-
有効な DNS サーバにアクセスするには、外部リンクまたはイメージに必要な名前解決で、管理ルール内にインターセプト ACL を設定する必要があります。
-
カスタム Web ページ機能がイネーブルに設定されている場合、設定された auth-proxy-banner は使用されません。
-
カスタム Web ページ機能がイネーブルに設定されている場合、ログインの成功に対するリダイレクション URL は使用できません。
-
カスタム ファイルの指定を解除するには、このコマンドの no 形式を使用します。
カスタム ログイン ページはパブリック Web フォームであるため、このページについては、次の注意事項に従ってください。
-
ログイン フォームは、ユーザによるユーザ名とパスワードの入力を受け付け、これらを uname および pwd として示す必要があります。
-
カスタム ログイン ページは、ページ タイムアウト、暗号化されたパスワード、冗長送信の防止など、Web フォームに対するベスト プラクティスに従う必要があります。
成功ログインに対するリダイレクト URL の注意事項
成功ログインに対するリダイレクション URL を設定する場合、次の注意事項に従ってください。
-
カスタム認証プロキシ Web ページ機能がイネーブルに設定されている場合、リダイレクション URL 機能はディセーブルにされ、CLI では使用できません。リダイレクションは、カスタム ログイン成功ページで実行できます。
-
リダイレクション URL 機能が有効に設定されている場合、設定された auth-proxy-banner は使用されません。
-
リダイレクション URL の指定を解除するには、このコマンドの no 形式を使用します。
-
Web ベースの認証クライアントが正常に認証された後にリダイレクション URL が必要な場合、URL 文字列は有効な URL(たとえば http://)で開始し、その後に URL 情報が続く必要があります。http:// を含まない URL が指定されると、正常に認証が行われても、そのリダイレクション URL によって Web ブラウザでページが見つからないまたは同様のエラーが生じる場合があります。
その他の機能と Web ベース認証の相互作用
ポート セキュリティ
Web ベース認証とポート セキュリティは、同じポートに設定できます。Web ベース認証はポートを認証し、ポート セキュリティは、クライアントの MAC アドレスを含むすべての MAC アドレスに対するネットワーク アクセスを管理します。この場合、このポートを介してネットワークへアクセスできるクライアントの数とグループを制限できます。
LAN ポート IP
LAN ポート IP(LPIP)とレイヤ 2 Web ベース認証は、同じポートに設定できます。ホストは、まず Web ベース認証、次に LPIP ポスチャ検証を使用して認証されます。LPIP ホスト ポリシーは、Web ベース認証のホスト ポリシーに優先されます。
Web ベース認証のアイドル時間が満了すると、NAC ポリシーは削除されます。ホストが認証され、ポスチャが再度検証されます。
ゲートウェイ IP
VLAN のいずれかのスイッチ ポートで Web ベース認証が設定されている場合、レイヤ 3 VLAN インターフェイス上にゲートウェイ IP(GWIP)を設定することはできません。
Web ベース認証はゲートウェイ IP と同じレイヤ 3 インターフェイスに設定できます。ソフトウェアで、両方の機能のホスト ポリシーが適用されます。GWIP ホスト ポリシーは、Web ベース認証のホスト ポリシーに優先されます。
ACL
インターフェイスで VLAN ACL、または Cisco IOS ACL を設定した場合、ACL は、Web ベース認証のホスト ポリシーが適用された後だけ、ホスト トラフィックに適用されます。
レイヤ 2 Web ベース認証では、ポートに接続されたホストからの入力トラフィックについて、ポート ACL(PACL)をデフォルトのアクセス ポリシーとして設定することが必須ではないものの、より安全です。認証後、Web ベース認証のホスト ポリシーは、PACL に優先されます。ポートに設定された ACL がなくても、ポリシー ACL はセッションに適用されます。
MAC ACL と Web ベース認証を同じインターフェイスに設定することはできません。
アクセス VLAN が VACL キャプチャ用に設定されているポートには Web ベース認証は設定できません。
コンテキストベース アクセス コントロール
コンテキストベース アクセス コントロール(CBAC)が、ポート VLAN のレイヤ 3 VLAN インターフェイスで設定されている場合、レイヤ 2 ポートで Web ベース認証は設定できません。
EtherChannel
Web ベース認証は、レイヤ 2 EtherChannel インターフェイス上に設定できます。Web ベース認証設定は、すべてのメンバ チャネルに適用されます。