セキュリティ : Cisco Identity Services Engine

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

2015 年 11 月 25 日 - 機械翻訳について
その他のバージョン: PDFpdf | 英語版 (2015 年 8 月 22 日) | フィードバック

概要

この資料はワイヤレス LAN コントローラ(WLC)の中央 Web 認証(CWA)を完了するために使用する設定例を記述したものです。

Contributed by Nicolas Darchis, Cisco TAC Engineer.

前提条件

要件

このドキュメントに関する特別な要件はありません。

使用するコンポーネント

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

  • Cisco Identity Services Engine ソフトウェア リリース 1.2

  • Cisco WLC ソフトウェア リリース 7.3.102.0

設定

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

  1. ユーザは、Web 認証 Service Set Identifier(SSID)に関連付けられています。

  2. ユーザはブラウザを開きます。

  3. URL を入力するとすぐに、WLC によってゲストのポータル(ISE または NGS など)にリダイレクトされます。

  4. ポータルで認証します。

  5. 入力されたクレデンシャルを持つ WLC にゲストのポータルによってリダイレクトして戻されます。

  6. WLC は RADIUS を介してゲストのユーザを認証します。

  7. WLC は元の URL にリダイレクトして戻します。

このフローには、複数のリダイレクションが含まれています。 新しいアプローチは CWA を使用することです。 この方法は、ISE(バージョン 1.1 以降)と WLC(バージョン 7.2 以降)で動作します。 フローには、次の手順が含まれます。

  1. ユーザは Web 認証 SSID に関連付けられています。これは、実際には open+macfiltering とレイヤ 3 セキュリティなしの SSID です。

  2. ユーザはブラウザを開きます。

  3. WLC はゲストのポータルにリダイレクトします。

  4. ポータルで認証します。

  5. ISE はコントローラにユーザが有効であることを示すために RADIUS の認可変更(CoA - UDP ポート 1700)を送信し、最後にアクセス コントロール リスト(ACL)などの RADIUS の属性をプッシュします。

  6. ユーザは元の URL の再試行を促されます。

使用する設定は、次のとおりです。

central-web-auth-1.gif

WLC の設定

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

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

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

central-web-auth-02.png

central-web-auth-03.gif

central-web-auth-04.gif

central-web-auth-05.png

central-web-auth-06.gif

最後に、リダイレクト ACL を作成します。 この ACL は ISE の access-accept で参照され、どのトラフィックをリダイレクトする必要があるか(ACL によって拒否)、どのトラフィックをリダイレクトする必要がないか(ACL によって許可)を定義します。 ここでは、ISE に対するリダイレクション トラフィックを回避するだけです。 より具体的には、ポート 8443(ゲスト ポータル)で ISE が送受信するトラフィックのみを回避しますが、ユーザがポート 80/443 で ISE へのアクセスを試みた場合はリダイレクトされます。

: 7.2 か 7.3 のような WLC ソフトウェアの以前のバージョンは DNS を規定 するように要求しませんでしたが、コードバージョンはそのリダイレクト ACL の割り当て DNS トラフィックに必要とします。

central-web-auth-07.png

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. [Redirect] ドロップダウン リストで [Default] を選択します。 (デフォルト以外のカスタム ポータルを使用する場合は、デフォルト以外を選択します)。

central-web-auth-08.png

認証ルールの作成

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

[Policy] メニューで、[Authentication] をクリックします。

次の図は、認証ポリシー ルールを設定する方法の例を示します。 この例では、MAB が検出されたときにトリガーされるルールを設定します。

  • 認証ルールの名前を入力します。 この例では、ISE のバージョン 1.2 ではデフォルトで存在する MAB を使用します。

  • [If condition] フィールドでプラス(+)アイコンを選択します。

  • [Compound condition] を選択し、次に [Wired_MAB OR Wireless_MAB] を選択します。

  • ルールをさらに展開するには [and ...] の横にある矢印をクリックします。

  • [Identity Source] フィールドの [+] アイコンをクリックし、[Internal endpoints] を選択します。

  • [If user not found] ドロップダウン リストから [Continue] を選択します。

central-web-auth-09.png

許可ポリシーの作成

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

  • 1 つ目は、ユーザが SSID に関連付けられて中央 Web 認証のプロファイルが返されるときの認証と認可です(未知の MAC アドレスため、リダイレクションのためにユーザを設定する必要があります)。

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

central-web-auth-10.png

: ISE リリース 1.3 では、Web 認証の種類に依存は、「ゲスト フロー」使用例もう見つからないかもしれません。 承認規則はそれから唯一の可能性のある状態としてゲスト ユーザーグループが含まれていなければなりません。

次のステップを実行し、前の図に示すように認可ルールを作成します。

  1. 新しいルールを作成し、名前を入力します。 この例では Guest Redirection を使用します。

  2. 条件フィールドでプラス([+])アイコンをクリックして、新しい条件を作成します。

  3. [Expression] ドロップダウン リストを展開します。

  4. [Network Access] を選択し、展開します。

  5. [AuthenticationStatus] をクリックし、[Equals] 演算子を選択します。

  6. 右側のフィールドの [UnknownUser] を選択します。

  7. [General Authorization] ページの [then] という単語の右側のフィールドで [WLC_CWA](「許可プロファイル」)を選択します。

    この手順では、ユーザ(または MAC アドレス)が不明な場合でも、ISE が続行されるようにします。

    これで未知ユーザにログイン ページが表示されます。 ただし、クレデンシャルを入力すると、認証および認可ポリシーで設定された内容にもかかわらず、クライアント クレデンシャルが有効であれば認証に成功します。 ISE バージョン 1.1 と 1.2 では、ポータルの認証は認証および認可ルールに従わず、有効な場合は成功します。 したがって、ポータルのログインに成功する場合はアクセスを許可するルールを作成する必要はありません。

  8. Guest Redirection ルールの最後にある [Actions] ボタンをクリックし、このルールの前に新しいルールを挿入することを選択します。

    注: この新しいルールが Guest Redirection ルールの前に位置することは非常に重要です。



  9. 新しいルールの名前を入力します。 この例では Guest Portal Auth を使用します。

  10. 条件フィールドで、プラス([+])アイコンをクリックし、新しい条件の作成を選択します。

  11. [Network Access] を選択し、[UseCase] をクリックします。

  12. 演算子として [Equals] を選択します。

  13. 右オペランドとして [GuestFlow] を選択します。 (この条件の ISE リリース 1.3 に関してこれらのステップの前に、リストされたメモを参照して下さい。)

  14. 認可ページでプラス(+)アイコン([then] の横にある)をクリックし、ルールの結果を選択します。

    [Permit Access] オプションを選択するか、または任意の VLAN または属性を返すためにカスタム プロファイルを作成できます。 [If GuestFlow] の上では、ユーザ グループに基づいてさまざまな認可プロファイルを返すようにさらに条件を追加できます。 ステップ 7 で説明したように、この Guest Portal Auth ルールはポータルのログインに成功した後、およびクライアントを再認証するために ISE が CoA を送信した後に 2 つ目の MAC アドレスと照合されます。 この 2 つ目の認証の違いは、単に ISE の MAC アドレスが ISE に渡されるのではなく、ISE がポータルで提供されたユーザ名を記憶していることです。 この承認規則にゲスト ポータルで前に入る資格情報を少数のミリ秒考慮に入れさせますことができます。

注: 機能をプロファイルしている場合未知 の ユーザ状態が一致する、エンドポイント データベースで自動的に挿入できます有効に されます。 この場合、Wireless_MAB (組み込み条件)要求を一致するより適切です。 コントローラの MAC 認証を使用する場合、特定の許可のためにエンドポイント グループを使用できますまたはゲスト SSID と一致する条件を追加して下さい。

central-web-auth-10a.png

IP リニューアルを有効にする(任意選択)

VLAN を割り当てると、最後のステップは、クライアント PC に対して IP アドレスをリニューアルすることです。 この手順は、Windows クライアント用のゲスト ポータルによって実現されます。 前の手順で 2 つ目の認証ルールのために VLAN を設定していない場合は、この手順をスキップすることができます。

VLAN を割り当てて、IP のリニューアルを有効にするために次の手順を実行してください。

  1. [Administration] をクリックし、[Guest Management] をクリックします。

  2. [Setting] をクリックします。

  3. [Guest] を展開し、次に [Multi-Portal Configuration] を展開します。

  4. [DefaultGuestPortal] または作成したカスタム ポータルの名前をクリックします。

  5. [VLAN DHCP Release] チェックボックスをクリックします。

    : このオプションは、Windows のクライアントでのみ動作します。

Anchor-Foreign のシナリオ

この設定は、WLC の自動アンカーの機能でも使用できます。 唯一の問題点は、この Web 認証方式はレイヤ 2 であるため、すべての RADIUS 作業が外部 WLC で実行されることに注意する必要があります。 外部 WLC のみが ISE と通信し、リダイレクション ACL も外部 WLC 上にある必要があります。

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

: 中央 Web 認証(CWA)を用いる固定外部 セットアップはリリース 7.3 またはそれ以降でだけはたらきます。

: Cisco バグ ID CSCuo56780 が原因で(バージョンで修正が含まれている)、によりプロファイルを IP-to-MAC 結合の潜在的な欠如が不正確な原因になる引き起こすので外部固定の会計を実行。 それはまたゲスト ポータルのためのセッションID で多くの問題を作成します。 会計を設定することを望む場合外部 コントローラでそれを設定して下さい。

確認

ユーザが SSID に関連付けられると、認可が [ISE] ページに表示されます。

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

central-web-auth-11.png

これで、クライアントで任意のアドレスを開くと、ブラウザが ISE にリダイレクトされるようになります。 ドメイン ネーム システム(DNS)が正しく設定されていることを確認します。

central-web-auth-12.png

ユーザがポリシーを受け入れるとネットワーク アクセスが許可されます。

central-web-auth-13.png

central-web-auth-14.png

ISE の例に示すように、適用される認証、認可変更、およびプロファイルは permitAccess です。

central-web-auth-15.gif

前のスクリーンショットは、個々の認証手順を明確に示す ISE バージョン 1.1.x のスクリーンショットです。

次のスクリーンショットは、同じクライアントで実行される複数の認証を ISE が 1 行にまとめた ISE バージョン 1.2 のスクリーンショットです。 実際には後者が実用的ですが、バージョン 1.1.x のスクリーンショットはこの例で厳密に何が起きているのかをわかりやすく表示しています。

central-web-auth-16.png

コントローラでは、ポリシー マネージャの状態と RADIUS NAC の状態が POSTURE_REQD から RUN に変わります。

: リリース 7.3 以降では、この状態は POSTURE_REQD と呼ばれず、CENTRAL_WEBAUTH_REQD と呼ばれるようになりました。

トラブルシューティング

CWA 問題を解決するか、または隔離するためにこれらのステップを完了して下さい:

  1. デバッグ クライアント < コントローラの client> コマンドの MAC アドレスを入力し、クライアントが CENTRAL_WEBAUTH_REQD 状態に達するかどうか判別するために監視して下さい。 よくある問題は WLC に(または入力することはきちんとありません)ない ISE がリダイレクト ACL を戻すとき観察されます。 これが事実である場合、クライアントはプロセスが再度始まります CENTRAL_WEBAUTH_REQD 状態が達すれば deauthenticated。

  2. 正しいクライアント ステートが達することができる場合 > WLC Web GUI のクライアント監視し、正しいリダイレクト ACL および URL がクライアントに適用することを確認するナビゲート。

  3. 正しい DNS が使用されることを確認して下さい。 クライアントはインターネット Webサイトおよび ISE ホスト名を解決する機能があるはずです。 nslookup によってこれを確認できます。

  4. すべての認証ステップが ISE で行われることを確認して下さい:

    • CWA 属性が戻る MAC 認証は最初に行われるはずです。

    • 門脈ログイン認証は行われます。

    • 動的許可は発生します。

    • 最終的な認証は最終的な許可結果が返される ISE の門脈ユーザ名を示す MAC 認証です(最終的な VLAN および ACL のような)。

シナリオを固定するための特別な配慮

モビリティ シナリオの CWA プロセスの効率を制限するこれらの Cisco バグ ID を考慮して下さい(特にとき説明は設定されます):

  • CSCuo56780 - ISE RADIUSサービス サービス拒否の脆弱性

  • CSCul83594 -セッションID はモビリティを渡ってネットワークが開いている場合、同期されません

関連するシスコ サポート コミュニティ ディスカッション

シスコ サポート コミュニティは、どなたでも投稿や回答ができる情報交換スペースです。


Document ID: 115732