はじめに
このドキュメントでは、ISE自己登録型ゲストポータル機能の設定およびトラブルシューティング方法について説明します。
前提条件
要件
ISE 構成の経験と、次のトピックに関する基本的な知識があることが推奨されます。
- ISE の導入およびゲスト フロー
- ワイヤレスLANコントローラ(WLC)の設定
使用するコンポーネント
自己登録型ゲストポータル:ゲストユーザは従業員とともに自己登録し、ADクレデンシャルを使用してネットワークリソースにアクセスできます。このポータルでは、複数の機能を設定およびカスタマイズできます。
このドキュメントの情報は、次のソフトウェアとハードウェアのバージョンに基づいています。
- Microsoft Windows 10 Pro
- バージョン8.5.135.0のCisco WLC 5508
- ISEソフトウェアバージョン3.0
このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されました。このドキュメントで使用するすべてのデバイスは、クリアな(デフォルト)設定で作業を開始しています。本稼働中のネットワークでは、各コマンドによって起こる可能性がある影響を十分確認してください。
トポロジとフロー
このシナリオでは、ゲストユーザが自己登録を実行するときに使用できる複数のオプションを示します。
一般的なフローを次に示します。
ステップ 1:ゲストユーザはService Set Identifier(SSID):Guest-WiFiに関連付けられます。これは、認証に ISE を使用する MAC フィルタリングが設定されたオープン ネットワークです。この認証はISEの2番目の認可ルールと一致し、認可プロファイルはゲストの自己登録ポータルにリダイレクトされます。ISE から、2 つの cisco-av-pairs を使用した RADIUS Access-Accept が返されます。
- url-redirect-acl(どのトラフィックをリダイレクトする必要があるか、およびWLCでローカルに定義されているアクセスコントロールリスト(ACL)の名前)
- url-redirect(そのトラフィックのリダイレクト先 - ISE)
ステップ 2:ゲストユーザはISEにリダイレクトされます。ログインするためのクレデンシャルを入力する代わりに、ユーザはRegister for Guest Accessをクリックします。 ユーザは、そのアカウントを作成できるページにリダイレクトされます。オプションの秘密登録コードを有効にすると、自己登録権限をその秘密値を知っているユーザに制限できます。アカウントが作成されると、ユーザにはクレデンシャル(ユーザ名とパスワード)が提供され、これらのクレデンシャルでログインします。
ステップ 3:ISEがRADIUS認可変更(CoA)再認証をWLCに送信します。WLCは、Authorize-Only属性を使用してRADIUSアクセス要求を送信するときに、ユーザを再認証します。ISEはWLCでローカルに定義されたAccess-AcceptおよびAirespace ACLで応答し、インターネットへのアクセスのみを提供します(ゲストユーザの最終的なアクセスは認可ポリシーによって異なります)。
注:EAPセッションはサプリカントとISEの間で行われるため、再認証をトリガーするにはISEがCoA Terminateを送信する必要があります。ただし、MAB(MACフィルタリング)の場合は、CoA再認証で十分です。ワイヤレスクライアントの関連付け/認証解除は必要ありません。
ステップ 4:ゲストユーザがネットワークへの望ましいアクセス権を持っている。
ポスチャや個人所有デバイス持ち込み(BYOD)など、複数の追加機能を有効にできます(後述)。
設定
WLC
- 認証とアカウンティングのために新しい RADIUS サーバを追加します。RADIUS CoA(RFC 3576)を有効にするため、[Security] > [AAA] > [Radius] > [Authentication] に移動します。
アカウンティングでも同様の設定があります。また、[Called Station ID] 属性で SSID を送信するように WLC を設定することが推奨されます。これにより、ISE は SSID に基づいて柔軟なルールを設定できます。
- WLANsタブで、ワイヤレスLAN(WLAN)Guest-WiFiを作成し、正しいインターフェイスを設定します。MAC フィルタリングで Layer2 セキュリティを [None] に設定します。Security/Authentication, Authorization, and Accounting(AAA)Serversで、認証とアカウンティングの両方にISE IPアドレスを選択します。Advancedタブで、AAA Overrideを有効にし、Network Admission Control(NAC)StateをISE NAC(CoA support)に設定します。
- [Security] > [Access Control Lists] > [Access Control Lists] の順に移動し、2 つのアクセス リストを作成します。
- GuestRedirect:リダイレクトしてはならないトラフィックを許可し、他のすべてのトラフィックをリダイレクトします。
- Internet:社内ネットワークについては拒否され、その他のすべてのネットワークについては許可されます。
GuestRedirect ACLの例を次に示します(ISEとの間のトラフィックをリダイレクトから除外する必要があります)。
ISE
- Work Centers > Guest Access > Network Devicesの順に選択し、WLCをネットワークアクセスデバイスとして追加します。
- エンドポイントIDグループを作成します。Work Centers > Guest Access > Identity Groups > Endpoint Identity Groupsの順に移動します。
3. 「ワーク・センター」>「ゲスト・アクセス」>「ポータルとコンポーネント」>「ゲスト・タイプ」に移動して、ゲスト・タイプを作成します。この新しいゲストタイプで以前作成したエンドポイントIDグループを参照して保存します。
4.新しいゲストポータルタイプとしてSelf-Registered Guest Portalを作成します。Work Centers > Guest Access > Guest Portalsに移動します。
5.ポータル名を選択し、前に作成したゲストタイプを参照し、登録フォーム設定の下でクレデンシャル通知設定を送信して、クレデンシャルを電子メールで送信します。
ISEでSMTPサーバを設定する方法については、次のドキュメントを参照してください。
https://www.cisco.com/c/en/us/support/docs/security/identity-services-engine/216187-configure-secure-smtp-server-on-ise.html
その他の設定はすべてデフォルトのままにします。ポータルページのカスタマイズでは、表示されるすべてのページをカスタマイズできます。デフォルトでは、Guestアカウントは1日間有効で、特定のGuest Typeで設定された日数まで延長できます。
6. Work Centers > Guest Access > Policy Elements > Results > Authorization Profilesの順に移動して、これら2つの認可プロファイルを設定します。
- ゲストポータル(ゲストポータルCisco_Guestへのリダイレクト、およびGuestRedirectという名前のリダイレクトACLを使用)このGuestRedirect ACLは、WLCで以前に作成されました。
- Permit_Internet(Airespace ACLとInternetは同じ)
7. Defaultという名前のポリシーセットを変更します。デフォルトのポリシーセットは、ゲストポータルアクセス用に事前に設定されています。MABという名前の認証ポリシーが存在します。このポリシーにより、MAC認証バイパス(MAB)認証を未知のMACアドレスに対して継続(拒否ではなく)できます。
8.同じページでAuthorization policyに移動します。次の図に示すように、この認可ルールを作成します。
ゲストSSIDに関連付けられた新しいユーザは、まだIDグループに属していないため、2番目のルールに一致し、ゲストポータルにリダイレクトされます。
ユーザが正常にログインした後、ISEがRADIUS CoAを送信し、WLCが再認証を実行します。今回は、最初の認可ルールが照合され(エンドポイントが定義済みのエンドポイントアイデンティティグループの一部になるため)、ユーザはPermit_internet認可プロファイルを取得します。
9.また、条件ゲストフローを使用して、ゲストへの一時的なアクセスを提供することもできます。この条件はISE上のアクティブセッションをチェックしており、属性が設定されています。そのセッションに、以前にゲストユーザが正常に認証されたことを示す属性がある場合は、条件が一致します。ISEがNetwork Access Device(NAD)からRadius Accounting Stopメッセージを受信すると、セッションは終了し、後で削除されます。その段階で、Network Access:UseCase = Guest Flowの条件が満たされなくなっています。その結果、そのエンドポイントに対する後続のすべての認証が、ゲスト認証のためにリダイレクトされる一般的なルールにヒットします。
注:一時ゲストアクセスまたは固定ゲストアクセスのいずれかを使用できますが、両方は使用できません。
ISEゲストの一時的および永続的なアクセスの設定の詳細については、このドキュメントを参照してください。
https://www.cisco.com/c/en/us/support/docs/security/identity-services-engine/200273-Configure-ISE-Guest-Temporary-and-Perman.html
確認
ここでは、設定が正常に機能しているかどうかを確認します。
- ゲストSSIDと関連付けてURLを入力すると、図に示すように、ゲストポータルページにリダイレクトされます。
- まだクレデンシャルを持っていないため、Register for Guest accessオプションを選択する必要があります。アカウントを作成するための登録フォームが表示されます。ゲストポータル設定でRegistration Codeオプションが有効になっている場合は、このシークレット値が必要です(これにより、正しい権限を持つユーザだけが自己登録を許可されるようになります)。
3.パスワードまたはユーザポリシーに問題がある場合は、[Work Centers] > [Guest Access] > [Settings] > [Guest Username Policy] に移動して設定を変更します。ランダム データの例は次のとおりです。
4.アカウントが正常に作成されると、クレデンシャル(ゲストパスワードポリシーに従って生成されたパスワード)が表示されます。また、ゲストユーザが設定されている場合は、電子メール通知が受信されます。
5. Sign Onをクリックして、クレデンシャルを入力します(ゲストポータルで設定する場合は、アクセスパスコードを追加する必要があります。これは、パスワードを知っている人だけがログインできるようにする別のセキュリティメカニズムです)。
6.成功すると、オプションのアクセプタブルユースポリシー(AUP)を表示できます(ゲストポータルで設定されている場合)。ユーザにはパスワードの変更オプションが表示され、ログイン後のバナー(ゲストポータルでも設定可能)も表示されます。
7.最後のページ(ログイン後のバナー)で、アクセスが許可されたことを確認します。
トラブルシュート
ここでは、設定のトラブルシューティングに使用できる情報を示します。
この段階で、ISEは図に示すように、Operations > RADIUS > Live Logsの下にこれらのログを表示します。
ここで、フローを示します。
- ゲストユーザは2番目の許可ルール(Wifi_Redirect_to_Guest_Portal)に遭遇し、ゲストポータルにリダイレクトされます(認証に成功しました)。
- ゲストは自己登録のためにリダイレクトされます。(新しく作成されたアカウントで)ログインに成功すると、ISEはCoA再認証を送信し、WLCによって確認されます(Dynamic Authorization succeeded)。
- WLCはAuthorize-Only属性で再認証を実行し、ACL名が返されます(Authorize-Only succeeded)。ゲストには、正しいネットワークアクセスが提供されます。
レポート(「操作」>「レポート」>「ゲスト」>「マスター・ゲスト・レポート」)では、次の確認も行います。
スポンサーユーザ(正しい権限を持つ)は、ゲストユーザの現在のステータスを確認できます。
この例では、アカウントが作成され、ユーザがポータルにログインしたことを確認します。
オプションの設定
このフローの各段階で、異なるオプションを設定できます。これらはすべて、ゲストポータルごとにWork Centers > Guest Access > Portals & Components > Guest Portals > Portal Name > Edit > Portal Behavior and Flow Settingsで設定します。さらに重要な設定は次のとおりです。
自己登録設定
- Guest Type(ゲストタイプ):アカウントがアクティブである期間、パスワードの有効期限オプション、ログオン時間、およびオプション(時間プロファイルとゲストロールが混在)について説明します。
- 登録コード:有効にすると、シークレットコードを知っているユーザだけが自己登録を許可されます(アカウントの作成時にパスワードを入力する必要があります)。
- AUP:自己登録時に使用ポリシーを受け入れる
- スポンサーがゲストアカウントを承認またはアクティブ化するための要件。
ログインゲストの設定
- アクセスコード:有効にすると、シークレットコードを知っているゲストユーザだけがログインを許可されます。
- AUP:自己登録時に使用ポリシーを受け入れます。
- パスワード変更オプション。
デバイス登録の設定
ゲストデバイスのコンプライアンス設定
BYODの設定
- ポータルをゲストとして使用する企業ユーザが個人デバイスを登録できるようにします。
スポンサー承認アカウント
Registration Form SettingsでRequire guests to be approvedオプションが選択されている場合、ゲストによって作成されたアカウントはスポンサーによって承認される必要があります。この機能では、電子メールを使用してスポンサーに通知を送信できます(ゲストアカウントの承認のため)。
Simple Mail Transfer Protocol(SMTP)サーバの設定に誤りがある場合、アカウントは作成されません。
guest.logからのログは、SMTPサーバの設定が誤っているためにスポンサー電子メールに承認通知を送信する際に問題が発生していることを示しています。
2020-11-07 07:16:38,547 ERROR [GUEST_ACCESS_SMTP_RETRY_THREAD][] cpm.guestaccess.apiservices.util.SmtpMsgRetryThreadUtil -::- An exception occurred while sending email :
javax.mail.MessagingException: Could not connect to SMTP host: outbound.cicso.com, port: 25, response: 421
2020-11-07 07:16:38,547 ERROR [https-jsse-nio-10.106.32.25-8443-exec-1][] cpm.guestaccess.apiservices.notification.NotificationService -::- sendApprovalNotification
com.cisco.cpm.guestaccess.exception.GuestAccessSystemException: com.cisco.cpm.guestaccess.exception.GuestAccessSystemException: Unable to send mail. Failure occured
電子メールとSMTPサーバを適切に設定すると、アカウントが作成されます。
Require guests to be approvedオプションを有効にすると、ユーザ名フィールドとパスワードフィールドがInclude this information on the Self-Registration Success pageセクションから自動的に削除されます。このため、スポンサーの承認が必要な場合、アカウントが作成されたことを示す情報を表示するWebページには、ゲストユーザのクレデンシャルがデフォルトでは表示されません。代わりに、ショートメッセージサービス(SMS)または電子メールで配信する必要があります。このオプションは、Send credential notification upon approval usingセクション(mark email/SMS)で有効にする必要があります。
スポンサーに通知メールが送信されます。
スポンサーが承認リンクをクリックし、スポンサーポータルにログインすると、アカウントが承認されます。
この時点から、ゲストユーザはログインを許可されます(電子メールまたはSMSで受信したクレデンシャルを使用)。
要約すると、このフローでは3つの電子メールアドレスが使用されます。
- 通知の「送信元」アドレス。これは静的に定義されるか、またはスポンサーアカウントから取得され、スポンサーへの通知(承認のため)とゲストへのクレデンシャルの詳細の両方の送信元アドレスとして使用されます。これは、Work Centers > Guest Access > Settings > Guest Email Settingsで設定します。
- 通知の「宛先」アドレス。これは、スポンサーに承認のアカウントを受信したことを通知するために使用されます。これは、ゲストポータルでWork Centers > Guest Access > Guest Portals > Portals and Components > Portal Name > Registeration Form Settings > Require guests to be approved > Email approval request toの順に選択することで設定されます。
- ゲストの「宛先」アドレス。これは、登録時にゲストユーザによって提供されます。Send credential notification upon approval using Emailが選択されている場合、クレデンシャルの詳細(ユーザ名とパスワード)が記載された電子メールがゲストに配信されます。
SMS経由で資格情報を配信する
ゲストクレデンシャルはSMSでも配信できます。次のオプションを設定する必要があります。
- Registration Form SettingsでSMSサービスプロバイダーを選択します。
- Send credential notification upon approval using: SMSチェックボックスにチェックマークを付けます。
- 次に、ゲストユーザがアカウントを作成するときに、使用可能なプロバイダーを選択するように求められます。
- 選択したプロバイダーと電話番号を含むSMSが配信されます。
- SMSプロバイダーは、Administration > System > Settings > SMS Gatewayで設定できます。
デバイスの登録
ゲストユーザがログインしてAUPを受け入れた後で、Allow guests to register devicesオプションを選択すると、デバイスを登録できます。
デバイスがすでに自動的に追加されている([デバイスの管理]リストに表示されている)ことに注目してください。これは、「ゲストデバイスを自動的に登録」が選択されているためです。
ポスチャ
Require guest device complianceオプションが選択されている場合、ゲストユーザは、ログインしてAUPを受け入れた(およびオプションでデバイス登録を実行した)後にポスチャ(NAC/Web Agent)を実行するエージェントでプロビジョニングされます。ISEはクライアントプロビジョニングルールを処理して、プロビジョニングする必要があるエージェントを決定します。次に、ステーションで実行されているエージェントが(ポスチャルールに従って)ポスチャを実行し、結果をISEに送信します。ISEは必要に応じてCoA再認証を送信し、認証ステータスを変更します。
許可ルールは次のようになります。
Guest_Authenticateルールが発生した最初の新規ユーザは、自己登録ゲストポータルにリダイレクトされます。ユーザが自己登録してログインすると、CoAは認証ステータスを変更し、ユーザにはポスチャと修復を実行するための制限付きアクセスが提供されます。NACエージェントがプロビジョニングされ、ステーションが準拠した後にのみ、CoAはインターネットへのアクセスを提供するために認可ステータスを再度変更します。
ポスチャの一般的な問題には、正しいクライアントプロビジョニングルールがないことが含まれます。
これは、guest.logファイルを調べる場合にも確認できます。
2020-11-09 09:23:32,157 ERROR [https-jsse-nio-10.106.32.25-8443-exec-7][] guestaccess.flowmanager.step.guest.ClientProvStepExecutor -:guest18:- CP Response is not successful, status=NO_POLICY
BYOD
Allow employees to use personal devices on the networkオプションが選択されている場合、このポータルを使用する企業ユーザはBYODフローを通過して個人デバイスを登録できます。ゲストユーザの場合、この設定は何も変更しません。
「ゲストとしてポータルを使用する従業員」とはどういう意味ですか。
デフォルトでは、ゲストポータルはGuest_Portal_Sequence IDストアで設定されます。
これは、最初に(ゲストユーザの前に)内部ユーザを試行し、次にADクレデンシャルを試行する内部ストアシーケンスです。選択したIDストアに認証アクセスできない場合、詳細設定はシーケンス内の次のストアに進むことであるため、内部クレデンシャルまたはADクレデンシャルを持つ従業員はポータルにログインできます。
ゲストポータルのこの段階では、ユーザは内部ユーザストアまたはActive Directoryで定義されたクレデンシャルを提供し、BYODリダイレクションが発生します。
このように、企業ユーザは個人所有デバイスに対してBYODを実行できます。
内部ユーザ/ADクレデンシャルの代わりにゲストユーザのクレデンシャルが提供されると、通常のフローが継続されます(BYODなし)。
VLANの変更
これにより、DHCPの解放と更新をトリガーするactiveXまたはJavaアプレットを実行できます。これは、CoAがエンドポイントのVLANの変更をトリガーする場合に必要です。MABが使用されている場合、エンドポイントはVLANの変更を認識しません。考えられる解決策は、NACエージェントでVLAN(DHCPリリース/更新)を変更することです。別のオプションとして、Webページに返されたアプレットを使用して新しいIPアドレスを要求する方法もあります。リリース/CoA/更新間の遅延を設定できます。このオプションは、モバイルデバイスではサポートされていません。
関連情報