Web ベース認証の制約事項
-
Web ベース認証と URL リダイレクトは、同じポートで同時にはサポートされません。
The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
Web ベース認証機能(別名 Web 認証プロキシ)は、IEEE 802.1x サプリカントが実行されていないホスト システムのエンド ユーザを認証します。
Web ベース認証と URL リダイレクトは、同じポートで同時にはサポートされません。
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 がデフォルトである場合、セッションは廃棄され、適用されたポリシーは削除されます。
認証プロキシ機能は、クライアント ホスト上でユーザとの対話を必要とします。次の表で、認証プロキシとクライアント ホストの対話について説明します。
|
認証プロキシのクライアントとの動作 |
説明 |
|---|---|
|
HTTP 接続の開始 |
ユーザが現在ファイアウォール ルータで認証済みでない場合、ユーザが HTTP 接続を開始すると認証プロキシが起動されます。ユーザがすでに認証済みの場合、認証プロキシはユーザに対して透過的です。 |
|
ログイン ページを使用したログイン |
認証プロキシをトリガーすると、HTML ベースのログイン ページが生成されます。ユーザは、AAA サーバで認証されるために、ユーザ名とパスワードを入力する必要があります。How the Authentication Proxy Works モジュールの Authentication Proxy Login Page の図で、認証プロキシのログイン ページを図示しています。 |
|
クライアントでのユーザの認証 |
ログインの試行の後の認証プロキシの動作は、ブラウザで JavaScript がイネーブルになっているかどうかで変わります。JavaScript が有効なときに認証が成功した場合、認証プロキシは、How the Authentication Proxy Works モジュールの Authentication Proxy Login Status Message の図に示すように、認証のステータスを示すメッセージを表示します。認証ステータスが表示された後、プロキシは自動的に HTTP 接続を完了します。 JavaScript がディセーブルになっており、認証が成功した場合、認証プロキシは、接続を完了するための追加の手順を表示したポップアップ ウィンドウを生成します。Secure Authentication モジュールの Authentication Proxy Login Status Message with JavaScript Disabled の図を参照してください。 いずれの場合も、認証が成功しなかった場合は、ユーザはログイン ページから再度ログインする必要があります。 |
認証プロキシは、次のような状況で使用できます。
ホスト IP アドレスやグローバルアクセスポリシーに基づいてアクセスコントロールを設定するのではなく、認証サーバによって提供されているサービスを使用して、個人ごと(ユーザごと)にアクセス権を管理する場合。任意のホスト IP アドレスからのユーザを認証および認可することにより、ネットワーク管理者は、DHCP を使用してホスト IP アドレスを設定できるようにもなります。
イントラネットやインターネットサービスへのアクセスを許可する前に、ローカルユーザを認証および認可する場合。
ローカルサービスへのアクセスを許可する前に、リモートユーザを認証および認可する場合。
特定のエクストラネットユーザに対するアクセスを制御する場合。たとえば、企業パートナーの財務責任者を、あるアクセス権のセットを使用して認証および認可し、同じパートナーの技術責任者を、別のアクセス権のセットを使用するように認可することができます。
認証プロキシを VPN クライアントソフトウェアとともに使用して、ユーザを検証し、特定のアクセス権を割り当てる場合。
認証プロキシを AAA アカウンティングとともに使用して、課金、セキュリティ、またはリソース割り当てのために使用可能な開始および終了アカウンティングレコードを生成することで、ユーザが認証済みホストからのトラフィックを追跡できるようにする場合。
認証プロキシは、ユーザごとの認証と認可を行うルータの任意のインターフェイスで、インバウンド方向に適用します。認証プロキシをインターフェイスでインバウンド方向に適用すると、ユーザからの初期接続要求が、他の処理に渡される前に、認証プロキシによって代行受信されます。ユーザが AAA サーバによる認証に失敗すると、接続要求はドロップされます。
認証プロキシの適用方法は、セキュリティ ポリシーに依存します。たとえば、インターフェイスを通過するすべてのトラフィックをブロックし、認証プロキシ機能を有効にして、ユーザが開始したすべての HTTP 接続に対して認証と認可を義務付けることができます。ユーザは、AAA サーバで正常に認証されない限り、サービスの利用が認可されません。
認証プロキシ機能では、標準のアクセス リストを使用し、どのホストまたはホスト グループからの初期 HTTP トラフィックに対してプロキシを起動するかを指定できます。
下の図に示す認証プロキシは、LAN インターフェイスに適用されており、すべてのネットワーク ユーザは、初期接続時に認証される必要があります(すべてのトラフィックは各インターフェイスでブロックされます)。

下の図に示す認証プロキシは、ダイヤルイン インターフェイスに適用され、すべてのネットワーク トラフィックが各インターフェイスでブロックされます。

Web 認証を使用して、デフォルトのカスタマイズ済み Web ブラウザ バナーを作成して、スイッチにログインしたときに表示するようにできます。
このバナーは、ログイン ページと認証結果ポップアップ ページの両方に表示されます。デフォルトのバナー メッセージは次のとおりです。
認証成功
認証失敗
認証期限切れ
ローカル ネットワーク認証バナーは、レガシーおよび新スタイル(セッション アウェア)CLI で次のように設定できます。
レガシーモード: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 ベース認証プロセスでは、スイッチ内部の 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 ページは、スイッチのブート フラッシュ、またはフラッシュにコピーできます。
ログイン ページを 1 つのフラッシュ上に、成功ページと失敗ページを別のフラッシュ(たとえば、スタック マスター、またはメンバのフラッシュ)にすることができます。
4 ページすべてを設定する必要があります。
Web ページを使ってバナー ページを設定した場合、このバナー ページには効果はありません。
システム ディレクトリ(たとえば、flash、disk0、disk)に保存されていて、ログイン ページに表示する必要のあるロゴ ファイル(イメージ、フラッシュ、オーディオ、ビデオなど)すべてには、必ず、web_auth_<filename> の形式で名前をつけてください。
設定された認証プロキシ機能は、HTTP と SSL の両方をサポートしています。
デフォルトの内部 HTML ページの代わりに、自分の HTML ページを使用することができます。認証後のユーザのリダイレクト先で、内部成功ページの代わりとなる URL を指定することもできます。

カスタマイズされた認証プロキシ 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 フォームに対するベスト プラクティスに従う必要があります。
認証プロキシを使用して、課金やセキュリティ監査で使用できる十分な情報を含む開始および終了アカウンティングレコードを生成できます。そうすることで、認証プロキシ サービスを使用する認証済みホストの動作をモニタできます。
認証プロキシのキャッシュが満了して削除されると、経過時間などの追加のデータがアカウンティング情報に追加され、終了レコードがサーバに送信されます。この時点で、情報がデータ構造から削除されます。
認証プロキシ ユーザ セッションに対するアカウンティング レコードは、キャッシュおよび動的 ACL の使用に関連付けられます。
Web ベースの認証を行うには、インターフェイスでポート ACL を設定する必要があります。
Web ベースの認証を実行できる十分な TCAM 容量があることを確認します。
インターフェイスで VLAN ACL、または Cisco IOS ACL を設定した場合、ACL は、Web ベース認証のホスト ポリシーが適用された後だけ、ホスト トラフィックに適用されます。
レイヤ 2 Web ベース認証では、ポートに接続されたホストからの入力トラフィックについて、ポート ACL(PACL)をデフォルトのアクセス ポリシーとして設定することが必須ではないものの、より安全です。認証後、Web ベース認証のホスト ポリシーは、PACL に優先されます。ポートに設定された ACL がなくても、ポリシー ACL はセッションに適用されます。
MAC ACL と Web ベース認証を同じインターフェイスに設定することはできません。
アクセス VLAN が VACL キャプチャ用に設定されているポートには Web ベース認証は設定できません。
VLAN のいずれかのスイッチ ポートで Web ベース認証が設定されている場合、レイヤ 3 VLAN インターフェイス上にゲートウェイ IP(GWIP)を設定することはできません。
Web ベース認証はゲートウェイ IP と同じレイヤ 3 インターフェイスに設定できます。ソフトウェアで、両方の機能のホスト ポリシーが適用されます。GWIP ホスト ポリシーは、Web ベース認証のホスト ポリシーに優先されます。
LAN ポート IP(LPIP)とレイヤ 2 Web ベース認証は、同じポートに設定できます。ホストは、まず Web ベース認証、次に LPIP ポスチャ検証を使用して認証されます。LPIP ホスト ポリシーは、Web ベース認証のホスト ポリシーに優先されます。
Web ベース認証のアイドル時間が満了すると、NAC ポリシーは削除されます。ホストが認証され、ポスチャが再度検証されます。
Web ベース認証とポート セキュリティは、同じポートに設定できます。Web ベース認証はポートを認証し、ポート セキュリティは、クライアントの MAC アドレスを含むすべての MAC アドレスに対するネットワーク アクセスを管理します。この場合、このポートを介してネットワークへアクセスできるクライアントの数とグループを制限できます。
次の表に、デフォルトの Web ベース認証の設定を示しています。
|
機能 |
デフォルト設定 |
|---|---|
|
AAA |
無効 |
|
RADIUS サーバ
|
|
|
無活動タイムアウトのデフォルト値 |
3600 秒 |
|
無活動タイムアウト |
イネーブル |
Web ベース認証は入力だけの機能です。
Web ベース認証は、アクセス ポートだけで設定できます。Web ベース認証は、トランク ポート、EtherChannel メンバ ポート、またはダイナミック トランク ポートではサポートされていません。
スイッチが特定のホストまたは Web サーバにクライアントをリダイレクトしてログイン メッセージを表示する場合、外部 Web 認証はサポートされません。
スタティックな ARP キャッシュが割り当てられているレイヤ 2 インターフェイス上のホストは認証できません。これらのホストは ARP メッセージを送信しないため、Web ベース認証機能では検出されません。
デフォルトでは、スイッチの IP 装置追跡機能はディセーブルにされています。Web ベース認証を使用するには、IP デバイスのトラッキング機能をイネーブルにする必要があります。
スイッチ HTTP サーバを実行するには、IP アドレスを少なくとも 1 つ設定する必要があります。また、各ホスト IP アドレスに到達するようにルートを設定する必要もあります。HTTP サーバは、ホストに HTTP ログイン ページを送信します。
2 ホップ以上離れたところにあるホストでは、STP トポロジの変更により、ホスト トラフィックの到着するポートが変わってしまった場合、トラフィックが停止する可能性があります。これは、レイヤ 2(STP)トポロジの変更後に、ARP および DHCP の更新が送信されていない場合に発生します。
Web ベース認証は、ダウンロード可能なホスト ポリシーとして、VLAN 割り当てをサポートしていません。
Web ベース認証は、セッション認識型ポリシー モードで IPv6 をサポートします。IPv6 Web 認証には、スイッチで設定された少なくとも 1 つの IPv6 アドレスおよびスイッチ ポートに設定された IPv6 スヌーピングが必要です。
Web ベース認証および Network Edge Access Topology(NEAT)は、相互に排他的です。インターフェイス上で NEAT がイネーブルの場合、Web ベース認証を使用できず、インターフェイス上で Web ベース認証が実行されている場合は、NEAT を使用できません。
スイッチから RADIUS サーバへの通信の設定に使用される次の RADIUS セキュリティ サーバ設定を確認します。
ホスト名
ホスト IP アドレス
ホスト名と特定の UDP ポート番号
IP アドレスと特定の UDP ポート番号
IP アドレスと UDP ポート番号の組み合わせによって、一意の ID が作成され、サーバの同一 IP アドレス上にある複数の UDP ポートに RADIUS 要求を送信できるようになります。同じ RADIUS サーバ上の異なる 2 つのホスト エントリに同じサービス(たとえば認証)を設定した場合、2 番めに設定されたホスト エントリは、最初に設定されたホスト エントリのフェールオーバー バックアップとして動作します。RADIUS ホスト エントリは、設定した順序に従って選択されます。
RADIUS サーバ パラメータを設定する場合は、次の点に注意してください。
別のコマンドラインに、key string を指定します。
key string には、スイッチと、RADIUS サーバ上で動作する RADIUS デーモンとの間で使用する、認証および暗号キーを指定します。キーは、RADIUS サーバで使用する暗号キーに一致するテキスト文字列でなければなりません。
key string を指定する場合、キーの中間、および末尾にスペースを使用します。キーにスペースを使用する場合は、引用符がキーの一部分である場合を除き、引用符でキーを囲まないでください。キーは RADIUS デーモンで使用する暗号に一致している必要があります。
すべての RADIUS サーバについて、タイムアウト、再送信回数、および暗号キー値をグローバルに設定するには、radius-server host グローバル コンフィギュレーション コマンドを使用します。これらのオプションをサーバ単位で設定するには、radius-server timeout 、radius-server transmit、および radius-server key グローバル コンフィギュレーション コマンドを使用します。
![]() (注) |
RADIUS サーバでは、スイッチの IP アドレス、サーバとスイッチで共有される key string、およびダウンロード可能な ACL(DACL)などの設定を行う必要があります。詳細については、RADIUS サーバのマニュアルを参照してください。 |
認証ルールとインターフェイスを設定するには、次の手順を実行します。
| コマンドまたはアクション | 目的 | |
|---|---|---|
| ステップ 1 |
enable 例:
|
特権 EXEC モードをイネーブルにします。
|
| ステップ 2 |
configure terminal 例:
|
グローバル コンフィギュレーション モードを開始します。 |
| ステップ 3 |
ip admission name name proxy http 例:
|
Web ベース許可の認証ルールを設定します。 |
| ステップ 4 |
interface type slot/port 例:
|
インターフェイス コンフィギュレーション モードを開始し、Web ベース認証をイネーブルにする入力レイヤ 2 またはレイヤ 3 インターフェイスを指定します。
|
| ステップ 5 |
ip access-group name 例:
|
デフォルト ACL を適用します。 |
| ステップ 6 |
ip admission name 例:
|
インターフェイスの Web ベース許可の認証ルールを設定します。 |
| ステップ 7 |
exit 例:
|
インターフェイス コンフィギュレーション モードを終了し、グローバル コンフィギュレーション モードに戻ります。 |
| ステップ 8 |
ip device tracking 例:
|
IP デバイス トラッキング テーブルをイネーブルにします。 |
| ステップ 9 |
end 例:
|
グローバル コンフィギュレーション モードを終了し、特権 EXEC モードに戻ります。 |
| ステップ 10 |
show ip admission 例:
|
ネットワークアドミッションのキャッシュエントリと Web 認証セッションに関する情報を表示します。 |
| コマンドまたはアクション | 目的 | |
|---|---|---|
| ステップ 1 |
enable 例:
|
特権 EXEC モードをイネーブルにします。
|
| ステップ 2 |
configure terminal 例:
|
グローバル コンフィギュレーション モードを開始します。 |
| ステップ 3 |
aaa new-model 例:
|
AAA 機能をイネーブルにします。 |
| ステップ 4 |
aaa authentication login default group {tacacs+ | radius} 例:
|
ログイン時の認証方式のリストを定義します。
|
| ステップ 5 |
aaa authorization auth-proxy default group {tacacs+ | radius} 例:
|
Web ベース許可の許可方式リストを作成します。 |
| ステップ 6 |
tacacs-server host {hostname | ip_address} 例:
|
AAA サーバを指定します。 |
| ステップ 7 |
tacacs-server key {key-data} 例:
|
デバイスと TACACS サーバとの間で使用される許可および暗号キーを設定します。 |
| ステップ 8 |
end 例:
|
グローバル コンフィギュレーション モードを終了し、特権 EXEC モードに戻ります。 |
RADIUS サーバのパラメータを設定するには、次の手順を実行します。
| コマンドまたはアクション | 目的 | |
|---|---|---|
| ステップ 1 |
enable 例:
|
特権 EXEC モードをイネーブルにします。
|
| ステップ 2 |
configure terminal 例:
|
グローバル コンフィギュレーション モードを開始します。 |
| ステップ 3 |
ip radius source-interface 例:
|
RADIUS パケットが、指定されたインターフェイスの IP アドレスを含むように指定します。 |
| ステップ 4 |
radius-server host {hostname | ip-address} test username username 例:
|
リモート RADIUS サーバのホスト名または IP アドレスを指定します。
|
| ステップ 5 |
radius-server key string 例:
|
スイッチと、RADIUS サーバで動作する RADIUS デーモン間で使用される認証および暗号キーを設定します。 |
| ステップ 6 |
radius-server dead-criteria tries num-tries 例:
|
RADIUS サーバに送信されたメッセージへの応答がない場合に、このサーバが非アクティブであると見なすまでの送信回数を指定します。指定できる num-tries の範囲は 1 ~ 100 です。 |
| ステップ 7 |
end 例:
|
グローバル コンフィギュレーション モードを終了し、特権 EXEC モードに戻ります。 |
Web ベース認証を使用するには、デバイスで HTTP サーバをイネーブルにする必要があります。このサーバは HTTP または HTTPS のいずれかについてイネーブルにできます。
![]() (注) |
Apple の疑似ブラウザは、ip http secure-server コマンドを設定するだけでは開きません。ip http server コマンドも設定する必要があります。 |
HTTP または HTTPS のいずれかについてサーバをイネーブルにするには、次の手順に従います。
| コマンドまたはアクション | 目的 | |||
|---|---|---|---|---|
| ステップ 1 |
enable 例:
|
特権 EXEC モードをイネーブルにします。
|
||
| ステップ 2 |
configure terminal 例:
|
グローバル コンフィギュレーション モードを開始します。 |
||
| ステップ 3 |
ip http server 例:
|
HTTP サーバをイネーブルにします。Web ベース認証機能は、HTTP サーバを使用してホストと通信し、ユーザ認証を行います。 |
||
| ステップ 4 |
ip http secure-server 例:
|
HTTPS をイネーブルにします。 カスタム認証プロキシ Web ページを設定するか、成功ログインのリダイレクション URL を指定します。
|
||
| ステップ 5 |
end 例:
|
グローバル コンフィギュレーション モードを終了し、特権 EXEC モードに戻ります。 |
Web ベースの認証中に、デバイスのデフォルト HTML ページではなく 4 種類の代わりの HTML ページがユーザに表示されるように、Web 認証を設定できます。
カスタム認証プロキシ Web ページの使用を指定するには、次の手順を実行してください。
デバイスのフラッシュ メモリにカスタム HTML ファイルを保存します。
| コマンドまたはアクション | 目的 | |
|---|---|---|
| ステップ 1 |
enable 例:
|
特権 EXEC モードをイネーブルにします。
|
| ステップ 2 |
configure terminal 例:
|
グローバル コンフィギュレーション モードを開始します。 |
| ステップ 3 |
ip admission proxy http login page file device:login-filename 例:
|
デバイスのメモリ ファイル システム内で、デフォルトのログイン ページの代わりに使用するカスタム HTML ファイルの場所を指定します。device: はフラッシュ メモリです。 |
| ステップ 4 |
ip admission proxy http success page file device:success-filename 例:
|
デフォルトのログイン成功ページの代わりに使用するカスタム HTML ファイルの場所を指定します。 |
| ステップ 5 |
ip admission proxy http failure page file device:fail-filename 例:
|
デフォルトのログイン失敗ページの代わりに使用するカスタム HTML ファイルの場所を指定します。 |
| ステップ 6 |
ip admission proxy http login expired page file device:expired-filename 例:
|
デフォルトのログイン期限切れページの代わりに使用するカスタム HTML ファイルの場所を指定します。 |
| ステップ 7 |
end 例:
|
グローバル コンフィギュレーション モードを終了し、特権 EXEC モードに戻ります。 |
クライアントが待機時間中にウォッチ リストに掲載されるまで許容される失敗ログイン試行の最大回数を設定するには、次の手順を実行します。
| コマンドまたはアクション | 目的 | |
|---|---|---|
| ステップ 1 |
enable 例:
|
特権 EXEC モードをイネーブルにします。
|
| ステップ 2 |
configure terminal 例:
|
グローバル コンフィギュレーション モードを開始します。 |
| ステップ 3 |
ip admission max-login-attempts number 例:
|
失敗ログイン試行の最大回数を設定します。指定できる範囲は 1 ~ 2147483647 回です。デフォルトは 5 分です。 |
| ステップ 4 |
end 例:
|
グローバル コンフィギュレーション モードを終了し、特権 EXEC モードに戻ります。 |
Web 認証が設定されたデバイスでローカルバナーを設定するには、特権 EXEC モードで次の手順を実行します。
| コマンドまたはアクション | 目的 | |
|---|---|---|
| ステップ 1 |
enable 例:
|
特権 EXEC モードをイネーブルにします。
|
| ステップ 2 |
configure terminal 例: |
グローバル コンフィギュレーション モードを開始します。 |
| ステップ 3 |
ip auth-proxy auth-proxy-banner http [banner-text | file-path] 例: |
ローカル バナーをイネーブルにします。 (任意)C banner-text C と入力して、カスタム バナーを作成します。ここで、C は区切り文字、またはバナーに表示されるファイル(例:ロゴ、またはテキスト ファイル)を示すファイル パスです。 |
| ステップ 4 |
end 例: |
グローバル コンフィギュレーション モードを終了し、特権 EXEC モードに戻ります。 |
中央 Web 認証(CWA)とは、Cisco Identity Services Engine(ISE)などのポリシー サーバを使用して Web 認証によりユーザを一元的に認証するプロセスです。Web 認証のための中枢ポリシー サーバがあると、運用面での実装が容易になります。CWA では、ACL ベースの適用も VLAN ベースの適用もサポートされます。また、RADIUS CoA もサポートされます。これにより、プロファイリングに基づくポスチャ アセスメントおよび適用が可能になります。
すべての Catalyst スイッチに関する中央 Web 認証の設定方法の詳細については、ドキュメント『Central Web Authentication with a Switch and Identity Services Engine Configuration Example』を参照してください。
Web ベース認証キャッシュ エントリを削除するには、次の手順を実行します。
| コマンドまたはアクション | 目的 | |
|---|---|---|
| ステップ 1 |
enable 例:
|
特権 EXEC モードをイネーブルにします。
|
| ステップ 2 |
clear ip admission cache {* | host ip address} 例:
|
Delete 認証プロキシ エントリを削除します。キャッシュ エントリすべてを削除するには、アスタリスクを使用します。シングル ホストのエントリを削除するには、具体的な IP アドレスを入力します。 |
すべてのインターフェイスまたは特定のポートに対する Web ベース認証設定を表示するには、このトピックのコマンドを使用します。
|
コマンド |
目的 |
|---|---|
|
show authentication sessions method webauth |
FastEthernet、ギガビットイーサネット、または 10 ギガビットイーサネットのすべてのインターフェイスに対する Web ベース認証設定を表示します。 |
|
show authentication sessions interface type slot/port[details] |
FastEthernet、ギガビットイーサネット、または 10 ギガビットイーサネットの特定のインターフェイスに対する Web ベース認証設定を表示します。 セッション認識型ネットワーク モードでは、show access-session interface コマンドを使用します。 |
すべてのインターフェイス、または特定のポートに対する Web ベースの認証設定を表示する手順は、次のとおりです。
| コマンドまたはアクション | 目的 |
|---|---|
|
show authentication sessions {interfacetype/ slot} 例:
例:
|
Web ベース認証設定を表示します。
|
HTTP 認証プロキシの設定をトラブルシューティングするには、次の手順を実行します。
| コマンドまたはアクション | 目的 | |
|---|---|---|
| ステップ 1 |
enable 例:
|
特権 EXEC モードを有効にします。
|
| ステップ 2 |
debug ip admission all 例:
|
Web ベース認証のすべての IP アドミッションのデバッグ情報を表示します。 |
HTTPS 認証プロキシの設定を確認するには、オプションで次の手順を実行します。
| コマンドまたはアクション | 目的 | |
|---|---|---|
| ステップ 1 |
enable 例:
|
特権 EXEC モードを有効にします。
|
| ステップ 2 |
show ip auth-proxy cache 例:
|
ユーザ認証エントリのリストを表示します。 認証プロキシ キャッシュにより、ホストの IP アドレス、送信元ポート番号、認証プロキシのタイムアウト値、接続の状態が一覧表示されます。認証プロキシの状態が HTTP_ESTAB の場合、ユーザ認証が成功したことを示します。 |
| ステップ 3 |
show ip admission { status | cache } 例:
|
Web 認証セッションのネットワーク アドミッション設定ステータスとキャッシュ エントリを表示します。 |
次の例は、ファスト イーサネット ポート 5/1 で Web ベース認証を有効化する方法を示しています。
Device> enable
Device# configure terminal
Device(config)# ip admission name webauth1 proxy http
Device(config)# interface fastethernet 5/1
Device(config-if)# ip admission webauth1
Device(config-if)# exit
Device(config)# ip device tracking
Device(config)# end
次に、設定を確認する例を示します。
Device# show ip admission
IP admission status:
Enabled interfaces 0
Total sessions 0
Init sessions 0 Max init sessions allowed 100
Limit reached 0 Hi watermark 0
TCP half-open connections 0 Hi watermark 0
TCP new connections 0 Hi watermark 0
TCP half-open + new 0 Hi watermark 0
HTTPD1 Contexts 0 Hi watermark 0
Parameter Map: Global
Custom Pages
Custom pages not configured
Banner
Banner not configured
Device> enable
Device# configure terminal
Device(config)# aaa new-model
Device(config)# aaa authentication login default group tacacs group radius
! Set up the aaa new model to use the authentication proxy.
Device(config)# aaa authorization auth-proxy default group tacacs group radius
! Define the AAA servers used by the device.
Device(config)# aaa accounting auth-proxy default start-stop group tacacs+
! Set up authentication proxy with accounting.
Device(config)# tacacs-server host 172.31.54.143
Device(config)# tacacs-server key cisco
Device(config)# radius-server host 172.31.54.143
Device(config)# radius-server key cisco
Device(config)# end
Device> enable
Device# configure terminal
! Enable the HTTP server on the device.
Device(config)# ip http server
! Set the HTTP server authentication method to AAA.
Device(config)# ip http authentication aaa
! Define standard access list 61 to deny any host.
Device(config)# access-list 61 deny any
! Use ACL 61 to deny connections from any host to the HTTP server.
Device(config)# ip http access-class 61
Device(config)# end
次の例では、カスタム認証プロキシ Web ページを設定する方法を示します。
Device> enable
Device# configure terminal
Device(config)# ip admission proxy http login page file flash:login.htm
Device(config)# ip admission proxy http success page file flash:success.htm
Device(config)# ip admission proxy http fail page file flash:fail.htm
Device(config)# ip admission proxy http login expired page flash flash:expired.htm
Device(config)# end
次の出力には、ホスト IP アドレス、セッション タイムアウト、ポスチャ状態が表示されています。ポスチャ状態が POSTURE ESTAB になっていれば、ホスト検証は成功しています。
Device# show ip admission cache eapoudp
Posture Validation Proxy Cache
Total Sessions: 3 Init Sessions: 1
Client IP 10.0.0.112, timeout 60, posture state POSTURE ESTAB
Client IP 10.0.0.142, timeout 60, posture state POSTURE INIT
Client IP 10.0.0.205, timeout 60, posture state POSTURE ESTAB
Device> enable
Device# configure terminal
Device(config)# ip admission proxy http success redirect www.cisco.com
Device(config)# end
|
関連項目 |
マニュアル タイトル |
|---|---|
|
この章で使用するコマンドの完全な構文および使用方法の詳細。 |
Consolidated Platform Command Reference, Cisco IOS Release 15.2(7)Ex (Catalyst 1000 Switches) |
| 説明 | リンク |
|---|---|
|
シスコのサポート Web サイトでは、シスコの製品やテクノロジーに関するトラブルシューティングにお役立ていただけるように、マニュアルやツールをはじめとする豊富なオンライン リソースを提供しています。 お使いの製品のセキュリティ情報や技術情報を入手するために、Cisco Notification Service(Field Notice からアクセス)、Cisco Technical Services Newsletter、Really Simple Syndication(RSS)フィードなどの各種サービスに加入できます。 シスコのサポート Web サイトのツールにアクセスする際は、Cisco.com のユーザ ID およびパスワードが必要です。 |
次の表に、このモジュールで説明した機能に関するリリース情報を示します。この表は、ソフトウェア リリース トレインで各機能のサポートが導入されたときのソフトウェア リリースだけを示しています。その機能は、特に断りがない限り、それ以降の一連のソフトウェア リリースでもサポートされます。
プラットフォームのサポートおよびシスコ ソフトウェア イメージのサポートに関する情報を検索するには、Cisco Feature Navigator を使用します。Cisco Feature Navigator にアクセスするには、www.cisco.com/go/cfn に移動します。Cisco.com のアカウントは必要ありません。|
機能名 |
リリース |
機能情報 |
|---|---|---|
|
Web ベース認証 |
Cisco IOS リリース 15.2(7)E1 |
この機能が導入されました。 |